Modern desktop environments all seem to suffer from similar problems which, at the back end, have similar causes. Some examples from Windows, which apply to other environments too:

  • You click on the ‘start’ menu button and the menu doesn’t appear instantly. You wait... nothing happening, so you wonder if you missed it, and click again. Immediately after you did this, the menu appears and then disappears in the blink of an eye.
  • You right-click on a file but the menu doesn’t appear yet, so you think you missed, and click on something else, but the menu is there (logically, at least) as you click the the second time, so you end up doing something to the file you clicked on first, but you might not know what. Deleting is possible. If you’re in Windows, and you deleted a file on a network drive, there’s no ‘undo’ and there’s no ‘recycle bin’. Time to restore from backup.
  • You ‘launch’ a document by clicking on its icon/name. It doesn’t appear immediately, so you assume there’s something going on which is making your computer sluggish and switch back to whatever it was you were doing before you decided to open the document. The application which handles editing of the document appears five seconds later. You were typing, and just about to press Return. The dialog which the newly-started application has shown is accepted, but you didn’t get a chance to read what it said. You don’t know what you’ve just said yes to. Now you get to see an empty application window for a few seconds while the app loads your document.

There are very good technical reasons for desktops working this way. The ‘start’ menu is there because it’s shown by a program, e.g. Windows Explorer or kicker. Explorer and kicker are just applications. They have to wait their turn on the processor like other applications. You can increase their priority, but that’s a hack, which will alleviate, rather than fix, your problem with the menu.

The problem with the menu in the file manager is slightly different. The fact that the file manager might not be able to use the CPU at the moment is only part of the story. The other problem is that the application itself has trouble getting the menu visible immediately. This is true even when no extensions have been added to the menu. It’s really down to poor internal application design.

The last problem, with applications ‘stealing’ focus, has recently been partly dealt with. KDE beat the problem years ago, but it was easy to do so, running on X11, where the window manager is in control of which windows are allowed to do what.

Windows XP also has a mechanism for stopping windows ‘stealing’ focus. Most of the time it works perfectly. The only applications it doesn’t work with are Microsoft’s Office applications. Slightly ironic, I know.

Years ago I came up with a plan for fixing at least the first two problems above, but unfortunately it’s not one that’s easy to implement, as it involves completely replacing the GUI code in all applications.

My plan was to have the entire GUI handled in one process, which runs with realtime priority. This is a little like giving X11 realtime priority, except that it goes further: X11 deals mainly with graphical primitives (lines, rectangles, text) and windows. My plan was to extend this to handle every commonly-used GUI element, including scrollable areas, scrollbars, menu bars and pop-up menus, buttons, checkboxes, combos, etc. etc: the graphical elements that are provided in toolkits such as Windows.Forms, Qt, Motif, etc.

Applications would post descriptions of their windows to the GUI server, which would ensure that all elements were rendered as fast as possible, without pausing to let another process run.

I was very keen on my own idea until I realised that, of course, it wasn’t a panacea: application developers would still design bad GUIs which didn’t respond as the user expected. Look at any web page to see how badly the user is dealt with. How often do you click a button and are not sure if something is happening which you should wait for?

My GUI plan could simply make the desktop as bad as a web application. The model would be similar. To be honest, it’s pretty similar to simply running a full-screen web browser with realtime priority and only using web apps. That’s a scary thought. Let’s not do that.

Write comment
No comments