[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    KDockedWidget discussion (was Re: Current docking limitations)
From:       Aaron Levinson <alevinsn () inetarena ! com>
Date:       1999-04-10 16:53:57
[Download RAW message or body]

On Sat, 10 Apr 1999, Matt Koss wrote:

> This is another thing that should be put into the common KDockedWidget
> class. BTW is anybody working on this ?

I haven't worked on a KDockedWidget class, but I did create a
KDockedApplication class, which inherits KUniqueApplication (a really
awesome class).  It's currently available as part of Kmp3
(http://www.kmp3.org/).

The problem with a KDockedWidget class, as you might recall, is there was
no closure over how docking should be done correctly in our last
discussion, at least from a user interface perspective.  There were two
factions--one, where people wanted clicking the "X" button to hide the
main window and go to docking only (among other things) and one where
people wanted to obey common GUI conventions.

So, I did a little user interface research.

After looking at how docking is done is Microsoft Windows (in the System
Tray), I've determined that there is a use for the approach where clicking
the "X" button docks.  This technique is used in "persistent"-type apps.  
By persistent, I mean applications that are meant to always be active.  
Examples of this in Microsoft Windows are the Volume Control (ala KMix),
the Norton Antivirus Dock Icon, etc.  Double-clicking on the docked icon
in the SysTray, for these apps, causes a window to appear--the docked icon
remains.  Clicking the "X" gets rid of the window--the docking icon
remains.  Single left-clicking or right-clicking on the docking icon
causes a popup-menu to appear.

It is important to remember that the above Microsoft Windows cases are for
persistent applications, applications that are meant to always be running,
i.e. "stay-in-residence".  This policy, as a general rule, is easily
discernable by many or most Microsoft Windows users and is not confusing.

But, what about applications that are "one-time-usage" apps?
"One-time-usage" apps (for lack of a better name) are applications that,
in general, the user starts on his/her own, most likely from the Start
Menu.  It is quite possible that the user intends to use the app for a
long period of time, but it isn't meant to always be running on the
computer.  Some KDE docking applications that fit this "one-time-usage"
model are Kscd, Kmp3 and Kpm.  A Microsoft Windows application that fits
this model is the WinNT Task Manager (ala kpm).  When the main window is
visible, the docking icon is not used.  When the user minimizes (iconizes)
the window, it stays in the taskbar, but the docking icon also appears.
Double-clicking on the docking icon and single-clicking on the taskbar
entry causes the main window to reappear and the docking icon to
disappear.  When the user clicks the "X" button, the Task Manager
immediately exits.

Various KDE docking apps add the useful "Hide/Show" functionality to
Microsoft's one-time-usage model, allowing the user to completely hide the
window, removing it from the taskbar, and leaving the docking icon.  It is
important to note that this is also the default state for persistent
docking apps, although with persistent apps, the docking icon is
frequently the only window, and double-clicking it starts an application
that is associated with the docking icon.  The user can then control the
application from the docking icon, which is visible on all desktops.  
This functionality minimizes the use of space on desktops that are
frequently cramped and is also easily accessible.

All this discussion is meant to provoke KDE docking application authors
out there to really think about how docking should be implemented!  Does
your application fit into the "persistent" category, or, in the general
case, does it follow the "one-time-usage" model?

I think the correct way to go about doing the KDockedWidget class is to
create a generic KDockedWidget class and then create two subclasses,
KPersistentDockedWidget and KOneTimeDockedWidget (or
KSingleUsageDockedWidget).

What do you think??

Aaron Levinson

[prev in list] [next in list] [prev in thread] [next in thread]