WINDOWPATH environment variable?

[Carsten Haitzler (The Rasterman)]

On Mon, 5 Dec 2005 18:04:45 +0100 Samuel Thibault
<samuel.thibault at ens-lyon.org> babbled:

> Carsten Haitzler, le Mon 05 Dec 2005 23:34:07 +0900, a $(D+1(Bcrit :
> > i guess to some extent the environment variable thing is nice -
> > but something says there is something bad about it to me - maybe
> > needing to add something to add it to the envirnment of every login
> > session....
> 
> Well, it is similar to setting the DISPLAY environment variable.
> 
> > > > also we have a problem of remote apps being able to display on the
> > > > local braille terminal as well.
> > > 
> > > The X server relaying module would set its own braille server and define
> > > some environment variable for applications to connect to it instead of
> > > the "root" braille server. Then ssh can forward connections to that port
> > > and the WINDOWID variable.
> > 
> > ouch this feels a little painful.
> 
> No so much for the user: the relaying braille server and environment
> variable would be automatically set by Xorg, WINDOWPATH and WINDOWID
> could be propagated by ssh by default (just like LANG/LC_*), the user
> would only need to remember forwarding ports.
> 
> > somehow i'm wondering if perhaps a new x output device would perhaps
> > be cleanest?
> 
> The problem is that we want to handle text applications too, which have
> nothing to do with X, so a non-X braille server is needed here.
> 
> 
> There's an additionnal thing which may be useful to build some day:
> add ttys some features for letting applications get access to special
> services.
> 
> The problem with the usual tty design is that there is only one i/o
> channel, connected to the application's stdin/stdout/stderr by default.
> What could be handy is to have a standard way for applications to
> "connect" to some services if available (braille output, gpm, or even
> X, etc.).  This could just be an ioctl performed on the fd of the tty,
> which would return an fd of a socket connected to the service.  It could
> for instance be implemented thanks to the STREAM I_SENDFD / RECVFD
> ioctls.  Xterms would of course need to be modified so as to handle this
> ; ssh could be extended for automatically relaying this ; screen could
> be extended too and handle multiplexing/detaching.

well if x provided a braille output device, then xterm can use it. as a naieve
"catch all" xterm can just display all new text  to the braille term. that way
non-braille-aware apps will work in terms of basic display (ncurses wont - but
simple question/answer stuff will work nicely). xdterm then CAN provide the
ability to do whatyou say above and relay it to the x braille device - then if
its xnest - it relayes it to the parent xserver braille output device etc. etc.
exactly the way all current display is done for non-braille output. identical
design - consistent... but a bit more work for sure.

> Another option may be to define new tty escape sequences, just like
> xterm did for mouse events, but it becomes hairy to get data coming from
> stdin demultiplexed correctly in applications.  Having a separate fd
> lets services handle i/o by their own.

i can see usefulness there - but i think even just handling basic text streams
on stdout/strderr would be a nice fallback.

> Regards,
> Samuel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
$BMg9%B?(B
Tokyo, Japan ($BEl5~(B $BF|K\(B)