WINDOWPATH environment variable?

Carsten Haitzler (The Rasterman) raster at rasterman.com
Wed Dec 7 16:49:54 PST 2005


On Thu, 8 Dec 2005 00:29:56 +0100 Samuel Thibault
<samuel.thibault at ens-lyon.org> babbled:

> Hi,
> 
> Carsten Haitzler, le Tue 06 Dec 2005 22:09:08 +0900, a $(D+1(Bcrit :
> > >  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. :)
> 
> Good candidates for performing this are xinit and xdm, so yes it
> involves Xorg.

you need it a little higher level for the xnest work - as the session under
xnest doesnt launch through xdm/startx. :) really its a matter of:

WINDOWPATH=$WINDOWPATH:`xwininfo -root | grep "Window id" | awk '{printf("%s
\n", $4);}'`

added to the very beginning of the session script. :)

> What about the name? Does it seem good enough?

i would call it BRAILLESERVERPATH
myself as it is specific to the braille terminal server and its contents even
though window id's may not be usable/accessible directly by an x program (the
first root id may be invalid for apps in an xnest environment)

> > > > 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. :)
> 
> Hacking xterm will be needed for exposing an at-spi interface anyway.
> The good thing with at-spi is that both braille, speech, whatever
> assistive technology will then be able to get xterm's text.
> 
> > > > > 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...
> 
> Yes, but then it's a pain for _non_ visually-impaired people who are
> working with visually-impaired people.

no - i meant the output to the braille terminal is limited to the nraille
temrinals display abilities, the user of the braille terminal has to page
through output (much like less/more) until they reach the end of the current
output batch. it buffers so if mroe comes its waiting until the user has paged
all the way through.

> > 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. :)
> 
> You imagined quite well so far :)

thanks. :) i will say - it's hard for me not to feel that this is just well -
taking a cudgel and turning it into a ball point pen. ie - apples and oranges.
i would imagine a braille temrinal works wonderfully at questions/answer style
interaction. (much like our good old zork games). but trying to convert normal
gui stuff into it is hard. with windowing systems, multiple windows overlapped,
focus, nested severs, it's a very very very very visual thing. i can't help
shake that feeling off. i know i'm biased - i'm one of these visual guys with
20/20 and better vision who likes his eyecandy, beauty, flashy stuff etc. so
for me it's really a hard concept to wrap my head around - a blind person
wanting to use a windowing system/environment to interact with a computer. the
old fashioned text terminal q/a zork style "UI" to me sounds like the perfect
interaction level - but thats an uneducated guess. i'd like to know why it is
you are choising to use a mutliple context, app, focus, etc. windowing system
for this work? to me it seems like it is just making your life harder :
( definitly lots of bonus points for you for chosing to do it the hard way :)

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



More information about the xorg mailing list