Older blog entries for auspex (starting at number 55)

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.

This is bold.

This is italic.

This is a link.

This has been a test of GnomeBlog.

Have a nice day.

Temperament

tk: according to http://keirsey.com/personality/nt.html, Rand would be an INTJ. (And you've a typo s/F/T/.)

tk, faassen: According to that same site, when depressed (like now) I'm either a "mastermind" (Eisenhower, Rand) or a "fieldmarshal" (Gates (!), Thatcher). And when not, add: "crafter", "promotor", "inspector", and "supervisor".

Oh, yeah, and I'm also an Aries and a Dragon. ;-)

GUP

I think personas [sic] are a gimmick. They're a way to get programmers to think about the things that, in my experience, in programming classes they're taught to think about and detest thinking about. They're a shortcut around rigorous design. I never met anyone who liked drafting a flowchart. I hope they'll be an effective gimmick for GNOME.

Part of the trouble I'm having with a design document is the persnicketiness of some people. You can ask, "Does the application allow the user to create something?" and get the response, "Yes. My application allows the user to create a device state." Try to narrow it down: "Does the application allow the user to create a document?" "Yes. The document which is the permanent storage of the device state." If you actually manage to get a precise question: "This document is too long. I'm not reading it."

Another thing bugging me is that people make a living off of this, or at least get a degree. I doubt I'll be doing either.

Temperament

mibus mentions an article about introverts. In false one-upmanship, I declare that my group is more rare than introverts. Almost every time I've gone through a personality sorter (hmm, sounds painful), I've found myself split between introversion and extroversion. On rare occassion, I've been a point to one side or the other.

It gets worse. I'm not only split between introversion and extroversion, I'm also split between the pairs sensing/intuiting and judging/perceiving. Only in the pair thinking/feeling do I fall clearly to one side: thinking. However, depression is a wicked thing. I am not certain of this, but when depressed I seem to fall to intuiting and judging - slightly.

So, my normal type: XXTX; my depressed type: XNTJ.

