Created attachment 3082 xfwm4 tiling patch Hi all! It's not a secret that Windows 7 and KDE have a very nice feature — tiling windows when moving them to the left or right edge of the desktop. Encouraged by this useful feature I wrote a patch to implement it in xfwm4. I'm sorry for the code — it can be not good (but it works!), but I hope that you like this idea. Patch is attached, and there is also an AUR package for it: http://aur.archlinux.org/packages.php?ID=40030
Created attachment 3083 xfwm4 tiling patch v2
Created attachment 3084 xfwm4 tiling patch v5
Thanks for your contribution. I am not using neither kde nor windows 7, can you describe roughly what's this is about? Regarding the patch itself, I try to avoid any C99 and therefor C++ style comments. Also, I am not sure I understand this: + // we need to substract another two (left, right) frames' width + // because of two windows we have + + c->width = (wc.width - frameRight(c) - frameLeft(c))/2; + c->height = wc.height; Do you make the assumption that all windows have the same decoration? Can you also make sure it applies to the git master (no new features are added to the stable branches) I'll probably have more questions later :)
> Thanks for your contribution. I was glad to be useful. > I am not using neither kde nor windows 7, can you describe roughly what's this > is about? That is when the windows is moved to the edge of the screen it maximizes in the corresponding half of the screen. > Regarding the patch itself, I try to avoid any C99 and therefor C++ style > comments. Ok, I'll change them. > Also, I am not sure I understand this: > > > + // we need to substract another two (left, right) frames' > width > + // because of two windows we have > + > + c->width = (wc.width - frameRight(c) - frameLeft(c))/2; > + c->height = wc.height; > > Do you make the assumption that all windows have the same decoration? Yes, I do. I realize that it's not very good and I shall try to do this in other way. The screen with one maximized window (w1) is divided: Screen.Width = lp + w1lf + w1 + w1rf + rp, and with two windows (w1 & w2): Screen.Width = lp + w1lf + w1 + w1rf + w2lf + w2 + w2rf + rp, where: lp/rp = left/right panel (dock) width (if exists), w1/2lf = window 1(left)/2(right) left frame, w1/2 = window 1/2 width, w1rf = window 1/2 right frame. After calling clientNewMaxSize(c, &wc) we have: when maximized one window: wc.width = Screen.Width - lp - w1lf - w1rf - rp = w1, when maximized two windows: wc.width = Screen.Width - lp - w1lf - w2rf - rp = w1 + w1rf + w2lf + w2. On this basis I got: c->width = (wc.width - frameRight(c) - frameLeft(c))/2; (a) where: frameRight(c) = w1rf, frameLeft(c) = w2lf, with assumption that w1lf == w2lf, w1rf == w2rf because of I can get frameRight/frameLeft only for active window - c. I think it's necessary to make a structure in which we can store pointers to currently tiled clients to make them available for getting their frames' sizes in the expression (a). I'll try to do it when I have some time. > Can you also make sure it applies to the git master (no new features are added > to the stable branches) Yes, I'll try to do it. > I'll probably have more questions later :) Ok, hope I can answer them :) -- Best regards, Denis. P.S. I'm sorry for my English. Hope that I could explain my thoughts :)
In place of using a new flag why not reuse the Maximizes_Horiz and Vert flags as well as storing the old dimensions in the same places it is stored for Maximizing. If I get a chance I may implement a few additions/changes of my own and post the patch here.
(In reply to comment #3) > I am not using neither kde nor windows 7, can you describe roughly what's this > is about? http://www.youtube.com/watch?v=MzQQcdw1qmY I like the maximize feature a lot. Also less notable are the double-click on the right/left or top/bottom border of a window to maximize respectively horizontally or vertically.
(In reply to comment #5) > In place of using a new flag why not reuse the Maximizes_Horiz and Vert flags > as well as storing the old dimensions in the same places it is stored for > Maximizing. If I get a chance I may implement a few additions/changes of my own > and post the patch here. Thanks for an idea! I'll think about it. Unfortunately I have a very little time. I shall try to make it all using git master. (In reply to comment #6) > (In reply to comment #3) > > I am not using neither kde nor windows 7, can you describe roughly what's this > > is about? > > http://www.youtube.com/watch?v=MzQQcdw1qmY > > I like the maximize feature a lot. > > Also less notable are the double-click on the right/left or top/bottom border > of a window to maximize respectively horizontally or vertically. Yes, these are also good features, I'll try to realize them.
Created attachment 3175 Port of Denis patch for git master branch. Denis patch did not apply against git master branch. I applied all his changes manually, converted all comments to the correct format and removed mixed code and declarations. The attached patch is the result.
Yai, really cool, it works great with current git (no crash). I'll test it more deeply :-)
Jérôme Guelfucci, thank you very much! I am very grateful because I really do not have enough time now!
No problem Denis, it was a really easy thing. There is a problem with the current patch. Drag a window to the left border and wait until it is moved to the next workspace (another xfwm4 feature), the mouse is moved a little bit right compared to the window. If you do that two or three times, you end up with a mouse more than half a screen away from the window, but you are still dragging this window.
Yes, I know about this bug. I want to rewrite something to fix this and to add some functionality.
Created attachment 3238 Port of Denis patch for git master branch. Updated patch which applies cleanly against current master branch.
It's a bit late now in the development cycle to add this for 4.8 so I propose to include this patch in 4.10 If I understand correctly, it still needs some more fixing and testing, and it should also include a config option (I am sure some user will want to disable it, no matter how good this can be) so we shall need xtion as well and 4.78 is frozen in this regard, so 4.10 is the earliest we should aim at.
Ok, I think it is a good decision.
as an additional feature xfwm4 could draw an empty "window box" (like when cycling windows with tabwin or when hovering over window-buttons in the panel) when the user still holds the window (as in: hasn't released the mouse-button yet). example: i want my terminal window to fill the right half of the screen, so i grab the window-title and drag it to the right screen-edge. when i reach the position so that the tiling would apply, xfmw4 would draw an empty "window-box" where the window would end up when i release the mouse *now*. when i drag the window back to the center the empty box would disappear again. this could also be useful visual feedback for a user as to when he actually reaches the "snap-zone" and when he keeps on dragging to the right in the example above it would change workspaces, meaning dragging it "out of the snap-zone" to the right would also make the box disappear.
Created attachment 3811 Updated patch for latest master branch
I applied this patch to ubuntu's 4.8.2-0ubuntu. The results are pretty good, but there are a few bugs and things which could be improved: * with a multiple monitors, the 'edge' between the screens is not detected, so no snapping occurs * windows (possibly only those which exist when the session is started) sometimes get resized to an almost-invisible bar which then must be resized by hand. I assume this has to do with the defaults of -1 used in the patch * windows are resized only to take up 50% of the available screen real-estate, based on which edge the user drags them towards. Better would be for the sizing algorithm to determine what space is available, so if there's already windows "docked" at the edge of the screen, the new window doesn't overlap. For example, if there's a window on the right of the screen, 'docked', which takes up 60% of the horizontal space, and we dock a new window on the left, the newly-docked window should probably only take up 40% of the horizontal space. * a more general suggestion: a keybinding to tile all the windows on a given screen * the distance from the screen edge where the resizing takes effect is pretty small, so if you have workspace wrapping turned on and are trying to dock a window, you'll often end up on another workspace
(In reply to comment #18) > * windows are resized only to take up 50% of the available screen real-estate, > based on which edge the user drags them towards. Better would be for the sizing > algorithm to determine what space is available, so if there's already windows > "docked" at the edge of the screen, the new window doesn't overlap. For > example, if there's a window on the right of the screen, 'docked', which takes > up 60% of the horizontal space, and we dock a new window on the left, the > newly-docked window should probably only take up 40% of the horizontal space. > > * a more general suggestion: a keybinding to tile all the windows on a given > screen What you want here is a full tiling window manager, which xfwm4 is not. Having some tiling functionality as planned with this bz is OK, yet I do not want xfwm4 to become yet another tiling window manager. Better switch to real tiling window manager is this what you need.
(In reply to comment #18) > * with a multiple monitors, the 'edge' between the screens is not detected, so > no snapping occurs Yup, this would be awesome > * a more general suggestion: a keybinding to tile all the windows on a given > screen I like how Win7 has Super+Left to tile to left half and Super+Right to tile the right half
(In reply to comment #18) > * with a multiple monitors, the 'edge' between the screens is not detected, so > no snapping occurs so this would be very nice. For now there is only a snapping on the outer edges of (e.g. two monitors). I think there is something like a virtual edge needed. Maybe you can take a look at KDE (sorry ;))... but this snapping on multiple monitors would be a great feature for persons who read multiple documents at one time.
I do not pay much attention on how Windows or KDE work wrt to tiling, so I do nor want to mimic these other environments. As noted before, the proposed patch does not work well with dual-head. Also it fails to detect the edge on smaller screen in dual head depending on the actual monitor layout, and cause a lot of flickering in some cases when the window moves alternatively from one monitor to the other (like if it was unsure what monitor the window belongs to). Beside, this does not work well with workspaces warping either, as the window tiles at the same time the workspace switches to the next one once the pointer reaches the edge. I am not too much in favor of this being a state either, ie once the window has been "tiled", the previous size should not be remembered as there is no visual indication of that pseudo-semi-maximized-state (there've been lengthy discussions in the past as to whether or not fill should be a state or not, and I was against it being a state of its own, it's the same here, tilling is not a state). At last, this should be definitely configurable. And that option would be incompatible with "wrap_windows". Nothing insurmountable, but this patch needs a bit of work before it can make it in git imho.
I think it is not per-se incompatible with wrapping. With wrapping workspaces, you 'push' the mouse-cursor past the window-edge (at least you try, keeping it at the window-edge does not do much). When xfwm4 has a 'hot-zone' that, when released there will resize the window to fill half the screen. that might work. so: +-+------------+----------+------------+-+ | | | hot zone | | | | | +----------+ | | |h| |h| |o| |o| |t| |t| | | | | |z| |z| |o| |o| |n| |n| |e| |e| | | | | | | | | +-+------------------------------------+-+ When the window is released in the hot-zone, it will get maximized, or filled to fit half the screen. (depending on which hot-zone you use). But, when dragging the window beyond that zone, the wrapping takes place (if it's enabled).
I ment to say screen-edge.
Hello, why limit to half of the screen. Compiz (grid plugin) and Stiler (little python script to allow tilling in non tilling wm : original : https://github.com/TheWanderer/stiler with a better description than mine's / enhanced : https://launchpad.net/~serge-hallyn/+archive/stiler) have an interesting approach. They allow with a shortcut to resize and place a windows in a predefined place. It is particulary useful for large screen. For exemple, we can use <crt>+<alt>+<keypad 6> on existing window to maximize it in height and place it on the right of the screen. The screen is generally separates in 9 zones (3 vertically and 3 horizontally). If you hit several time <crt>+<alt>+<keypad 6>, the width of the window will vary from 2/3 to 1/2 to 1/3 of the width of the screen. It is the same thing for <keypad 4,8,2>, put in other directions. The <keypad 1,3,7,9> allow to place a windows in a corner. The <keypad 5> allow to maximize a windows. Those simple shortcuts allow to place two windows beside each others very easily, and organize your workspace very efficiently. Even if stiler.py works with XFWM 4, it is still slower than compiz implementation, especially at the first invocation. After implementing the basics behaviour, we can imagine great things like in stiler : Big windows on 2/3 of the screen on the left, and 3 little windows on the right 1/3 of the screen, and you cycle those 4 windows, the big windows goes little on the top right, and the little windows on the bottom right become the big windows, etc ... Schematic results of each shortcut : Repeated <crt>+<alt>+<keypad 6> : +------+------+------+ +------+------+------+ +------+------+------+ | | XXXXXXXXXX| | | |XXXXXX| | |XXXXXXXXXXXXX| | | XXXXXXXXXX| | | |XXXXXX| | |XXXXXXXXXXXXX| +------+---XXXXXXXXXX+ +------+------+XXXXXX+ +------+XXXXXXXXXXXXX+ | | XXXXXXXXXX| > | | |XXXXXX| > | |XXXXXXXXXXXXX| | | XXXXXXXXXX| > | | |XXXXXX| > | |XXXXXXXXXXXXX| +------+---XXXXXXXXXX+ +------+------+XXXXXX+ +------+XXXXXXXXXXXXX+ | | XXXXXXXXXX| | | |XXXXXX| | |XXXXXXXXXXXXX| | | XXXXXXXXXX| | | |XXXXXX| | |XXXXXXXXXXXXX| +------+------+------+ +------+------+------+ +------+------+------+ Repeated <crt>+<alt>+<keypad 8> : +------+------+------+ +------+------+------+ +------+------+------+ |XXXXXXXXXXXXXXXXXXXX| |XXXXXXXXXXXXXXXXXXXX| |XXXXXXXXXXXXXXXXXXXX| |XXXXXXXXXXXXXXXXXXXX| |XXXXXXXXXXXXXXXXXXXX| |XXXXXXXXXXXXXXXXXXXX| +XXXXXXXXXXXXXXXXXXXX+ +XXXXXXXXXXXXXXXXXXXX+ +------+------+------+ |XXXXXXXXXXXXXXXXXXXX| > |XXXXXXXXXXXXXXXXXXXX| > | | | | | | | | > |XXXXXXXXXXXXXXXXXXXX| > | | | | +------+------+------+ +------+------+------+ +------+------+------+ | | | | | | | | | | | | | | | | | | | | | | | | +------+------+------+ +------+------+------+ +------+------+------+ Repeated <crt>+<alt>+<keypad 9> : +------+------+------+ +------+------+------+ +------+------+------+ | |XXXXXXXXXXXXX| | | XXXXXXXXXX| | | |XXXXXX| | |XXXXXXXXXXXXX| | | XXXXXXXXXX| | | |XXXXXX| +------+------+------+ +------+------+------+ +------+------+------+ | | | | > | | | | > | | | | | | | | > | | | | > | | | | +------+------+------+ +------+------+------+ +------+------+------+ | | | | | | | | | | | | | | | | | | | | | | | | +------+------+------+ +------+------+------+ +------+------+------+ Cycling : +------+------+------+ +------+------+------+ +------+------+------+ |AAAAAAAAAAAAA|BBBBBB| |DDDDDDDDDDDDD|AAAAAA| |CCCCCCCCCCCCC|DDDDDD| |AAAAAAAAAAAAA|BBBBBB| |DDDDDDDDDDDDD|AAAAAA| |CCCCCCCCCCCCC|DDDDDD| +AAAAAAAAAAAAA+------+ +DDDDDDDDDDDDD+------+ +CCCCCCCCCCCCC+------+ |AAAAAAAAAAAAA|CCCCCC| > |DDDDDDDDDDDDD|BBBBBB| > |CCCCCCCCCCCCC|AAAAAA| |AAAAAAAAAAAAA|CCCCCC| > |DDDDDDDDDDDDD|BBBBBB| > |CCCCCCCCCCCCC|AAAAAA| +AAAAAAAAAAAAA+------+ +DDDDDDDDDDDDD+------+ +CCCCCCCCCCCCC+------+ |AAAAAAAAAAAAA|DDDDDD| |DDDDDDDDDDDDD|CCCCCC| |CCCCCCCCCCCCC|BBBBBB| |AAAAAAAAAAAAA|DDDDDD| |DDDDDDDDDDDDD|CCCCCC| |CCCCCCCCCCCCC|BBBBBB| +------+------+------+ +------+------+------+ +------+------+------+ Hope it would give you great idea ... Thanks Best regards Denis Sacchet
Sorry Oliver.. A query, but respect of the original patch. I could not test git. Will implement some kind of "prelight" when tiling? When I move the edge, sometimes it's annoying that the window changes geometry directly, and sometimes lose the position of the mouse with respect to the window.. I repeat.. this behavior with the patches in this bug.. Not git.. :S A more correct behavior (in my modest opinion.), is that when you drag a window to the edge, xfwm4 show a prelight (a blue square, or anything else) to show the future disposition of the window, and only when I release the mouse click changes position and geometry of the window definitely. King regards. And thank you very much for all your work.. P.s: It would also be interesting change the transparent squares with black borders, to a simi-transparent blue square (or the color selection) when use task switcher, or when passing the mouse over the tasklist panel plugin.. But this is a matter of taste. :)
A little bug, Tiling with unresizable windows, when you move it left, bottom, ... them are not-resized (and this is good) but are moved to the top-teft corner of the resizing area. Finally, according to Matias De lellis "it's annoying that the window changes geometry directly"
Out of curiosity. Is this popular feature scheduled to be included so it can make it into the Fedora 17 XFCE spin to be released 2012-05-08? http://fedoraproject.org/wiki/Releases/17/Schedule
Is there also a way to disable tiling, because dragging window to the top of my screen constantly maximizes it to the whole top-half of the screen.
(In reply to comment #29) > Is there also a way to disable tiling, because dragging window to the top of > my screen constantly maximizes it to the whole top-half of the screen. You have to enable the wrap workspace when window reaches the edges of the screen. Than tilling won't happen.
(In reply to comment #30) > (In reply to comment #29) > > Is there also a way to disable tiling, because dragging window to the top of > > my screen constantly maximizes it to the whole top-half of the screen. > > You have to enable the wrap workspace when window reaches the edges of the > screen. Than tilling won't happen. Not entirely, I have 2 workspaces so when you hit an edge without neighbor ws, tilling still works.
The restore_on_move settings disables tiling, but the new tile_on_move settings is not implemented yet.
(In reply to comment #32) > The restore_on_move settings disables tiling, but the new tile_on_move > settings is not implemented yet. Oh it is, I need to push my git tree, some day.
Should be fixed in git master.