For me, the re-sizing of windows with xfwm is, frankly, cumbersome and requiring either too much mouse precision [to hit the window edge - which, at the same time, I don't like to be too thick], or requiring two hands [alt + rmb drag on the window area], or not really convenient [rmb click, selection from menu] I wonder - how about employing right mouse button dragging of the titlebar for this pivotal purpose? Basically, what I'm proposing is - make the titlebar a resize region, activated when dragged with right mouse button. This would make window resize [a pivotal function of a window manager] much easier, and attainable with just one hand. I just found that currently, with rmb drag on titlebar, you can move the window without bringing it forward. My presumptuous guess is this is not a widely used feature, and easy resize instead would be more appreciated... One would just catch the left half of the titlebar with rmb = could resize left and top edge. If you catched the right half = resize top and right edge. Would it be possible to make this an option at least?
Created attachment 6344 rmb drag title resize
What I am proposing can actually be achieved very easily, see the attached patch. It's a one-line change in events.c, titleButton function: if (tclick == XFWM_BUTTON_DRAG) { - clientMove (c, (XEvent *) ev); + clientResize (c, (ev->x < c->width / 2 ? CORNER_TOP_LEFT : CORNER_TOP_RIGHT), (XEvent *) ev); } I find it oh too practical.... Resizing is a breeze with this.
A bit more complicated patch proposal below. With this: right dragging left 2/5 of titlebar resizes topleft corner; right dragging middle 1/5 will resize top edge (i.e. only height change); right dragging right 2/5 will resize topright corner. diff --git a/src/events.c b/src/events.c index 50303b0..03fc465 100644 --- a/src/events.c +++ b/src/events.c @@ -772,6 +772,7 @@ static void titleButton (Client * c, guint state, XButtonEvent * ev) { ScreenInfo *screen_info; + int part; g_return_if_fail (c != NULL); g_return_if_fail (ev != NULL); @@ -794,7 +795,11 @@ titleButton (Client * c, guint state, XButtonEvent * ev) tclick = typeOfClick (screen_info, c->window, (XEvent *) ev, FALSE); if (tclick == XFWM_BUTTON_DRAG) { - clientMove (c, (XEvent *) ev); + if (ev->x < 2*c->width/5) part = CORNER_TOP_LEFT; + else if (ev->x > 3*c->width/5) part = CORNER_TOP_RIGHT; + else part = CORNER_COUNT + SIDE_TOP; + + clientResize (c, part, (XEvent *) ev); } else if (tclick != XFWM_BUTTON_UNDEFINED) {
Created attachment 6345 rmb drag title resize v2
Tested this, works great! Although I modified it to get a 1-3-1 distribution, which feels more natural. Also doesn't work on top of window buttons unfortunately.
The reason I chose 2-1-2 distribution is basically just a workaround to make resizing of very slim windows possible. It is rather hard to enlarge a very slim window with 1-3-1, due to the fact [as you point out] the rmb drag doesn't work on windows buttons and icon with the current patch. Anyhow, looking at an older post of mine https://forum.xfce.org/viewtopic.php?id=9083 - it would be even better to implement twm-style resizing, initiated by right-dragging on the titlebar. The resize would work like that: You would right-drag [=click and hold right mouse button, move the mouse] from the titlebar. Whichever window edge you'd cross, you'd "grab it" and can move it, hence resizing the window - the opposite one stays fixed. For example, you drag the mouse from titlebar across the top = you grab the top edge, bottom side holds. You can enlarge as well as shrink the window, once you got the hold of the edge. You can also switch the side you are resizing by e.g. dragging "top across the bottom" - top becomes fixed at the original position, bottom edge can be moved. The resize is finished when you release the mouse button [and can be also cancelled with 'esc']. Basically it's a mouse gesture, that's been here since the days of twm, where I always loved it. There's a dedicated button for this purpose in twm, but by using the rmb drag off of titlebar, no button would be necessary. You could enlarge window with one swipe of a mouse, shrink with two swipes (with first you catch the edge, then shrink the window). And, foremost, titlebar is easy to hit; no "pixel-hunting". I'll try to write a patch for this (code is better than lengthy arguments), not sure if I'll manage.
What's wrong with alt+rmb to resize?
(In reply to Olivier Fourdan from comment #7) > What's wrong with alt+rmb to resize? It requires two hands.
Created attachment 6349 Resizing by right mouse dragging from the titlebar [twm inspired]
To my own surprise, I think I succeeded in adding the "twm like resizing" into xfwm4, see the above attachment 6349 . To resize a window, you press and hold right mouse button anywhere on the titlebar [except window icon and buttons] and drag the pointer (+) to the side(s) you’d like to resize. Once you hit the window edge, you "grab" it, and can then size it (it follows the mouse), releasing the pointer when the window is the desired size. That’s about it. Easily doable with just one hand. Inspired by twm http://www.x.org/archive/X11R6.8.2/doc/twm.1.html
Created attachment 6351 Resizing by right mouse dragging from the titlebar [twm inspired] v2 Much cleaned up and simplified version of the patch, with more respect to original code. Removed (superfluous) ability to switch sides during resize.
Thanks for the patch, but tbh I am not entirely convinced that taking twm as a usability example is the right path for xfwm4. I'd rather see a patch to implement input-only windows to increase the resize area (only when the compositor is active, obviously, so it would remove those automatically when the compositor is off), a bit like gtk 3.x does for its CSD windows with a compositor enabled. See https://git.gnome.org/browse/gtk+/tree/gtk/gtkwindow.c for what I mean.
(In reply to Olivier Fourdan from comment #12) > Thanks for the patch, but tbh I am not entirely convinced that taking twm as > a usability example is the right path for xfwm4. > > I'd rather see a patch to implement input-only windows to increase the > resize area (only when the compositor is active, obviously, so it would > remove those automatically when the compositor is off), a bit like gtk 3.x > does for its CSD windows with a compositor enabled. > > See https://git.gnome.org/browse/gtk+/tree/gtk/gtkwindow.c for what I mean. Thanks for the reply. I might have been repeating "twm" too many times... The primary point is that it is a very (very) practical and easy approach to resizing. Please - give it a try. (I will try to make a demonstration video/animation, but one has to try it anyway to believe it's any good... and it is)
(In reply to Adam Purkrt from comment #13) > [..] > Please - give it a try. Oh, I did :) > (I will try to make a demonstration video/animation, but one has to try it > anyway to believe it's any good... and it is) I am not saying it's bad, but I reckon it's a lot less intuitive than the already implemented alt+rmb that will resize from the closest corner/side, or simply the keyboard shortcuts to resize. It is also less efficient as one has to first click on the title bar and then move to the corner/side that he/she wishes to move. So if we were to add code, I'd prefer to see the approach I posted in comment 12
Created attachment 6352 rmb_drag_titlebar_resize_gesture.diff only a minor cleanup of the proposed patch
(In reply to Olivier Fourdan from comment #14) > (In reply to Adam Purkrt from comment #13) > > [..] > > Please - give it a try. > > Oh, I did :) Let me thank you :) > I am not saying it's bad, but I reckon it's a lot less intuitive than the > already implemented alt+rmb that will resize from the closest corner/side, > or simply the keyboard shortcuts to resize. Alt+rmb does require two hands to complete. The proposed gesture requires only one (on the mouse). For me, it's a night and day difference. The point is to use the mouse anyway (preferably mouse only), so I honestly don't know why you are mentioning keyboard shortcuts. It's like saying "you can walk in those shoes" when one ponders which bike to ride. Couple of arguments in favour of the proposed gesture [considering one wants to use the mouse to resize] * You always have a visual feedback with the gesture. The target - first the tilebar, than the window edges - is visually defined. No need to wonder "is this the upper third or am I in the middle part already?" which happens [to me] when using alt+rmb. * You can resize any side, any corner with the gesture - as opposed to only lower right corner when using "resize" command from the rmb click on the titlebar menu. * The move and resize can be easily streamlined - first you move with lmb drag, than you can release lmb, and continue right away with rmb and resize, since you are still on the titlebar. Example: move small window from lower left corner to upper right and enlarge it. A real breeze with the gesture. Intuitiveness is highly debatable. Sure, people are not used to rmb drag the titlebar to resize [they hardly can, if it's not implemented :] But they are more than used to lmb drag on the titlebar to move the window. It would be "move with left, resize with right"... pretty complementary, quite intuitive to me. It is also less efficient as one > has to first click on the title bar and then move to the corner/side that > he/she wishes to move. > I would argue it is not. Distance alone is not the primary concern for efficiency (ergonomy); the size of the target often matters more. Let me mention here the so called Fitt's law: http://cgvr.cs.uni-bremen.de/teaching/vr_literatur/A_Quiz_Designed_to_Give_You_Fitts.shtml The titlebar is ~25 pixels high on my very standard XFCE installation, times c->width. That's a pretty comfortable target. Once you hit it [it still does require some precision, i.e. steadiness], you can move the mouse very fast to the desired edge. As long as you hold rmb down, you have a _certainty_ you will grab the edge. No need to pinpoint anything. Just one swift swipe, opposed to tedious pixel-hunting. > So if we were to add code, I'd prefer to see the approach I posted in > comment 12 From what I understand, you are working to make the resize borders functionally thick and visually thin; adding transparent extra active area. Will this active area be as wide as the titlebar? If not, I'd bet the gesture will still be faster. Definitely for resizing of the top edge, almost as fast if not faster for left and right, probably a bit slower for the bottom edge. Overall a tie at worst. I know this has been rather long. All in all, I'm not saying "hey, let's abandon all the other methods and use only this gesture, it's always the best option". But I do think it should be included as a valuable and valid way of how to get the resize done. I see nothing wrong that there would be one more way how to do a window resize, since as I already stated it is the pivotal, if not quintessential, operation of a window manager.
Created attachment 6353 picture about streamlining move and resize resize immediately following move can be easily streamlined with rmb resize gesture - 1) you move the window with lmb drag of titlebar 2) you release the lmb and can immediately press rmb - since you are still on the titlebar
The patch/gesture has issues resizing mpv. Has something to do with the fact it actively maintains the aspect ratio. Will try to fix. One principal disadvantage of the gesture - the very requirement that the window has a titlebar. The gesture is not applicable e.g. on chromium, when it's configured to have none.
(In reply to Adam Purkrt from comment #18) > [...] > One principal disadvantage of the gesture - the very requirement that the > window has a titlebar. The gesture is not applicable e.g. on chromium, when > it's configured to have none. Chromium without decorations is what is called CSD (for client side decorations), just like GNOME/gtk+ CSD windows, means that the client itself decorates its window. In this case the window manager does not add any title bar nor drag handles, it's all up to the clients to do that by itself. So nothing the window manager can do there, it's not specific to your patch. In the case of GNOME/gtk+ with compositing enabled, the toolkit adds that input only area around its windows so the size of the handle is totally dependent on the gtk+ theme used.
Created attachment 6365 rmb_drag_titlebar_resize_gesture.patch Incorporated fixes related to the resize of the windows with fixed aspect ratio 1) added "passdata->ow = c->width;" and "passdata->oh = c->height;" at the appropriate places (that was the primary bug mentioned above) 2) found and fixed another annoyance - after resizing of a fixed aspect ratio window, when subsequently trying to resize with the gesture - the size of the window would sometimes shrink slightly even before hitting any edge (when the cursor is still crosshair). That is basically because clientConstrainRatio does not converge with one call. Repeated calls can reduce the size (pixel by pixel), until it converges to a certain point, where neither "minx * c->height > miny * c->width" nor "maxx * c->height < maxy * c->width" is fulfilled. Simply disabled the call to clientConstrainRatio when handle still in the "CORNER_COUNT + RESIZE_GESTURE" phase.
(In reply to Adam Purkrt from comment #0) > For me, the re-sizing of windows with xfwm is, frankly, cumbersome +1
Created attachment 6450 xfwm4-4.12.3-rmb_drag_titlebar_resize_gesture.patch Added patch against xfwm4-4.12.3 (no changes in code, just adjusted for 4.12.3 instead of git). For reference from a forum https://forum.xfce.org/viewtopic.php?pid=38581
Any updates on this? I've been using this patch very frequently for years now. Very very useful, especially considering bug 11808.
As stated before, I don't think this patch is suitable upstream, it won't work with client side decorations, so it's a NAK from me for upstream.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/193. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev