Idea
#5488: Hide Rhythmbox on close
|
| |
165
|
|
|
Written by Creak the 23 Mar 08 at 12:37.
Category: Multimedia.
Related to:
Nothing/Others.
Status: New
|
|
|
Description
One of the most annoying stuff in Rhythmbox: when you close the window, it quits the application. I just wanted to get rid of the window on the desktop, that's all.
I know some person like this behavior. So a solution would be to add a checkbox to enable/disable the "hide on close" in the preferences.
Edit> IMO, once an application is in the systray, "close" differs from "quit" (i.e. you "close" the window, but you don't "quit" the program).
Tags:
(none)
Attachments
Duplicates
Comments
|
joeally wrote on the 23 Mar 08 at 14:55
| |
naa i don't think this should be enabled by default. Just change in preferences.
|
|
Eldmannen wrote on the 23 Mar 08 at 15:19
|
Ehh, its annoying that it close when you click the close button? :D
It does what it supposed todo. If you want hide the window, click on the Rhythmbox icon in the upper-right corner of the screen where the clock is.
|
|
Creak wrote on the 23 Mar 08 at 15:33
|
Then why pidgin hides in the systray? Why transmission also hides in the systray? What I mean is that it feels normal that once the application is in the systray, closing its window send it back to the systray.
There is a difference between "close" and "quit". And once an application is in the systray, close shouldn't quit, imho.
And I'm not asking for enabling it all the time, I'm just asking for a checkbox so that everyone could choose the behavior he likes.
|
|
Eldmannen wrote on the 23 Mar 08 at 15:51
|
The behaviour of applications should be consistent across the system.
Applications should behave as expected.
|
|
Creak wrote on the 23 Mar 08 at 16:22
|
If you want consistency, I'd say that quiting the applications when you close the window isn't really consistent, but it "feels right".
If you look at Mac OSX guidelines, you'll see that when you close a window, the application never quits. You have to select "Quit" in the app menu to really quit it.
I expect that once an application is in the systray, it means that I'll use it in background all along my session. So I don't think it's that much inconsistent to have the choice to only close the window (i.e. and not quit the application) when you actually close it.
|
|
Ssdg wrote on the 23 Mar 08 at 21:49
| |
I love the idea. But unchecked by default in the "preferences" panel. (Because other people might be surprised bye this behavior)
|
|
mafitzpatrick wrote on the 23 Mar 08 at 22:30
|
I don't care either way but I wish all applications did it the same. Sigh :)
Thing is, for apps without system tray icons closing the window *has* to close the application. So to be consistent with that, apps with system tray icons would also need to close when the window is closed.
I've wondered for a while why there isn't an additional toolbar icon for "minimise to tray" - it could be put in the place of the X if preferred. Or make plain old minimise drop them to the tray (makes more sense than "close" doing that :)
|
|
duda.rio wrote on the 24 Mar 08 at 05:41
| |
Some Windows apps, not writen by oncle Bill, of course, have a fourth option on the window to "minimise to tray".
|
|
Ralf.Nieuwenhuijsen wrote on the 24 Mar 08 at 10:00
|
Close should be QUIT.
You click on the icon in he system-tray to minimze the app there.
|
|
Creak wrote on the 24 Mar 08 at 11:24
|
@duda.rio: I'm not really fond of the fourth button in the title bar.
@Ralf.Nieuwenhuijsen: As I said, we all like different look&feels and it's perfectly normal. But adding a simple option in the preferences would satisfy everyone. And, as far as I can see, I'm not the only one to think that.
|
|
frandavid100 wrote on the 24 Mar 08 at 11:59
|
"I don't care either way but I wish all applications did it the same. Sigh2
Agreed on that one. Maybe we should be filing some bugs on Transmission, Pidgin...
|
|
linbai wrote on the 26 Mar 08 at 01:13
| |
Should be "hide on minimize"
|
|
Ralf.Nieuwenhuijsen wrote on the 8 Apr 08 at 10:18
|
@Creak
Adding an option is fine. But it shouldn't the default option. Also, i still think that the ubuntu/mac way of doing this is the superior usability experience. No reason to cripple software because people are used to using crippled software. They are using Ubuntu because they want to move away from that. Not because they want a free alternative that copied all the design mistakes.
Finally, if this is an option, it should be general gnome option and be applied to all tray-like-programs (transmission, pidgin, etc.)
We need to keep things at least _consistent_, otherwise it will just get messier.
|
|
Creak wrote on the 14 Apr 08 at 17:00
|
I totally agree. And, to me, it feels like the hide on close is the most used among systray programs.
And some programs like sound, calendar, update-manager, etc. uses other behaviors. For some (sound, calendar), clicking on it shows a dialog window without close button. For other (update-manager), clicking on it open the real application.
I agree that all these programs aren't exactly in the systray, but it like it for the user. And in all cases, the icon _is_ persistent.
|
|
zedlander wrote on the 11 May 08 at 20:20
| |
Yes, let's make this a non-default option, please :)
|
|
pistache wrote on the 30 Jun 08 at 10:35
|
I agree that many users expect any Gnome application to quit when the main window is closed.
But, some other users may want Rhythmbox to hide in the tray, so to make a non-default option would be great and many users would be pleased (including me)
So let's make this a non-default option, please :)
|
|
deadowl wrote on the 30 Jun 08 at 13:20
| |
Biggest problem: it isn't consistent with Pidgin and Ekiga. Many programs just ask when you hit the X button for the first time.
|
|
vincenzo_ml wrote on the 14 Jul 08 at 10:30
|
Are there other applications that use the notification area, in the default installation, that behave like rhythmbox? How many of them behave like pidgin? In my opinion if the window has to quit the application, then the application shouldn't have a notification area icon enabled by default. That will confuse all users that have seen any of the other music players with a notification area icon.
In my opinion totem gets this right. It took a while to get used to the fact that if I click an mp3 and close the window, then the music stops, but since there is no notification area icon, this is right. If there is an icon, then the icon should survive the window.
So if you are concerned that our users will expect something, then why not disabling the notification area icon entirely by default for consistency? People who want the icon will go to configuration to see if there is a possibility, and will also discover an option to "close don't quit".
There is a bug on launchpad that lasted two years and was finally solved by providing a plugin. This closes the bug but leaves the default desktop inconsistent.
https://bugs.edge.launchpad.net/rhythmbox/+bug/38512
|
|
christian.apolloni wrote on the 14 Jul 08 at 11:56
|
At the moment I have seen the following behaviours:
1. Permanent icon in notification area: once the application is running if you close the window, the application keeps running in the notification area. Example application I guess is Pidgin. It is my understanding this is the most common behaviour among applications which use the notification area.
2. Notification area used only for notifications: the application running normally has no icon in the area, an icon is shown only when there is something to notify the user about. Example application update manager? I guess this is the correct, intended usage of the notification area.
3. Not-so-permanent icon in notification area: like 1 but if you close the window the application quits and the notification area icon disappears. Example is Rhythmbox. It is my unterstanding that this confuses users since it is the less common behaviour.
4. Applet: if you want some permanent icon you put an applet in the bar. Example application is Tomboy if I remember correctly.
So, I guess the intended behaviour explained in the GNOME guidelines for applications should be to use the notification area _only_ for notifications, and should not show an icon there for merely running. If the user wants a permanent icon he should use an applet.
That would make things consistent but I am not sure the users would like it, not to mention the developers of the concerned applications. Nowadays the notification area is basically used like the windows tray icons area and I can think only of a couple applications which actually use it the intended way (update manager, mainly).
|
|
vincenzo_ml wrote on the 14 Jul 08 at 16:27
|
Christian: I also thought that an example for (2) would be update manager, however in the end even update manager uses (1): as soon as you get a notification, if you open the update manager by clicking on the notification area, and close it, the "updates available" icon will not disappear. It really seems that the only application using (2) is rhythmbox.
An applet is for really permanent things that get loaded at login. An use case that is not contemplated if we faithfully stick to the hig, hence we say "notifications in the notification area, permanent applications as applets" is when you want to use a long-running application, whose main window you don't need so frequently. Examples include instant messaging, download managers and ... music players. An applet would not solve the problem since applets are not expected to disappear at any point of their execution.
|
|
christian.apolloni wrote on the 14 Jul 08 at 19:07
|
From the perspective of the user the update manager is "always running". The notification appears when there are updates and goes away when the updates are done. In my opinion this behaviour is as (2).
Rhythmbox does not use the notification icon to notify anything, it is used to control the application, why are you categorizing it as (2)?
The GNOME HIG says the notification area should be used preferably for temporary icons which appear in response to events. There is a parapgrah explaining when an applet should be used instead of the notification icon but it is not clear to me:
http://library.gnome.org/devel/hig-book/2.22/desktop-notification-area.html.en
I'd appreciate an explanation from a native English reader.
|
|
rlaager wrote on the 14 Jul 08 at 19:54
|
I think vincenzo_ml hit the nail on the head here. The problem is that the HIG is optimizing for a small notification area and thus wants things there temporarily only: "The utility of the notification area decreases rapidly when more than about four icons are always present. For this reason, icons that appear only temporarily in response to events are preferable."
On my laptop, I regularly have a battery icon, network manager, a music player, and an IM client.
I think there are two issus here:
1. Either the HIG is right and Rhythmbox, Pidgin, etc. should use applets OR the HIG is out-of-touch with reality and should be updated to address those cases.
2. Regardless of tray icon vs. applet... Rhythmbox is a clear exception to the hide-on-close majority. Is that because Rhythmbox's developers are in the (apparent) minority that prefer that behavior or is it because music players in general should be treated differently than, say, IM clients. If it's the latter (which I don't believe it is), then we should update other music players that have tray icons. If it's the former, then either Rhythmbox should be patched to override the upstream developers so everything is consistent, or more likely, we should add a GNOME-level preference for this and make applications respect it.
Given that people seem to come down differently on what applications should do (as opposed to IM clients or music players specifically), I think there should be a GNOME-level preference for this.
Music players and IM clients both seem to fit well in the notification area, because it gives you a natural place to anchor your notification pop-ups (on song change or new message, respectively). Tomboy, however, doesn't really have notifications, so doing it as an applet (and allowing you to place it independently) seems useful. For this reason, I think the HIG should be updated.
|
Post your comment
|
|
|
Bug #38512
Ubuntuforums.org thread #733830
