WINDOWPATH environment variable?
samuel.thibault at ens-lyon.org
Tue Dec 6 01:44:10 PST 2005
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
More information about the xorg