Aaron J. Seigo
Aaron J. Seigo <aseigo at kde dot org>
... sponsors my KDE work
aseigo> su -
Password:
linux:~/KDE/Kicker4.0 # _

Visual Elements For Kicker 4.0

This is a work in progress and the ideas are slowly forming and congealing. It is tricky to try and come up with something Brand New™ when you have a lot of prior art everywhere you look. So on the march towards a KDE panel for KDE 4.0 I'm starting not with visual descriptions but functional ones. Working with artists, people whose forté is visual experession, these elements will take shape in the form of story boards and mockups. Then the graphics developers and the application developers will breath life into the dreams. But here is where we begin, with the humble word.

As graphic treatments become available, I'll add my favourites here with comments and further thoughts.

Panels

Just as it is now, it will be possible to have multiple panels. However, these panels will not only be able to dock to the edges of screen but will also be able to float like an undocked toolbar. It may also be desirable to be able to stack panels together so that they become "connected" allowing simple two dimensional layouts to be created.

The edges of the panels and the interior will be styled independantly. Background pixmaps as they are now will be a thing of the past, and the only supported transparency will be via COMPOSITE. The ends, corners and edges of panels can all have unique treatments, so as to allow for maximum flexibility. Because these edges can vary in size and position, pixmaps may or may not be used. A plugin based theming system, much like KWin's window decorations, may well be the best approach allowing our coding capabilities to be the limits here.

The interior of panels will be themed so as to reflect the contents. This may take the form of "zones" where different types of panel elements (buttons, applets, etc) are placed or may reflect the individual contents above. The idea is to offer visual clues as to what is on that area of the panel, and the panel rendering will modify as the contents do. For instance, the applications menu may have a specific type of background rendering. Buttons or applets that need attention, have the keyboard focus or are currently hovered over may have distinct looks. Note that the current "button tiles" will be going away.

Note that this will only apply to standard panels. Other panels such as the Kasbar will have their own rendering plugins written for them.

The panel also must not be garish or busy. It should be elegant and peaceful to look at. It also needs to work in right-to-left mode, in vertical and horizontal lay outs and docked to a screen edge as well as floating. A panel scheme that looks distinct from normal windows is also a plus.

Hiding

Panels will still have hide buttons and these should be styled in a complimentary fashion to the rest of the panel. Panels will also be able to autohide and have hide animations. Both the buttons and the animations should be styled.

Mouse Hover Effects

In Kicker 3.4, when you mouse over a button an informatinal window appears with an animation giving extra information to the user. These should also be themable as part of the theme plugin. They are currently available to all buttons and applets so this will be a universally used item. It should accept, at a minimum, a graphic element such as an icon, a title text and additional descriptive text. Supporting simple interface elements such as push buttons in some cases may also be useful. Think of the various buttons and applets available on the panel and think of what sort of information that would be useful for them to share.

Extenders

Similar to the hover effects, "extenders" will be a standard graphic element available to all buttons and applets (including system tray icons). An extender will appear on a mouse click and will animate into view, appearing to come "out of" the panel. This may look like a drawer or an actual "growth" out of the panel. The purpose is to provide a generic area for the panel element to populate with custom widgets that don't need to be visible all the time and which would not otherwise fit comfortably in a thin panel. Think of the Kontact icon popping up a miniature version of the summary page, or the trash applet showing the contents of the trash in a list.

Panel Elements

Panel elements will no longer paint their own backgrounds. Instead this will be handled by the panel background. All elements will be able to be dragged around and between panels. How the dragging is handled visually is an interesting venue for exploration.

Panel Buttons

Buttons will still be primarily represented by icons, but some buttons may also have text associated with them. There are also a few button states to take care of, and transitional animations are perfectly find as long as they are subtle and now overly exagerated:

  • normal
  • inactive
  • newly created (there might be a fade in or "grow in" effect for this)
  • deleted (which should mirror the newly created state, if any)
  • activated (e.g. when clicked)
Additionally, there are three distinct types of buttons and each should look distinct:
  • standard click to activate buttons
  • buttons with a menu
  • buttons with both a click to activate action and a menu

Panel Applets

Applets may contain buttons, which are already abstracted into the main kicker library though currently many applet make their own buttons. Additionally it needs to be obvious where applets begin and end and how to get to controls to move, remove and access their applet specific menus. Whether this is done with applet handles as it is now or as some part of th background rendering is up to our imagination. Not having any indicator is not an option, however.

Applets will also be allowed to "float" without being in a panel. They may be attached to the desktop itself (under all other windows) or reside above all apps with an easy way to show and hide them. Arrangement of these floating applets and what this would look like needs to be determined.

Menus

Aside from the standard applications menu, we have the opportunity to do some innovative things here. Task based menus, project centric menus ... more on this later when I have had more time to consider various options. Input always welcome, however.

Dialogs

Dialogs will be replacing (or at least augmenting?) the current context menus for adding and removing items from panels. They should be obvious and easy to use. While drag and drop may be supported, it should not be the only mechanism employed for adding new items to the panel.

The Clock

The clock in Kicker 4.0 will be based on StyleClock, whose author has already agreed to work towards this goal. In addition to a few missing features (time zones and dates) and some new ones added (PIM integration for the calendar), three themes will be shipped by default with the rest available via GetHotNewStuff. The three tehemes will be an analog clock, a digital clock and a plain clock.

The System Tray

TBD

The Taskbar

The basic concept of a taskbar is pretty sound. I don't want to mess to much with the interaction elements of it, but an updated look would be most excellent. What should a task button look like? The following states need to be addressed:

  • just sitting there, nothing special is happening
  • when it's a group of tasks
  • when it's minimized
  • when it demands attention
  • when an application is launching (right now we have a pretty outdated looking "spinning hourglass" animation for this)
I'd like something with fewer bevels and more sophisticated looking than our current "bunch 'o buttons" taskbar. I'm also interested in making it more apparent which desktops the windows represented by the buttons are on and perhaps even providing more information in a nice hover-tip (screenshot, application name, desktop it's on, etc?)

The Pager

TBD

The Default Menus

TBD