Window close should close, not quit

Bug #38512 reported by Richard Laager on 2006-04-06
62
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Rhythmbox
Fix Released
Medium
rhythmbox (Debian)
Fix Released
Unknown
rhythmbox (Ubuntu)
Wishlist
Ubuntu Desktop Bugs

Bug Description

Clicking the close button in the window titlebar should be the same as choosing File -> Close -- it should "minimize" rhythmbox to the tray. Currently, clicking the window close button quits the application.

Related branches

Sebastien Bacher (seb128) wrote :

Thanks for your bug. The close button is supposed to close the application, that's a feature not a bug, I'm rejecting it since that's not a bug

Changed in rhythmbox:
assignee: nobody → desktop-bugs
status: Unconfirmed → Rejected
Richard Laager (rlaager) wrote :

I disagree. Look at what Gaim does in the same situation.

With rhythmbox, if I click minimize, it minimizes to the tray. If I click close, it quits. There is no way that I can see to minimize it to the tray from the application itself. I have to go up and hit the tray icon. This consequently means I can't use a keyboard shortcut to minimize it to the tray either, like I can with Gaim where the window close action is mapped to the minimize to tray behavior when the system tray plugin is active.

Sebastien Bacher (seb128) wrote :

There is no way to make everybody happy on that. rhythmbox behaviour changed during 0.9.n versions and I complained upstream about closing button not closing the application, I'll not complain other way now ;) Feel free to go argue upstream directly though

Sebastien Bacher (seb128) wrote :

note that Ctrl-W does minimize to the tray with the keyboard

Richard Laager (rlaager) wrote :

I'll look into Ctrl-W.

However, if there is no way to make everyone happy and they're two legitimate viewpoints, then they need a pref. I know the rationale for keeping prefs down, and I support it, but this might be one of those cases.

Sebastien Bacher (seb128) wrote :

having the behaviour changing between boxes and applications is just confusing, what is your issue with having the close button closing an application?

Richard Laager (rlaager) wrote :

Applications that have a tray icon are generally long-running. (Why else would they have the ability to minimize to tray?) Thus, the desired behavior when I close that window is that the application keep going. The desired behavior when I close other apps (say Firefox, GnuCash, OpenOffice.org, etc.) is that they close, as I'm done with them.

Rhythmbox and Gaim are the two applications I use that have a corresponding system tray icon. I close applications with Alt-F4, which is, of course, my window manager's close window mapping. Having Ctrl-W in Rhythmbox minimize to tray achieves the desired effect, but there are two flaws:

