Ok, added all the patches as blockers for this bug. I assume the control center ones are dependent on the metacity ones going in first. Hopefully the patches are in a state where we can merge them and once and for all end this silly argument with Linus.

let's keep focused on what the patches do, not who wrote them or what flamewars went on. changing title accordingly. There are some related discussions already in bugzilla, probably.

The patches all look pretty sensible to me.  The combined effect is that you can set double click on the menu bar to lower or open a window menu.  No new UI is created except to add those options to the droplist in the control panel applet.

Do you think Linus would mind working on some of the other issues listed in Bug 155457 also?

Well actually that's not quite right as it adds middle and right click droplists as well.

Can linus' email also be added to CC list in this tracker bug?

Additionally, could mouse scroll wheel events be bindable as well? Not necessarily by default (stray scroll events may be confusing for some users), but if the other mouse events are to be bindable then scroll up/down (while mouseover titlebar) would be a handy way to shade/unshade windows, for example.

Shade/unshade per scrollwheel would be cool.

Isn't custom functionality like this ideal for Devil's pie [1] instead of metacity itself?

[1] http://www.burtonini.com/blog/computers/devilspie

Scroll up/down for shade/unshade is useful. I used to use it in Xfwm. It is easier to scroll a wheel than to double click for me. It's very addictive.

The scrollwheel thing is bug #142825 and bug #91338, probably best not to mix it in to this bug.

I think we might be able to handle them similarly, though: I wrote about it in bug 142825 comment 16, for those who follow this bug but not that one.

Obviously there are two camps around the issue of adding user more interface options. A discussion in bug#154614 wants to remove the few options which are already there as they confuse people, while others want more configurability. Perhaps this should be taken as impetus to create a Gnome global Novice/Expert option which exposes the options which should be hidden from easily confused users. It may be true that some new users should not have these options as they might make the interface less windows like and panic, but in my case I found moving to Gnome (from FVWM) rather painful precisely because of the lack of these features. If Gnome is going to take 30% of the desktop market it should appeal to as wide range of users as possible. If people agree then I’ll open a ticket to that affect.

A Novice/Expert setting has been tried before in Nautilus, and it failed. Everyone is just going to set the setting to Expert anyway, because people like to make themselves feel like they are better at something than they actually are. And I think open source inherently creates a much more useful Novice/Expert barrier anyway. The real experts can do whatever they want, because they have the code, and can change it to their liking. The problem here though, is that the upper echelon of the Novice group, thinks the rest of the Novice group should be exposed to options which most people don't need to use, see, or care about. Some Experts also have this same problem.

I haven't actually looked at these patches yet though, and I probably won't, based on the simple fact that I know what the current "advanced" keyboard options settings looks like in the UI. But just try and get the patches reviewed and committed, rejected, or whatever, rather than arguing about simple vs. complex, novice vs. expert, and all that crap. It's a waste of time, and keeps people from actually making the desktop better.

(In reply to comment #12)
> Obviously there are two camps around the issue of adding user more interface
> options. A discussion in bug#154614 wants to remove the few options which are
> already there as they confuse people, while others want more configurability.
> Perhaps this should be taken as impetus to create a Gnome global Novice/Expert
> option which exposes the options which should be hidden from easily confused
> users. It may be true that some new users should not have these options as they
> might make the interface less windows like and panic, but in my case I found
> moving to Gnome (from FVWM) rather painful precisely because of the lack of
> these features. If Gnome is going to take 30% of the desktop market it should
> appeal to as wide range of users as possible. If people agree then I’ll open
> a ticket to that affect.
> 

Regarding Devil's Pie: it doesn't capture clicks on windows so can't be used to control what double-click on a window title does.

Could Metacity not just pass unwanted events on to somewhere else?  I have no desire to decide what should happen on single/double/right/middle clicks/scrolls, and I doubt that many people really do.

If the current settings dialog was just changed to allow disabling of the built-in actions, and all unhandled actions were emitted somehow, most of us would be able to ignore the whole thing.

Ross:
Would you count it as within Devil's Pie's scope if there was a way to pick up the events?  That would certainly cover the configurability complaints.

I think responding to mouse events on a window's titlebar is entirely within the scope of a window manager.

Since the remaining open sub-bugs belong to gnome-control-center, they can have the master bug too.

Ping.

2.19 has hit feature freeze now. Does gnome-control-center has any plans for the remaining patches? 

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.