After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 358674 - Unidirectional maximization is inaccessible.
Unidirectional maximization is inaccessible.
Status: RESOLVED FIXED
Product: metacity
Classification: Other
Component: general
trunk
Other Linux
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
: 308293 439749 456278 (view as bug list)
Depends on: 140362
Blocks: 329503
 
 
Reported: 2006-10-01 03:10 UTC by Carlo Wood
Modified: 2008-03-04 00:44 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Fix for this bug (1.38 KB, patch)
2006-10-01 03:13 UTC, Carlo Wood
none Details | Review
Same, without TABs. (1.70 KB, patch)
2006-10-01 21:23 UTC, Carlo Wood
reviewed Details | Review
Duplicate the existing methods of full maximization. (6.69 KB, patch)
2006-10-04 03:38 UTC, Carlo Wood
reviewed Details | Review
Moved the decoding of 'button' to core.c, getting rid of the introduction of four new functions. (6.80 KB, patch)
2006-10-12 15:25 UTC, Carlo Wood
reviewed Details | Review
Version 5 (20070315) of "unimaxmouse" patch. (6.77 KB, patch)
2007-03-15 03:11 UTC, Carlo Wood
reviewed Details | Review
Tony Houghton's patch to do the same thing (8.99 KB, patch)
2007-07-31 13:15 UTC, Thomas Thurman
reviewed Details | Review
implements maximize vertically and horizontally as toggle actions (5.16 KB, patch)
2007-09-12 13:15 UTC, Cosimo Cecchi
committed Details | Review
Hardwired one way maximization depending on which mouse button is clicked (4.49 KB, patch)
2007-11-12 19:22 UTC, Tony Houghton
rejected Details | Review
Version 7 (20080128) of "unimaxmouse" patch. (11.85 KB, patch)
2008-01-28 19:40 UTC, Carlo Wood
reviewed Details | Review

Description Carlo Wood 2006-10-01 03:10:59 UTC
The only way to currently unidirectionally maximize a window is by binding a key to the maximize_horizontally or maximize_vertically functions.

That this is possible is VERY hard to find: one has to open:
System Tools -->  Configuration Editor --> apps --> metacity --> window_keybindings