1. It's a per-application setting. The window manager close functionality is consistent across apps. I can't map Alt-F4 to that menu item, can I (as it's already caught by the window manager)?

2. It's inconsistent. The menu item that Ctrl-W maps to is "Close", not "Minimize to Tray". Therefore, I expect the close button on the window to have the same effect as that menu item. The "X" on a window is not a "quit" application button, it's a "close window" button. If I click it on a dialog for an application, the application doesn't quit. That window goes away. Therefore, we already have a precedent for context-specific behavior of the close window button.

Sebastien Bacher (seb128) wrote :

GNOME HIG should probably have a recommendation about that and application stick to it. Anyway having behaviour changing between distributions is not nice, better to argue upstream if you want to, we are not going to make a distribution specific patch for that and I'm not going upstream to argue on that because I prefer the current behaviour personnally

Simone Tolotti (simontol) wrote :

Adding an option in preferences could solve this...
Listen for examlple has a "close in system tray" option that you can enable.
Please move this to wishlist...

Richard Laager (rlaager) wrote :

This came up again with Pidgin...

(12:52:57) John Bailey (rekkanoryo): I can think of AIM, yahoo, windows live messenger, mozilla seamonkey, I believe myspaceim, and a bunch of others whose names aren't occurring to me right now that force the default of close button == send to tray icon

Also, Banshee uses close-to-tray.

Vincenzo Ciancia (vincenzo-ml) wrote :

All applications I know that have an icon in the system tray can show a window when clicked, but closing that window will not make the application quit or the icon disappear from the systray. Is it ok to close a window, but the application in this context is represented by the systray icon, like it was an user-launched daemon. There exist two different _objects_ on screen: the application, in the systray, and the window.

Also, the HIG has been mentioned here. If I click on the close button of a given window, the _window_ must disappear, not a different object that I have in the tray. This is in the HIG. Rhythmbox is currently violating the HIG not doing so. When I click on the close button, and hear music stopping, and see the tray window disappear, I swear. Really. Because it's not normal that I close a window and the tray icon goes away.

If this is not the intended behavior then rhythmbox shouldn't have a tray icon at all. For me it's confusing, it's not following the behavior of other apps there. Totem does not have any tray icon, and I have no confusion about it when I use it.

I am reopening, not because I want to be picky. It's because it's breaking my usual workflow, which is to launch the player, then to click on it to open the playlist, then to close the _playlist_ leaving music in background. I think systray was invented just to make background applications like this observable, and leaving an handle to the user to interact with. The icon in the tray means something very precise. Totem does not have it, for example, hence I don't expect the music it is playing to survive to the close button. But if I see an icon in the tray, I expect it to represent an application that will not close if I close all of its windows. Like it was a daemon, let me say it again.

There is no worry about the close button being inconsistent: if you close a window you just close a window, and that's all you expect. Doing more than this, should be a worry. Would you expect closing a chat window in pidgin to disconnect you? I wouldn't, but when I want to _close_ the chat window, I _close_ it using the _close_ button. There exists an application, pidgin, which is responsible to keep you connected, and "n" chat windows, where "n" can also be zero. With audio players it's the same: there exists an application which is responsible to keep playing music in backround while you work, and there is the main window that you can show to select what music to play in the next hour, and you can close to let it disappear.

Examples: look at pidgin, thunderbird, skype. Look at tomboy: you close the only opened note, the icon stays there. If this was not the expected behavior, then the systray would absolutely make no sense. I don't know any other gnome, kde or windows application that has the current behavior of rhythmbox, if you can name one, please do so. In ubuntu there even exists a program, "alltray", for the sole purpose of mimicking the usual close-to-tray behavior that we are talking about.

Vincenzo Ciancia (vincenzo-ml) wrote :

Ok, I've read other discussions on the gnome bug tracker. Not going to surrender :) Sorry for causing trouble here, but I really think I am seeing a mistake in gnome, and would like to see it corrected. So let me summarize the two most important points that have been overlooked, apart from personal preferences and impressions.

 Sebastian: you asked: "what is your issue with having the close button closing an application?". Issue is, I would prefer the close button to close a window, not an application. If usually, and for very good reasons, application and window coincide (and I know this is part of the HIG), the systray is exactly an exception. The systray is a mean to represent an "application" as a separate entity from the windows it created.

But, more important: current policy violates the HIG. You manipulate an object (the window) and end up deleting another object (the tray icon). The HIG principle I mention here has been considered so important in the history of gnome, that we can't have a damn "panel properties" menu entry, in the menu of panel items. I remember the discussion when I still used gnome 1.2 in debian potato. This leads to various usability problems, especially when you have a full panel and you can't open the context menu of your panel, but we had to accept these usability problems just because acting on an object should not act on other visible objects. Now I really don't see why you should violate this principle, and don't see what other principles would be violated by letting the close action on a window do what you asked for, which is, "close the window, please".

Stefan Wagner (wagner-stefan) wrote :

The first application I met which didn't close, but minimized to the tray, was skype, and that was confusing for me.
Why didn't it close?

Close has allways meant close. Minimize was minimize.
IMHO a program should provide an extra systray-icon, if wanted.
rhythmbox is doing right - the others should be reported buggy for not closing.

Vincenzo Ciancia (vincenzo-ml) wrote :

What do you mean with "IMHO a program should provide an extra systray-icon, if wanted" ? That users should be able to choose whether to have or not a systray icon?

Anyways, stefan: before skype, did you ever see any other application which installed a systray icon when launched using menus?

Changed in rhythmbox:
status: Invalid → New
Richard Laager (rlaager) wrote :

Yes, "Close has allways (sic) meant close," and minimize has always meant minimize. Furthermore, quit has always meant quit. Why on earth would the close button mean quit on an application that has other objects open? Closing the buddy list in Pidgin shouldn't close all the conversation windows any more than closing a conversation window should close the buddy list, and it doesn't. We have a system tray icon so the application keeps running. Given that I've filed a bug against rhythmbox and I don't recall anyone ever filing a bug against Pidgin for the correct behavior, I tend to think that the vast majority of people are with me on this one.

Sebastien Bacher (seb128) wrote :

rhythmbox has one window and there is no reason you should close it and than have to go to the systray and right click there to stop using it, there is no consensus there, you should rather argue upstream on bugzilla.gnome.org

Changed in rhythmbox:
importance: Medium → Wishlist
status: New → Triaged
Changed in rhythmbox:
status: Invalid → Confirmed
Vincenzo Ciancia (vincenzo-ml) wrote :

I am just calling for a comment on the hig violation I mentioned, that closing a window should not cause an object in the panel to disappear. For what I understand about tray icons and the intended behavior of rhythmbox, this application shouldn't have a tray icon at all. In any case, I don't think it can be denied that current behavior is unconsistent with all other applications, and this is another indication that the tray icon is not appropriate in this application, which is meant to behave like a single window app, not like a background daemon.

Seeing an icon in the tray we expect a background daemon, and this is an usability problem. It's not because I want it that way, I usually run amarok :) I am pointing out that the HIG states you shouldn't propagate the effect of an action on an object to other visible objects, and that's applicable to the tray icon as well.

Sebastien Bacher (seb128) wrote :

the notification area is not made for daemon but for notifications as suggested by its naming

Vincenzo Ciancia (vincenzo-ml) wrote :

Still, the HIG violation is there. However, I should ask this question on the gnome bug tracker, not here, because violating the HIG is an issue of gnome, not ubuntu. I will do that ASAP.

Sebastien Bacher (seb128) wrote :

note that the HIG is a set of guidelines not rules that applications have to apply

I think than i will be very good if i can choose what application should do, considering that different peoples has different opinions. It should be a preference option that will control behavior of "Close" (button with crosshair). By default it should be turned off, so never versions of application will behave like older.

sockopen (rk-mailinator) wrote :

I have now just removed Rhythmbox because of the way it exits and not closes, I was okay with it not having an equalizer (though that did bother me), exiting instead of closing is absolutely intolerable.

beaver82 (beaver82) wrote :

i think "close in system tray" option is a must for a system tray program, i'm looking forward for it

Simone Tolotti (simontol) wrote :

I'm impressed by the blindness of rhythmbox developers.
It's about 1 year that it's been discussed.
Don't you think that this worth an option to choose if you want to close or minimize to tray, when you click window's close button?
I think this should be true for every app that has a reason to live in the background.
In the meantime I've now learned to click on the tray icon to minimize rhythmbox...

Vincenzo Ciancia (vincenzo-ml) wrote :

I don't have the necessary time. If some of you could prepare a patch for the ubuntu package, we can distribute the package trough a ppa on launchpad in the meantime and see if people likes it. Patch should be trivial but as I said I don't personally have the time to look into details.

Alexander Jones (alex-weej) wrote :

The current behaviour is a massive usability disaster.

Scenario:

I'm listening to music, RB's main window is hidden.
I click the RB icon, and the window shows up.
I close the window.
My music stops. Huh?

Changed in rhythmbox:
status: Confirmed → In Progress
Johnny Proton (obijuan) wrote :

RIDICULOUS!!!

Every other application that resides in the system tray (or whatever it is called in Ubuntu) minimizes to that tray when the "X" in the upper right of the application window is clicked. Only Rythmbox actually quits when I click that button.

This has been a problem for years and while Rythmbox has gotten much better, this has not been addressed.

WILL SOMEONE PLEASE WAKE UP OVER THERE AND FIX THIS???

EVEN DEVELOPERS HAVE FIGURED THIS BUG OUT LONG AGO.

Johnny Proton (obijuan) wrote :

It should be a Gnome thing, but the Gnome Apps should shre a comon interface and behavior Rythmbox could exily fix in their own code and at least the "platform" would be consistent.

"Make it a law later, because everyone agrees."

end-user (end-user) wrote :

I'm so tired of losing my random track or having to re-buffer my radio feed because I accidentally close Rhythmbox. This happens 2-3 times a session.

Minimizing to tray on close, honestly, should simply be the default behaviour. It is just common sense.

Barring that, there should at least be an option in the main GUI. If common sense isn't prevailing, at least let clear demand.

Barring THAT, there should at least be an option in gconfig. Frankly, this isn't good enough. But it would show someone knows this is a concern.

Barring even THAT, is a plug-in too much to ask? I mean, this has to be one of the most requested features.

I appreciate the hard work that is put into this program. I was disappointed to not see an option yet this time around - I know that if it were added there would be a plethora of users who would be very thankful, and would think kindly about the developers who took their feedback to heart, every time they close Rhythmbox and see it go to the tray. As it should.

Vincenzo Ciancia (vincenzo-ml) wrote :

I attach the obvious 4 lines patch that fixes this bug. Notice there's a TODO to make it an option. I don't think an option would be of any use here but if any of you can come with code I will add it to my patch. I will upload the fixed package to a new PPA as soon as possible, this means that you'll have a sources.list entry for this and other obvious and missing fixes for ubuntu.

Vincenzo Ciancia (vincenzo-ml) wrote :

Here is the new ppa. The ubuntu-quickfix team is open to provide simple and widely requested "cures" like this one, please join if you can do that.

To get rhythmbox that minimizes to tray instead of exiting, use the sources.list line in the page below or download .deb archives directly from there.

https://launchpad.net/~ubuntu-quickfix/+archive

I have patched this upstream as a gconf option weeks ago. It's on the
upstream report. Save the effort.

Vincenzo Ciancia (vincenzo-ml) wrote :

Alexander: in which version of gnome will this end? Will it hit hardy or intrepid?

Ripfox (rippleband) wrote :

Bravo for the patch...much better, thanks!

Would it be possible to add this patch to the rhythmbox package shipped with ubuntu? This bug is more than 2 years old and there is a trivial fix...

Maxim Levitsky (maximlevitsky) wrote :

So when this is going to be fixed?

I am also tired of this bug.

Ian (eddieshowcase) wrote :

I agree... PLEASE fix this. This is just ridiculous... I know its minor, but its my biggest gripe about rhythmbox.

I should be consistent like every other popular music app on Linux Amarok, Listen, Banshee... it should close to the tray icon.

Vincenzo Ciancia (vincenzo-ml) wrote :

Il giorno sab, 28/06/2008 alle 04.14 +0000, Ian ha scritto:
>
> I should be consistent like every other popular music app on Linux
> Amarok, Listen, Banshee... it should close to the tray icon.
>

It *does* seem to me like developers are just waiting for people to
forget this. Just asking for a stupid option is not enough. It seems
that the only viable alternative is a fork. I will not do this anyway,
because I have better things to do. However I can't but notice the lack
of any will to dialogue with users. In ubuntu we have transmission and
pidgin installed by default. They make a certain use of the notification
area. Then, we have rhythmbox. It makes a different use of the
notification area. Nobody wants to comment on this except for saying
"things are not going to change".

I personally don't see why I should see a notification icon disappear
when I close a window that I open clicking on it. Its not logical. NO
ubuntu application does this by default.

Looking for examples?

The blue round pair of arrows that signals that you need to reboot the
machine. It's in front of me right now. I click on it, and it tells me
to reboot. I have NO WAY to make it disappear. Very cool. I can only
reboot my machine or keep the thing there forever. Closing the window
won't make the notice disappear.

And it is a notification, after all. As that is a "notification area"
the notice should disappear after I ack it. Instead, there is no way.

For normal applications, that are not just notices, like pidgin or
transmission, it's not even under question that the application should
quit when I close the window. Why? Because I can open the window
clicking on the icon, then the window is seen as *dependent* from the
icon. So how it is that I can open a window clicking on a symbol on the
screen, and then I can make the symbol on the screen disappear by
closing this dependent window?

Take the mixer, the network icon and so on. There is no other
application I can see installed by default, that shows a symbol in the
upper right corner of the screen, that exhibits the following behaviour:
1) click on the symbol 2) close the window that appears 3) see the
symbol disappear.

