WINDOWPATH environment variable?

[Carsten Haitzler (The Rasterman)]

On Thu, 8 Dec 2005 02:15:49 +0100 Samuel Thibault
<samuel.thibault at ens-lyon.org> babbled:

> Hi,
> 
> Carsten Haitzler, le Thu 08 Dec 2005 09:49:54 +0900, a $(D+1(Bcrit :
> > On Thu, 8 Dec 2005 00:29:56 +0100 Samuel Thibault
> > <samuel.thibault at ens-lyon.org> babbled:
> > > Carsten Haitzler, le Tue 06 Dec 2005 22:09:08 +0900, a $(D+1crit :
> > > > >  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. :)
> 
> Yes, but note that it can be started via xinit too:
> xinit -- $(which Xnest) :1
> 
> Xnest could set its window ID as a root property (like XFree86_VT).

well the window id can be sourced from outside xnest or inside. also you might
consider trying xephyr instead of xnest. xephyr supports all the modern x
extensions in a nested xserver... unlike xnest. :)

> > > What about the name? Does it seem good enough?
> > 
> > i would call it BRAILLESERVERPATH
> > myself as it is specific to the braille terminal
> 
> Mmm, it is _not_ specific to braille: WINDOWPATH just designates where X
> windows appear.
> 
> > 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
> 
> Yes, text mode is much better for everyday life.
> 
> However, the fact is: people write X applications. An example is
> javascript support: the text-mode browser elinks2 has some support, but
> it's quite bad compared to mozilla's support. The latter has no textual
> interface. There is no textual interface for OpenOffice.org either.

yeah... maybe... well see below.

> Yes, mozilla & OOo people may start writing a textual interface, but
> there's little hope many developpers will take enough time to do it
> properly (including testing in real conditions: a 40x1 terminal).

absolutely. then again - is mozilla, or openoffice a "sensible" idea in a 40x1
terminal? i mean they simply aren't geared to doing that at all and likely
never will be. the best u can hope for is to make a mozilla derivative based on
gecko, spidermonkey etc. but web pages wouldnt be usable in a braille temrinal
mostly - especialyl if they use javascritp to make dynamic popup menus etc.
like many do. openoffice just doesnt make sense when a basic 1 line text editor
is all you can really "display" and thus your main point is document format
support. as i said - i give you full points for taking on a hard problem - and
i know you know much more about it than i do, but i just can't shake the
feeling that this feels like the wrong way to attack it? splitting these apps
into backend libs then breaking out a new front end customised for things liek
a braille term... might be the best 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)