and then find that maximize_horizontally exists at ALL, and is not bound to anything by default (you can really note it when the main developer of an application doesn't use something).

Other window managers, like the default window manager of KDE, allow users to unidirectionally maximize by middle- or right-clicking the maximize icon. Letf-clicking still fully maximizes, of course.
Comment 1 Carlo Wood 2006-10-01 03:13:18 UTC
Created attachment 73732 [details] [review]
Fix for this bug

This patch implements the behaviour that left-clicking the maximize icon is still (un)maximize fully, middle-clicking now means a vertical (un)maximize and right-clicking a horizontal (un)maximize.
Comment 2 Havoc Pennington 2006-10-01 07:06:30 UTC
Thanks for the patch. This feature is pretty much hidden on purpose though - it was only added at all over my misgivings, and because it isn't something one would stumble on accidentally. Having middle and right buttons do magic stuff is also something we've avoided... right click reliably brings up a menu right now.

The fix I'd suggest for this sort of thing is to have a "Traditional UNIX Users" control panel or similar special control panel for people whose feature expectations originate from historical UNIX window managers. I think someone may have done this even.
Comment 3 Carlo Wood 2006-10-01 11:40:27 UTC
Why was it hidden on purpose though?
I can understand the reasoning that you don't want right-clicks to do anything else than pop-up a menu (by default), but there isn't any reason to think of unidirectional maximizations as evil.
I agree that the whole unidirectional maximized window behaviour was a bit crippled, but I've been working on that in the past weeks. After applying the two patches for bug #358042, the unmaximized geometry of maximized windows are preserved over a restart, as well as the fact that they are (unidirectional) maximized at all (very handy for developers), the patch of bug #358311 fixes the maximization constrain routine to work correctly for unidirectional maximized windows, and last but not least, the patch of bug #356715 fixes the shake-loose code to work for unidirectional maximized windows. Unidirectional maximized windows are now matured, if I may say so myself - their behaviour is pleasant and intuitive. The shakeloose is necessary for people who use them with a xinerama setup.

I think metacity is ready to make this feature more accessible.

I can't find any 'Traditional UNIX Users' control panel... Can you please tell me what action would cause this control panel to pop-up, and what you mean EXACTLY in terms of how to configure that you want to use the middle- and right-click for unidirectional maximization in this case?

Originally, my idea was to write a more general approach and simply allow users to bind mouse clicks to actions; thus: left-, middle- or right- clicks on title bar, client window area, menu icon, close icon, minimize icon or maximize icon; should all be treated as events that the user can bind to any of the existing actions. This more general approach, with events (key presses AND mouse clicks) on one side, and the actions on the other side, seems to right way to go - but... well, to be honest, I wanted to stop putting so much time into metacity for now, until I see some of my patches actually being committed, so I just wrote a quick hack for my own needs for this particular thing :p

Comment 4 Havoc Pennington 2006-10-01 16:25:35 UTC
The basic reason to hide it is that it complicates the user model a lot relative to its value. (Originally also because it complicated the code too much, but I guess that battle is already lost.)

Some people really like this feature, but they are people who used to have it in the past, as far as I know, and will generally already be poking all around in hidden metacity settings (there are quite a few sadly).

The "Traditional UNIX Users" control panel is a suggestion for GNOME control center which would allow it to support multiple target audiences in a clean way without stomping on one audience with stuff for another audience. But it does not afaik exist already.

Re: bind mouse clicks to actions, this is trickier than you think. I tried writing the patch once, and found it very hard without creating regressions in the details of the mouse interactions. Somewhere in bugzilla I may have explained in more detail why it was tricky, I don't know. I think the partial/failed patch is also attached somewhere.
Comment 5 Elijah Newren 2006-10-01 19:10:17 UTC
*** Bug 308293 has been marked as a duplicate of this bug. ***
Comment 6 Carlo Wood 2006-10-01 21:23:14 UTC
Created attachment 73779 [details] [review]
Same, without TABs.

Not that I expect this patch to be applied... but well. No more TABs.
Comment 7 Elijah Newren 2006-10-02 06:29:11 UTC
Havoc has already commented on the bigger picture, so I'll update the patch status accordingly; however, you've been submitting some good patches recently so I'll comment on the patch anyway to help you understand metacity a bit better:

- the window.h include is not allowed in frames.c; check the 'technical gotchas' section of the HACKING file for the full explanation

- the patch would result in an UI inconsistency with the standard maximization -- standard maximization takes effect on button release rather than button press, but you have done the opposite with the vertical/horizontal stuff

- the patch doesn't really match how the maximization is done, namely that you don't start a grab op.  This is somewhat a reflection of the previous point, just looking at it from the coding side rather than the UI side.
Comment 8 Carlo Wood 2006-10-04 03:30:57 UTC
(In reply to comment #7)
> - the window.h include is not allowed in frames.c; check the 'technical
> gotchas' section of the HACKING file for the full explanation

Thanks. I don't see why this is needed, because the "correct" way just calls a function that calls the function that I called directly. So, at most it's a few clock cycles slower. Nevertheless, as did the exercise to duplicate the way it is done for fully maximization.

> - the patch would result in an UI inconsistency with the standard maximization
> -- standard maximization takes effect on button release rather than button
> press, but you have done the opposite with the vertical/horizontal stuff

Ok, my new patch also corrects this.

> - the patch doesn't really match how the maximization is done, namely that you
> don't start a grab op.  This is somewhat a reflection of the previous point,
> just looking at it from the coding side rather than the UI side.

Yes, I didn't duplicate the existing code of 'maximization', it was just a hack - and it worked for me. But because you made this list, I decided to redo it ;).

Thanks again.
 

Comment 9 Carlo Wood 2006-10-04 03:38:22 UTC
Created attachment 73987 [details] [review]
Duplicate the existing methods of full maximization.

The effect of this patch is:
middle clicking the 'maximization button' will vertically maximize a window if it is in the fully unmaximization state, while right clicking will horizontally maximize it. The result will have the maximized-icon in the maximize button.
Clicking this button again, either with a left click, or with a middle or right click respecitively for vertical or horizontally maximized windows, will unmaximize the window again and change the icon back to normal. Middle clicking a horizontally maximized window, or right clicking a vertically maximized window has no effect. The (un)maximization only happens at button release, just as with full (left click) maximization.

I like this patch more, especially because now also the icon changes :)
It has been really annoying me that it was sometimes hard to see if a window is horizontally maximized, or just as wide as the monitor (which for some reason is still a few pixels less wide).

It is my understanding that you don't want to commit this patch - but I thought I'd post it anyway :p
Comment 10 Elijah Newren 2006-10-10 23:12:00 UTC
Again, just trying to provide helpful feedback: Other than the fact that I'd add a MetaMaximizeFlags to meta_core_maximize instead of adding 2 new maximization functions to core.[ch] (which would require moving the defintion of MetaMaximizeFlags from window.h to common.h), the patch looks fine.

But, as per Havoc's big-picture comments, I'm marking as reviewed.
Comment 11 Carlo Wood 2006-10-12 15:20:57 UTC
(In reply to comment #10)
> Again, just trying to provide helpful feedback: Other than the fact that I'd
> add a MetaMaximizeFlags to meta_core_maximize instead of adding 2 new
> maximization functions to core.[ch] (which would require moving the defintion
> of MetaMaximizeFlags from window.h to common.h), the patch looks fine.

Moving MetaMaximizeFlags to core.h really looks bad somehow... It would also require including core.h in window.h. Imho, using three functions is even better than doing that. The best solution would probably be too create a new headerfile with all the enum's - and include that in both core.h and window.h - but I feel that that change is too big for this small patch. I already had a collision, and I want to avoid that as much as possible. Nevertheless, in an attempt to get rid of the introduction of four new functions, I decided that the decoding of the button then has to be done in core.c instead of frames.c.


Comment 12 Carlo Wood 2006-10-12 15:25:14 UTC
Created attachment 74575 [details] [review]
Moved the decoding of 'button' to core.c, getting rid of the introduction of four new functions.

Just provided here because I had a collision.
I already marked the patch as reviewed ;)
Comment 13 Elijah Newren 2006-10-12 16:05:56 UTC
(In reply to comment #11)
> Moving MetaMaximizeFlags to core.h really looks bad somehow...

Yes, it does, which is why I said:

> (which would require moving the defintion of MetaMaximizeFlags from window.h
> to common.h)

so that both window.h and core.h include common.h instead of including each other.  ;-)
Comment 14 Carlo Wood 2007-03-15 03:11:46 UTC
Created attachment 84626 [details] [review]
Version 5 (20070315) of "unimaxmouse" patch.

This is just an update of the patch to match the current SVN.
Comment 15 Elijah Newren 2007-04-03 16:22:15 UTC
From a technical perspective, the patch looks fine.  I'd rather have policy for button-to-maximization-type in either frames.c or window.c rather than core.c, but that'd be trivial to fix.

From a nontechnical perspective, the issues Havoc raised are still outstanding.  I think we need general solution such as the one he outlines first.  That might involve another attempt at trying to get the attention of control-center maintainers and fighting with them (which I have a batting average of 0.000 in), plus maybe bringing up the general direction of GNOME (like Havoc has done on d-d-l) and the future of the release sets (as Dave has been talking about) in order to get this (and many related issues) squared away.

I know that's not what you wanted to hear.  It'd be easier to just hide from it all and simply commit the patch, but I just don't feel that's Right for the general user.  It'd just be a cop-out at best, and it's really time to discuss those bigger issues anyway.  Sorry.
Comment 16 Thomas Thurman 2007-07-31 13:12:10 UTC
*** Bug 456278 has been marked as a duplicate of this bug. ***
Comment 17 Thomas Thurman 2007-07-31 13:15:49 UTC
Created attachment 92794 [details] [review]
Tony Houghton's patch to do the same thing

Tony Houghton <h@realh.co.uk> submitted bug 456278 where he gave a patch which does substantially the same thing, but in different ways. The current version of that patch is attached, for the benefit of anyone who comes here looking for a patch and wanting a choice; obviously, the same caveats which attach to including attachment 84626 [details] [review] attach to this patch too. We need to talk to some HIG people, I suppose.
Comment 18 Tony Houghton 2007-07-31 14:50:51 UTC
Sorry about the fork, I'm never any good at finding existing bugs. I think I searched for "maximize" but didn't think of "maximization".

Anyway the reason I made it an option is because I already knew Havoc didn't like  anything that breaks the consistency of right button always opening a menu so I reasoned that he'd prefer to keep the existing behaviour for new users.

I like the idea of an extra capplet or an extension on the existing one for "Traditional Unix Users".
Comment 19 Cosimo Cecchi 2007-09-12 13:15:39 UTC
Created attachment 95435 [details] [review]
implements maximize vertically and horizontally as toggle actions

I wrote this patch looking at bug #329503
This patch simply adds the possibility from Control Center capplet to set maximize horizontally and vertically as default action for double click on window frame, and does not involve changing mouse clicks behaviour. See also the attached patch to aforementioned bug #329503 for the implementation in Control Center.
Comment 20 Havoc Pennington 2007-10-10 15:51:53 UTC
The only small-picture comment I'd have on the patch is maybe don't abbreviate "vert" and "horiz"

As to whether the patch is a good idea, it doesn't make sense to me to add more stuff to that menu - the things on there are 1) the traditional windows behavior (maximize), 2) traditional unix behavior (shade) and 3) the sane behavior (nothing). So the intent was not, that I can remember, to have N things, only these specific 3 things.

But, I really am not the maintainer of either metacity or control center, so I'm more just giving an opinion than reviewing the patch.
Comment 21 Tony Houghton 2007-10-10 17:14:42 UTC
Is the concept of using middle and right click on the maximize button officially squashed then? The trouble with this double-click idea (if I've understood it correctly) is that you have to keep reconfiguring it if you want to sometimes go horizontal and sometimes vertical. Nearly all other *nix window managers use middle and right click, it's simple, so why keep trying to come up with alternatives?
Comment 22 Carlo Wood 2007-10-10 17:25:22 UTC
There is absolutely no reason not to add support for this to metacity.
I'm thinking about making a fork... Also my patches for a better support
for multi-head are waiting two years now, and there is a lot more wrong
with metacity that I run into on a nearly daily basis, but that I can't
be bothered to fix as long as my previous patches don't get any attention.
Comment 23 Havoc Pennington 2007-10-10 18:06:23 UTC
Well, nobody except volunteers are working on it. I don't spend any time on it for example, so I can't complain about my favorite unfixed bug (I do have one!).

re: forking because you disagree on UI decisions, in all seriousness, my view has always been that I'd rather see that than have a metacity that's a sea of compromise and clutter. So you are more than welcome to do it. Maybe the current maintainers will get grumpier than I would, though.

Comment 24 Tony Houghton 2007-11-12 19:22:11 UTC
Created attachment 98983 [details] [review]
Hardwired one way maximization depending on which mouse button is clicked

Bug 456278 contains comments that it would probably be preferable to hardwire this behaviour (middle click on maximize for vertical, right click for horizontal) instead of adding a hidden gconf option. This is an update of mine and Thomas Thurman's patch to that effect.
Comment 25 Thomas Thurman 2007-11-12 19:34:19 UTC
Better, yes, although I think Havoc called it "totally busted and bizarre". (For myself, since it's not like middle/right click on maximise already does anything, if people actually want it and are going to use it (and at least some people do), I can't see it's such a bad idea for it to go into trunk; but I'd like consensus first. Also, have you considered shift-click and ctrl-click, or is that even crazier?)

Or perhaps this and the double-click-menu-button-to-close patch should go into a "weird stuff that didn't make it into the theatrical release version" collection, or something. :)
Comment 26 Tony Houghton 2007-11-12 19:43:16 UTC
I think right and middle click has 2 advantages over shift and control:

* Most other X window managers do it; power users will know where to look for it.

* You only need one hand.
Comment 27 Thomas Thurman 2007-11-12 20:06:34 UTC
Fair enough.

I think the two places where you do "if (event->button == 2)... else if (event->button == 3)... else something else" would be better done with switches. Other than that it looks fine (though I haven't actually run it yet, so I won't mark it reviewed until this evening).

I don't think this adds much complexity to the code, and it doesn't make the perceived interface any more complicated for beginner users, and it adds some useful benefit, so on balance I'm in favour of putting it in; I'm also willing to be persuaded otherwise, though. :) Thoughts?
Comment 28 Havoc Pennington 2007-11-12 20:39:42 UTC
This (and related bugs) really make me regret ever agreeing to support vertical and horizontal maximize at all... they've created a cascade of bugs and screwy UI issues. A learning experience I suppose.

