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.
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:
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
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:
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.
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.
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...)
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.
#!/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'.)
#!/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.
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!