The only application that does this is rhythmbox. Please just
acknowledge this.

And now say that I am unpolite and I don't respect free software. I just
don't respect being mercyless ignored for months and years and having to
fork a package just for the sake of people I install ubuntu to.

Vincenzo,

I understand your disappointment but I don't think the developers are waiting for people to forget. This issue has been fixed upstream with a trivial patch wich adds a gconf option, so the developers did do something about this problem (even if it took a long battle for this...).

What I wish to have is this patch backported to the current version of rhythmbox shipped with ubuntu (I guess the version with the patch included will not be available in ubuntu until the next release?). I don't care if the default option stays the same as it is now (which is wrong in my opinion but this has ben beaten to death and I'm tired of it).

To be able to change the default behaviour via gconf is enough for me and I guess for almost all the other people annoyed by this bug, so, since the patch is obviously not dangerous, backporting it is a reasonable solution, IMHO.

Parthan SR (parth-technofreak) wrote :

Sorry that we could see some frustration building up over the bug's status. As you can see, it has been confirmed, triagged and "in progress", which means you have indeed got some attention over this bug. As bsolar points out, may be it needs to be backported to the existing version in Hardy. Let's keep our fingers crossed and hope this issue gets fixed ASAP.

Alexander Jones (alex-weej) wrote :

