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

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

Created attachment 11052 [details] [review]
Patch to add customizable alt+click mouse buttons

Hi, I added this functionality to it, I tried to copy the way
things were handled for other prefs.
It adds
/apps/metacity/general/mouse_move_button   1
....................../mouse_resize_button 2
....................../mouse_menu_button   3

Which is what they were before, I modified display.c instead of 
using those hard coded numbers to use the meta_prefs_get_*
functions for the new gconf keys.
It works for me on my system.

Please tell me if I didn't do anything right. This is my first
attempt at a patch for a gnome program.

I was considering going the other direction, something like:

 modified_button_one_action = move
 modified_button_two_action = menu

or something. That has a pesky issue that you can't add new actions 
to the set of possible actions without breaking the configuration
setting (as the setting may be shared between multiple metacity
versions). This may be OK as long as old metacity versions gracefully 
fall back to defaults if they see an unknown action name.

In all this we need to be careful to handle the case where the
configuration changes in the midst of an action.

Created attachment 11054 [details] [review]
Updated patch with your suggestions

I updated the patch with your suggestions,
I added modified_mouse_button_one,two,three_action
with the possible values of "menu", "move", "resize" and "default"

The only thing that isn't done is protecting against the changes
happening while an action is taking place. I don't know enough
about the code to fix that. Any pointers would be appreciated.

Please comment on the patch.

marking PATCH/high

One more request on this bug -- can we add the ability to pass these
actions through to the window?  GIMP, for one, uses Alt-clicking for a
number of actions that are unavailable to metacity users because of
the Alt-grabbing behavior.

I have already coded up the prefs handling code for this,
but I don't know how to get event_callback() to pass the event on to
the window. Maybe havoc has some suggestions?

Aswell, from the prefs.c code is it possible to get a pointer
to the display/window so that I can call meta_mouse_end_grab_op?

end_grab_op doesn't belong in prefs.c I don't think, maybe in a prefs
listener callback.

To pass thru click, there's at least one example in display.c already
(look for XAllowEvents)

Can someone give me and example of how to detect if
alt+mouse button has passed through to an application?

Created attachment 11180 [details] [review]
Updated patch

Here is an updated patch, it *should* work with the passthrough
option but I am not sure. I also added a function in display.c
called meta_display_must_end_grab_op() which just walks
the display list called meta_display_end_grab_op() on each display.
This function is called before we make a change to the gconf
key. This might be overkill I am not sure.

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

I think there's a bug in the patch (id=11180).

I does do something when I set it to "passthrough", but not what I
expected. It doesn't seem to pass through the pointer.
The <alt> keypress seems to be passed through without any problems.

I've been reading up on XGrabPointer and XAllowEvents, but this is a
bit above my understanding of C and XFree.

The problems seems to in the way the pointer is grabbed. That is just
an uneducated guess.

-Rene

I can only fix this if I get a test program. I don't know
anything about X programming but I should be able to figure it out.
Any pointers havoc?

The code already passes through plain (unmodified) clicks with
XAllowEvents(), it's just a matter of doing same for modified clicks.

(XGrabButton() does a 'passive grab' which means the mouse events are
frozen when the grabbed button/modifier combo is pressed;
XAllowEvents() says what to do with the frozen events - pass through,
or eat them, or whatever.)

John, you can use Gimp to test it. Paint a stroke or load a picture.
Alt+leftclick should enable the color picker. That should allow you to
drag over the picture while the selected color also updates.

I think what Havoc is saying is that we should use a XGrabPointer to
do 'active grabs' of the pointer. I have no idea where that should go
though.

I'm working on merging this patch.

With or without a fix for the 'active grab' vs 'passive grab' problem?

Just so I know if I should go bug a friend about fixing it.
Thanks.

I'll try to sort it all out. We'll see ;-)

I am busy with university right now, so I don't have time
to look at the code. But I think this should go in now, and a
new bug should be created to fix the pointer passing issue.

I'm working on it. It's complicating the code a fair bit and 
is going to take a bit of time to handle all the issues.

Well, what seems like the logical thing to do for me is simple to
change "passthrough" to "disable". The problem is that metacity tries
to do something with a shortcut that I want completely disable.
So wouldn't it be easier to make a switch that adds these shortcuts
into the ignored modifier mask?
That way metacity does what I want, and errors would be less likely (i
think).
Just a thought.

Created attachment 11391 [details] [review]
patch so far, doesn't have gconf keys, does have most of the rest

