* 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