Older blog entries for auspex (starting at number 6)

ICCCM

The copy of the ICCCM shipped with XFree86 is not the same as the one available from X.org. There is no indication of this within it.

Things that make me go GUH

  • A number of GNOME library headers are installed as $INCLUDEDIR/libfoo/libfoo.h - some now are $INCLUDEDIR/libfoo-version/libfoo/libfoo.h. AFAICT, only GNOME and guile keep the lib- prefix on header directories and files.
  • GNOME has a bugzilla, but some of the package maintainers do not use it even though the package is registered there.
    80078, 82290, 86080, and an email later.
    Another one.
  • Many things GNOME is built on are documented. Few people read these documents, even when they are the most relevant - e.g., if you write a window manager, you should read the ICCCM; if you write a session manager, you should read the XSMP and ICE protocol documents. According to one person from one company working on GNOME, "We don't install documentation on Linux boxes." (paraphrased from memory)
  • Out: Scratching an itch.
    In: Dogfooding.
  • Language - Part 1. 'Dogfooding' is a gerund of the verb 'to dogfood' which is formed from the phrase "to eat one's own dogfood." In that phrase, dogfood is a euphemism for excrement. The euphemism either plays on the fact that dogs will eat excrement or on that canned dogfoods look like excrement. It the reason is the latter, I hold little hope for an end of racism during my life.
  • Language - Part 2. 'Crack' Maybe I wouldn't find the allegations of drug use so abhorrent if I'd first heard the ad hominem under different circumstances. In the course of my studies, I came across a problem which most people do not solve - including most at CERN where and when the problem was first presented by someone else. While arguing with my classmates and all but one of my professors, one of my classmates made the usual allegation. I stopped trying to explain and said that if he didn't want to correct his error I wasn't going to bother trying to correct it for him; I never spoke to that fellow again. Eventually one of the opposing professors privately acknowledged the correct solution. The classmates have graduated. They will probably go on and eventually be teaching. One day the problem will be presented by one of their students and he'll have a worse time than I did. Hopefully by then my former classmates will have learned some civility.
2 Jul 2002 (updated 2 Jul 2002 at 23:45 UTC) »

ICCCM

I sent email to x.org a few days ago asking about revising the ICCCM. No reply yet.

Menus

Menus make a lousy user interface and there are so many ways to make them worse. Perhaps the most familiar problem with menus is that they rarely present all the important information, though it wouldn't matter since such things are rarely read any way. Some people can look at a menu and decide everything on the spot; others need a dialog after making selections. Sometimes there are dependencies which the menu makes clear, but there are for some people vitally important things which are almost never included. Sometimes you even find yourself looking at the wrong menu and other things can make it hard to see menus at all or to differentiate the items. For somethings though, nobody ever needs a menu - everyone expects some things to be a certain way.

