Re: lynx-dev lynx and ncurses and gpm

[Klaus Weide]

On Sat, 17 Apr 1999 address@hidden wrote:
[kw:]
> >  -- Question 1: 
> >     Is this common for all Linux distributions?  Are thare any Linux 
> >     distributions with an ncurses package that has gpm support enabled? 
> 
> I don't think there are (it's not a technical issue though)

Probably because ncurses is a very basic package, it shouldn't depend
on many other packages.  It would have to depend on a gpm package unless
gpm code was statically linked in.

> >             gpm_connect.eventMask = GPM_DOWN|GPM_UP; 
> >             gpm_connect.defaultMask = ~(gpm_connect.eventMask|GPM_HARD); 
> >             gpm_connect.minMod = 0; 
> >             gpm_connect.maxMod = 
> > ~((1<<KG_SHIFT)|(1<<KG_SHIFTL)|(1<<KG_SHIFTR)); 
> >  
> > recompiled ncurses, and got a lynx with mouse support under gpm that  
> > works.  At least brief testing didn't shown problems that were specific 
> > to the gpm environment, only those that are also there in an xterm. 
> 
> I'll try this out today - the only caveats I can think of offhand are
> whether the KG_ macros are defined in all versions of Linux.  But I can
> certainly make this configuration available somehow.

I looked more into why the defaultMask change is necessary; the gpm (1.17.6)
server side do_client() function has some strange logic.  (event->type
is filtered through GPM_BARE_EVENTS for comparison with eventMask but not
for comparison with eventMask).  Actually the defaultMask set by ncurses
should probably be

          gpm_connect.defaultMask = GPM_BARE_EVENTS(~gpm_connect.eventMask);

instead of the above, otherwise the test in gpm's do_client() will
give wrong results becuae of the additionl non-bare bits. (this is untested)

About KG_SHIFT, it is used in the gpm code itself (and it is gotten the
same way, by including linux/keyboard.h, without fallback definitions).
I guess that means it's available on all linux versions where gpm can be
used.  I don't know about KG_SHIFTL and KG_SHIFTR though, didn't see them
used.

> >  -- Question 3: 
> >     Tom, could these changes be incorporated into ncurses? 
> >     (If there are no apllication for which the previous behavior was 
> >     right, as I suspect, this should go into the to-be-released-soon 
> >     ncurses.) 
> 
> Possibly - I'm only making bug-fix changes to the beta right now.
> If it looks like a low-impact change, I can add it.

At least the defaultMask change should be regarded as a bug fix, or
a necessary workaround for a bug in gpm.

> >  -- Question 4: 
> >     How are the chances of getting this kind of increased flexibility 
> >     into the ncurses distribution? 
> >     (Also, are there significant security issues with allowing 
> >     control by an env variable? - Note it can hardly be worse than 
> >     what there is currently.)
> 
> That's something that I'll have to think about (I would suppose that going
> the other way - to force paste-behavior - would be less secure).

The less bits set in defaultMask, the less chance/risk for fallback to
pasting.  In that sence taking bits out is a security improvement...

> >  ------------------- 
> >  
> > Various other remarks steeming from recompiling-ncurses experience: 
> >  
> > 1. I added another model to the ncurses configuration, to get shared libs 
> >    with debugging: they will be generated after  
> >        ./configure --with-debugshared 
> >    as lib*_g.so[.M[.N]] (in case of linux, at least).  The changes are 
> >    mostly straightforward, just a combination of --with-shared and 
> >    --with-debug settings.  Tom, are you interested in patches? 
> I do this by
>       CFLAGS=-g configure --with-shared

Yes, that looks much simpler. :)

> (I'm not entirely happy with the multiple models, but they work)
>   
> > 2. What is --with-install-prefix supposed to do, and is it implemented 
> >    correctly by configure? 
> >    I used it as 
> >         ./configure  --prefix=/usr/local --exec-prefix=/usr/local \ 
> >         --with-install-prefix=/usr/local/stow/ncurses-5.0-beta1-990403 ... 
> >  
> >    and assumed that compiled-in paths would be configured to reference 
> >    locations (for terminfo directory etc.) under /usr/local/, but 
> >    actual installation on 'make install' would take place under 
> >    the longer path (for example, terminfo files under 
> >    /usr/local/stow/ncurses-5.0-beta1-990403/share/terminfo). 
> >    But what I found was that actual installation actually takes place 
> >    under /usr/local/stow/ncurses-5.0-beta1-990403/usr/local/, 
> >                                                  ^^^^^^^^^^ 
> >    is that as intended?  It seems rather useless. 
> 
> yes - it's so someone can build and install under the install-prefix,
> then tar that tree up and plop it down on user's machines under the
> regular prefix.

Ok, thanks.

> >    (I am playing around with the GNU "stow" program, which assumes 
> >    packages that are supposed to appear under /usr/local are actuall 
> >    installed under /usr/local/stow/<packagename> and then maps all 
> >    files into their expected locations as symlinks.) 
> 
> some of the paths in ncurses are compiled-in (does stow edit binary files?).

No, it just creates (or removes) symlinks, and possible creates/removes
directories under /usr/local as necessary.

But I didn't find any compiled-in paths that were wrong (they seem to
use --prefix/--exec-prefix/etc. as theu should, not the install-prefix).
I got the install into the desired 'real' place by making first a bogus
    /usr/local/stow/ncurses-5.0-beta1-990403/usr/local -> ..
symlink.


    Klaus