Created attachment 82735 [details] [review]
Linus's patch

I'm not immediately happy about accepting this patch. I think it's acceptable to allow rebinding of left double and middle because we don't have any equivalent to what HIG says about those, but HIG clearly states:

   Similarly for right-handed users, the right button on a conventional mouse is used for operations involving pop-up menus. We therefore call it the right button in this chapter. [...] Your application uses right button gestures to display and select actions from a popup menu.

 -- http://developer.gnome.org/projects/gup/hig/2.0/input.html#mouse-buttons

...and since we *have* a popup menu, I think we need to reserve right-click for that menu in order to abide by HIG. HIG unfortunately doesn't have a section saying whether it's reasonable to override its provisions if the default is in accord with them; I'm ccing Calum because I'd like some usability feedback on the matter. Also if Havoc or Elijah or anyone else have any thoughts, I'd like to hear them.

I have read linus mail about this (http://lists.osdl.org/pipermail/desktop_architects/2007-February/001127.html) and  some points seem reasonable:

"I want something very simple: I want to configure my mouse button window 
events. That doesn't sound so bad, does it? Everybody else can do it, 
gnome does not. My laptop has a two-button mouse, which means that I want 
the right button to do something more useful than show me the menu that I 
never use."

I also have this problem my laptop only have two buttons, and I would prefer configure the events.

For not "breaking" HIG, I think that the best option could be preserve the current behavior as default, but add a preferences dialog for allowing the user to change this behavior later.

HIG are great, also, I am using GNOME since many years ago, but I think that we shouldn't force users to only have a behavior.

I think that the best solution, like I have sayed, is preserve current righ and middle mouse behavior by default (like in HIG standars) but ALSO ALLOW the user to change this if it need this change.

Thanks a lot :-)

I should mention that everything you might want the right button to do can in fact be chosen from the context menu.

What we have here is, in my interpretation, a violation of the HIG. This is a serious problem, no less than an ICCCM or EWMH violation, because the HIG is one of the specs of this program. We therefore have a number of options:

1) Someone can convince me I'm misunderstanding the whole affair.
2) The HIG authors (e.g. Calum) can say that I'm misunderstanding the HIG.
3) The HIG authors can agree that the HIG should say that the requirement is only a requirement for a *default*, and change the HIG to say so.
4) I can reject the patch, or accept only the middle-click parts of it.

- there's already some discussion on some other bug that's been open for years, someone should dig that up
- there is no sacred text quality to the HIG, it's guidelines
- the defaults are the important thing, as long as we aren't adding prefs to fix a bug while leaving the default broken, then letting people do something silly is not the end of the world (assuming someone is going to maintain the resulting code)
- this is obviously an only-unix-geeks-care patch (after all, neither Mac nor Windows have this, or most of the other metacity prefs for that matter, let alone the prefs of most WMs, and 99% of people use Mac or Windows for window management)
- but gnome is pretty much maintained for unix geeks at the moment, so there's no reason to be purist about bouncing this kind of feature.

One issue to think about is forward/back compat of config options, anytime you have an enum-like setting, if you add values in the future it can confuse old versions sharing a config store with new versions. A typical solution to this is to allow the config setting to be a list of preferred settings (sort of like _NET_WM_WINDOW_TYPE iirc) so an admin setting up a config for two different GNOME versions can list a value for the new version and a fallback for the old version. Don't remember if metacity already has any settings like this. (And I didn't look at the patch to see if it already does this.)

(In reply to comment #5)
> - this is obviously an only-unix-geeks-care patch (after all, neither Mac nor
> Windows have this, or most of the other metacity prefs for that matter, let
> alone the prefs of most WMs, and 99% of people use Mac or Windows for window
> management)

Minor quibble: just because Windows and MacOS don't allow these things to be configured in the base install doesn't mean some percentage of users don't go out of their way to get various power toys and third party addons to add such configurability. So saying "only-unix-geeks-care" is a little misleading and perhaps inaccurate. 

Otherwise, your arguments strike me as far sensible :-)

Err.. that is "very sensible"

Okay, lovely. Let's put this in, then.

I am a little puzzled about the forward/backward compatibility thing. Do you mean that it would be best if the new middle and right click settings were GCONF_VALUE_LISTs, so we could iterate down them and pick the first recognised string? If so, what do we do about the existing double-click setting? I suppose the best thing would be to make a whole new key in the schema for double-click-action as list, like we did a while ago for multiple keybindings.

well, one approach is to punt on the list thing and worry about it if you extend the enum, the problem is that then you have to remember to worry about it. Maybe a comment in the enum declaration.

