There has been debate on whether Rhythmbox should close or minimise when the
close button is pressed on bug 318629 and on the mailing list.

Created attachment 61581 [details] [review]
plugin patch

I've reimplemented this as a plugin. Requires the RBRemoteProxy Python bindings I just committed to cvs.

*** Bug 158168 has been marked as a duplicate of this bug. ***

Created attachment 63308 [details] [review]
patch to allow plugins to override close behaviour

This patch lets plugins override the behaviour of the close button, which means it trivial to write a plugin for this.

It also lets plugins override the behaviour of visibility setting. This would lets us turn small-mode into a plugin which uses it's own window; it would hide the main window, show it's own, and override the visibility-chanegs to affect it's window.

plugin to use this"


import rb

class CloseHideDisplay(rb.Plugin):
	def __init__(self):
		rb.Plugin.__init__(self)
			
	def activate (self, shell):
		self.close_id = shell.connect('window-close', self.close_pressed)
	
	def deactivate (self, shell):
		shell.disconnect (self.close_id)

	def close_pressed (self, shell):
		shell.set_visibility (False)
		return True

*** Bug 342049 has been marked as a duplicate of this bug. ***

Created attachment 70929 [details] [review]
always hide when delete_event is emited

I think programs that have a tray icon should always hide when close button is clicked. Many times I closed the rhythmbox by thinking it will minimize on tray. Here is a very simple patch to do like that.

Rhythmbox used to have code virtually identical to that, but it was removed.

We aren't going to add code that always makes it hide when you click close, but a plugin or option would be acceptable. 

gossip, gaim and liferea all don't exit the application when closing the main window with a tray icon... It's really annoying to not have a common way for all gnome applications. Actually rhythmbox is the exception.

