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

List:       kde-look
Subject:    Re: DockingApps and StyleGuide [Re: KMix major changes: Your help is
From:       Michael Reiher <michael.reiher () gmx ! de>
Date:       1999-11-17 2:20:57
[Download RAW message or body]

Matthias Ettrich wrote:
> 
> > > Also, why when I close the window, the KMix closed? why can't it be
> > > closed ONLY from the docked menu?
> >
> > Why? It simply does what every application does: It quits, when you
> > press the "close" button of the window manager.
> >
> 
> That's another thing that might be mentioned in the styleguide.
> 
> AFAIK we decided to let docking applications
> (http://ettrich.priv.no/components-docking.html ) behave like this:
> 
>     -  Hit iconify => hide the window and the taskbar entry (because the
>         docking icon _is_ conceptual a taskbar entry).
> 
>     - Hit close => close the window and the application as with other
>         applications
> 
IMO it is quite different from a taskbar button. Because applications
that dock in the panel are normally running for a longer time or even
always. They shall be easyly accessable but also space saving when not
needed. They normally  should remain there when I'm done with using the
applications main window and have closed it. And closing a window
happens normally with the X button. The X does not mean quit the
application, but close this window. 
An examle: I have kmix alway running docked and hidden. If I'm doing
some multimedia stuff I open it because I intend to use it fequently for
some time. It's now an application like any other on my screen. This
means also that I want it to minimize/restore to the taskbar like any
other app I'm currently working with. Restoring apps from the taskbar is
more convienient than from the docking area. When I'm done with my
multimedia stuff I don't need the mixer anymore as a normal app. But of
course I still want it to stay docked. So I Close it (with the X
button). Close for docking apps means for me "I'm done with you for now,
so go away and don't take up screen and taskbar space, but stay ready I
will need you again." It's completely illogical to have to minimize it
in order to keep it docked. Minimize means for me "just go away, but I
will need you very soon again" and that's not what the dock icon
resembles but the ordinary task button. 

So my proposal:

The main window:

The window close button only closes the window and removes it from the
taskbar. The dock icon remains.
The  minimizes the window i.e. it remains in the taskbar. The dock icon
remains as well.

The context menu over the dock item has an entry "Remove" or "Quit". I'm
not quite sure about that. If the window can only be "Closed"(which
would be consistent with the SDI approach) the context menu should only
offer "Remove". But this means that you have to do two steps for
completely quitting the app, first close the window then remove the icon
or the other way round. That's gonna be annoying if you already know you
will need the app only shortly. OTOH it's IMO no problem anymore if
docking is not default, because then only those applications dock that
the user _wanted_ to dock.

It has to have an File menu with a Close entry, which does the same as
the X button. 
It has to provide a config option under Options->Preferences for
enabling/ disabling docking. 
The menus are either in a menubar or like in knotes in the context menu
over the main window.

The dock icon:

A single LMB click on the dock icon opens the main window.
A RMB click opens the popup menu. It remains there until you select an
entry or click somewhere else. 
Keeping the RMB pressed and drag the cursor makes the menu disappear as
soon as it gets released. In case there is an entry under the cursor it
gets executed.
(actually this is the normal behaviour, but there were some discussion
recently. Don't know what came out of it)

> In the beginning of KDE-1.0, the CD player used to stay alive when users hit
> close. It just hided the window.  As a result, this was the number one support
> issue with KDE-1.0: People started the CD player. Closed the window. Started it
> again. Closed the window. Started it again. Closed the window. and so on. And
> (thanks to session management) they suddenly had 10 or more CD players runnign,
> with a lot of icons docked into the panel.  I agree it's hard to imagine that
> they didn't see the huge amount of CD icons in the panel and had no clue what
> to do with them, but fact is they didn't. Maybe it was because Linux User's
> were not used to icons ;)
Please, not again the CD player issue!
1. The CD player(and friends like kmidi, kmp3) have a completely stupid,
non standard user interface. So people often don't recognize the Exit
button as such. This is what needs to be fixed! The default interface
should have a menu and only a few _well known_ picture buttons. There
should rather be the possiblity to install skins for friends of the cool
look. If the user installs them it's his own fault.
2. The CD players context menu over the dock item has no
Quit/Remove/whatever button. This was for instance one of the first
places where I looked to get rid of this thing. But there was nothing. 


> 
> Things have changed, however. KDE-2.0 provides much more technology. So we could
> define CLOSE on docking applications to just hide the window but not to quit
> the application ( similar to MS-Windows) but at the same time _require_ docking
> applications to be KUniqueApplications, so that users can't lunch multiple
What has uniquness of apps to do with letting the app stay alive when
closing the window? i.e. why need they to be KUniqueApplications in this
case?
Of cource I agree that theres not much use in having several kppps, but
how is it related? For instance I could have several kbiffs for several
mailboxes and still only Close the main window.

> instances. I mean, why would anybody want to have two CD-Players? Or two
> knotes? Or two kppps and so on?
> 
> All one have to do is to reimplement
> 
>      virtual void newInstance(QValueList<QCString> params);
> 
> in KUniqueApplication to show the existing appliation window ( QWidet::show(),
> KWin::setActiveWindow(winId() ); )
> 
> But I'm not sure whether we want that. So I happily pass this on to the style
> guide team  :)
> 
> Any opinions?
see above:)

> 
> Matthias

Greets

Michael

-- 
Michael Reiher  
     Student at Dresden University of Technology
          Department of Computer Science
               email: michael.reiher@gmx.de

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