but yeah you would basically have to rename the key on the existing setting and make it a list.

This comes up when people have an NFS homedir and multiple GNOME versions. Some deployments do this, for example an animation studio has a fixed GNOME version per movie, and if someone works on two movies they have two different GNOME versions. (Basically, they never change the software mid-movie)

But it can also happen if someone just has a lot of computers, or downgrades, things like that.

Well, one of the other patches already extends the enum for double-clicked to include "lower" and "menu", so I suppose we should deal with it now anyway. Okay, I'll fiddle with the patch a bit.

Okay, my plan is: we will make the existing key "action_double_click_titlebar" obsolete, and introduce a new key "actions_[actionname]" (a list of strings). Metacity will then iterate down this list and find the first known enum value. If the string "action_[actionname]" is defined anyway, it will be treated as the last entry in the list. I will write this tomorrow and include it in the patch.

Created attachment 82878 [details] [review]
Adds schemas for the middle and right click actions

Adds schemas which contain the default values for the middle and right click actions.

(In reply to comment #11)
> Okay, my plan is: we will make the existing key "action_double_click_titlebar"
> obsolete, and introduce a new key "actions_[actionname]" (a list of strings).
> Metacity will then iterate down this list and find the first known enum value.
> If the string "action_[actionname]" is defined anyway, it will be treated as
> the last entry in the list. I will write this tomorrow and include it in the
> patch.
> 

Seems the best solution, good idea :-)

Thanks a lot :-)

I really dislike the list solution.  While it adds the most flexibility for backwards compatibility with NFS deployments, how much of a gain is that?  Is there really anyone who would want to set up their systems that they switch between to behave multiple different ways?  That sounds like a royal pain.  I think they'd rather just choose some behavior that all versions supported.  IMO, providing lists of options sounds like a large cost in terms of both gconf-key polluting and maintainence (and possibly making any specialized unix-user UI too cluttered for even the unix-using crowd), without any real useful gain from it.  I'd prefer to just make sure that the code can handle "invalid" options by just reverting to the default behavior.

The current control center configuration for the window manager is simply clutter, IMO.  Worse, some of the options are downright damaging to include (see bug 154614).  None of those options is really worthwhile for the screen real estate that they waste in the menu. I've ranted about it a bit in the past, but couldn't find an active maintainer to get things fixed.  I'm afraid that if we commit this option before the control center is fixed, someone will patch the control center to expose these options and thus make things even worse, so we may want to wait.  What would be optimal is having the current window manager configuration stuff get pulled out of the control center (though I might relent on the "movement key" thing; I can understand a significant portion of users wanting to workaround certain legacy applications without needing to install an additional package), have a bunch more currently gconf-only stuff thrown into it, and then have it be an optional extra package.

Anyway, other than the list idea and the caveat about timing above, I agree with Havoc about the general route forward and the inclusion of these options.

I had actually started to write the list thingy, but it's ridiculously baroque, not to mention special-casey: if this is a problem with *this* gconf enum, then it's a problem with *any* gconf enum, and it needs to be dealt with in a library-- gchar* gconf_client_get_enum_string (client, key, string1, string2, ...) or something.

I half got the idea that Havoc in comment 9 was assuming this patch was only for new keys ("punt on the list thing and worry about it if you extend the enum"), but bear in mind that if we don't go down the list route, we *will* be adding new enum values (namely "lower" and "menu") to an existing gconf key.

Elijah: There are already patches for control-center (bug 408906, bug 408907), but I haven't looked at them in any detail.

Other than the list thing, the patch looks good to me; my only worries were the HIG problem that I raised and the backwards compatibility thing that Havoc raised. I'm happy to commit it if we have consensus that neither of these are problems.

it's fine with me to punt the list thing, I think as long as unknown values are handled gracefully it will be fine. It's not like the rest of gnome really gets this right anyway. It is a genuine problem for some deployments but they probably already hack around it.

A quick reminder: We're under a zillion freezes right now, so we have to wait to commit either way...

So, Linus, it appears your bug is going to be fixed after all, right?

:-D

(btw -pedantic warning: the patch should have been named Linus' patch, without the s after the ')

Yes, the patch is indeed going in, but not for 2.18.

(And no, that is not the way to spell "Linus's", or at least not the only way-- see:

http://www.economist.com/research/styleGuide/index.cfm?page=841359
http://owl.english.purdue.edu/handouts/grammar/g_apost.html
http://www.guardian.co.uk/styleguide/page/0,,184844,00.html

)

Into the trunk goes Linus's patch...

And in go the schemas. Fixed.