WINDOWPATH environment variable?

[Carsten Haitzler (The Rasterman)]

On Tue, 6 Dec 2005 10:44:10 +0100 Samuel Thibault
<samuel.thibault at ens-lyon.org> babbled:

> Carsten Haitzler, le Tue 06 Dec 2005 09:57:18 +0900, a $(D+1(Bcrit :
> > On Mon, 5 Dec 2005 18:04:45 +0100 Samuel Thibault
> > <samuel.thibault at ens-lyon.org> babbled:
> > 
> > > 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.
> > [...]
> > 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.
> 
> Yes, that's why it would be a good solution for the long run, but on the
> short term WINDOWPATH would be quite handy for getting similar result
> with much less pain.

well if that is what you need it is as simple as setting it before the
wm/session manager/desktop startup starts and everything will inherit it. it
doesnt have to invovle x, wm authors, etc. etc. :)

> > 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).
> 
> For this, we have a daemon running in the X session that peeks tty text
> thanks to at-spi and let the user read it appropriately (just like the
> linux text console, actually)

hmmm - hacking xterm sounds maybe better - but i guess it does work this way. :)

> > > 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.
> 
> Mmm, indeed. But this would prevent a lot of features: the application
> not knowing the size of the braille display, not getting braille
> keypresses, etc.

good point - though xterm could handle that - by limiting output of 1 line (or
how ever much the braile term can display) and then requiring the user to page
to get the rest... but i do have to admit - i have never even seen such a
device, so i'm talking only on what i imagine it might be like. :)

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