Go and yell upstream, I very much doubt Ubuntu will be shipping this
feature as a distribution patch.

Alexander,

> I very much doubt Ubuntu will be shipping this
> feature as a distribution patch.

Is there a particular reason for this?

Alexander Jones (alex-weej) wrote :

No, just my experience.

Alleluja! There is a plugin which does not require patches to rhythmbox itself! My bad I didn't get it...

You can get it from there:
http://methlab42.itee.uq.edu.au/~jonathan/rhythmbox-plugins/dontreallyclose/

If you prefer I changed it a bit to get the correct animation when hiding the window:
http://bugzilla.gnome.org/attachment.cgi?id=113594

As a side note would be nice to have this plugin easily installable in Ubuntu, but personally I'm already satisfied.

Simone Tolotti (simontol) wrote :

Hi, Christian ,as said upstream, your version of the plugin doesnpt work for me!
It correctly minimize to tray when clicking on close button, but I can't restore the window clicking on the tray icon...
No issues with the original version of the plugin.

You're right, I'm sorry. Please disregard my version, I'll try to get it working later.

erlguta (gonzalomarcote) wrote :

Thanks Vicenza for this patch so desired. But to be a version rhythmbox_0.11.5-0ubuntu6 + quickfix1_i386.deb and sources of official 0.11.5-0ubuntu8 always asks for upgrade...
Is there any way to resolve this?
It is incredible that something so trivial, so simple and so necessary to give this much work. It says much about the ability to listen from developers.

erlguta,

you can upgrade to the new (unpatched) version ad use the plugin from
http://methlab42.itee.uq.edu.au/~jonathan/rhythmbox-plugins/dontreallyclose/

Changed in rhythmbox:
status: In Progress → Won't Fix
Vincenzo Ciancia (vincenzo-ml) wrote :

