[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: [KDE Usability] Close button: reaaly close or go to system tray?
From: "Jos Poortvliet" <jospoortvliet () gmail ! com>
Date: 2010-01-26 11:53:40
Message-ID: 4b5ed7d4.16115e0a.0543.56e1 () mx ! google ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
--
Sent from my mobile computer using Nokia Messaging
----- Original message -----
> > My perception has been the sys tray is for server/client apps. Whether a
> > server/client consists of two distinct apps, or one divided into two parts,
> > is irrelevant to the user because the user appears to invoke and close the
> > client 'app', while the server 'app' continues running.
> >
> > The quit/close is therefore consistent when viewed from a server/client
> > perspective, but not as stand-alone app.
> >
> > For example, we don't expect closing our client browser will also close the
> > site server we're connected to. Similarly, closing amarok's 'client' should
> > not close its 'server' in the sys tray. Imho, the problem is assuming we're
> > only dealing with one app, rather than two.
> >
>
> If the user were to open two applications (i.e., click on two icons)
> then I would accept that arguement. Seeing how the user clicks a
> single Amarok icon, I disagree.
I think this isue transcends the close button thing. At camp KDE a few ppl discussed \
this: there is a category of applications, currently often 'closing' to the systray, \
which is indeed more service lik than other apps. A word processor or a webbrowser is \
supposed to be there while you work with it and go when you no longer need it. \
However, music players, chat applications and more (often social media stuff) is \
different: they need to stay available in the background. The systray is a poor place \
for such applications/services and another solution must be found for this. For \
example, creating a special service plasmoid area; making these apps split back- and \
frontend and upon closing keep only the backend running; or have a kded or plasma \
dataengine or so take the place of the app's functionality. Compare having the 'news' \
plasma applet, and whenever you want more info you click the 'full app' button on the \
applet (new in plasma 4.4). Anyway. We won't sove it in this thread but i hope some \
developers interested in this issue will start thinking and experimenting. And you \
usability ppl might have iedeas too. Cheers,
jos
> --
> Dotan Cohen
>
> http://what-is-what.com
> http://gibberish.co.il
> _______________________________________________
> kde-usability mailing list
> kde-usability@kde.org
> https://mail.kde.org/mailman/listinfo/kde-usability
[Attachment #5 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" \
"http://www.w3.org/TR/html4/loose.dtd"> <html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="generator" content="Osso Notes">
<title></title></head>
<body>
<p>
<br>--
<br>Sent from my mobile computer using Nokia Messaging
<br>----- Original message -----
<br>> > My perception has been the sys tray is for server/client apps. Whether \
a <br>> > server/client consists of two distinct apps, or one divided into two \
parts, <br>> > is irrelevant to the user because the user appears to invoke and \
close the <br>> > client 'app', while the server 'app' continues running.
<br>> >
<br>> > The quit/close is therefore consistent when viewed from a server/client
<br>> > perspective, but not as stand-alone app.
<br>> >
<br>> > For example, we don't expect closing our client browser will also close \
the <br>> > site server we're connected to. Similarly, closing amarok's \
'client' should <br>> > not close its 'server' in the sys tray. Imho, the \
problem is assuming we're <br>> > only dealing with one app, rather than two.
<br>> >
<br>>
<br>> If the user were to open two applications (i.e., click on two icons)
<br>> then I would accept that arguement. Seeing how the user clicks a
<br>> single Amarok icon, I disagree.
<br>
<br>I think this isue transcends the close button thing. At camp KDE a few ppl \
discussed this: there is a category of applications, currently often 'closing' to the \
systray, which is indeed more service lik than other apps. A word processor or a \
webbrowser is supposed to be there while you work with it and go when you no longer \
need it. However, music players, chat applications and more (often social media \
stuff) is different: they need to stay available in the background. The systray is a \
poor place for such applications/services and another solution must be found for \
this. <br>
<br>For example, creating a special service plasmoid area; making these apps split \
back- and frontend and upon closing keep only the backend running; or have a kded or \
plasma dataengine or so take the place of the app's functionality. Compare having the \
'news' plasma applet, and whenever you want more info you click the 'full app' button \
on the applet (new in plasma 4.4). <br>
<br>Anyway. We won't sove it in this thread but i hope some developers interested in \
this issue will start thinking and experimenting. And you usability ppl might have \
iedeas too. <br>
<br>Cheers,
<br>
<br>jos
<br>
<br>
<br>> --
<br>> Dotan Cohen
<br>>
<br>> <a href="http://what-is-what.com">http://what-is-what.com</a>
<br>> <a href="http://gibberish.co.il">http://gibberish.co.il</a>
<br>> _______________________________________________
<br>> kde-usability mailing list
<br>> <a href="mailto:kde-usability@kde.org">kde-usability@kde.org</a>
<br>> <a href="https://mail.kde.org/mailman/listinfo/kde-usability">https://mail.kde.org/mailman/listinfo/kde-usability</a>
<br><br></p>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic