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