If the patch has been merged upstream (I don't care if using a plugin) then I am fine with that. For consistency with other applications, this should be enabled by default but I guess you can't ask too much. What I understood in principle was that the patch had not been accepted upstream, if it is, it will get into ubuntu soon or later.

Thank you for clarifying this. By the way I am now happily using the plugin at http://methlab42.itee.uq.edu.au/~jonathan/rhythmbox-plugins/dontreallyclose/ . To use it (I had to guess the machinery) you have to create a directory named "plugins" in .gnome2/rhythmbox and copy both the files there.

Sebastien Bacher (seb128) wrote :

could everybody stop comment spamming this bug? the default will not be changed because some vocal users decided to add lot of comments there

some comments though:
- the notification area is not made to have applications staying there
- consistancy is good, but do you have many applications not closing when you close those? that's rather pidgin and the reboot notifications which should be changed if they are not consistant in the default installation
- seems that users will not agree on that so the best way is probably to have a plugin available to change the setting, that's where recent comments are going

note as usual you might have the impression that everybody would like to get the default changed reading the bug but that's because users who have no issue don't go to comment on the bug, the topic was discussed at the ubuntu summit when trying banshee and there was quite some users in the room who don't like having the software closing when being told to do so, it's really annoying to have to close the dialog, wonder why it's still playing some music when it should be closed, go to display the dialog again and use the menu to really close something that should have stopped running some time ago already when you clicked on closed

Sebastien, I'd like to address some of your comments:

>could everybody stop comment spamming this bug? the default will not be changed because some
>vocal users decided to add lot of comments there

I don't care about the default, I care about having an option. We are vocal because the option is easy to include in rhythmbox and we don't se a rational reason not to provide it for the many users who would like it.

>- the notification area is not made to have applications staying there

that's not what a lot of other application developers think and for sure is not what I am used to and lots of other users are used to. Rhythmbox is the exception, and does not offer choice.

>- consistancy is good, but do you have many applications not closing when you close those? that's rather pidgin and the >reboot notifications which should be changed if they are not consistant in the default installation

As I said, at least for the applications I use, Rhythmbox is the exception. When I have an application with a persistent icon in the notification area, I identify the application with the icon, not the window. When I close the window, I expect to close the window, not quit the application, like with all the other similar applications I have.

>- seems that users will not agree on that so the best way is probably to have a plugin available to change the setting, that's >where recent comments are going

It is obvious to me that when different users wish different reasonable behaviours you offer choice, that's what made a lot of people "vocal" about all of this story. This seems not obvious to the rhythmbox developers and at least I cannot figure out why.

Changed in rhythmbox:
status: Unknown → Invalid
Sebastien Bacher (seb128) wrote :

> It is obvious to me that when different users wish different reasonable behaviours you offer choice, that's what made a lot of people "vocal" about all of this story. This seems not obvious to the rhythmbox developers and at least I cannot figure out why.

could be that you are using the wrong stategy there:

- launchpad is a distribution bug tracker and people who read your comments are packagers and bug triagers, not people who writte this code
- you will not convince people who are working for free on the code and trying to fix your issues by being vocal or rant, quite the contrary
- the issue is usually that people working on free software projects are really busy so better to be constructive and try to give a hand on the changes

working on code changes to have an option is a constructive behaviour there rather than complaining about other contributors

Changed in rhythmbox:
status: Unknown → New

Sebastien,

>- launchpad is a distribution bug tracker and people who read your comments are packagers and bug triagers, not people who writte this code

Since from upstream it is not clear if and when at least the plugin will be released I just asked for a fix included in the distribution package: see https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/38512/comments/35

>- you will not convince people who are working for free on the code and trying to fix your issues by being vocal or rant, quite the contrary

If you check my posts here and on the upstream bugreport you can see that I have never ranted, I said that "rants are not justifiable but are understandable". Also, the code is already "fixed", the plugin is there.

>- the issue is usually that people working on free software projects are really busy so better to be constructive and try to give a hand on the changes

As i said the plugin is there since ages: it is not a problem of being busy or not having time.

>working on code changes to have an option is a constructive behaviour there rather than complaining about other contributors

The plugin is there since ages, it just has to be included with rhythmbox, that's not the problem. The problem is in my opinion convincing the rhythmbox developers of the wrong attitude they are having, as I tried here: http://bugzilla.gnome.org/show_bug.cgi?id=318629#c44

I think I have been constructive in that post, if you disagree please be specific about it.

Sebastien Bacher (seb128) wrote :

the comment was not especially about your contribution but a note for the people ranting on this bug, your comment upstream is mostly constructive though nobody claims to know better, whoever is writting the software is just free to take the choice he wants for his code and being agressive to convince him to change is not really good.

I've to admit I also have difficulties to get why users go in flame mode for such a detail, clicking on the icon is not that hard, is it? you do it to display the dialog again anyway. having a gconf value to change would probably reduce the discussion, it would make the rhythmbox behaviour inconsistent between installations though and not especially a good move, would be better to have a common behaviour in GNOME rather

>the comment was not especially about your contribution but a note for the people ranting on this bug, your comment upstream is mostly constructive though nobody claims to know better, whoever is writting the software is just free to take the choice he wants for his code and being agressive to convince him to change is not really good.

I am sorry that I took it personally, but you replied to me talking about "my strategy" so I inferred you were discussing about my personal doing. I agree that flaming and ranting will lead to nothing. I also agree that developers are free to do what they like, that's why discussion is the only option in this case. The fix is there, what lacks is convincing the developers it's worth inclusion in rhythmbox. I agree that being aggressive is not a good thing, but it is understandable given the history of this issue.

>I've to admit I also have difficulties to get why users go in flame mode for such a detail, clicking on the icon is not that hard, is it?

I've to admint I also have difficulties to get why developers go in flame mode for such a detail, adding an option is not that hard, is it?

Not to mention that I am used to have this behaviour with all my other applications with a persistent notification icon and it is difficult to remember "oh, this is rhythmbox, don't do what you usually do, instead do something completely different!" when you are clicking away your window. For sure it is annoying, but probably you don't understand this because you have different habits. The fact the problem for you is irrelevant does not mean it is irrelevant for everybody else.

By the way I agree that this should be fixed upstream with an option somewhere. Lacking this, including the patch in ubuntu is better than nothing.

Also, the idea of the common behaviour for GNOME is nice, but let's say that they decide ok, all the applications should behave like A. All the users who like the behaviour of application B will be disappointed when it gets changed to behave like A. Of course if you reverse it it is the same, users of A will be disappointed. I understand there are cases in which it is clear which is the right way, but this is not, since a lot of different people seem to know a different right way: I'd say in this case, stick with a default coherent behaviour and give choice to the user who wants a different thing.

Maxim Levitsky (maximlevitsky) wrote :

Btw transmission doesn't close too, when clicking on close button.
I don't remember any 'background' application that does
Even in KDE

Please add an option to rhytmbox, and thats all and lets move forward,
We users don't ask to remove an option, or even change an option, but just add it
and everybody is happy.

Jonathan Hitchcock (vhata) wrote :

As has been pointed out right at the top of the thread, GNOME has very clear rules and guidelines about how applications should behave in order to fit in with the rest of the environment: http://developer.gnome.org/projects/gup/hig/

Currently, Rhythmbox violates those guidelines, as clearly described in https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/38512/comments/12

This thread is getting very vocal about what people do and do not want, and whether there should be defaults, or options, or plugins. However, the above should be all that is necessary to decide whether or not the behaviour should be changed.

That said, how should Ubuntu react? People seem to want them to push out a bugfix update right now, but that just should not happen. Read the guidelines on when one can push a Stable Release Update: https://wiki.ubuntu.com/StableReleaseUpdates

There are very good reasons why we wait for the next version of Ubuntu before pushing some updates - this one is too trivial to warrant a distribution update. So, while I wholeheartedly agree that the problem needs to be fixed, I also wholeheartedly agree that this thread is getting out of control - no more "ME TOO THIS BUG SCUKS" comments, please, everything that needs to be said has been said. Now we wait.

(On a sidenote: I have attached a simple python script which will toggle rhythmbox's visibility (launching it if it is not currently running) - bind one of your hotkeys to run this script, use that hotkey instead of the close-button or the panel icon - when I started doing this, I stopped even realising that this bug still existed.)

Vincenzo Ciancia (vincenzo-ml) wrote :

Il giorno lun, 30/06/2008 alle 07.46 +0000, Sebastien Bacher ha scritto:
>
> some comments though:
> - the notification area is not made to have applications staying there
> - consistancy is good, but do you have many applications not closing
> when you close those? that's rather pidgin and the reboot
> notifications which should be changed if they are not consistant in
> the default installation
> - seems that users will not agree on that so the best way is probably
> to have a plugin available to change the setting, that's where recent
> comments are going
>

Sebastian: if there will be an option for setting this, then I am
perfectly fine. Nobody explained this for months and the impression I
got is that this was not ever going to be adjusted.

Please don't say we are spamming. I am not the kind of guy that believes
there is an universal "truly correct behaviour" for an user interface.
It's a matter of habit, so if you want to change this particular
convention for the ubuntu desktop, I will be glad to change my habits as
soon as there is consistency.

For now, however, if you can name another ubuntu application (possibly
part of the default desktop) that behaves as rhythmbox, I will take note
of that. For now, the bug seems to be in rhythmbox.

If you (intended as the ubuntu developers community) want to "fix" every
other application, please do so, but let us know, perhaps by just
writing an e-mail to other developers, making everybody aware of this
new trend in the usage of icons in the notification area so they'll
start respecting it. I seriously put in doubt there's agreement on what
the right behavior is, but at least in ubuntu some should be found.

Not caring about consistency in such well-exposed elements of the
interface is, in my opinion, not a viable option expecially if things
are so trivial to fix. When I teach people how to use ubuntu, it should
be easy for me to explain what the notification area is for, by giving
examples. Pidgin and rhythmbox are the obvious candidates, and they
behave differently. This is uncomfortable.

However, as I said, I will no longer care about this issue, since I am
fine with the planned option or plugin, and I am fine with the plugin
being in my home directory right now. God bless python (but I am a
theoretician, so I will deny having said this :)).

Vincenzo

Vincenzo Ciancia (vincenzo-ml) wrote :

Il giorno lun, 30/06/2008 alle 09.08 +0000, Sebastien Bacher ha scritto:
> - you will not convince people who are working for free on the code
> and trying to fix your issues by being vocal or rant, quite the
> contrary
> - the issue is usually that people working on free software projects
> are really busy so better to be constructive and try to give a hand on
> the changes
>
> working on code changes to have an option is a constructive behaviour
> there rather than complaining about other contributors

If you dig this bug report instead of just posting obvious common sense,
you will find

1) my patch without offering an option, that I made just to show it's a
one-line fix,