Here's my current patch, it does not yet read gconf keys, but 
does most of the rest. It's pretty likely to break some things 
so it might be nice to try it out. You can simulate changing the 
gconf keys by editing the prefs.c mouse_actions[] default values.

I'm not super happy with this yet, but it's getting sorted out.

Umm.. were can I get 2.4.2 ? It seems that is the version the patch is
against.

ftp.gnome.org

Thanks. I got the new source and it compiles with the patch. I have
not been able to make it work as I need though.
"Passthrough" seems to be gone and replaced by "nothing". I've tried
replacing "META_MOUSE_BUTTON_ACTION_MOVE" with
"META_MOUSE_BUTTON_ACTION_NOTHING" in several places and combinations.
It does have an effect, but the effect seems to be the same as the
"passthrough" option had with the old patch.
I just can't make any sense of prefs.c. Please explain what it is I
should change to disable the alt+mouse shortcuts.
Thanks.

There's an array near the top of prefs.c called button_actions that
you would call. 

(What I'm mostly interested in for this patch is whether the default 
behavior gets broken as a result of it, rather than whether 
all the config options work yet. We can sort out all the options later
if the basic setup is working.)

I've had no problems with default behavier when testing. I don't do
much testing since I'm working on a Redhat 7.3 install and will
continue to do so until I know that 8.0 is a workable solution.
The good old chicken and egg problem.
I have an old workstation for testing redhat 8.0. Metacity is the only
thing keeping me from trying it out on my workstation since I know I
will be unable to work.

The patch changes the default behaviour for double clicking
the title bar. It shouldn't be toggle maximize. It should toggle shade.
Also, is anything holding the gconf handling code? I could
easily write it up.

I attached a patch to http://bugzilla.gnome.org/show_bug.cgi?id=79315
that just makes the modifier for the Alt+foo actions configurable, 
and lets you disable the Alt+foo stuff if you are using Maya or whatever.

I've been thinking about the patch for this bug, and I really don't
like it. It adds substantial code complexity (I can't even convince
myself the patch works right by code inspection alone, and it will
make it harder to add things such as making windows raise on release,
or only when not doing DND). Moreover the patch makes it sort of
inevitable to allow configuring _unmodified_ clicks as well, which I'm
strongly opposed to.

Basically after spending a couple days on this I think I should have 
stuck to the standard metacity line here; this pref is not a good
idea. Maybe if I could figure out a cleaner implementation strategy, 
but I don't like this patch.

I would like to keep the double-click-titlebar aspect
because it isn't complicating much, that's on
http://bugzilla.gnome.org/show_bug.cgi?id=90418
That bug also mentions middle click which creates the same problems
as this patch.

Anyway I'm applying the configure-the-Alt-click-modifier patch 
immediately, but holding off on this bug, I just can't honestly say it
looks like a good idea to me, at least not with the patch as it stands.

What I meant about the double-click title bar configuration
option was that it changed the default and expected behaviour
from shading the window to the windows style of maximize/unmaximize.

And another point with this new patch is that when you alt+left click
(action assigned to move) it doesn't raise or focus the window. That
is the opposite of what everyone is used to.

When you say shade is 'expected' I assume you mean by the .5% of
desktop users using a window manager that does that, instead of 
by the 99% that are using Windows? ;-)

For not raising on alt+click, that's the kind of issue that I don't
like about the patch. It makes it hard to figure all that stuff out.

Don't forget the 5% of mac users.
The raising worked with my patch. Since all of this worked
before the patch, just with different mouse buttons it shouldn't
be that difficult to turn most of this into a nice interface
that could cover all the current behaviour and be extensible.

Whats the status of this? Has any patch gone in?

Same status:

> Anyway I'm applying the configure-the-Alt-click-modifier patch 
> immediately, but holding off on this bug, I just can't honestly say
> it looks like a good idea to me, at least not with the patch as it 
> stands.

I also want to add a setting for "double-click titlebar" action, 
there's another bug open for that.

I've been using the cvs patch since it was commited and have had no
problems with it :)
One thing that may be a bug in metacity: I have xmms set to "put on
all workspaces". That works, but whenever I change workspaces xmms is
_always_ the app focused instead of the app that was focused when I
left the workspace. Really annoying and maybe a bug.
-Rene

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

I'm going to close to clean up the bug list, since I have 
no near-term actions planned for this bug. 
I added a link to it to rationales.txt, 
double-click-titlebar is configurable, Alt+click modifier 
configurable, that's all I plan to do for now.

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

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

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

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

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

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