WINDOWPATH environment variable?

[Samuel Thibault]

Carsten Haitzler, le Mon 05 Dec 2005 23:34:07 +0900, a écrit :
> 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.


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.

Regards,
Samuel