2) a link to a patch that adds an option to rhythmbox

3) more recently even a plugin appeared

Ubuntu developers can and should fix usability and consistency issues
(as they do when they disable spatial mode by default in nautilus), and
it does NOT take too much of their time to just add a patch that an user
has provided. The plugin I am currently using already exists and is a
ten-liner including whitespace. It should be added to the ubuntu package
of rhythmbox and, you bet it, the ubuntu developers are the only pepole
entitled to do that.

We *have* been quiet and constructive for a long time in this bug
report. We have well explained the several reasons why a dependent
window should not quit an application, and we have provided the plethora
of examples that guide us in saying this is a bug in rhythmbox. I
personally insist because I care of the overall impression ubuntu gives
on users, and I would like more consistency in the user interface among
applications.

Saying that we have "tried to fix our issues by being vocal or rant" is
extremely unfair and does not correspond to the history of all the
comments that you have on your screen right now.

Vincenzo

Sebastien Bacher (seb128) wrote :

the 8 comments added on saturday don't bring any value to the bug and I consider that spamming the people subscribed to the bug, that's what this pointless discussion do too so I'll stop contributing to it now, some notes though:
- giving urls to other website or blog entry is not considered as sending a patch for the issue, you should consider attaching a patch to the bug if you want to get it considered
- the example you mention are just opinion on the topic, there is no reason to consider the notification area as a part of the application rather than an indication of the fact that the application is running
- having a plugin would be nice but somebody needs to send a proper patch and this discussion should really continue on bugzilla.gnome.org

Alexander Jones (alex-weej) wrote :

Sebastian -- both a complete GConf option, documented et al, and a
plugin are available on the upstream Bugzilla. The fact is that Jon
Matthews doesn't like the idea at all, and is clearly reluctant to
distribute either.

Sebastien,

among the 8 comments you mention there is described a workaround which interested users (I guess every users who is interested in this bug) can use to get what they want quickly and somewhat painlessly. They also made clear that a fix at ubuntu level is unlikely, even if I would find it nice to have. I don't consider this bringing no value, especially the workaround provided. People look into bugreports for this kind of things too until there is a nice fix released.

>- the example you mention are just opinion on the topic, there is no reason to consider the notification area as a part of the application rather than an indication of the fact that the application is running

There is no reason to consider the notification area icon as only an indicator either. The guidelines might say that, but all the other applications I use consider the notification area icon as part of the application, then I assume this should be true for all the applications. That's what a coerent user interface should allow you to do, and it should be the goal of any desktop environment. Rhythmbox is an exception to the usual user experience with applications with notification area icon. And even if this would not have been the case, given the number of users interested in this I'd say adding this option would make Rhythmbox a better software.

About the "patch" you mention, I don't understand what needs to be patched. Rhythmbox itself does not need any patch, just the plugin needs to be included in the release (I don't care if it's from upstream or added by ubuntu).

The upstream bug has been closed with WONTFIX. Last comment was:

> Comment #46 from Jonathan Matthew (rhythmbox developer, points: 23)
> 2008-07-01 22:16 UTC [reply]

> I am tired of even thinking about this issue. In future, I'm not even going to
> comment on it (or anything related), let alone commit any patches.

So now the question is if the plugin can be included in ubuntu or if this bug too will be closed with WONTFIX.
For my part, it doesn't matter, I am not going to use a software developed by people with this attitude anymore.

Alexander Jones (alex-weej) wrote :