(The one-upmanship is false because I'm really just bewildered. Most people I know fall heavy to one type.)

GUP

Minimal progress. I wrote my to-do list thinking that doing so would prevent a depressed lull. It didn't work.

[Edited to correct a spelling error.]

My GUP to-do list

• 1st decent draft of notification area guidelines (I have one in a HIG bug, but I need to go over it, comments made on it, and Mark's proposal that seems to have slipped from view.)
• 2nd draft of Notification Area Preferences proposal
• 2nd draft of window list proposal
• 3rd draft of Find and Replace dialogs proposal
• Draft power management control panel proposal (The one on Windows really sucks. It's something to avoid.)
• Draft language/input/keyboard control panel proposal
• Check the HIG bugs and maybe do something about them.
• Maybe knock off a few UI reviews. Maybe my hair is short enough now so that I can't pull it all out. (Mumble something about not being able to grab a scrap from a garbage can and say, "No. Like this.")
• Finally take the time to write the big frickin' huge document describing a complete user model for the GNOME which I could present in person on a napkin. (Curse the lack of "Oh, I get it!"-cues. Bemoan the state of the non-(but should be)-obvious)
• Think of more things to put on this list to make the point that even though I suffer from recurrent major depression and, at the moment, post traumatic stress disorder, I am doing something other than complaining and cursing the broken 'B' key on my laptop.

Other software to-do's

• Think of a better name than "WordSense" for my WordNet interface. (It's better than the first name: gwordnet)
• Write libgwn so I don't have to depend on libwn
• Just pick one of the possible APIs to the X-selection-based remote control, and finish the damn thing.
• Figure out how to auto-tool-ize it so people don't whine about my handwritten Makefile
• Release the damn thing this time
• Curse more in code comments so I don't do it on to-do lists

Did I tell you so?

I've noted many times that an X client that tries to reparent the window of another X client without the assistance of the other client or the window manager is inherently flawed. X doesn't work that way.

This is why the KDE system tray protocol often failed outside of KDE. It depended on the window manager, but just how was not known to many. (With WM support, it worked fine. It's another question whether it should depend on the window manager.) GNOME's status dock (the old one) was an acknowledged hack that failed more frequently as window managers improved but without support for KDE's protocol.

The "swallowing" feature of the GNOME panel exhibited the same error. Perhaps because this was finally realized, the feature was removed. It has been resurrected as an applet, but it is still doomed.

Now, prompting this entry, Mozplugger has failed as I expected. Although it certainly tries harder than the old GNOME status dock or any "swallowing" for which I've read the code, it too is ultimately doomed. Moments ago, a GhostView window created from a process launched by Mozplugger appeared in the bottom right corner of my screen and stayed there.

I wonder who will get the first bug report. It belongs to Mozplugger, but I won't be filing it. There's no point to filing a bug against a program for the basic concept of the program, is there? I imagine there will be reports to every program possibly involved: browsers; the browser engine; the to-be-reparented programs; window managers; the GNOME panel; the GNOME window list; libwnck (these last three because a button for the window appears in the window list in the panel); and, of course, the culprit, Mozplugger. Despite this entry, fingers will be pointed and tongues will be forked.

Providence, I should say nothing more.

Interlude

Among other frustrations are the astonishing unresponsiveness of Mozilla's text area and the poor wrapping of Emacs.

Mozilla is so slow that I, a slow typer, can write an entire sentence before its first chraracter is displayed. I don't know why this is so; it appears to be unique to Mozilla. (I should perhaps say Epiphany instead of Mozilla, as that is what I use, but, as I recall, I did check the Mozilla browser too.)

I decided to use Emacs and then cut-and-paste to the webpage text area. This was fine until I reread what I'd written. Not wanting to insert unnecessary carriage returns, I'd typed long lines. (I wasn't writing email or code, after all.) If Emacs can wrap text at word boundaries without inserting characters, I've not found the setting to make it do so.

Having surveyed other text editors, I knew of none to my liking. GEdit would probably be fine for me if not for the inescapable document tab. It serves as a persitent reminder of other usability problems; with Emacs, which I've used for a while, the nagging errors are quieter because of familiarity. I wonder if abused spouses are also guilty of this error: if I'm going to use an unfamiliar text editor, there had better be no blatant prolems with it; better with errors is worse than worse with familiarity.

This interlude was written in a new editor. This editor is named "stupiditor" and may be downloaded from http://www.phys.lsu.edu/~merchan/stupiditor.c. (A command to compile it that works for me is at the top of the file.) Cursory use, or reading of the source code, should explain the name. I cannot and do not recommend using it for more than amusement. The command line syntax is: stupiditor regular file you can read and write. Actually, permissions are never checked, and errors resulting from are not reported. When you are done playing, you have two choices: save or lose your changes. If you close the window with your window manager and no errors occur, your changes will be saved. (Unless your window manager is so archaic that it uses XKillClient instead of sending a WM_DELETE_WINDOW message.) Any other program termination will lose changes.

Unfortunately, it is not as responsive as I hoped it would be.

Frustrated (cont.)

The X selection mechanism can be used for more than it is commonly used today. The most common use is for the user to "mark" some data and transfer it. Marking here include selection (for middle-button paste) and also the more widely known Cut and Copy commands. Along the same lines, some other uses have emerged:

• At least some WindowMaker "squares" (I don't know what the correct name is) accept middle-button clicks as "paste" commands.
• The Googlizer is a program that reads selected text and opens a Google query URL in a web browser.
• The GNOME dictionary applet can lookup selected text.

The system is not without problems. The select-and-paste method, because it needs one clearly active selection, conflicts with the expectation of non-X users that there may be more than one visible selection. The cut/copy/paste method, while providing dynamic typing, does not provide persistence. Another program must be used to provide persistence. When there is a large amount of data or many forms which it may take, the bottleneck of a persistence-providing program is a nuisance. Motif UTM (the protocol, not the API) alleviates this, but it is poorly documented.

Another use of X selections is window manager control. Though it has long been documented, only recently did window managers other than MWM (and maybe DTWM) begin to implement it. There are only two documented suggestions for using it: explicitly, to get the version of the ICCCM with which the window manager complies; and implicitly, to switch window managers.

There is also a "workspace manager" and protocol which MWM recognizes, but I've found no documentation. Something like this for the window manager specification at freedesktop.org is being discussed.

One new use of selections is the XSETTINGS system. Unlike the previous selections, it stores data on the selection owner and clients are expected to monitor this window for changes. Here, using a selection ensures uniqueness to a screen and identifies the owner window. Uniqueness is important to avoid conflicting settings. Screen-specificity is important because settings, such as colors, on one screen may be inappropriate for another. Because XSETTINGS are available from on program for use by many others, it is better for all interested programs to monitor a particular window for changes. If this were implemented using the full selection mechanism:

• Every interested client would have to either:
  • Periodically query the XSETTINGS program for changes, or
  • Register with the XSETTINGS program to be notified of changes.
• The XSETTINGS program would have to notify every other program directly. If a registration system were used, then it would also have to watch for new and dropped registrations.

Programs watching for changes on a specified window is like registration, except that the programs register with the X server.

The system tray protocol is the last common use of the selection mechanism. Its accepted form uses a selection just to be unique, then batteries of ClientMessages for communication. The originally proposed protocol used selections for communication.

I don't feel like going on for now. Part III later.

"HIG"

HIG is an acronym for either Human Interface Guidelines or Human Interaction Guidelines. So, it's a noun. In the context of a particular environment, the name of the environment may be omitted. The GNOME HIG is simply "the HIG" if you're talking about GNOME.

The noun "HIG" has been verbified. (Or verbed? Or verbificated?). To HIGify [sic] is to make compliant with a HIG. This is a poor verbification; the -ify form would ordinarily make it mean "to make into a HIG". Now gerund and gerundive forms of the verbificative have appeared. Their usage, oddly enough, seems to have lost their connection to the original noun. Something HIGified is something made "cool", regardless of good taste, HIG-compliance, and probably a lick of sense.

I still like the name I once used for a shell script to build the GNOME HIG when we started working on it: higgy-piggy.

(If someone knows the proper names of the linguistic convolutions I've described, I'd like to know them too.)

SpamAssassin

I finally installed SpamAssassin and added procmailrc rules to use it. It is very slow, but I can imagine why. I had placed the SA rules at the beginning of my procmailrc, but this was not necessary. I have now moved them near the end of the file and I am much happier. Mail from known addresses is no longer checked, and those include a list of domains which go to /dev/null.

Magic!

After suspending and resuming my laptop, sound works! This is so bizarre. Something, I know not yet what nor do I much care, changed in some Debian ALSA packages. Sound quality is very poor and music skips on all sorts of events such as terminal output, focus changes, and rapidly moving the mouse. This used to just work.

Irrationality × Irrationality = Rationality ???

Lacking a good model, application features and options sets grow wildly. Lacking - well - a good model, GNOME usability work became option removal. Between these opposing forces, things have gotten a little bit better. It's a lot like chemotherapy, I suppose.