(In reply to comment #8)
> Rhythmbox used to have code virtually identical to that, but it was removed.
> 
> We aren't going to add code that always makes it hide when you click close, but
> a plugin or option would be acceptable. 

There are a number of arguments here about how rhythmbox is the exception:
https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/38512

Why do you feel that Rhythmbox should be the exception here? After all, it is a music player, and many people like background music.

> 
> Why do you feel that Rhythmbox should be the exception here? After all, it is a
> music player, and many people like background music.
> 
I agree.

Still problem in 0.11.2. Quite annoying. Make it as an option in preferences or a plugin, please. It's a matter of a while, from what I have read.

(In reply to comment #4 and comment #5)

James,

this is a beautiful solution. It is simple, yet universal. I feel that committing both the patch and the plugin to the trunk (activated by default) and close this bug is the right thing to do.

*** Bug 526237 has been marked as a duplicate of this bug. ***

From my comment on Launchpad:

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?

Hide should be default, it is the only sane thing. A window is just a window,
nowhere in the "Close Window" tooltip does it say "Application", and
furthermore the "Close" menu item, Ctrl+**W** (the W is for "Window") hides the
window, too.

The only problem here is people who are used to using our platform in the
pre-Notification Area era and who refuse to let go. Please let us move forward,
we are already well behind.

The patch above isn't actually necessary.  You can just connect to the window's delete-event signal, hide the window and return True in the callback.

http://methlab42.itee.uq.edu.au/~jonathan/rhythmbox-plugins/dontreallyclose/

if you really want it.

Created attachment 108637 [details] [review]
Patch

Here's a better patch, that should at the very least complement the code to allow plugins to override it. This sets a sane default. And we all love sane defaults.

Alexander, why did you set status to NEEDINFO? It should be NEW, we don't need any more info from the *users*. We need active developers. Therefore NEW.

So.. your argument appears to hinge on the fact that the tooltip over the 'close' button on the window chrome says 'close window'.  That and a variety of insults.

I think the argument hinges on the fact that music was playing before the window was opened, so closing the window shouldn't change that.

Can we take a vote on Ubuntu Brainstorm or something?

(Also, sorry, I must have accidentally clicked NEEDINFO. Trackpad is funny.)

I really don't think voting is a useful technique for making software design decisions.  Voting works when you can present a full set of available options to a representative sample of those affected.  We have neither a full set of available options nor a representative sample.  We have (so far) two options, neither of which seems to be sufficient.

An option (at least a GCONF one) would be completely sufficient for many of us and would hurt nobody. No voting required.

As for the default behaviour, I don't care (although I am absolutely sure what it should be) as long as I can change it.

This bug is opened "to have an option", not "to change default behaviour". That's another issue.

Created attachment 108650 [details] [review]
Patch to add GConf option

Added /ui/close_window_means_quit boolean GConf option, and made the delete window callback use it.

I don't know if the GConf option installed correctly, at least my system isn't picking it up in /usr/local for some reason, but I have attempted to keep the peace by leaving close_window_means_quit = TRUE by default in the schema. We can argue the case otherwise in another bug.

PLEASE

*** Bug 532313 has been marked as a duplicate of this bug. ***

This bug is more than 2 years old and there is a trivial patch available. Is the patch scheduled for inclusion in Rhythmbox? If not there is a reason for this?

I understand that this might look like a minor issue for the developers but I find it very annoying (and I'm not alone). Since the bug is very old and the patch seems quite simple to me I don't understand why the problem is not fixed and the bug closed...

I'm not interested in adding a gconf option to switch between two broken behaviours.

Then what do you propose?

I'm not really proposing anything.

If I cared enough to endure the flames that would no doubt result (I don't understand why people get so worked up over this), I'd remove minimise-to-tray entirely.

If you want close-to-tray, you can use the plugin linked in comment 16.

Tune in next week for another episode of upstream developers from hell!

Thank you Alex for your constructive arguments.

The link is broken.

Jonathan,

I am sorry, I didn't get that the plugin would be working without the need of a patch. For me the solution is satisfactory, I just changed the plugin to unrealize the window (thus getting the correct animation whit compiz...).

About your comment about removing minimise-to-tray, I think a possible solution would be to provide a plugin for the whole tray, making it optional. This way you can remove it by default as you wish but avoiding major flames by providing a simple way for the (many) users who actually like it to get it back.

Created attachment 113594 [details]
modified plugin to get the correct animation

Original version: http://methlab42.itee.uq.edu.au/~jonathan/rhythmbox-plugins/dontreallyclose/

Alexander is right. This is completely sick. This issue is causing displeasure for every second rhythmbox user (Rhythmbox is the default player in Ubuntu, the popular distribution for newbie Linux users), but rhythmbox developers are not interested even in adding a hidden gconf option. On top of that, Jonathan Matthew is threatening to remove tray functionality completely. What can we say about that? I am completely speechless. Absolutely astonished. There's not nothing to add.

Jonathan Matthew is fighting some kind of holy war about application control concepts, who knows. What he is trying to say is "Go to hell! I don't care about you people, so stop bothering me!". Well, we should do what he says. Go to hell and find another music player. There is nothing else we can do. The distributions will change the default player eventually too, because with this attitude, this is certainly not the last problem where communication is impossible.

Like I said, I don't understand why people get so worked up over this.

Alex, Kamil: when you're talking to me about this thing I do in my spare time for "fun" (whatever that is), please try to be less of a dick about it.

People get so worked up because people try to use this software (maybe you don't?). And every time people by mistake close this software instead of send it to tray, people really swear. And people are really annoyed when they hear that for some reason they should be punished and should not have the option to use it in their preffered way.

But most of the people are dicks, so it really doesn't matter.

Oh, god. This is pointless.

My version of the plugin is broken, please ignore it.

About the last comments, I'd say to stop it since it's obvious there is no way to have a constructive discussion to improve the software that way.

In my opinion Jonathan thinks that actually giving this "minimize instead of close" option is not an improvement of rhythmbox but an involution. We (well, at least I) think otherwise. Forcing a single-sided way makes the other side unhappy. Having a plugin makes both of us happy, giving us choice. Giving choice to the user is the way in cases like this when there are more than a way to do things and there is no clear preferred way among the user base (at least from what I read in the countless disucssion about this topic).

What it's not clear to me is why there is this attitude of ignoring the request of a part of the userbase for features which are dead simple to implement and would kill the whole debate at the start instead of 2 years later (sorry if this is not the general approach but I talk from the experience I had with this particular problem).

Please take all of this constructively, I understand rhythmbox developers mainly do this in their free time and I appreciate their effort in providing a good music player. I believe that listening to the user request (if reasonable) would make rhythmbox better. For sure for me having the option to minimise it to tray instead of quitting the application makes it _a_lot_ better, even if other people might not understand why.

As developer of Empathy I can understand this bug is really a difficult one for rb developers. We had the exact same discussion lots of time for empathy.

I think there is no good or bad behaviour here, what we need is a consensus and all GNOME application must follow it. Atm each application does what it want and that result to an absolute nightmare which is bad for all users.

On the other hand, I personally dislike the current way plugins are used: A plugin is not a replacement for gconf!!! You can't just say "you can do what you want as a plugin", it leads to a totally broken UI because the user don't know where to configure the application: In the preference dialog or in the plugin dialog?

Really this bug can by no mean be fixed by a plugin, that's totally stupid! And asking the user to put the plugin in ~/.gnome2 manually is just not an option!

A gconf option is IMO not good either because that will lead to bloated preference UI with too many options OR a hidden gconf key is simply useless for most non-geek users.

We must once and for all have a clear GHIG and all applications MUST follow it whatever the developers/users prefer.

For empathy I choosed to minimize-on-tray when closing the main windows because it is the behaviour of *all* IM client on windows and GNOME. Most other application also minimize to tray... In fact rb is the only application I use that quit the application instead of minimize to tray...

Note: Please keep nice with developers, they are doing their best for you and for free! This is a *very* difficult question and there is no solution that will satisfy everyone.

Hi all,

I completely agree that we need a GNOME-level decision on this topic. I think discussion was attempted a couple of times already, so in the meantime individual apps should come with their own take on this IMO.  I do think we could target an unified GConf key below /desktop/gnome controlling behavior of systray apps on window close on the long term.


I disagree with Xavier though in that I think a midterm solution could very well be a plugin, but discussing whether code should be in a plugin or in the main app would be a bit off topic for this bug report.

Instead of looking at ramdom chats such as IM clients (Empathy and Gaim/Pidgin were mentionned), I think we should focus on other media player.  Banshee, Quodlibet, or even Amarok (looking at the other side of the fence), or iTunes or Windows Media Player (looking at the other side of the universe).  These all face the same problem, while one could argue slightly differently for IMs or other topics.

I tried out banshee some 2 weeks ago at the occasion of its 1.0 release (to see how mature it was nowadays in comparison to RB); I tried both the Ubuntu hardy version (0.13.2) and the one zero version.  It naturally has to face the same problem as described here.
  I found that the systray/notification area status was handled by a plugin in 0.13.2 and 1.0.
  I just tried quitting 1.0 and it minimized to tray with a notification message that it had minimized itself and that I should use the "quit" function to exit banshee.  This notification was only displayed the first time.

In 0.13.2, I found a plethora of options to control the systray extension, but I couldn't find these in the 1.0 version, the only thing which can still be customized is whether to display notifications or not.


So probably interesting ideas can be stolen from other media players, but displaying a first time notification sounds quite good to me UI-wise for such a difficult decision.

Would it be acceptable to:
a) reduce RB to notification area the first time it's closed and display a notification that you can exit Rhythmbox with the quit function?  This could be overriden in config

or:
b) show a dialog the first time RB is closed -- before actually closing -- proposing to Quit (default), or minimize to tray, or cancel, with a checkbox to always do this the next times RB is closed?  This could be re-changed later in config


I think implementing "everything systray/notification area" in a plugin is a good thing, but the question of where to implement this is really orthogonal. 
  Doing it in a systray plugin could be useful to change the default though: we could imagine always exiting when the plugin is disabled and always minimizing to notification area when it's enabled.

Bye,

(In reply to comment #39)
> People get so worked up because people try to use this software (maybe you
> don't?).

Consider this your first warning. Rants aren't welcome.

Rants are not justifiable but are surely understandable, after all that happened. The point is that users are disappointed when their complaints about software usability are met with a "You should not wish for that, I know better" attitude.

Do a google search e.g. for rhythmbox close to tray. It is obvious that a lot of users want a different behaviour from what is now available in rhythmbox. They ask for it, and 2 years later we are still here arguing...

From what Jonathan wrote I guess the idea is to get rid of the tray icon completely, thus having a coherent "window only" application. This would make rhythmbox coherent: close means quit application in the menu and when you click the window close button.

Obviously this would ignite a big fat flamewar since there are many users who like to have the tray icon: for them a plugin seems a nice idea to me. With the plugin activated rhythmbox has the tray icon, close means close window and in the menu quit means quit application (or configurable, if you feel it's better that way).

In the meanwhile, I appreciate the plugin as workaround.

I am angry, in a word.

1. This behaviour is not default
2. It's not an option
3. It's not even a distributed plugin
4. If you want it, you have to find GNOME Bugzilla and figure out how to install a plugin, which means finding hidden folders etc.
5. The plugin is called "DontReallyClose". That's taking the piss.

It's clear to me that someone is fighting some kind of war against sanity, and making it as difficult as possible for people to enable what they deem to be the only sane behaviour. 

And other people do this in their spare time, too, Jonathan.

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.

> 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.


I'm sorry that it upsets you so much that users want this, I realize as a personal project it must be disheartening when such a large portion of the user base disagree on a particular point.

I don't think it is right, though, for you to criticize others for "ranting" or submitting non-constructive comments and then you to leave a comment like that, as if you tried to work with the pro-option people but everyone was just completely unreasonable. This thing is almost three years old, clearly you never sought any compromise. That is your prerogative, but don't throw your hands in the air and act like it failed because of some diplomatic shortcoming of the pro-option people. I honestly don't know how you could be "tired of even thinking" about it, obviously you never had any real intention of considering it.

2008-07-02  Bastien Nocera  <hadess@hadess.net>

	* configure.ac:
	* plugins/Makefile.am:
	* plugins/dontreallyclose/Makefile.am:
	* plugins/dontreallyclose/dontreallyclose.py:
	* plugins/dontreallyclose/dontreallyclose.rb-plugin.in:
	Add a plugin by Jonathan to allow minimising to the tray
	(Closes: #318629)

(In reply to comment #47)
> > 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.
> 
> 
> I'm sorry that it upsets you so much that users want this, I realize as a
> personal project it must be disheartening when such a large portion of the user
> base disagree on a particular point.
> 
> I don't think it is right, though, for you to criticize others for "ranting" or
> submitting non-constructive comments and then you to leave a comment like that,
> as if you tried to work with the pro-option people but everyone was just
> completely unreasonable. This thing is almost three years old, clearly you
> never sought any compromise. That is your prerogative, but don't throw your
> hands in the air and act like it failed because of some diplomatic shortcoming
> of the pro-option people. I honestly don't know how you could be "tired of even
> thinking" about it, obviously you never had any real intention of considering
> it.
> 

I completely agree with you Paul and also with Christian Apolloni; I don't think users like the "You should not wish for that, I know better" attitude. I know I don't.

(In reply to comment #49)
<snip>
> I completely agree with you Paul and also with Christian Apolloni; I don't
> think users like the "You should not wish for that, I know better" attitude. I
> know I don't.

The bug is fixed, and the comment above the entry mentions that people shouldn't add any more comments. Consider this a first warning.

*** Bug 549079 has been marked as a duplicate of this bug. ***

If plugins are a way to add more complicated optional behavior to Rhythmbox, then perhaps the solution is to improve the Preferences and Plugins dialogs.  Maybe plugins should be allowed to dad configuration options? Or maybe the plugins list could be merged into the prefs window.  The new section or tab should have a title like "Extended Options" or "Extensions" or "Optional Behaviors" or "Extended Behavior" or "Extras" or something to help people find it when looking for special features like this.

I know I would have found several options I was trying to find more quickly if I could have moved from Preferences (where I didn't find the feature), to a nearby "More/Extras/Extensions/Options" panel that happened to include options provided by plugins.  

Most of the "plugins" really do just add a single special feature or behavior to Rhythmbox, and that's how most users will think of them, especially if their distribution includes a set of them (rather than as plugin modules/objects/libraries per se)