For anyone interested, I've put a fork of RB on GitHub, with this
change applied. I'll continue to pull updates from Rhythmbox until I
get bored.

http://github.com/alex-weej/boombox/tree/master

Changed in rhythmbox:
status: Unknown → Confirmed
Richard Laager (rlaager) wrote :

This can be patched in Ubuntu pretty easily. We just need to drop this file in debian/patches (as 20_close_to_tray.patch or something):
    http://bugzilla.gnome.org/attachment.cgi?id=70929&action=view

Åskar (olskar) wrote :
Sebastien Bacher (seb128) wrote :

right, this has been discussed on IRC this morning in a constructive way

Sebastien,

do you know if it's possible to get a log of the discussion and where? I am quite interested in it.

Sebastien Bacher (seb128) wrote :

there is nothing interesting in the log, upstream agreed that the plugin was a good option but just didn't want to commit due to the users attitude on the bug, he suggested that somebody else should do the commit instead

Vincenzo Ciancia (vincenzo-ml) wrote :

How has this bug been fixed? Was it finally decided to leave an option
to the user and which is the default? This is very good news in any
case.

Vincenzo Ciancia (vincenzo-ml) wrote :

My fault, I overlooked the upstream bug report. It was fixed by adding the relevant plugin. Very good.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package rhythmbox - 0.11.5.90-0ubuntu1