One of the fundamental problems with vert/horiz maximize is that they are modes, but there is no graphical representation of the mode. Regular maximize leads to dropping the window edges and changes the maximize button's appearance. So if you get in this mode, you know, and you can get out again.

Vertical and horizontal maximize don't have any representation, nor can I think of a good one. So, if people get in the state accidentally (say by right-clicking in the wrong place), it's a "why can't I resize this window???" type situation. 

This is why originally I had coded vert/horiz maximize as shortcuts that resized the window, rather than window states.

There's no natural place to put the UI for viewing or controlling the vert/horiz maximized state... there's no "vertical maximize" button that can control the mode. And if we did add visible UI for these two states, say a couple extra buttons, it would create clutter way out of proportion to the value of the feature.

Anyway... I suppose that's all a bit of a tangent. But it *is* tempting to just rip vertical and horizontal maximize back out of the code ;-)

<constructive>
What if you just add vert/horiz maximize as configurable actions on double/middle/right click (i.e. add them to the MetaActionTitlebar enum)? That would be less "easter egg" than the magic middle/right click on a particular button, perhaps.
</constructive>

Comment 29 Carlo Wood 2007-11-12 21:10:29 UTC
I used horizontally and vertically maximized windows daily and frequently. One of the major advantages of them is that you can temporarily increase the size of an existing window, while remembering it's old position, and without having it take the WHOLE screen (covering all other windows). For example, I edit source code always in horizontally maximized windows, and still can have several above each other.

