Re: 'r2l' continuation

[Tzafrir Cohen]

On Tue, 3 Jul 2001, Nadav Har'El wrote:

> On Tue, Jul 03, 2001, Tzafrir Cohen wrote about "Re: 'r2l' continuation":
> > You are confusing two things here: biditext.so needs not poll. It needs to
> > only check once. In fact, how does a check of an X property compare to a
> > stat() of a file ? Is itnot too costly to perform such a check every time
> > a string is drawn?
> 
> Yes, I am confused: does it need to check it once, or every time a string
> is drawn? Anyway, if many strings are drawn in quick succession (say, within
> 5 seconds) there's really no need to check the property every time.
> 
> Checking a property on the local server is pretty quick, but somewhat slower
> than stat()ing a local file that hasn't changed (the former needs a context
> switch, while the latter can be cached by the kernel - but obviously you
> can and should cache the former yourself!). But all that changes if you use
> X windows the way "it was meant to", with clients running on several different
> machines (usually, on the local network): in that case stat() on NFS needs
> an RPC call through the network (again, caching is involved, so it doesn't
> actually contact the network every time - you need to do some sort of caching
> on the property yourself because it's not automatic). But worse, nobody can
> guarantee you that just because a machine can display something on your
> display they share an NFS directory. NFS also doesn't really promise you
> how out-of-date your 'stat' results will be (or worse, if you actually
> try to write information out to the file, you'll run into filelocking
> problems).
> 
> > A top-level-window property may be user-frinedly. The problem is how to
> > get biditext to find the top-level window it is running in.
> > 
> > Assuming that a process holds only one top-level window, and that this
> > window does not change in the lifetime of the process, the following might
> > work:
> > 
> >   http://www.mail-archive.com/lin-club%40vipe.technion.ac.il/msg00297.html
> > 
> > But I haven't got around to even start implementing it :(
> 
> Note that window managers reparentthe top-level window, i.e., they add
> a window above it in the window tree which shows the various decorations
> (title, border, etc.) they want to show. But that shouldn't be a problem:
> biditext just chooses a window belonging to the application (the only
> requirement is that window will exist throughout the application's life -
> you can call it a "top-level window" if you want), and puts a property on it.
> Later, the application (or window manager, or whatever) that wants to change
> the r2l state on some window, simply needs to walk the window tree and find
> the appropriate "relative" window which holds the relevant X property, and
> change it.

Yes. That is it.

There is a technical problem here, though:

XDrawStrings recieves a Drawable and a display. That Drawable needs not be
a window (it can be a bitmap, for instance). Also, I believe that this
walk on the process tree costs too much time to be performed on every
XDrawString. Right?

Is it possible for every copy of biditext.so to hold one window handle,
and query its BIDITEXT_FLAG property?

(This means that this window can easily be changed to another window:
either the root window, or some sub-window of the top-level window (in
case of an app that opens two seperate windows). I can't think of an easy
way to notify biditext from the outside to change the "active window")

-- 
Tzafrir Cohen
mailto:[EMAIL PROTECTED]
http://www.technion.ac.il/~tzafrir