---------------
rhythmbox (0.11.5.90-0ubuntu1) intrepid; urgency=low

  * New upstream pre-version:
    - Relicensed with GPL exception for GStreamer plugins
    - Improvements to the cross-fading playback backend
    - Use Amazon ECS 4.0 web service for cover art searches
    - Remember browser state for (some) removable devices
    - Automatically remove podcast episodes that are no longer available
    - Only display error dialogs for manually triggered podcast updates
      (lp: #73128)
    - Allow playlists from DAAP shares to be sorted
    - Fix transcoding when transferring to MTP devices
    - Start moving cached data to XDG_CACHE_HOME
    - More inclusive local cover art search
    - Lots of improvements to the iPod plugin (lp: #117925)
    - Switch to the new last.fm streaming system
    - New plugin allowing to configure the close button behaviour (lp: #38512)
  * debian/control.in:
    - updated libgpod and libtotem-plparser requirements
  * debian/copyright:
    - updated to mention the gstreamer plugins GPL exception
  * debian/patches/70_from_svn_fix_incorrect_ipod_shuffl_detection.patch,
    debian/patches/71_from_svn_fix_ipod_aac_copies.patch,
    debian/patches/72_from_svn_ipod_correct_set_year_tag.patch,
    debian/patches/80_browser_by_default.patch,
    debian/patches/81_use_uri_to_import_directory.patch,
    debian/patches/90_from_svn_fix_audioscrobbler_issue.patch,
    debian/patches/91_from_svn_fix_eject_crasher.patch,
    debian/patches/92_from_svn_fix_amazon_coverts_download.patch,
    debian/patches/93_from_svn_fix_cdda_gvfs_handling.patch,
    debian/patches/93_from_svn_fix_xfade_locking_issue.patch,
    debian/patches/94_from_svn_fix_podcast_parsing_issue.patch,
    debian/patches/95_from_svn_extra_translatable_strings.patch,
    debian/patches/96_from_svn_fix_artwork_crasher.patch,
    debian/patches/97_from_svn_fix_ipod_crasher.patch,
    debian/patches/98_from_svn_correctly_handle_playing_changes.patch:
    - those changes are in the new version
  * debian/patches/01_install_podcast_xul1.9.patch:
    - refreshed for the new version

 -- Sebastien Bacher <email address hidden> Wed, 02 Jul 2008 16:53:41 +0200

Changed in rhythmbox:
status: Triaged → Fix Released
Richard Laager (rlaager) wrote :

I'm glad the option has shown up. I think turning it on by default would be good for Ubuntu (in terms of consistency), but I don't care to debate this any more than saying that.

Vincenzo Ciancia (vincenzo-ml) wrote :

Il giorno mer, 02/07/2008 alle 15.08 +0000, Sebastien Bacher ha scritto:
> there is nothing interesting in the log, upstream agreed that the
> plugin
> was a good option but just didn't want to commit due to the users
> attitude on the bug

On this bug report, I see a constructive discussion, getting very few
attention from who could solve the problem, from the date when the bug
was opened, which is: 2006-04-21, until 2008-03-02, when Simone Tolotti
has expressed a very little bit of anger by asking

"Don't you think that this worth an option to choose if you want to
close or minimize to tray, when you click window's close button?"

Indeed it was worth.

There is no kind of non-constructive information that I or other
commenters added during the first TWO YEARS of life of this annoying
bug. We just would have been happy with an option or a plugin from the
first day.

This may sound strange to your ears or eyes, but I report and insist on
such minor bugs quite because I think

  "developers don't have time to worry about minor issues"

so it's up to us to spot such problems and do the very lightweight but
time consuming work of finding a plugin, a patch, a suggestion for
improvement, a comment in another bug report etc. Developers are busy
with difficult things, so users that can develop should help with minor
issues, but they should be listened to a little bit. I don't really know
why an option setting took two years to be given.

In any case, the final word necessarily has to be

 "thank you for doing that chat in IRC and solving the problem"

Vincenzo

Sebastien Bacher (seb128) wrote :

the issue is not this one, but that's not because you disagree with whoever is writting the code that you have rights to rant at him or to comment in a not correct way

the code is open and the people who are working on it can take whatever choice they want, they work on their free time, don't charge you for any service and don't own you anything, now if the software doesn't fit your requirements you are free to use an another one or to contribute and scratch your own itches there

complaining because somebody who contributes on his free time works on what he's interested in rather than doing what you want is not constructive no, quite the contrary, and this negative energy is one of the reason why some people stop contributing to the softwares you are using

Sebastien,

As you said, developers are free to do what they want, but this does not mean users are not allowed to complain when they believe developers are wrong or are behaving in an unprofessional way. It is perfectly right for a user to express his opinion, even in a very direct way, and I find very childish postponing the merit of an issue with a personal problem (that's what happened in my understanding of your previous comment about the discussion in IRC).

The bugreport has been very constructive until 2 years from start. Then, since there was no feedback from rhythmbox developers, I asked very politely what was planned for this bug, since the fix were there for such a long time (http://bugzilla.gnome.org/show_bug.cgi?id=318629#c28). You can check the response to that for yourself and what followed, maybe then we can discuss again exactly who has not been constructive and why people stop contributing.

Negative energy did not come from nothing.

Sebastien Bacher (seb128) wrote :

why should people who are hobbists and working for free should behave in a professional way? the comment was not a reply to your contribution but some people have not been correct in their behaviour and that's what created the conflict. everybody will agree than discussion and good sense usually lead to correct choices, but when upstream is busy or not responsive expressing frustration is just not the right way

> why should people who are hobbists and working for free should behave in a professional way?

To avoid unnecessary attrition with the users. To have constructive discussions with the goal of improving the software under development. To avoid "negative energy" as you called it. In my opinion these are very valid reasons.

I agree some users crossed the line with some caustic comments, nobody ever denied that, but if you check again the whole bugreport you'll see that discussion and good sense had been ignored for years. Expressing frustration might not be the right way, but it does not surprise me it happened given the history of the issue. As I said, I don't justify it but I for sure understand it.

Vincenzo Ciancia (vincenzo-ml) wrote :

Il giorno mer, 02/07/2008 alle 20.29 +0000, Sebastien Bacher ha scritto:
> why should people who are hobbists and working for free should behave
> in
> a professional way?

That's ok Sebastien, that's why I in principle did not bother
quarrelling upstream and asked for a choice in ubuntu, like for many
other cases (e.g. spatial mode)!

Also, I think that striving for coherence and usability _is_ behaving in
a "professional" way on our side, for the very small contributions we
can make.

Vincenzo Ciancia (vincenzo-ml) wrote :

As a final note to this bug, there is an ubuntu brainstorm idea for this

http://brainstorm.ubuntu.com/idea/5488/

Changed in rhythmbox:
status: Confirmed → Fix Released
Creak (romain-failliot) wrote :

@Vincenzo Ciancia: Just to be sure, you think devs should add a button instead of a plugin?
If that's it, I actually completely agree with you.

At least, there is the plugin now.

Vincenzo Ciancia (vincenzo-ml) wrote :

In my opinion, there should be consistency among all gnome apps, so the default should be not quitting but closing, for reason that I longly explained. If I have to resort to a preference, I personally don't care if it's a plugin or a hidden setting or whatever: I will be able to choose what I want.

I don't care on how the option is presented because if it's not the default it is useful only for us hackers/nerds/whatever. My concern is for new users who will _not_ care or be able to hunt for a setting, and just experience and enjoy an inconsistence between the following installed by default applications: pidgin, networkmanager, tracker-desktop-search as started from the tracker notification icon, AND rhythmbox which behaves differently. Not to speak of the applets which sit near the notification icon (e.g. gnome-volume-manager). All the "colored icons in the upper right corner of the screen" (as I might describe them to my mother on the phone), THEY ALL, open windows when clicked in various ways, and all these colored icons DON'T DISAPPEAR when that window is closed. Rhythmbox is the only exception. I have my plugin, I can set my own preference, fancy if I care anymore - expecially because my mother does not listen to music. I might say that, forgetting any attention I might have for other ubuntu users, I am happy with the current situation.

Vincenzo Ciancia (vincenzo-ml) wrote :

Just to be constructive I could add that a different _proper_ solution to me seems the following: just don't have a notification area icon by default. Thus, rhythmbox would act like totem and no inconsistency would be experienced. This bug is already fix-released and I shouldn't be commenting anymore, I know.

bealer (robertbeal) wrote :

Definitely a bug or inconsistency in my opinion.

As mentioned something like Pidgin, if I select close or click the "x" it just minimizes. Rhythmbox seems to be the only app that goes against this. Hence I see it as a bug as it's not consistent with other apps.

Vincenzo Ciancia (vincenzo-ml) wrote :

Isn't this properly fixed in intrepid? AFAIR (I am not using ubuntu right now - since I am not on my PC) rhythmbox has now no icon by default. If you enable the notification area plugin then it minimises. This is in my opinion a very good fix - but maybe I remember one thing for another :)

Vincenzo Ciancia (vincenzo-ml) wrote :

No it's not properly fixed, I was wrong, the situation is always the same.

There should be a plugin available in rhythmbox to switch to the desired behaviour. As far as I understand this is the most we will ever get (and it is enough for me at least).

b2ag (thomas-b2ag) wrote :

On my Ubuntu 8.10 PC activating a Rhythmbox-plugin called "minimize to tray" solved this issue.

Changed in rhythmbox:
status: New → Fix Released
Changed in rhythmbox:
importance: Unknown → Medium
Julien Olivier (julo) wrote :

Now that there's an Ubuntu-Gnome distribution, the patch should be reverted so that Rhythmbox works as expected in Ubuntu-GNOME. And stock Ubuntu should "fix" Rhythmbox by having a rhythmbox-unity package or something like that. There's no reason why GNOME users shuld suffer from Unity's behaviour.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.