When Havov says "I regret ever agreeing to support vertical and horizontal maximize at all" and even "it *is* tempting to just rip vertical and horizontal maximize back out of the code", then all I can think is: why is he being so selfish about it? Because you don't use it, it doesn't need to be available for others?

The cascade of bugs and screwy UI issues have all been resolved by me a year ago in another patch that I wrote (which still hasn't even been reviewed). I do not think it's an argument because it can be fixed. I HAVE fixed most of the issue, and if there still exists others then I am willing to work on them and fix them as well (PROVIDED that I don't have to wait a year before a patch is reviewed: I simply have no time to constantly fix collisions and worse, update patches because of others having worked on the code while my fixes weren't in there already). The best would be if I'd just get cvs (svn?) access, so I can an active developer.

As I said, I've been using my patches for a long time, and I think that the argument that you can't see if a window is partically maximized is not correct: I can see it. A window that is not maximized at all has a small window icon in the button, and a window that is (partially) maximized has a large (maximized) window icon in the button. If I see a window that spans the full width of my monitor and the icon is large, then I know it's horizontally maximized. There is not reason to worry about the exception of a window that is NOT maximized but spanning the full height (or width) and then being partically maximized horizontall (vertically) so that it might be confused with a fully maximized window, while it only is in fact partically maximized (because both use the same icon). That never happens in practise, and if it would happen, then people would just left click on the maximized button, the icon would then change to a small window, and the window would change size (still spanning the full height (width)), and it would be totally clear in what state the window is in then.

Extra buttons are certainly not necessary. It would be kludgy imho, and well... there is really no need for them. It works perfectly the way I have it.

Finally, I'd like to remark that if this is going to be added I really hope that my original patch will be used. My other patch that fixes most of the issues with partial maximization (ESPECIALLY in the case of Dual-Head!) depends on it (http://bugzilla.gnome.org/show_bug.cgi?id=356715).
My original patch has been posted here a year ago (2006-10-01) and I last updated it not to collide with changes made in the trunk on 2007-03-15, see comment #14. If there are new collisions or problems, I will fix them of course-- but first I'd like to hear that after that the patch WILL be added short term :/

Comment 30 Tony Houghton 2007-11-12 22:25:25 UTC
I get the point about the difficulties of windows being maximized and not maximized at the same time, but the advantages surely outweigh the problems. I don't mind the idea of having these extra actions available on the titlebar instead, but to my mind the maximize button is more logical. It also saves the complication of being conditional on options (I don't know about Carlo's patch), and is consistent with other window managers. And there are patches already available. I don't care whether mine or Carlo's is used but please let's have it incorporated.
Comment 31 Elijah Newren 2007-11-13 14:25:52 UTC
(In reply to comment #28)
> This (and related bugs) really make me regret ever agreeing to support
> vertical and horizontal maximize at all... they've created a cascade of bugs
> and screwy UI issues. A learning experience I suppose.

+1.  I really wish that when I noticed the bugs in meta_window_fill_{horizontally|vertically}(), it would have been nice if I would have realized that the correct fix was ripping it out instead of "fixing" them.  Didn't realize the amount of additional work they'd become to actually fix...

> Vertical and horizontal maximize don't have any representation, nor can I
> think of a good one. So, if people get in the state accidentally (say by
> right-clicking in the wrong place), it's a "why can't I resize this window???"
> type situation. 

(True, but the user can click on the maximize button to complete the maximization, then click on it again to return the window to normal size.  It's probably not discoverable enough, but at least it's something.)
 
> Anyway... I suppose that's all a bit of a tangent. But it *is* tempting to
> just rip vertical and horizontal maximize back out of the code ;-)

Very tempting, but oh well.


(In reply to comment #29)
> When Havov says "I regret ever agreeing to support vertical and horizontal
> maximize at all" and even "it *is* tempting to just rip vertical and
> horizontal maximize back out of the code", then all I can think is: why is he
> being so selfish about it? Because you don't use it, it doesn't need to be 
> available for others?

"selfish" doesn't seem like quite the right word.  prudent about how to spend maintainence time would be more the issue.  (Even if extra volunteers exist to work on it, it will significantly increase maintainence burden for all other maintainers regardless.)

> The cascade of bugs and screwy UI issues have all been resolved by me a year
> ago in another patch that I wrote (which still hasn't even been reviewed).

Yeah, I suck and I'm terribly sorry about that.  I did spend many hours over many days looking at the patch; I noticed some things that looked good, some that were good starts but could be improved a bit, and other things that looked like workarounds to other bugs.  However, I couldn't keep enough state in my head to feel confident whether I was understanding the full behavior and ramifications so I really wanted to test it out.  I kept assuming I'd be out of school soon (which kept being delayed beyond my control) and be able to get my own multi-monitor setup to test it out with soon (and then had computers and monitors suddenly going bad).

I guess I should at least upload the comments I wrote down on a printout of your patch well over a year ago.  I'll try to dig them out in the next day or two and do that.  Hopefully I can get a multi-monitor setup soon too (and then I'll volunteer to update and fix it up as well if you like; yeah, despite the fact that I'd personally rather rip out vertical and horizontal maximization.)

Sorry about putting you through so much pain on this issue.
Comment 32 Carlo Wood 2007-11-13 18:51:21 UTC
Elijah, thanks for your comment. I know I've been an ass lately, and although I could defend my behaviour by saying that I was frustrated, I would like to add that I realize that all your and Havoc's arguments are, actually, correct:

It DOES make the code more difficult to maintain, it will cost more time and it will introduce new bugs. Yet, I would like to see unidirectional maximization to be fully supported on dual head set ups. I can only ask for the willingness of the other maintainers to bare the additional complexity.

However, I'd make it clear that I am willing to assist in every way possible to make it work. There is just this nagging feeling of having to fix a patch over and over again while it is not committed yet. Therefore (a while ago) I decided not to fix it anymore. The catch-22 now is you can't/won't apply a broken patch (though still very workable, I'm using it right now and normally I see no problems). So, I'd like to propose that you let me know when you WILL have time. Then I will dive into the code again and fix all outstanding issues. Once the patch is ready again to be applied, then (I hope) you can review it and commit it (after we worked together on any additional issue you find). That way the time between me fixing the patch one more time and it actually being committed will be short.

Thanks,
Carlo
Comment 33 David Laban 2008-01-19 17:07:55 UTC
Please tell me when this is all sorted out.

This missing functionality is the biggest thing keeping me from using GNOME as my DE currently. I'm thinking of trying out GNOME again when 2.22 comes out. Hopefully it won't be too hard to use an alternative window manager until this is all fixed.
Comment 34 Thomas Thurman 2008-01-19 22:38:12 UTC
I came over here to see what was going on, and I had to spend about two hours reading it and taking notes. So here are my notes.

0. General background to adding features: http://ometer.com/features.html. Adding new features means more code to go wrong and more code to maintain, which is prima facie bad. Adding new features and disabling them by prefs is not an answer: it actually makes the situation worse, since the code is run less and will therefore be the source of rare bugs, and the pref code will need maintenance too.

1. It is possible to horzmax/vertmax with the keyboard, but this is hard to find (Havoc, bug 456278, comment 5, calls them essentially easter eggs). Some people think that this functionality is good and should be easier to find, or that it should at least be findable if we're going to support it at all. Other people think that it's a bad thing and are considering removing the whole thing (Havoc, comment 28; Elijah, comment 31).

2. The horzmax/vertmax functionality that does exist has been greatly improved since people's original objections (Carlo, comment 3). Havoc still thinks that the way it's shown in button states is confusing (comment 28); Carlo provides a counterargument to this in comment 29.

3. Some people says there should be a way of horzmax/vertmax with the mouse (Carlo, comment 1). One possible way is middle-click and right-click on the maximise button (Carlo, attachment 84626 [details] [review] et alia; Tony, attachment 456278). Havoc says this is a bad idea because right-click means context menu (comment 2, and bug 456278 comment 5). Carlo points out that this doesn't mean that horzmax/vertmax is per se evil, just that this way of doing the UI is contrary to HIG (comment 3).

4. Another possibility is to add the options to the double-click-menu-bar system (Cosimo, comment 19, attachment 95435 [details] [review]). Later, Havoc agreed that this was a less objectionable way of dealing with things (comment 28).

5. It might astonish newbies if they hit any of these by mistake, so perhaps it should be an option in a "traditional users" panel (Havoc, comment 2), or "power users" panel (Havoc, comment 4), although this is really just a proposal for control-center and doesn't exist anywhere at present (Havoc, comment 4). (Presumably the CC extension would modify a metacity pref anyway, so this would mean we could unilaterally implement even while we were "waiting" for the CC people to get around to noticing us.)

6 (not directly related, but brought up). Maybe we need to think about whether it would actually be simpler internally, and easier to maintain, to have a set of (mouse/kbd) events, a set of resulting actions, and a mapping (Carlos, comment 3). This is not the first time this question has come up (recall the Linus controversy). Havoc says this is trickier than it sounds and the debris of one attempt is already in Bugzilla somewhere (comment 4).

A question I (Thomas) have: are vertmax/horzmax *currently* window states, or resize operations?

With my "person who spends at least 12 hours every day using Metacity" hat on, I would like horizontal maximisation. With my maintainer hat on, I can see arguments against it, and obviously we have to find consensus. I would like to revisit the issues in point 6, and see whether it's still such a problem.
Comment 35 Tony Houghton 2008-01-19 23:08:59 UTC
> 6 (not directly related, but brought up). Maybe we need to think about whether
> it would actually be simpler internally, and easier to maintain, to have a set
> of (mouse/kbd) events, a set of resulting actions, and a mapping (Carlos,
> comment 3). This is not the first time this question has come up (recall the
> Linus controversy). Havoc says this is trickier than it sounds and the debris
> of one attempt is already in Bugzilla somewhere (comment 4).

I like the sound of this; it's how openbox is configured if you look beneath
the GUI tool. You can assign multiple actions to one button eg focus and
raise. That would be good, because it would provide a fix for bug 326156
too. OTOH even more reason for Elijah and Havoc to hate the idea :-/.
Comment 36 Vincent Untz 2008-01-20 09:03:23 UTC
FWIW, I use vertical maximization daily (with keybindings -- I wouldn't need a gui for this). And I'm quite happy with the way it is right now. I would even be ready to argue that it's more useful than minimization ;-) Anyway, just my personal opinion, so it's not that important.

(In reply to comment #34)
> A question I (Thomas) have: are vertmax/horzmax *currently* window states, or
> resize operations?

Didn't look at the code, but I'm 99% sure it's window states. Changing this to resize operations would probably simplify the code in some ways (but would also means less support of the EWMH, not sure how important it is). But it won't change the core problem of the reporter, ie, the fact that it's not gui-accessible.
Comment 37 Thomas Thurman 2008-01-20 20:52:23 UTC
So, the current situation is untenable: the horzmax/vertmax code is barely run and as such is going to be an instability problem. It is also well-nigh undiscoverable.

Hence, I can see two ways to go forward:

1) We remove horzmax and vertmax entirely (comment 28, comment 31).

2) We add it as an action to the (double|middle|right)-click titlebar code (comment 19, comment 28, and similar to attachment 95435 [details] [review]). This means that both the horzmax/vertmax code *and* the (double|middle|right)-click titlebar code get more visible and more used. There will need to be a control-center setting for what (double|middle|right)-click titlebar do anyway, and there already is a gconf setting, so the amount of added complexity is low.

I would go with 2. Your thoughts are welcomed.
Comment 38 Thomas Thurman 2008-01-20 22:07:57 UTC
(some feedback from other users in a Metacity Journal post:
http://blogs.gnome.org/metacity/2008/01/20/2008-01-19-minimal-journal/ -- one says remove it, four say they want it)
Comment 39 John Stowers 2008-01-20 23:51:44 UTC
Wow! 

I didn't even know vertical maximization existed in metacity. Having just got a widescreen monitor I am glad I found this bug.

I was already getting sick of resizing GNOME terminal vertically (because normal maximixing a terminal over 24" makes no sense)

Consider this a HUGE ++ on making the feature more discoverable through the window bar title code
Comment 40 Andrew Conkling 2008-01-23 04:09:10 UTC
(In reply to comment #37)
> 2) We add it as an action to the (double|middle|right)-click titlebar code
> (comment 19, comment 28, and similar to attachment 95435 [details] [review] [edit]). This means that both
> the horzmax/vertmax code *and* the (double|middle|right)-click titlebar code
> get more visible and more used. There will need to be a control-center setting
> for what (double|middle|right)-click titlebar do anyway, and there already is a
> gconf setting, so the amount of added complexity is low.

I think this sounds great. Maybe the titlebar code would be more acceptable and in line with the HIG? Adding "maximize horizontally/vertically" as another possible Titlebar Action would fit conventions.

Of course, *I'd* use the middle-click on the Maximize button all the time. Oh wait, I'd have to add the Maximize button back to my titlebar. (It's useless to me now on my widescreen monitor.)
Comment 41 Thomas Thurman 2008-01-28 18:03:22 UTC
Attachment 95435 [details] looks generally good to me on a quick look over except that in your meta_frame_titlebar_event() changes: you need to check for META_FRAME_ALLOWS_(HORIZONTAL|VERTICAL)_RESIZE and not META_FRAME_ALLOWS_RESIZE.

Does anyone object to adding this to the list of actions which can occur on various double/middle/right-click titlebar actions? Havoc suggested it, we have a bunch of people saying it will help them, and it will help people discover both the unidirectional maximisation and the click-on-titlebar functionality (which is especially important for unidirectional maximisation, since that's a lot of convoluted code which is rarely run). I think we've reached some level of agreement here; if there aren't any objections I'll commit some version of attachment 96435 [details] later today.

I am marking the middle/right click on maximise button patch as rejected since, as Havoc pointed out, this isn't anything like anything we already do, whereas the maximisation thing is actually quite similar.
Comment 42 Tony Houghton 2008-01-28 19:15:53 UTC
There is a big problem with this. I think Havoc at least would insist on right-click opening the menu, while middle-click is already bound to lower, so that effectively leaves only double click available. I sometimes use horizontal and sometimes vertical so I would want to bind both. Surely I'm not unique? 

How would you decide on the default behaviour? You could decide one of horizontal or vertical is more popular than the other and bind only that option by default, but there'd probably be a significant number of users moaning that you've chosen the wrong direction (let alone those who want both). OTOH if you leave the defaults as they are and let the user decide, these features are still going to be difficult to discover.

Or you could realise that binding them to right- and middle-click on the maximize button, consistent with all other Unix window managers, really is the most sensible thing to do ;-).
Comment 43 Thomas Thurman 2008-01-28 19:25:52 UTC
No, it would be just like the existing functionality for all the other things you can do with double/middle/right click. Neither would be bound by default; if you wanted to bind both you'd be welcome to do so. We already have this in the titlebar and adding it to buttons would just be a gateway to insane complexity (oh, I want to check my email, I'll just map that to ctrl-alt-double-right click on the minimise button).
Comment 44 Carlo Wood 2008-01-28 19:40:16 UTC
Created attachment 103910 [details] [review]
Version 7 (20080128) of "unimaxmouse" patch.

This is just an update of the patch to match the current SVN.
Comment 45 Tony Houghton 2008-01-28 20:48:41 UTC
"Right-click on the maximize button for horizontal, middle-click on the button for vertical," is a bit of a mouthful so I'll refer to it as "FMB" (for Flexible Maximize Button) from now on.

In response to comment 43...

Why go on about checking email? Nobody's ever suggested binding anything other than simple wm functions. Binding arbitrary (wm) functions to any buttons wasn't my idea anyway, I wouldn't have agreed with it if I'd realised it was just going to be used as an opportunity to build a straw man argument.

One of the original arguments against FMB was that right-click should always open the menu, but that obviously doesn't apply if you can bind it to something else on the title bar...

And if the one-way-maximize functions aren't going to be bound by default, bang goes the "discoverable" argument. Unless you believe that although average users are ignorant of FMB in most Unix window managers they're quite at home with gconf-editor.
Comment 46 Thomas Thurman 2008-01-28 21:08:39 UTC
(In reply to comment #45)
> "Right-click on the maximize button for horizontal, middle-click on the button
> for vertical," is a bit of a mouthful so I'll refer to it as "FMB" (for
> Flexible Maximize Button) from now on.

Okay, then, let's say that

  FMB  = middle and right on maximise are hardwired to H and V

  TCA  = titlebar click action configurable to H and V and various other things.

> Why go on about checking email? Nobody's ever suggested binding anything other
> than simple wm functions. Binding arbitrary (wm) functions to any buttons
> wasn't my idea anyway, I wouldn't have agreed with it if I'd realised it was
> just going to be used as an opportunity to build a straw man argument.

I was being silly. I'm sorry.

> One of the original arguments against FMB was that right-click should always
> open the menu, but that obviously doesn't apply if you can bind it to something
> else on the title bar...

No, it applies perfectly. Right-click *should* always open the menu. As it happens *now*, this isn't perfectly true. It is true by default, but you *can* bind right-click on titlebar to do other things. This is a special case which already exists. TCA uses the existing ability to click on the titlebar, and adds a couple of new actions which would not have bindings by default.

> And if the one-way-maximize functions aren't going to be bound by default, bang
> goes the "discoverable" argument. Unless you believe that although average
> users are ignorant of FMB in most Unix window managers they're quite at home
> with gconf-editor.

Nobody mentioned gconf-editor. There is control-center, and control-center can (or possibly already does for all I know) have a drop-list of possible actions for double, middle and right click. We would merely be adding new entries into the lists. The default behaviour wouldn't change at all.
Comment 47 Tony Houghton 2008-01-28 23:03:53 UTC
> Nobody mentioned gconf-editor. There is control-center, and control-center
> can (or possibly already does for all I know) have a drop-list of possible
> actions for double, middle and right click. We would merely be adding new
> entries into the lists. The default behaviour wouldn't change at all.

Fair enough if that's the intention. I don't think control-center, in Debian unstable at least, has caught up with configurable title bar actions.

I could get used to TCA I suppose, but to me having one of the actions as double-click and one as right-click seems more quirky than both being a single click on a button that's already established as maximize. And the main motivation behind TCA over FMB seems to be keeping the code consistent, and that's straining out gnats.

I get frustrated because in many ways metacity is my favourite wm, but it sometimes seems like it's a victim of negative user-friendliness ie when you can't make computer phobics like it, make competent users dislike it instead, at least it makes everyone equal.
Comment 48 Dafydd Harries 2008-01-31 00:57:35 UTC
I love the ability to vertically maximise terminal windows and I'd be pretty disappointed if that were removed.

Re window states vs resize operations: I think at the least, if you have a horizontally maximised window and you then invoke vertical maximisation, the window should become fully maximised as opposed to just at full size horizontall and vertically.

There are some cases where you can make metacity forget the vertical/horizontal unmaximised size, but that's a different bug and right now I can't work out a minimal set of operations to reproduce it.
Comment 49 Carlo Wood 2008-01-31 01:23:21 UTC
Dafydd, could you try my two patches, and see if you still see such bugs as where metacity forgets vertical/horizontal unmaximised size?

The patches are "Version 7 (20080128) of "unimaxmouse" patch." of this
bug (see attachment list below) and "Version 7 (20080129) of "xinerama" patch." that you can find as attachment under bug #356715

You can apply them in either order to a recent SVN check out.
If you're using debian, then let me know and I'll give you a script that will generate a debian package from the (patched svn) source tree.
Comment 50 Thomas Thurman 2008-02-21 03:25:42 UTC
Here are my thoughts.

A. As I said earlier, the status quo isn't an option: we need either to remove this or to make it more discoverable. Consensus is to make it more discoverable. Let's go with that. I am, however, worried that this is sticking on the FMB versus TCA discussion and we'll end up doing neither.

B. We have three patches:

       patch          by       implementing

 attachment 92794 [details] [review]     Tony     FMB
 attachment 95435 [details] [review]     Cosimo   TCA
 attachment 103910 [details] [review]    Carlo    FMB

C. I am unconvinced that FMB is as much better as its advocates make out. Out of the two options, TCA is far more discoverable because it can be added as options to a setting we already have, whereas FMB can only be discovered by accident. This is just as much about simplicity for the user as it is maintainability of the code, although both are important.

D. The idea of double/middle/right-clicking buttons and binding them to unusual actions is remarkably similar to the rejected bug 83892. In that bug, people wanted to be able to close windows by double-clicking the menu button, but only because other WMs allowed it. Almost exactly the same arguments were played out there.

E. Therefore, I am proposing that I use the maintainer stompy boots on the matter and that I will polish up attachment 95435 [details] [review] to go into trunk. I will do this tomorrow night and make a release immediately afterwards.

F. FMB advocates should, if they feel like it, make a new bug advocating FMB. I can imagine somewhere down the line having at least a collected set of patches with this and bug 83892 for "you click places and weird stuff happens", even if we never do do the arbitrary user action->WM action binding mechanism that's been floated now and again.
Comment 51 Thomas Thurman 2008-03-01 14:42:07 UTC
*** Bug 439749 has been marked as a duplicate of this bug. ***
Comment 52 Thomas Thurman 2008-03-01 14:45:07 UTC
From that duped bug, two patches to do much the same thing (both TCA):
attachment 106323 [details] [review] by Christopher Bratusek
attachment 101007 [details] [review] by Jason Ribeiro
Comment 53 Thomas Thurman 2008-03-03 02:00:59 UTC
Okay then: attachment 95435 [details] [review] went in (with some credit to all the other people who wrote patches, too).  I fixed a little code rot and used "vertically" etc instead of "vert".

http://svn.gnome.org/viewvc/metacity?rev=3619&view=rev
Comment 54 Carlo Wood 2008-03-03 02:16:58 UTC
I don't understand, why that patch? How am I supposed to maximize one window vertically and another horizontally now? Change the configuration of what a title bar click does every time?
Comment 55 Thomas Thurman 2008-03-03 02:23:22 UTC
Is it not possible for you to use, say, double-click on the titlebar for vertical and middle-click for horizontal?
Comment 56 Carlo Wood 2008-03-03 02:25:42 UTC
I guess it is, I didn't know there were more than one signal that could be bound like that. Can I also bind left- middle- and right- click on the title bar buttons to these functions?
Comment 57 Thomas Thurman 2008-03-03 02:40:41 UTC
Not as things stand.  (But do see point F of comment 50; such an idea, which would also be consonant with such requests as bug 83892, has occasionally been floated.  Even more common has been a request to have a generalised set of "MetaActions" which keys, titlebar clicks, buttons, etc., could be bound to; of course then there'd be the question of whether such requests could be parameterised, and eventually we end up reimplementing Sawfish, only not as well, because it's in our own ad hoc language rather than Scheme.)
Comment 58 Josh Triplett 2008-03-04 00:44:50 UTC
I've discovered this bug a few times, and assumed that the metacity policies on features and consistency would not allow it to get fixed.  I just discovered it again, and found that it got fixed, in a way.  Now I have some comments on the usability of the fix that went in.

I already use the ability to double-click the titlebar and maximize the window.  I use this because I can hit a target the width of my screen more easily than a small maximize button.  I see no reason to waste that easily-hit space by not assigning some action to it, as suggested in comment 20 item 3.  For the same reason, I use right-click on the titlebar to get to the window menu, rather than clicking on the small icon in the top left.

I would very much like to use vertical and horizontal maximization as well.  However, binding these to various types of clicks on the titlebar seems quite unintuitive and suboptimal to me, for several reasons.  First, given the above, I only have middle-click still available, and that only lets me use one of the two.  Second, while I have an expectation that right-click on the titlebar will give me the window menu, I have no such expectation about right-click on a *button* in the titlebar; I would expect that to either do the same thing as left-click on the button or to do some other function related to the button.  Third, I think that metacity should strive to provide power *and* consistency here, by providing a consistent interface to these features rather than one created through per-user customization.

Which of these scenarios sounds more metacity-like:

1) User A has middle-click on titlebar bound to vertical maximization, doubleclick on titlebar bound to full maximization, and right-click on titlebar bound to horizontal maximization.  User B has middle-click full maximization, doubleclick vertical maximization, and right-click window menu.  User C has the defaults, and does not have access to vertical or horizontal maximization.

2) All users can left-click on the maximize button for full maximization, right-click on the maximize button for horizontal maximization and middle-click for vertical maximization.  This does not change from system to system; it always works the same way.  All functions related to maximization occur via the maximize button.  At least by default, right-clicking anywhere on the titlebar other than on the buttons will bring up the menu.

To me, at least, the second scenario sounds consistent, works by default, does not rely on customization, and overall sounds more like how metacity should work.