Recent blog entries for auspex

pfh, don't forget simple masochism.

As for humour as a mode of thought: I wish I could be all dramatically "Woe is me!" depressed. Instead I find humour in all manner of things and laugh all too frequently. "How's it going?" I'm asked, and, "Absolutely miserably!" I smilingly respond. But that doesn't actually improve my mood or lift me far enough out of depression to do what I used to want to do, so . . . it's a bit depressing. (Ha!) I was a clown for a day - perhaps I should try to get paid to be one again.

Given the number of blogs wherein personal psychic problems are made public, I hope psychologists, psychiatrists, and sociologists are paying attention. That diaries, which used to be kept under lock, are now for public consumption is interesting in itself. I wonder how this is connected to the rash of "reality tv".

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

11 Apr 2004 (updated 11 Apr 2004 at 00:08 UTC) »
A misanthrope hates mankind, which includes women. A misandrist hates men - i.e., male humans. See also misandry, for which you don't need a subscription.

Raiseless DnD

Filed many bugs this past weekend to get raiseless DnD support in GNOME, and grouped them with a meta-bug. I split them too finely, so Owen promptly marked some as duplicates of others. All the Gtk+ bugs are on the 2.6 API freeze target milestone. Thanks to some earlier work and Matthias Clasen, there's already a patch which makes most of the necessary changes to Gtk+. The Metacity bugs have patches attached too, though they're the minimum needed (three lines) to get the right behavior and less than ideal.

30 Jan 2004 (updated 1 Feb 2004 at 02:43 UTC) »

A few hours ago, I discovered another way to make X window managers and applications so that the beginning of a drag does not raise the drag-source window. This method is even simpler than the method I wrote about in October.

That old method worked well and I had demos on my website for a short time. While writing to gnome-accessibility-list to request an assessment of the method's accessibility impact, I discovered the simpler method. (And cancelled the suddenly obsolete message.) The old method also made it easy to eliminate other problems. The new one eliminates even more problems.

Neither method introduces a new protocol. They both rely on what's in the ICCCM and judicious window management policies.

The ICCCM revision history seems to indicate that both methods have been possible since 1989, when ICCCM version 1.0 was released.

Is it better to be the first person to realize this than not? If I'm the first, then everyone else has missed the solution. If I'm not the first, then somebody else has been either silent or unduly ignored. It would have been better to not have considered the question.

Do you dislike indiscriminate clipboard managers?

Are you plagued by multiple requests for multiple data formats which no reasonable application would ever make?

Are you tired of claiming the clipboard only to lose it a moment later?

Well, now with The Amazing _OH_GOD_PLEASE_KILL_ME_NOW Selection Target(TM)(R) you can get rid of those pesky unwanted clipboard manager daemons!

Yes! That's right, folks! The Amazing _OH_GOD_PLEASE_KILL_ME_NOW Selection Target(TM)(R) guarantees* that you will never be bothered by those nasty clipboard daemons that try to grab all of your clipboard data!

Here's how it works:

  1. Claim the CLIPBOARD selection.
  2. Place The Amazing _OH_GOD_PLEASE_KILL_ME_NOW Selection Target(TM)(R) at the begining and end of your TARGETS target.**
  3. When any client requests The Amazing _OH_GOD_PLEASE_KILL_ME_NOW Selection Target(TM)(R), simply honor the request!

Yes, indeed, friends! It's just that simple!

The Amazing _OH_GOD_PLEASE_KILL_ME_NOW Selection Target(TM)(R) is a side-effect target which, when requested, promptly calls XKillClient() on the requesting client. Once the offending client has been disconnected from the X display server, it bothers you no more! Should it try to reconnect and reclaim the clipboard, you merely continue to honor its requests!

Get yours today!

* Guarantee does not apply to xclipboard, Klipper, or other lossy clipboards.

** To avoid ICCCM penalties, customize your The Amazing _OH_GOD_PLEASE_KILL_ME_NOW Selection Target(TM)(R) by postfixing a discriminator as described in ICCCM Section 1.2.6

