[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