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

List:       kde-usability
Subject:    Re: [KDE Usability] Close button: reaaly close or go to system tray?
From:       Kevin Krammer <kevin.krammer () gmx ! at>
Date:       2010-01-30 16:10:43
Message-ID: 201001301710.54169.kevin.krammer () gmx ! at
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday, 2010-01-30, Peter wrote:
> On Saturday 30 January 2010 12:31, Kevin Krammer wrote:

> > The icons usually used to represent their respective applications are
> > windows embedded into the window provided by the desktop shell.
> > It has little to no control over the representation, e.g. resizing, when
> > to show/hide some of them etc.
> > Visualization of and interaction with these representations is therefore
> > potentially inconsistent by design, the shell cannot do anything about
> > apps doing stupid things.
> 
> I take it shells are distinct beasts to apps such as klipper?

Shell is basically the word used for the concept of desktop, panel (plus their 
respective widgets) and window manager.

The thing you have before you launch any application, that remains after 
you've shut down all applications.

Hmm, the visual parts of the "desktop environment".

> > Most applications do not have the need for a permanent process running
> > without a user interface since their job is mostly or entirely user
> > interaction bound, e.g. editors, viewers, a lot of games, etc.
> 
> Okay, my understanding is that we're focusing only on apps that must run
> something 'after they quit', such as Amarok's player. It is these apps
>  which create inconsistent behaviour. Users expect Amarok to quit and
>  remove the player so the music stops immediately. However, users do not
>  want Amarok taking up screen space when they want to listen to background
>  music. So, they want Amarok to quit properly, but still listen to
>  background music. A similar situation exists for KMail, Juk, etc, but not
>  Kate, Konqueror.

An application that quits must not run afterwards. I has quit, stopped 
working, process has exited, operating system has freed all resources 
associated with the process.

The discussion is whether to quit when a specific interaction interface is 
closed despite other interaction interfaces still being available.
E.g. in the case of Amarok, whether it should quit just because the windowed 
interface has been closed despite the iconified interface still working.

> > > We also need to recognize that pps range from almost no user
> > > interaction (e.g. klipper) to fairly frequent (e.g. Amarok player).
> > > Their scope also ranges from system wide (e.g. klipper) to app specific
> > > (e.g. Amarok player). Their persistence likewise range from permenant
> > > (e.g. klipper) to transient (e.g. Amarok, KGet).
> >
> > I understand that you picked just examples but I think you are at least
> > missing scope "session wide" (e.g. klipper) because "system wide" is more
> > like "e.g. network manager".
> 
> That's possible, the idea of scope is wrt apps interacting with the pps,
> without regard to any other criteria. Perhaps it should be 'generic' rather
> than 'scope'?

No idea, I just wanted to point out that system wide is different from session 
wide. The former is "for all users" the latter is "per user" (well, actually 
per user session).

> > The "permanent vs. transient" is purley a matter of how something is
> > launched, e.g. Amarok becomes "permanent" in your model if it is started
> > by autostart or session restore.
> > I would actually go as far as say that all applications using a secondary
> > representation in system tray assume "permanent" usage just like those
> > which have this as their primary representation.
> 
> My point here was to clarify that a persistent process is still constrained
>  by time, they don't necessarily persistent 'forever'. This means any app
>  that leaves a process to 'clean up' (complete a download, for example),
>  after quitting qualifies as a persistent process, even though it may only
>  exist for one or two seconds.

I see. However, I don't think those fall into the same category. Something 
that quits will go away, no way to get it back short of starting it again, 
e.g. KMail compressing mbox folders when exiting.

Something that is "permanent" will just wait for a new controlling interface 
to attach, e.g. network manager continuing to work when user sessions exit and 
take down interaction interfaces like KNetworkManager.

> > Usually KDE applications have a Quit action, shortcut defaulting to
> > CTRL+Q. Quitting through closing the last window is an additional
> > facility, sensible for a lot of applications (see above).
> 
> The problem isn't with the app's interface behaviour, but that it continues
> running 'in the background' as a non-gui process. To the user, it has
>  failed to 'quit' as expected. These apps are now assuming the role of a
> non-interactive process (e.g. background music).

