Mon, 26 Dec 2005
Running tasks' icons
Yet another article from my "Desktop Rants" series. In the Good Old Days(tm) when there were no "desktop environments" per se, just a window manager with a bunch of apps, the window manager used on-desktop "icons" for minimized applications. Nowadays, probably inspired by MacOS, the icons on the desktop are used for files, directories, and application shortcuts instead. Minimized (or all?) applications were moved to a window list applet on the panel.
With this approach, minimized applications are not usable anymore. With the old-style on-desktop icons of minimized apps, user could distinguish between the icons of the same type from their location on the screen, something that is not possible anymore. Can you tell which terminal runs vim on my .profile?
In GNOME, I can no-longer minimze the applications in a sane way. So I have a huge virtual desktop (3x3 desktops on each of my two screens), and I just move to the next virtual desktop when starting a different work.
And there is another serious problem - some apps used to display an important status information in their icons and/or icon title (the song being played, availability of new security updates, etc.). In fact, some of those applications are designed to run minimized most of the time, and just display their status in the icon image or name. Only when the user action is needed (choosing a different album to play or actually installing a new security update), they can be unminimized, and their window appears.
So the desktop environments went one-step furher and one-step back at the same time - they introduced a "panel notification area", where some applications (such as rhn-applet or various music players) display their status. This is essentially an icon-box from older window managers, except that it isn't. Those icons are not first-class citizens anymore: not every application can have an icon there, it has to be explicitly written for it. Why something different than the old-style X11 window icon has to be chosen is beyond my reach. Fortunately, there is at least a freedesktop.org specification for these "almost-icons", so KDE apps can use mini-icons in the GNOME notification area and vice versa.
6 replies for this story:
Milan Zamazal wrote:
Perhaps the problem is elsewhere -- why do you need to run more than one terminal? But I agree GNOME window list should be able to display (optionally) the icon title and application class instead of the window title. Maybe it wouldn't be too difficult to write an appropriate patch?
Yenya wrote: Only one terminal?
I want to _see_ multiple things at once, so I want to run more than one window. The problem is not with window or icon titles, but with the fact that GNOME window list applet does not keep the windows always on the same position in the list, while the on-deskop icons can be _also_ located by its position on screen in addition to the icon shape or title.
oozy wrote: Only one terminal?
Just one terminal is not useable. Shell within terminal has history and current working directory and so on. When I do on something I often make small changes to commands or run same command repeatedly. That's why I use putty and screen for the same purpose as many xterms in X. To split workspace, each for one task.
Milan Zamazal wrote:
oozy: Sorry, I actually meant "more than one terminal window" (possibly managing several terminals). Yenya: I've never thought about opening new Emacs frame (Emacs is my primary terminal) when I wanted to see multiple things at once. It's more economical for me to run Emacs in a single maximized frame and manage its contents inside. But you're right there is a problem: Desktop should be scriptable, absolutely. Then it would be trivial to disable window sorting or replace window titles with window classes in the window list. In the same way as it's easy to customize Sawfish, the only civilized (I mean scriptable and working) window manager I know about. The lack of this way of customization is a *big* drawback of both GNOME and KDE. Let's focus on that primary problem.
Yenya wrote: Desktop environments
We are talking desktop environments here, not Emacs. Emacs is not a desktop environment, just a terribly bloated and heavily mutated text editor. Desktop environment is about cooperation between different applications, possibly written in different languages. Not a single Emacs process. But you are right, the lack of scriptability and customization is the problem of current desktop environments. Emacs just has nothing to do with it, not being a desktop environment.
Milan Zamazal wrote:
I was talking about Emacs as my single-window terminal application, not as a desktop environment (which it isn't). If you don't like it, think about any other civilized terminal application instead, what I said still applies.