Hyper-Desktop Markup Language ?

Among the "funny ideas" I had for Clicker, many has echoed in other's mind and some eventually got implemented here or there.

I won't call myself as "spolied inventor of tags", of course. I'm not. Though I have to admit tags are 100% aligned with what'd have pushed for Clicker if I had any resources to make things move by just pushing them.

Now, let's have a look at the box #7 of this "clicker desktop mockup" I made up somewhere near 2K++ ... the "one-key-command-line" for quickly spawning things is now mainstream ... Even Windows has it (or at least as some plugin) where you type [ESC]word[ENTER] to search and launch your report editor rather than crawling through clobbered menus.

"Incoming" (last imported documents) and "favourite" meta-folders are of lesser significance given we've got the "download history" window of Firefox. But let's check out that box #7 ... It was claiming "users do tasks, more than they use applications". That thing is starting to change as well, the welcome panels of Thunderbird 3, Wireshark (Lucid release) and K3B (a while ago) being an obvious example of it. They also claimed "a task is performed using a collection of tools operating on a collection of documents". We haven't got anywhere near that so far, afaik. Do I want to integrate something to the wonderful Tomboy application ? I have to learn C# ... Do I want to have Gimp able to learn new key combos for filters ? I bet I'll have to dig into some GTK+ and maybe some scheme or Python would help me.

Yet, all I'll be doing somehow is moving boxes around, connecting wires between blocks of code, etc. This is something that should be as easy to do as writing HTML, but there doesn't seem to be any Hyper-Desktop Markup Language around.

-- edit -- Btw, I was about to attach a picture in a thundermail while thunderbird crashed at me because I was also moving directories around. *sigh*. Long is the road.

shell companion windows

To some extent, it isn't necessary to write a whole new application for the futureshell. What we need is a connection to a "graphical tty" that is associated with the current shell, so that e.g. if I want to offer a preview of an image or show graphical relationships between items, timelines, etc., all I have to do is sending "drawing commands" to that companion window. Where the companion stands, whether it sticks and move along, what's its size, etc. can be managed by the window manager. That may not be as sweet as having "file descriptor #4" ready by default, but that'll certainly be easier to evolve to.

Formerly known as "FutureShell"

I once made a little mockup of "FutureShell", a sort of mix between Enlightenment terminal and nautilus. It had many "killer features" such as "intelligent icons" that can inspect the type of data you drop to them in order to move data to the "most appropriate place".

While working today, there's another feature I wish my shell/terminal had: transfer of configuration. I'd love I could somehow drag-and-drop the value of SSH-AGENT variable or the label of a directory so that it cd' to that directory in another window.

I wonder whether the SDL-for-perl could help me prototyping this ... since I've realised that I don't need to build up my own kernel / X server to experiment with document access.