Re: lynx-dev lynx and ncurses and gpm

[dickey]

>  -- 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)
  
>  -- Question 2: 
>     Are there any known applications running successfully with gpm 
>     mouse support *only* via ncurses (no direct calls to libgpm functions 
>     from the application)? 

just a few, I believe - most character-cell applications that use mouse only
use one button.  so it's not been a big issue til now (though known).

lynx, of course can use all 3 buttons (and come to think of it, lynx users
are more likely to want to use the console because of the setfont code).
  
>             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.
  
>  -- 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.
  
>  -- 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).

>  ------------------- 
>  
> 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

(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.
  
>    (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?).

> 3. Yep, the ABI has changed (just confirming...). 

ah.  This is something that'll be an FAQ.  The last major change I made
to the beta does change one of the structures, making the tables it defines
extensible (that changes some fixed-length arrays to pointers).  The
extension itself is normally not configured in (technically it's experimental),
but the struct changes were needed to make the extension transparent to
applications which would be linked against it.

Recompiling the application will fix this.

There was more than one change that affected the ABI; we decided to make
this additional change to take advantage of this.

(otoh, I expect to continue seeing people in the newsgroups advising other
people to symlink ncurses 3.0 to 4.2 to 5.0, etc).

>    apparently the lynx code here accesses internal ncurses structures 
>    directly which have changed (this may be sensitive to smaller library 
>    upgrades that are *not* reflected in changing the library's soname). 
>    Maybe it would be safer if lynx didn't do this... 

There's no function-interface that covers the structure - I expect there
will be some applications that use the structure, but not many.
  
> 4. Regarding the ^Z problems discussed a while ago: 
>    The obvious ones, which I was observing all the time with the previous 
>    libncurses 4.2, don't occur any more with the new version, but I 
>    haven't checked yet in detail. 

I have a hunch that your fixes from January have covered most of the problems
in this area.
  
>  Klaus 
>  
> 


-- 
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey