Ideas for KDE

Like any longtime user of KDE, I have various ideas about how it could be made better, and many more ideas than I have time to implement personally. I'm collecting them here for my own reference; and, what the hell, maybe someone with more spare time will come across this page and implement one or two of them. I do not claim that these ideas are original; other people have undoubtedly had them before, but usually they're archived on on old mailing list posts or bug reports. This is just an attempt to record, in a more widely accessible form, my current favorite ideas for improving KDE.

"Kupertino": Reproduce some good ideas from MacOS Classic user interface

Many things about Macs (ranging from their proprietary hardware monopoly to their frequently smug, sanctimonious users) annoy me, but Apple had a great user interface design team. Many aspects of the original MacOS user interface deserve to be imitated. A few alterations to the KDE UI would give it a much more Mac-like feel:

• Modify shared QMenu to support "menulets", or merge shared menu with Kicker.

  In the style of MacOS, KDE already supports an optional "shared menu", at the top edge of the screen, which replaces the separate menus for each application window:

  

  This has a number of benefits: it makes the menu quicker to select (because of Fitts's Law) and it also saves screen space by decreasing redundancy (there's seldom a need to see the menu for more than one application at once).

  Currently, using the "shared menu" wastes a lot of screen space, and is redundant with the Kicker (the main KDE task bar). If applets---like a task manager, clock, and extra menus---could be docked inside a QMenu, this feature would actually be practical, and more like the real MacOS menu.

  An alternative implementation approach would be to allow the shared application menu to be docked inside Kicker, which could then be placed on the top screen edge:

  

• In file management modes, modify Konqueror to act like a "spatial" browser.

  The idea behind a "spatial" browser is that all browser objects (files and folders) should appear in the same screen position whenever they are accessed. This allows the user to accumulate "muscle memory" for the screen locations of frequently accessed objects.

  In a spatial browser like the original MacOS Finder, a Finder window for a given directory always pops up at the same location on the desktop, and is always the same size and shape (unless the user changes it, in which case the size and shape are always remembered for next time). Additionally, the position of each icon inside a directory's Finder window is remembered---when the user drags and drops an icon inside a Finder window, then the next time the window is opened, the icon appears in the same location.

  In order to make Konqueror behave like a spatial browser, it needs about three changes:

  1. Konqueror should remember the placement of icons. This should not be a major problem---the KDE Desktop already remembers where icons are placed. The relevant code has to be ported to the general Konqueror file view.
  2. Konqeueror should cooperate with kwin (the KDE window manager) to remember the locations and window sizes of file views.
  3. Konqueror already has an optional behavior wherein every folder opens a new window. This behavior should be augmented with a special modifier-click action (say, Alt-click) that both opens the folder in a new window and closes the currently open window. This would be equivalent to Option-doubleclick on MacOS classic. Without this command, the "open in new window" policy is pretty much unbearable---the desktop rapidly clutters with dozens of folder windows.

  Individually, none of these changes sounds all that hard to me. Unfortunately, I don't have time to implement them personally.

"KPlugWin": Enhanced title bars.

Back when I used Windows 3.1, there was a shareware package called PlugIn for Windows. It was written by a little outfit called Plannet Crafters (sic.), and it was so cool that I actually paid the $24.99 registration fee. PlugIn enhanced the Windows GUI shell environment in many ways, and one of them was added display functionality for title bars. Here's a screen shot:

For those of you who aren't familiar with the Windows 3.1 interface, the window menu , minimize , and maximize buttons were standard. PlugIn added two things:

• An extra button that brought up the "PlugIn" menu. The PlugIn menu was highly user-configurable. I set it up to include shortcuts for launching all my commonly-used applications. Because you could bind the PlugIn menu to a keyboard shortcut, I was able to launch every application on my system with three keystrokes.
• Customizable information displays for the left and right ends of the title bar. In example above, the left side shows the amount of free space on the hard drive, and the current percentage of free RAM; and the right side shows the current date and time.

It would be nice to be able to add a PlugIn-like extension to KWin title bars. The first implementation stage would be to augment one of the window decoration styles---say, KStep---with this functionality. The second stage would be to write some more generic plug-in system so that these extensions could be applied to any KWin decoration that supported the proper API.

If Kupertino (see above) were to be implemented, it would reduce the need for title bar extensions. For example, if the system-wide menu contained a clock, it would be unnecessary to display the time in the title bar. But it still might be nice to be able to add extra information in the title bar. This might be appropriate for information about the current window (How much CPU is this application consuming? How long has it been running? etc.), or for information that wouldn't fit on the menu/Kicker (Kicker is pretty cluttered as it is).