I am not sure there are many of these type of applications yet.
Since you mentioned music, are we talking about an interface to a music player 
daemon like mpd?

> > > 2- Apps should minimize on quit to run persistent processes.
> > >
> > > Arguments for minimizing are apps are written such that it is the only
> > > way they can run pps. Arguments against this are that it is
> > > inconsistent behaviour and confuses/annoys users. (Not the same as 4)
> >
> > I am not sure I understand this one. An application that quits does not
> > run afterwards. I am not an English native speaker but I understood
> > "quit" to mean "stop doing"
> 
> Exactly what most users expect, too. Unfortunately, Amarok does need to
> continue running because it is now a persistent process, playing music. The
> traditional 'quit' behaviour is emulated by the app minimizing itself (it
>  has indeed 'gone away'), but users are not fooled when they see it
>  minimized.

Amarok always exitted properly on quit for me. I would consider anything else 
a bug.

This thread, however, seems to discuss whether to quit when closing a specific 
interaction interface.
Or to phrase it differently, whether to quit on close of last window vs. quit 
on close of first window.

> The argument is that this behaviour is the right one for apps with
>  persistent processes, they must minimize instead of quitting.

So you suggest that closing does not always close but minimized for certain 
applications?
Isn't that bad for consistency when you have to know about the implementation 
internals?

> > I think you are mixing things up.
> > The system tray is currently used for applications that either do not
> > have a top level window or which expect their top level window to be of
> > transient nature.
> 
> Exactly. The problem is Amarok etc. cannot make their top level window
> transient because it is intergrated with the persistent process as a
> consequence of historical development.

Could be, I don't know whether Amarok destroys the window on close or if it 
just hides it.
There is basically no difference from a user's point of view other than 
probably a bit more memory still being consumed when it is just hidden (with 
the advantage of it being shown faster on request later on than when it would 
have to be recreated).

> > > 4- Apps should quit on close and minimize to the sys tray.
> > >
> > > The arguments against this are: minimize is done to the task bar and
> > > the sys tray is not the place for minimized apps. This may be a moot
> > > point if the sys tray is replaced with K Status Notifier Item (KSNI). 
> > > (Not the same as 2)
> >
> > Right. Closing the window when minimizing is definitely wrong.
> > There are two different actions for a reason.
> >
> > "Minimize to tray" is a kind of weird attempt to phrase the "get rid of
> > window, keep running" part of reducing interaction options to the
> > secondary interface in terms already used for something completely
> > different but with similar visual effects.
> 
> Exactly, and this bothers users. Our problem is that most apps cannot
>  behave as expected and therefore opted to emulate the behaviour, creating
>  window management issues.

Hmm. Can you give an example of an application which minimizes to tray instead 
of properly minimizing?

I tried with a couple of apps I've installed and they all minimize their main 
windows correctly.

> > > 5- Apps should have a front-end gui and back-end persistent processes.
> > >
> > > There has been little comment on this, possibly because it is an
> > > implementation detail and the change doesn't seem to change anything.
> >
> > This doesn't make sense for all applications in general, those for which
> > it does are moving towards such a service oriented approach.
> 
> Agreed, only apps that need something to survive a quit, qualify for this
> model.

Right.

> > Summarising I am still confused why the current concept of "closing of
> > last interaction interface quits application" is considered bad because
> > most applications cannot do anything useful once the user can't interact
> > with them anymore.
> 
> The point here is that some windows attach to a non-gui process to allow
>  the user to interact with the _process_ (e.g. player). However, they
>  actually have the process intergrated into the window and cannot quit the
>  window without destroying the process as well (e.g. stop playing).
> 
> > And I think all of the applications with more than one interaction
> > interface do offer an explicit quit action for cases where having to
> > close all interaction interfaces would not be nice.
> 
> I missed that suggestion in my previous post: My objection is that it
>  includes a specifically non-gui element into the gui. Non-gui management
>  should, imho, be done at the app level, not by the window management
>  system.

Hmm, which non-gui element are you referring to? Both the quit action as well 
as interaction interfaces such as window or system tray icon are gui elements.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

["signature.asc" (application/pgp-signature)]

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability


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