Re: Some comments about the commits

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

 



* Nico Schottelius <nico-gpm@xxxxxxxxxxxxxxx> schrieb:

> > "A hacker's guide to ncurses internals" and terminfo(5) imply
> > that kmous is just a fake function key name --- it being set does
> > not imply that the terminal has xterm-style mouse support, although
> > it not being set probably implies the terminal is either old or
> > does not support xterm-style mouse reporting. As a reliable way
> > to check for a terminal with mouse reporting, kmous seems to be
> > useless.
> 
> That's why it's named curses ;-)

*rofl*

> > Using kmous as an indicator anyway, we find that screen, rxvt,
> > Eterm, xterm, putty, konsole, kterm, gnome-terminal, and some
> > other terminals besides support xterm-style mouse reporting.
> > Checking TERM is just not going to detect them all.
> 
> That's true, using $TERM would result in a possible long and
> almost always incomplete list.

hmm, better than nothing ;-)

BTW: are the mouse codes standardized somehow ? Maybe an auto-
detection on them could do the trick ?

> Perhaps a better way to detect xterm-mouse-support is
> via checking if $DISPLAY is set?

No, because:

a) an X display does not imply an xterm
b) missing $DISPLAY does not imply no-xterm

These mouse events are purely terminal issue and don't have 
*anything* to do with X. There could even be an modified telnet
or SSH client which routes local mouse to the remote side.
(oh, wouldn't that be wonderful ? ;-))

Well, the connection between (n)curses and gpm is an, aeehm,
*very delicate* one (in one word: crap). Libgpm and gpmd should
NOT have anything to do with (n)curses - instead (n)curses 
(more precisely: it's input handling) should to feed in mouse 
events into libgpm's queue.

*That* would be a clean design ;-P

> > In the long term, I think it would make sense to have some
> > terminfo capability representing "This terminal supports
> > xterm-style mouse reporting" so that at least rxvt etc would
> > work out of the box. But others have probably thought more
> > about this than I have, so I won't say any more about that.
> 
> Perhaps we should contact the authors of urxvt, perhaps they have
> some sane ideas.

IMHO, the termcap and/or ncurses folks are the right address.

> In general, which way we will go - I would like to implement new style
> xterm handling only in the gpm-2-* branches to not break things in gpm-1.

Actually, I wouldn't do anything on that front. If there should be
an generic xterm-mouse decoder for libgpm-based apps, this IMHO 
belongs into it's own lib.

> > Being without a mouse for a short time is not really a tragedy.
> > Arguably, the correct fix would be for the distributors' packaging
> > scripts to appropriately update the configuration file for the
> > initscript or notify the user. Backwards-compatibility shims like
> > this are not necessary. It is up to you whether you think they
> > are desirable.
> 
> I do not think backwards-compatibility is really needed, as it takes
> only a few minutes to resolve that issue in the distribution.

ACK.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
_______________________________________________
gpm mailing list
gpm@xxxxxxxxxxxxxx
http://lists.linux.it/listinfo/gpm

[Index of Archives]     [Kernel Development]     [Red Hat Install]     [Red Hat Watch]     [Red Hat Development]     [Gimp]     [Yosemite News]