GNOME Bugzilla – Bug 456278
Maximize in one direction at a time with mouse
Last modified: 2007-08-01 03:14:30 UTC
I like being able to maximize only horizontally or (vertically) but find it difficult to remember keyboard controls for it and would like middle and right click to maximize vertically and horizontally respectively. I realise the rationale for consistency of right mouse button behaviour but countering that is many other window managers do what I want so experienced users will be used to it. But I don't want to use another wm, I like nearly everything else about metacity. Would you accept a patch that makes it optional? I've already written one and will attach it. It's against 2.18.5 because that's what I've got in Debian so it's easier to mess around with the package than the latest version. If it's acceptable and applies OK to HEAD I guess all that needs to be done is translations for the new gconf schema.
Created attachment 91682 [details] [review] Patch to implement one way maximizing on middle/right mouse click
Created attachment 92792 [details] [review] Same again, but against current trunk a) Sorry for not getting back to you for a fortnight. b) There's been a little code rot since you submitted the patch, which I've fixed; I'm attaching the fixed patch. c) The code looks good and it does what it's supposed to. d) I have no objection to this functionality being in the default build, and it does seem useful. Does anyone else have any thoughts? e) I *don't* think it should be a pref; I think it should be hardwired. If it *is* a pref, it should default to "on". But I might be wrong. Does anyone else have any thoughts?
Oh, actually-- is this a dupe of bug 358674? I should have checked before.
Mm, yeah, I think it is. I will link to the patch there. *** This bug has been marked as a duplicate of 358674 ***
> Does anyone else have any thoughts? I think having buttons do something different on middle and right click is totally busted and bizarre, but other than that, no ;-) Of course I don't think separate vert/horiz maximize makes sense either, in part because there's nowhere good to put the features in the UI (other than keybindings), leading to insanity like making them a magic easter egg on the maximize button. I do agree there's no point in making it a pref, since it's essentially an easter egg anyway and most people won't find it. Anyway, "it doesn't hurt anyone who's not using it" I guess - though I think that argument is crap and leads to a slippery slope of more and more code to be supported and maintained, I suppose there's some half-truth to it. Avoiding the pref at least makes the patch much smaller. The patch incidentally has a couple of "void funcname" on the same line, should be "void\nfuncname"
(In reply to comment #5) > I think having buttons do something different on middle and right click is > totally busted and bizarre, but other than that, no ;-) I think we crossed into that territory when we accepted the Linus patches to make titlebar right-click and double-click and heaven knows what else do funky things, but that's no reason to continue down that road, of course. (Actually, if we *did* decide to continue down that road, maybe a cleaner solution would be to handle maximise left/middle/right click, etc., the same way as we currently handle titlebar double-left/middle/right click, and so on, and let people set them to maximise fully, maximise vertically, and so on. I think this paragraph is becoming a reductio ad absurdum.) > The patch incidentally has a couple of "void funcname" on the same line, should > be "void\nfuncname" Oops. Should have caught that in review. Thanks.
(obsoleting patch since an identical one is in bug 358674)
(In reply to comment #6) > > I think having buttons do something different on middle and right click is > > totally busted and bizarre, but other than that, no ;-) > > I think we crossed into that territory when we accepted the Linus patches to > make titlebar right-click and double-click and heaven knows what else do funky > things, but that's no reason to continue down that road, of course. In a way, the Linus patches were just an extension of allowing double-click on titlebar do multiple different things -- and some of his patches included some nice code cleanup (even if the possible permutations of abilities was increased). So I'm not so sure that qualifies as crossing new territory. However, if you're looking for territory crossing, perhaps you could go back to allowing double-click-titlebar actions at all (instead of the sane choice of not-doing-anything, all other choices are utterly craptastic in my opinion -- regardless of the fact that the 'major desktop OSes' each do something different)...or hacks that *almost* did basic-unidirectional-maximization (but which had bugs due to being hacks that caused more code to support it properly which resulted in the shake_loose being busted which results in some really complicated code being needed and Carlo being mad at me for never getting back to him). Or maybe it was the auto-raise (raise-on-focus-with-delay). Or maybe it was started way back with supporting sloppy/mouse focus. (raise-on-click and focus_new_windows modes are newer examples that are my fault) Just because we're suffering from a slippery slope doesn't mean we should pull the sleds out and have races. :-) That probably sounded overly rantish. Sorry about that. On a lighter note...I've only added two prefs the entire time I've been maintaining metacity. Thomas, since you applied Linus' patches, that means you have as many as me already. And Havoc added way more prefs than I did. So you two are slippery-er than me. :-)