Linux desktops compete with each other in an attempt to be just as flashy as the next graphical operating system. Resulting in bulky systems which reduce users to users with little more control than under the operating systems that Linux tries to be an alternative for. I was really happy to learn about Ion, which takes an original, Unix-style approach to managing windows.
| posted on Sun, 05 Nov 2006, 13:21 | weblog | rss | spin-off | comments |
The driving idea behind Ion is that a desktop should be usable -- but this term is not interpreted as the short-sighted easy to learn but as optimised for low effort in operating it after some learning time. And indeed, it took me a day to get used to the way Ion worked. After a few days I still grab for the mouse when I don't have to. Mice are supported by Ion, but they are obsoleted because a much faster mechanism exists -- the keyboard. It's your choice -- which is actually a lot more user-friendly than Gnome or KDE.
One keystroke I missed when I just started, was a cycle through my windows button, or actually a forward and backward version. Silly me -- it turns out Ion does this much more efficiently, by binding keys for different directions. There are cycles in horizontal and vertical direction, tabbed (more later) and switching between virtual desktops. This works much faster and much more intuitive.
The general approach of Ion is to offer a rich set of keystrokes, for optimal speed and minimal number of strokes to get a task done. An interesting quote in that respect is:
It's as if we have thrown away a million years of evolution, lost our facility with expressive language, and been reduced to pointing at objects in the immediate environment. Mouse buttons and modifier keys give us a vocabulary equivalent to a few different grunts. We have lost all the power of language, and can no longer talk about objects that are not immediately visible.
A major feature of Ion is that it supports tabbed windows. We've all used some application with multiple pictures or other documents open at the same time, and needing to switch between them. If the documents are to be large enough to work in them, they automatically overlap each other. Ion tries to prevent overlapped windows, unless they occupy exactly the same space (called a frame in Ion terminology).
All frames have tabs. In practice, that means that all windows have a partial title/drag bar than with average graphical interfaces. When multiple windows are open in the same frame (desktop region) then the title bar is broken up, turning the title bar into a tab bar without sacrificing additional screen space.
As soon as a command fires up a new window it will (in tiled mode, one of the alternative appearances of an Ion virtual desktop) appear under a new tab, rather than popping up a window in a place where I don't want it, overlapping another window that is still important to me. Requesterish popups (so-called modal windows) depend on the window from which they were initiated -- such windows overlap the initiating window to create a graphically sensible alternative to having a tab for such temporary tasks. It's all been done very pragmatically.
This is an incredibly good idea. Mozilla has proven that tabs are greatly appreciated to manage one's reading habits -- for those only used to IE, imagine doing a Google query, and firing up a background window for each of the possibly interesting finds, to come back to at a later time. This is excellent support for finding information in a structured manner. Ion applies this principle to all applications.
My common desktop screen consists of either four terminals, or two terminals on top of each other, with a larger application running next to it. With Ion, it is possible to use the available space for such setups much more optimal. But what's more, I often need an extra terminal to quickly do something. Ion enables me to create a new terminal with a single press of F2. This just adds a tab at the present location, and I can easily terminate it with Alt-C or tag it with Alt-T for dragging elsewhere, where I move it under the local set of tabs with Alt-K A.
The operations on tabs are generally grouped under Alt-K <something>. This key has been deliberately chosen to be two-handed, thus faster than something like Alt-X could have been. Marvellous. Of course, all key bindings can be reconfigured.
Configuration too, is powerful equipment. With only a few hundred kilobytes for the complete Ion system, there still is a programming language built into the system, that can be used to program all sorts of behaviours under the keys. It appears that this tool offers me an incredibly more powerful environment than WindowMaker (my former preference) ever did.
Even desktop menus appear to be configurable -- normal Ion users would of course press F3 to enter a command to be run, including tab completion. but it may be useful for previous Gnome users to have a complete menu at their hands, as they did with Gnome. It should be possible to automatically derive such menus from (possibly collected) sources like the Debian menu system and the free desktop menu system.
Working with Ion means a few style changes. For instance, when browsing with FireFox I now to open new windows with Ctrl+N to get an Ion tab, rather than opening a new FireFox tab which occupies vertical space for the second layer of tabs.
Moreover, FireFox enables switching off vertical clutter that is available with keystrokes. Removing the Bookmarks avoids a lot of senseless tabs to walk through for every page. The Location can also be hidden; pressing Ctrl-L for the location then brings up a (slightly unpleasing) requester. As always, Alt-Left and Alt-Right bounce back and forth through history, and Ctrl-R reloads the page and Ctrl-H opens the home page(s). The only thing missing, is that Ctrl-K does not bring up a search requester. This may be remedied in XUL.
The mouse is really becoming a burden again -- it is far away, I have to move my hand all the way over the cursor keys, the numeric pad and then finally it's there -- to copy from the clickboard through a pulldown-menu takes about 25 times the time of simply pressing Shift+Insert! This burden is felt strongly with many graphical applications that make you tab around like a lunatic until you've finally found the entry to click. I am now much more keen on aliasing keys for the use of link rel pages for next and up and so on in auto-generated manuals; to figure out a way of selecting Google's links faster; and I am in search of a textual spreadsheet.
Mousish applications like the Gimp work best in a floating virtual desktop. This is a mode of operation which allows windows to overlap. However, when editing multiple images, it is immensely useful to put them all in a single space and use Ion's tabbing mechanisms to switch between them. The support of the mouse is very useful for this type of application.
Ion does not pretend to be complete, it just pretends to be more usable than the Windows-look-alikes that are usually installed by default on Linux desktops. The following list of small deficiencies should therefore be no surprise. If I find the time, I will try to fix them.
Routing keystrokes to terminals
When I open a terminal, it takes some time to startup. (I am still using gnome-terminal at the time, but I find that it starts too slowly for the dynamic way in which Ion allows me to use it.) If I continue typing in this time, the keystrokes are sent to the previous application, instead of being saved for the newly opened terminal. This means I have to stop working until it pleases the terminal to popup.
It seems to me that it would be typical of Ion to route keystrokes to the newly opened terminal. This would mean I can press F2 and immediately continue with the command I want to enter. Although it may not be possible in general to know whether a new window pops up for a newly started command, it is certainly possible to treat the new-terminal key F2 in this manner. And it would increase (my) productivity a lot.
Routing windows to frames
New windows take a variable time to start. I am not in the habit of waiting until it pops up, but my continued work is usually interrupted by the new window, which usually overtakes control in the frame active at that time. This undermines the continued work that assumes background-startup of the new window.
One facility that would be useful, is a function key that opens a window in the background (and correspondingly at the end of the list of tabs for a frame). It may well be possible to define this in Lua, I haven't looked into that yet. I don't think such a work-permitting key exists at this time.
In general however, Ion seems a little bit off. When continuing to work, the command follows me to the frame to which I may divert the focus. For instance, in a tiled setup I might walk through the frames and initiate commands in each. But if I am fast enough, all the windows are opened in the last frame. The frame in which to open a window should not be the window that is active at the time of opening that window, but at the time of starting the command; this should at least be true for the first window of an application. Due to the variable startup time of applications, this is the only way to know where an application ends up, without waiting for it to have opened a window.
For continued windows of an application, this is harder to arrange. The application is probably in control of when to pickup the current frame for a newly opened window. On the other hand, applications are not aware of frames and may thus be tricked into staying in their own frame by default. This would have the same predictability as for the first window opened.
Firing up commands
The F3 button is another great facility of Ion -- it runs a new application, which can be entered on a temporarily shown commandline. Unlike the hard-to-find 'Run command...' menu entry in common desktops, it supports tab completion, which is almost a matter of survival to anyone who has gotten used to it. Effectively, this simple keystroke saves me from reserving a terminal for firing up programs as I do it in other window managers.
But there are problems with the F3 key, related to I/O of the commands started. For example, Ubuntu's package manager synaptic works quite well (and looks quite nice) when squeezed into a quarter of the screen, but for normal use it should be run by root. Common desktops know this, and ask for a password before firing up the command through sudo. But running sudo synaptic is not possible from F3, because of the needed I/O.
This is a general problem that I have with the F3 button, and it forces me to go back to a firing-up terminal for some tasks. Ion would be much more usable to me when it would keep an eye on the just-started command, and fork off a new terminal if and when it starts to speak or listen on its streams stdin, stdout and/or stderr. The current implementation of F3 does look at stderr for a while, but it fails to look at the other streams. If it would, it could support commands like sudo synaptic by setting up a new terminal screen when a password is needed.
You may call me lazy if you think I should have used F2 instead of F3. Perhaps I am. But I think what I am actually after is a temporary popup that displays the text until it no longer needs my input, and which then goes away. This would certainly be a good solution to the need to prefix sudo before commands like synaptic, and it would also support the occasional need to type a password in general.
Anti-aliased fonts
The designer of Ion, the Finnish researcher Tuomo Valkonen, has a lot of interesting opinions which he expresses on his blog. To many of those, I heartily agree, but not so regarding anti-aliased fonts.
His approach to anti-aliasing is that the characters are blurred, and should not be supported by Ion. Rather, he prefers characters that are drawn in a pixel-by-pixel fashion, as the standard X11 fonts. Those characters are designed for optimal use of the available size allotted to them.
I agree with Tuomo about the smeered quality of screen-rendering of fonts designed for any scale; however I do believe that a font designed with care for rendering at low resolutions would make anti-aliasing a beneficial technique for terminal displays. (But I have no incling of how pleasing the difference would be for its daily users.)
Ion is lean and mean. I've been told I should look into it years ago (thanks, Joeri!) but I hadn't until recently. I now understand fully why Joeri advised it to me -- it greatly awards those who are willing to invest a day to learn it.
Ion does not clutter my screen with nice graphics, it adheres to my view on desktop usability, and it has enough functionality and great configurability. Also practical, it is readily available in mainstream distributions like Ubuntu.
Vertaal naar het Nederlands