Older blog entries for auspex (starting at number 61)

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.

Undo

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.

Visioneering

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

I am amazed at the effort (thread continues in October) a developer of Java AWT will expend to make possible bad user interface.

Unix crack

Before I went to bed last night, I decided I should leave myself a note to try something later. I don't use a sticky note program or anything like that, and I figured I would miss a file containing the note. I decided to touch a note:

touch "Try blahblah for the blahblahblah"

That way, when I run ls, as I'm sure to do, I see my message.

But 'M' comes before 'T', so I was dissatisfied with the result. I renamed the file with a numeric prefix.

Then, I thought, "Why restrict myself to one line?" Indeed, I could insert newline characters in the filename, so I did so. But ls just showed question marks instead of newlines. A check of the man page revealed the --show-control-chars option. It worked, except for scatterring all the other filenames about. A wildcard fixed that easily enough.

So now I have these two (surely not portable) shell scripts, note and notes. The first takes a string argument and touches it with a little modification. The second lists, "showing" control characters, files matching those made by the first. Neither checks input or anything like that; I was about to fall asleep.

note

#!/bin/sh
touch ".^HNote from `date +"%-I:%M%P %A %e %B %Y"`
$1"

(That's '^H' the backspace character, not "^H" the string caret and 'H'.)

notes

#!/bin/sh
ls --show-control-chars .?Note*

(The '?' is a wildcard to catch the backspace.)

The backspace character rubs out the '.' which is there to keep normal ls clean. I sacrificed my initial purpose.

With a little modifcation, like using ui -in $USER, notes could include author information or whatever else. Of course, filename length is limited.

Well, for whatever reason, I only slept about two hours. I think I'll go back to bed now.

Hardware

We need at least two new computers, so I went to CompUSA to see what sort of things they're selling. I have a feeling they're not selling much; either they were remodelling, as one small oddly placed sign said, or they decided they didn't need marketing. The store was a mess beyond just the bad floorplan.

One of the fuzzypiles of boxes was littered with signs about customized computers. The most obvious customization available was the shiney Jolly Roger power supply fan grill.

When we need 128-bit machines to store Unix time, there will be a museum featuring a display case of PDAs next to an SUV with a sign, "Life before the extraterrestrial overlords. Be happy, citizen."

I wandered over to the dismal laptop section. The laptop business must depend on ignorance, stupidity, and desperation. It should be obvious that a laptop will not be used in a clean room, yet every laptop had a multipart keyboard. The design requirements must have included "short lifespan." Standalone keyboards would also be better with fewer parts, but they're at least sturdier and easier to replace. To get a decent keyboard on a laptop, you have to buy a "ruggedized" laptop; I guess that somehow ties into the SUV philosophy.

The standalone keyboards were hilarious. Some of them had a warning like, "Some experts think prolonged use of any keyboard may cause injury." They didn't even need any markup to get across the sarcastic tone. These warnings were etched into the plastic, not stickers. They also stated that more information could be found on the bottom of the keyboard. I tried to look, but the keyboards were bolted onto the shelves. (So much for checking heft.) Of course, most of them featured Windows keys, arrays of buttons, and Windows shortcut engravings.

My depression is a medical condition?

Craftsman

Craftsman hand tools have always had an unlimited warranty. To this day, past the 1950's demise of durable goods, you can take a broken Craftsman hand tool to any Sears store and get a replacement at no cost. (Sometimes the clerk doesn't know this, so you have to ask for the manager.)

GNOME Blog

Just now trying the free standing GNOME Blog. I got lost. Instead of the blog entry window, it opened to the preferences page. At first I thought the entry window was somehow buried underneath something else. For the third time, I had to set it to Advogato and enter my username and password. The applet version never survive being removed from the panel; this seems to be a systemic applet bug. The password field is asterisked out, but the key value is stored unencrypted.

There are a few HIG violations and other UI errors.

• The "Add Link" button opens a dialog which is correctly modal, but it doesn't have a trailing ellipsis.
• The ellipsis on the "Preferences..." button indicate that a modal dialog will be opened and indeed the window which appears is modal, but it's missing the OK and Cancel buttons. Instead it has the Close button of preference windows which are not supposed to be modal.
• The "Preferences..." button and the title field label (which didn't work for Advogato last I checked) lack access keys.
• There are two buttons with the stock Bold and Italic icons, but no labels (hence, no access keys) and no tooltips; and, last I checked, they actually added the tags STRONG and EM, respectively.
• Resizing the window shows that widgets are incorrectly packed. Though only the text area should grow taller, the whitespace above and below the title entry and the "Post Entry" button increases and the other buttons grow taller. The inconsistent heights of the bottom buttons indicate that more is wrong with packing than improper expand and fill properties. The secondary windows also exhibit packing problems.
• The Bold and Italic buttons don't set or show state properly. An inconsistent selection should show the buttons in an inconsistent state. Absent a selection, the state of the buttons should indicate what will happen on typing; e.g., pressing bold with nothing selected should cause subsequent typing to be in bold. In other words, they should act like the same buttons in a word processor.
• Added links can't be inspected. A tooltip should suffice for indicating where a link links, but doesn't allow editing. Removing the "Add Link" button (and dialog), and replacing it with an inspecting "Link" toggle button (like the Bold and Italic buttons) and entry would allow both inspecting and modeless linking.
• The window title "Post Blog Entry" looks like the title you'd expect on a dialog after pressing the "Post Entry" button. A better title would be ("%s Blog Entry for %s", blogname, bloguser), or something along that line.
• Not all blogs support titles, but the title entry is always there. Rather than conditionally showing the entry, it could be removed in favor of a "Title" button like the Bold and Italic buttons. What's sent to the blog would be whatever is appropriate as entry title.

As with most applications, GNOME Blog doesn't need preferences. It just needs a blog and some other data to post an entry. That this state is stored where various preferences are stored is an implementation detail. I can see two ways to eliminating the bogon:

• Change "Post Entry" to "Post Entry..." and show a dialog asking for the necessary data. After the data is given once (the first time dialog appears), it should be remembered for the next time. This adds an extra step for each subsequent post, but also allows a check against accidently clicking the button. It's a poor solution, but if the button is usually close to the panel applet button, the check may be worthwhile.
• Place the "Blog type" option menu in the main window with a disclosure button (perhaps "Details") next to it. Disclosed would be username and password fields, and whatever else is needed. This could replace the title field at the top of the window, or the "toolbar" could be at the top (maybe as a real toolbar) and the blog details at the bottom.

(I told Seth online that I'd just blog my complaints instead of adding to the email and bug reports he's already receiving. ;-) )

data:

This is nifty. It works in Mozilla and friends, but not in the version of IE I have. It won't work in text-only browsers, of course. The page may go away soon; see RFC 2397.

Another Test

The bold 'A' button uses the STRONG tag, and the italic 'A' button uses the EM tag. They behave oddly - only working when something is selected. The "Add Link" button, on the other hand, doesn't work on the selection at all. And I keep pressing enter at the end of a visual line because I'm used to soft returns from other markup contexts.

Does the person tag work? I am auspex.

What about explicit anchors? Advogato

The title entry didn't do anything. Maybe it should be removed when the blog is advogato.

I've noticed the button states for STRONG, EM, and the panel applet button get confused. The tag buttons will stay down when focus is changed via keyboard. The panel applet button was pushing in on mouseover for a while.

Maybe the popup window should skip the window list? It seems odd to have a borderless window with two buttons on the panel.

Must remember to check the source of the posted entry.