Re: 'r2l' continuation

[guy keren]

i'd like to ask people to try and send more complete ideas to the list.
remember that biditext works under various constraints, and they need to
be addressed regarding to any mechanism you suggest. i'll try to summarize
the currently known limitations, and the currently defined requiremenets.
when you post an idea, please also explain how you'll implement it, under
the given constraints.

constraints:

1. biditext isn't part of the application code. rather, it hijacks various
   library function calls (e.g. XDrawString). note that we could hijack
   other functions if needed (e.g. XCreateWindow).

2. biditext does not have its own main loop, and if you say "and we'll
   listen for such and such event - show us _how_ this listening will be
   done by biditext - NOT by the original application.

3. we don't want to need to make changes in any existing applications -
   this will make it much harder to maintain biditext, and harder for
   people to actually install and use it.

4. an application's top-level window isn't necessarily "a child window of
   the root window". both due to window-manager reparenting operations (it
   inserts its own window between the application's top-level window, and
   the root window). there might also be other situations, such as windows
   of one application embeded into windows of another application - e.g.
   this is how gnome applets work.

5. further to '4', a window manager's made window doesn't ahve to exist at
   all times. consider when a user kills their window manager, and
   launches another one. then all windows made by the first manager are
   destroyed (including any properties that might have been attached to
   them) and later on new windows are created by the new window manager,
   and become the parents of the existing application's top-level windows.


requirements:

1. we want to have something working soon (i.e. in 1 month). not in a
   year. we're mostly trying to fill in a gap until real bidi is
   implemented in the various applications.

2. if we want to have a per-window control, we need to remember that
   XDrawString does not necessarily get the handle of the top-level window
   - it most likely gets the handle of one of its child windows (or their
   child windows). these windows come and go, and thus anything we do to
   find their relevant top-level window (in order to know if we need to
   apply bidi or not) needs to handle this. further, a single biditext
   instance might need to control several top-level windows (e.g. biditext
   loaded into netscape, with netscape having 4-5 browse windows open).

3. running applications on a remote slow link? i don't think we realy
   need to care about that with regards to auto-refresh operations. note
   that auto-refreshes aren't done very often, and most of the people
   don't run netscape over a 28.8Kbps modem link...

4. we want to the user to have some GUI to control biditext. the way this
   GUI works is an issue of its own (Ilya has suggested clicking the 'r2l'
   applet, then the it will grab the mouse, let us click on a window a-la
   'xkill' style, and then toggle this window's state. we coudl also have
   a right-button click open a menu with entries for all windows that are
   currently bidi-texted. eli suggest to have a button added to the
   window-manager to handle a per-window biditexting, etc. etc. etc.).

5. applications for which we should properly test biditext compatibility:
   netscape (browser and mail)
   xterm
   gedit
   icq clients (licq, and the like)
   irc clients (xchat and the likes)
   anything to add to this list (please don't state "koffice" - that's
   quite otuside our scope, and it'll have its own bidi anyway).


i think that a good method to keep going forwards is as follows:

we have our arguments. we'll have several competing implementations done.
some (group A) will keep working (i.e. actually coding) with the current
file-based mechanisms, and try to enhance it to work on a per-window
situation, and make it work with as many applications as possible. noet
that this approach will be good enough for the home user, who runs all
their apps on a single machine, and thus for them, 1 display = 1 file
system.

meanwhile, others (group B) will check (discuss and _implement_) code that
will use X properties to handle the communications.

i will work on coding for group A, but allow myself to join the discussion
(not implementation) part of group B. group B people are also invited to
keep discussing also group A's approach - after all, various matters are
common to both approaches.

let the trials begin!

--
guy

"For world domination - press 1,
 or dial 0, and please hold, for the creator." -- nob o. dy