I wish people would stop trying to kluge over systemic bugs and start fixing the bugs that stand in the way of fixing them. Here's Havoc's favorite. Here's some much lower hanging fruit.


Every so often I look at the stubs of my generic undo library and find it woefully inadequate. I try to find more info about what's needed and how to implement it, but come up short.

It seems every GNOME program with undo has created its own special code for it. The code should be common and widespread. There are at least two attempts to create a generic facility, but they're out-of-date and unused.

I'm not sure what are the requirements. My best guess is:

  • Contextual records so that undo can be limited to a selected scope. (E.g., Select a paragraph and undo changes to it, though other changes may have been made elsewhere later.) Maybe context should just be application-specific data.
  • Two LIFO structures (per context?): one for Undo, one for Redo. Or, perhaps, a single structure (array, list, whatever) and a pointer to the current position.
  • An Action structure with callbacks for Undo and Redo, data needed for those, and the data needed to represent it in menus or lists.
  • Action compression for actions which, once done, should be treated as a unit for undoing and redoing.
  • Disposal of no longer relevant data.
  • (De)Serialization: To store and restore undo data between runs.

Especially because of the last item, I worry that a library for just undo is a bad solution. The serialized form could be made at least as human-readable as XML. If I can read the serialized form, then I can modify it wholesale in a text editor, open the document, and press Undo repeatedly to make the app do anything it can undo or redo. In other words, the serialization is a script.

And that's where I give up. The task is no longer just keeping some lists, it's writing a scripting or macro language. And how many of these do we already have? How many are fit to be read and edited by non-programmers? Should the primitives of the language (e.g., "insert" and "delete") be translatable? If so, will the syntax make sense? (Maybe "insert text" in English should be ordered as "text insert" in some other language.)

I could try to ignore the obvious (to me) extension of undo/redo into scripting, but I have trouble working that way.


(a.k.a., blahblah)

It's funny that the Apollo project should be mentioned, since my hostname has been Parnassus for most of this year.

Though I've not touched it in almost a month, I've been working on an model - call it a vision, if that's your cliché - for GNOME. I've been putting recommendations on my website. Some people have been reading them (according to server logs), but none have replied to any that haven't been announced. (Which is probably good, given the flux. Still, it's lonely.) Those are not the model documents, but they bear at least one resemblance: they're boring.

Boring. That's what most of the recommendations and the big picture will be. Why? Because we like you! . . . No, wait, that's the mouseketeer song. Well, maybe that's appropriate because it is the mouse that binds us. The keyboard, pointer, and smaller-than-a-cubicle-wall rectangular screen will be the primary interface to the general purpose computer for most people for many years.

Unless GNOME starts making hardware, it had better be boring - a WIMP interface - like the Star, the Lisa, the Mac, OS/2, Windows, and all the rest. Without manufacturing wetware, you can't, with fiscal responsibility, consider Hollywood movie interfaces for which you need all your body parts in working order.

Boring doesn't mean there isn't room for improvement beyond existing interfaces, but neither GNOME nor any other X-based UI has caught up to MacOS or OS/2. There may be niches of excellence, but the X environments are inhospitable. Most of the recommendations I've put on my site are meant to clear the air so we can get a look at the landscape. Poor window management, drag-and-drop, and clipboard handling are a thick smog.

When those are out of the way, the X environments will probably be equal to Windows. At least then the foremost differences will be the quality of the applications. Assuming GNOME's HIG is cleaned up and followed, GNOME should easily surpass Windows. This could happen as early as the 3.x series.

What remains after that requires more code and much more persuasion. Since today's usability gurus can't move Microsoft or Apple to implement something as basic as user object persistence, I should have little hope.

Improving DnD

I wrote a page about improving DnD in GNOME.

In other news . . .

I finally found my port expander! No more broken keyboard, I hope.

Lo! And I can type with much clicking of this old IBM keyboard! (Not that you can see that, but anyway...)

58 older 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!