screen-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [screen-devel] Getting started contributing to Screen


From: Micah Cowan
Subject: Re: [screen-devel] Getting started contributing to Screen
Date: Fri, 03 Oct 2008 10:02:53 -0700
User-agent: Thunderbird 2.0.0.16 (X11/20080707)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matt Saunders wrote:
> Hi there
> 
> I'm a longtime screen user, and I'd like to start contributing to the
> project, primarily because I'd really like to see bug #23637,
> "mouse-clicks in hardstatus" resolved, and I suspect that doing it
> myself might be the quickest way to make that happen.

Welcome! Development help is _very_ much appreciated.

Note, though, that #23637 (which was my submission) is a low-priority
feature, and even if it's implemented, I probably wouldn't place it in
the next release, out of concern that it could impede our current
efforts toward a stable release. A fix would probably go in for the next
major release, though, so by all means work on it.

Note that I'm trying to move (slowly) towards the use of scripting for
hardstatus and caption stuff, rather than our current inflexible
escaping system, so it might make some sense to wait on implementing
mouse support until we see what the future of those features will be
like. That being said, there's nothing particularly wrong with
supporting it in the current mechanisms.

If you don't mind offering help on other fronts, there are plenty of
other things that need doing before screen can release as well, and
development resources have become _extremely_ limited, as I've lately
had no time to work on Wget (my first priority), let alone Screen, and
Sadrul's school year has drastically reduced the time he's had for his
prolific development efforts. Most of the remaining bugs targeted at
4.1.0 really aren't that difficult, excepting the documentation issues
which have already been spoken for.

> So what I'd like, if possible, is some pointers to getting started with
> screen, any docs or articles etc.  Obviously I'm reading the source, but
> any 'getting started' docs would give me a boost and make the pretty
> tiny amount of time I have available for this, more productive.

Well, the sources now include a basic HACKING file:

http://git.savannah.gnu.org/gitweb/?p=screen.git;a=blob;f=src/HACKING;h=3d41cf4dd210ce8d66e71ff9fe145d31e216b035;hb=HEAD

It is _very_ basic, and I strongly encourage additions. It's a short
list of things to know, that I felt would've simplified reading the
sources when I first started browsing them.

> Also, if there's anything specific that people could comment on with
> regard to the feasibility of the feature request, or specific places to
> look in the code for mouse support etc, I'd really appreciate that.

Currently, mouse support is activated when the XT termcap feature is
advertised. It's a screen extension, and not a standard termcap feature,
so in practice no one advertises it. Screen automatically triggers that
feature when $TERM begins with "xterm" or "rxvt" (but, strangely, not
"screen"). Screen _ought_ to use the kM termcap feature, which _is_
standard, and which ncurses uses for this purpose.
https://savannah.gnu.org/bugs/?24075

Mouse support is enabled via special escape sequences ("\E[?100Xh",
where X is [0-3]), which is picked up in ansi.c's DoCSI, and results in
a call to LMouseMode. For displays in which mouse mode is active, the
mouse tracking sequences are picked up in disp_readev_fn (in the block
starting with "if (D_mouse && D_forecv)", which merely translates the
coordinates in-stream from the display coordinates to layer (region)
coordinates, or ignores them if they're outside the current layer.

Adding mouse support for switching windows in the hardstatus and/or
caption would mean detecting when we've clicked the hardstatus or
caption there. When the window list is generated for hardstatus or
caption, column start/end positions would need to be tracked and saved
for the layer (caption) or display (hardstatus).

> expect to have to work up to this goal from some simpler areas, so any
> suggestions for a simpler feature request or bug to look at first would
> be great.

Again, the bugs that aren't assigned to anyone else and are targeted for
4.1.0 are excellent candidates; see the links at
http://aperiodic.net/screen/bugtracker

- --
HTH,
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
GNU Maintainer: wget, screen, teseq
http://micah.cowan.name/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI5lA97M8hyUobTrERAkhRAJwIApaw0txMB7IQIpBr46wndCc2MwCfUrif
IM/h5qCMlx4S67fuQ+m7lSE=
=F8/B
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]