WINDOWPATH environment variable?

[Samuel Thibault]

Carsten Haitzler, le Tue 06 Dec 2005 09:57:18 +0900, a écrit :
> 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.

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

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

Regards,
Samuel