12 Apr 2004 auspex   » (Journeyer)

XUL Desktop Environment? I think it's almost possible, but I wish I knew how to start filling some gaps. These problems are present on at least the X11 (gtk2) backend.

  • Windows always accept focus. (Gtk2 also has this problem for the most part.) Some windows, such as an on-screen keyboard window, should never accept focus. (Gtk2 allows such behavior.)

    Other windows should only accept focus when it's is assigned by keyboard - to allow keyboard access. A simple palette with a grid of buttons, similar to the GIMP's, shouldn't accept focus because it functions as an auxilliary to a document. The user should be able to click a palette button and continue working on the document without having to move focus back to the document - just as if he had clicked on a toolbar in the document window. The gtk2 backend of XUL will not allow this, even if XUL does.

    Most windows should not accept focus if the user is merely dragging something from the window to another window, neither should they be raised in such a case. Windows Explorer and perhaps MacOS Finder exhibit this behavior. Nautilus was supposed to, but won't until Gtk2 and Metacity are fixed.

    Some windows, such as the GNOME panel, should perhaps exhibit a mix of these behaviors. Should the click fall in the text field of an applet, focus is needed. Otherwise, it should be refused.

  • Timestamps are very important for X11, and perhaps nothing else. They are needed to control focus, grabs, and selections. These needs push the need for timestamps down to the execution environment where they can be made available directly or by reference as in the freedesktop.org startup-notification-spec. While the need for timestamps can be almost surely be hidden behind a toolkit's abstractions, it is still an extra burden for building on X11 instead of Windows or MacOS.
  • The importance of the window manager has been greatly exaggerated. The window manager is needed to control some stacking, to sometimes control focus, and for some global operations like Alt+Tab window switching. "Decorations", as window frame controls are misnamed, would perhaps be better left to the toolkit. (Supposedly there's an implementation problem with that, but I won't believe so until I've seen it. My experiments reveal no such problem.)

    The stack control needed is minimal. Some windows should always be below others, and some windows should always be above others. Otherwise, the focused window should not be obscured when a new normal window is mapped.

    Focus control, if the frame is part of the toolkit window, is only needed when focus falls to the root window. Except for the next part...

    Global operations can't be left to the toolkit; or, at least I haven't thought of a way to do that yet. Consider Alt+Tab. For this to work as most people expect it to, the program that process the keystroke needs to know which windows to include in the chain, the order to include them, their names and icons. There are ways to do this without a window manager, but they're probably too slow and certainly too messy. Since the window manager is the best thing to handle this, it also needs to assign focus once the user selects a window. Until FocusChangeEvent can be extended to include a time and previous window, the best mechanism for this is the WM_TAKE_FOCUS message.

  • There's no fine control over whether the first click in an unfocused window does something. Sometimes it should and sometimes it shouldn't, but things are not currently done in a way that a program can reliably determine whether a click was part of a focus transfer or not. This is easily fixed in the same way focus handling is fixed.

The changes I have in mind are really simple if you ignore legacy applications. A migration scheme doesn't seem to hard either, except that I can't convince anyone the destination is worth reaching. So I've been toying with two ideas:

  • Write a toolkit and WM to make it happen. I wrote the core of the no-legacy-support WM over a month ago; after all, that's only a few K. Then I started toying with making a toolkit. Ha! The possibility of using Cairo has been very distracting. Most distracting though is looking at other toolkits and thinking, "maybe I could convice these guys to make a few changes instead." Lately, XUL is most appealing.
  • Give up.

I consider why I might do this and find no good reason. Every reason I can think of is neurotic. (I'll not list them.) I miss enjoying the study of physics. (I never got far enough to enjoy the study of nature as a physicist.) I miss enjoying study and I think I've been missing that for a long time. I laugh when I think puberty may have been to blame. I laugh a lot for someone so depressed, and it's not just a nervous reaction. This and more often mislead people. I wonder, but mostly doubt, whether I can still read French. Mr. Hugo might have a book for me. Perhaps I'll watch the movie first.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!