Some examples:

  • Menu item usually followed by a dialog

    Salad... Which dressing would you like? We have ...

  • Menu item with rarely considered dependencies

    The main course. You have a choice of sides listed here.

  • Menu information of vital importance

    Does the item contain this substance to which I am deathly allergic?

  • Wrong menu

    "Sorry, sir. We stopped serving breakfast at 10:30." "Well, the breakfast menu is still on the board."

  • Hard to see

    Low light provides ambiance - it also hides stuff you don't want to see.

  • No menu needed

    Beer in a bar.

  • The most recent copyright on the ICCCM is 1994.
    Sometime in 2002, a window manager may have, for the first time, full ICCCM 2.0 compliance. Kudos to FVWM.

    Of the window managers in Debian Sid, only the most recent FVWM has not yet failed simple compliance tests. These window managers include twm and two versions of mwm. The non-free version of mwm showed the most promise, but ultimately failed.

    It's been 8 years. Only one window manager (out of very very many) may be fully compliant. Meanwhile, selection managers in general have poor compliance. The standard xclipboard program in XFree86 4.1.x does not comply. The recent XSETTINGS spec at freedesktop.org is not compliant by design; compliance is seen as too difficult. The system tray spec as originally proposed was compliant, but the current proposal is not. Note that neither of these specs forbids an implementation from being compliant; both use a 'managed' selection without target support.

    8 years. What does it take to change the ICCCM?

    Wow.

    The idea of unique, stable node id's is interesting. If the tree is stored on a disk, then you maintain the mapping from id's to file offsets as an additional invariant, for example by using the node id as a btree key to the actual node contents. The big advantage is that clients don't have to worry about a node id ever changing.

    I was recently looking at something where I might need this. Thanks, raph, for the links and adding the recent entries link.

    (Can't say what. I might not do it and I don't want to get too many hopes up. ;-)

    Too much stuff.

    I've got an attempt at Debianizing vicious's PonG running in the background as I type this. And I'm typing on a recently-built-for-debian version of Galeon; I had to do some hunting and editing to get that, since not even Debian/Sid has a mozilla more recent than M18 and there is no official Galeon package at all.

    Along with that, Sid broke evolution. This sucks. I tried building from source, but there have been too many changes in libgal and cvs evo has lock-you-out-for-being-cocky requirements. So I'll be using mutt or mailx until the next evo release, which I'm told is far off but will be a big improvement. I hope that means it will finally have some sort of persistent alarm system and that that will be using cron or at. I do not want another daemon. If either of those needs improvement, fix them; don't kluge something else especially not for something like, oh say, emblems. (Too be fair, medusa may be better than that but I don't recall hearing how at the moment.)

    (Hmm, the debianization just returned to snafu.)

    I've got so many projects started and not released that it's not funny at all. Most of them work, more or less, but I've not bothered try to finalize for release. Some of them are on my website, for those who want to dig. In the meantime, I'm starting a few other projects :-) . Oh, but - joy of joys - it looks like one of them violates a patent, so I'll await the knock. I went from thinking, "Why not like this?" to thinking, "No, it's not really like Foo(tm)." and now, "Great, it's enough like Foo(tm) to violate the patent." All of these ethereal patents need to be pushed down the stairs.

    Enough rambling. Back to the packaging.

    Just a thought:

    I needed to draw some 'textbook-style' graphics recently and the only thing I found that provided sufficient control and ease of use was xfig. It is apparently a rather widely used program, judging from the .fig libraries that are part of the distribution.

    There are already many widely accepted programs in the land of UNIX that are 'mature' - i.e., feature creep seems to be under control and there are many other programs or datafiles that support it.

    Why don't today's desktop projects work on adjusting and integrating these programs? The user-base may be silent, but it seems to be quite large; at least large enough to support itself in many ways. Why do the leaders of the desktop projects seem to be abandoning the users they already have in an uncertain (though not necessarily futile) attempt to win a user-base that has no prior investment in any of the principles of the UNIX-world? (Among those: sharing reusable data)

    Some thing I'm working on at the moment.

    PCP: Project Control Panel Since I recently figured out how to put a gtk widget from rep-gtk into a C program, I can now use rep to write panel applets. PCP is the first one. The idea is simple: Place an applet on the panel that allow me to switch between projects, open files in particular ways and perform various actions at the press of a button. The implementation is a menu bar [[Projects][Edit][View]] and a toolbar with some buttons. The 'edit' and 'view' menu items have all of the current project's files and, by submenuing, directories. Say for example a project consists of two files: main.c and foo.html. Selecting main.c from the edit menu would invoke the designated editor or load the file if the editor is running or raise the file window/buffer if it's already loaded. Selecting the same file from the view menu may do the same thing, or perhaps it'll send it to something that presents a integrated display of the file and a lint report. Similarly, selecting foo.html would either use an HTML editor or display the page in a web browser. In this case the toolbar would probably have buttons for make-ing, running, and debugging.

    Here's where this can take another turn though. Suppose you'd like to work on two projects at the same time, but you don't want to trouble yourself with grouping windows, iconifying them and the like. Since the applet is written in rep, it can invoke sawfish window manager functions too. Selecting from the project menu could either create a new viewport/workspace or switch to the one containing all the windows pertinent to the project. When the applet invokes something that opens a window, it can perfrom the grouping as well.

    I've been working on a configuration interface for this applet and I've run into a wall. It seems there's no widget like GtkCList that allows widgets to be placed in cells. I'll probably have to write one or rethink the UI.

    Well, that's all I can think of for now; back to coding....

    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!