GNOME Bugzilla – Bug 615378
Windows in Overview should be arranged in a better more consistent way, respecting real arrangement and size of windows (Real OSX Expose, KDE-like)
Last modified: 2011-06-08 16:42:52 UTC
The most important reason why I am not yet comfortable in working with gnome-shell is the task-switching problem, discussed in https://bugzilla.gnome.org/show_bug.cgi?id=594931 I am using gnome 2.29 with compiz as well as KDE 4.4 on two different computers. As far as I can say: Compiz' Expose (which is similar to gnome-shell) is quite unusable: Everytime you activate it, you have to search for the windows because they are arranged in a random order and have all the same size. KDE's Expose is replacing a taskbar (for me): You can activate it and you find the window where you saw it the last time. If you search for a small window placed on the right part of the screen you will find it as a small window in the right part of the overview. KDE has already implemented this in the window-overview as well as in the desktops-overview. Both are quite the same like the single-desktop-view and the multi-desktop-view in gnome-shell. I would be very happy if this window-arrangement-logic could be implemented soon, maybe with the help of KDE. This could be an easy first start to satisfy the requests in the mentioned bug above.
I have to agree. A few important points I saw in Fedora 13: Please respect the original size of the window and scale all windows accordingly. I want my big Firefox window to be the biggest window in the overview. At the moment some small terminal is much bigger and that makes the whole selecting very weird, sorry. Therefore: 1. Scale sanely Next thing is the movement. Once you hit the windows key all windows fly like crazy and it is not easy to see where all the windows went. I guess you have to implement two different modes. One for single workspace users and one for people who want to use multiple. I don't see how a common mode could work for both. 2. Improve overview window movement. The third little thing I want to see is icons attached to the windows. Oh, and I really don't like all the text shorting like "Google Rea...". It is everywhere and it needs to go away. And I don't see any value in this new sliding mode. Cool experiment, but it is not working at all.
To make the idea a bit more testable, I'm thinking about implementing the so-called "natural window transformation algorithm". This weekend I took a look into the code of gnome-shell and KDE: In KDE the part of interest is in presentwindows.cpp: https://projects.kde.org/projects/kde/kdebase/kde-workspace/repository/revisions/master/entry/kwin/effects/presentwindows/presentwindows.cpp The whole natural window placement algorithm is in PresentWindowsEffect::calculateWindowTransformationsNatural(). It's just a few lines and quite easily understandable. In gnome-shell the part of interest seems to be in workspace.js: http://git.gnome.org/browse/gnome-shell/tree/js/ui/workspace.js to implement the natural algorithm in positionWindows() the lines (currently line 861) let slots = this._computeAllWindowSlots(clones.length); clones = this._orderWindowsByMotionAndStartup(clones, slots); and (currently line 879) let [x, y, scale] = this._computeWindowRelativeLayout(metaWindow, slot); would have to be changed to not use slots but the new algorithm. I tried to implement this, but since I don't have a real gnome-shell development environment (and don't really know javascript, especially the functionality of the javascript-C++ stuff) I failed in the first steps... All that is necessary is to know the correct functions corresponding to the qt QRect object (united(), adjusted(), intersects(), translate()) and a basic understandment of the positionWindows function and data types. Is there somebody out there who has the skill and the short time to write a first patch that makes this work?
Created attachment 183418 [details] [review] First implementation of the Natural Window Placement Strategy from KDE. This is a very ugly implementation using almost no function from the libraries. There are still some important errors in the behaviour - All marked in the code by "@todo". Most import
Review of attachment 183418 [details] [review]: If you want to test this patch test it with small windows! Fullscreen Windows don't work because of the "Windows' positions change" error. 2-3 small windows, slightly overlapping will be positioned very nicely. Also activating the workspace-bar on the right disturbs the effect a bit.
Created attachment 183726 [details] [review] First real implementation of the Natural Window Placement Strategy from KDE. All major functionality is working now. Behaviour can be modified by constants at the beginning of workspace.js.
(In reply to comment #5) > Created an attachment (id=183726) [details] [review] > First real implementation of the Natural Window Placement Strategy from KDE. > All major functionality is working now. Behaviour can be modified by constants > at the beginning of workspace.js. Cool. Seems to perform OK from my testing. In order to make it easier to review, please remove the commented out reference c++ code from KDE, and please keep to the coding style of the surrounding javascript
On second thoughts, I notice a performance penalty when using this, showing the overview seems to take twice as long
Created attachment 183768 [details] [review] First real implementation of the Natural Window Placement Strategy from KDE. All major functionality is working. Behaviour can be modified by constants at the beginning of workspace.js. All unnecessary stuff removed.
(In reply to comment #7) > On second thoughts, I notice a performance penalty when using this, showing the > overview seems to take twice as long I'm wondering if the performance can be improved by implementing the new function directly in C++? Compared to working with KDE with a 4 workspace overview it really feels to be slower...
It would need to be in C, not C++, and it's probably best to start profiling the JavaScript to see where you could improve things. Implementing the Meta.Rectangle methods in C would probably be a good start, since they should be there anyway.
According to bug 645247 it looks like Meta.Rectangle.Union is now bound. Perhaps you can submit a patch for Meta.Rectangle.Adjust before too.
Created attachment 183821 [details] [review] First real implementation of the Natural Window Placement Strategy from KDE All major functionality is working. Behaviour can be modified by constants at the beginning of workspace.js. All unnecessary stuff removed.
(In reply to comment #12) > Created an attachment (id=183821) [details] [review] > First real implementation of the Natural Window Placement Strategy from KDE > > All major functionality is working. Behaviour can be modified by constants > at the beginning of workspace.js. All unnecessary stuff removed. I attached a modified patch that uses the new meta_rectangle_union method, and I created meta_rectangle_adjust (bug 645265) and used that. This seems to improve performance a fair amount.
Tried this out quickly. My first impression is: a) doesn't work at all when you have all maximized windows b) and when you don't, it looks really messy
(In reply to comment #14) > Tried this out quickly. My first impression is: > > a) doesn't work at all when you have all maximized windows Can you explain a little bit more what you mean here? > b) and when you don't, it looks really messy What does messy mean to you? Thats how it is meant to work, how it works in KDE etc. Like much of GNOME Shell it is worth using it for a bit longer, to get over the initial shock, so that you can really get a feel for how it it improves productivity when using a workspace with multiple maximized and non-maximized windows.
Created attachment 183835 [details] [review] First real implementation of the Natural Window Placement Strategy from KDE All major functionality is working. Behaviour can be modified by constants at the beginning of workspace.js. All unnecessary stuff removed. Uses the new MetaRectangle.union method.
(In reply to comment #14) > Tried this out quickly. My first impression is: > > a) doesn't work at all when you have all maximized windows Yes - Just found out: That's a problem when using the elementary algorithm without any tweaks. When all windows are in same size and position the algorithm doesn't know, where to push them and (currently) uses the x-direction as a backup. Activating NATURAL_WINDOW_PLACEMENT_MORESCREEN solves this but moves the windows a bit in non-optimal direction. Since I would like to have the positions as real as possible I think this behaviour is a drawback, but as long as we don't have a better idea NATURAL_WINDOW_PLACEMENT_MORESCREEN has to be activated. (not yet activated by default) > b) and when you don't, it looks really messy That's either your opinion about the algorithm itself. Or it is because of the not yet finally tweaked "gaps between windows" and the not fitting overlay (Window-names + close-button)?
(In reply to comment #17) > (In reply to comment #14) > > Tried this out quickly. My first impression is: > > > > a) doesn't work at all when you have all maximized windows > > Yes - Just found out: That's a problem when using the elementary algorithm > without any tweaks. When all windows are in same size and position the > algorithm doesn't know, where to push them and (currently) uses the x-direction > as a backup. How about detecting if the workspace contains all maximized windows and defaulting to the current behavior - or a 2D grid instead of just placing windows on the the x-axis?
(In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #14) > > > Tried this out quickly. My first impression is: > > > > > > a) doesn't work at all when you have all maximized windows > > > > Yes - Just found out: That's a problem when using the elementary algorithm > > without any tweaks. When all windows are in same size and position the > > algorithm doesn't know, where to push them and (currently) uses the x-direction > > as a backup. > > How about detecting if the workspace contains all maximized windows and > defaulting to the current behavior - or a 2D grid instead of just placing > windows on the the x-axis? What if I have two large windows, maybe one maximized, and one tall skinny one? I have this set-up right now: XChat, Empathy Chat Window, Empathy Buddy List, and it doesn't look too good.
(In reply to comment #19) > (In reply to comment #18) > > (In reply to comment #17) > > > (In reply to comment #14) > > > > Tried this out quickly. My first impression is: > > > > > > > > a) doesn't work at all when you have all maximized windows > > > > > > Yes - Just found out: That's a problem when using the elementary algorithm > > > without any tweaks. When all windows are in same size and position the > > > algorithm doesn't know, where to push them and (currently) uses the x-direction > > > as a backup. > > > > How about detecting if the workspace contains all maximized windows and > > defaulting to the current behavior - or a 2D grid instead of just placing > > windows on the the x-axis? > > What if I have two large windows, maybe one maximized, and one tall skinny one? > I have this set-up right now: XChat, Empathy Chat Window, Empathy Buddy List, > and it doesn't look too good. Like http://imgur.com/a/Z8gkw#HAKXI I get (left to right through album) 1) Tall window on left of maximized window 2) Overview shows tall window on left of maximized window 3) Tall window below right of maximized window 4) Overview shows tall window below right of maximized window Is that what you see? Because that is the intended behaviour. With a few non maximized windows on a workspace, its really productive for them to always go to the same-ish place in the overview, and that same-ish place be related to where they actually sit on the screen. Of course, it clearly appears this might not be too everyones taste, but it certainly makes my window management more predictable.
Two large windows, one skinny: http://i.imgur.com/Hu7ra.jpg
(In reply to comment #21) > Two large windows, one skinny: http://i.imgur.com/Hu7ra.jpg Oh, I get that too. Im just not convinced that it is wrong... As the op mentioned, the behavior is slightly different with NATURAL_WINDOW_PLACEMENT_MORESCREEN=true, what do you think in that case?
Created attachment 183849 [details] [review] First javascript-only implementation of the Natural Window Placement Strategy from KDE. No Meta.Rectangle is used in the main loop speeding up the whole algorithm.
(In reply to comment #23) > Created an attachment (id=183849) [details] [review] > First javascript-only implementation of the Natural Window Placement Strategy > from KDE. > > No Meta.Rectangle is used in the main loop speeding up the whole algorithm. Performance is much better. Well done! p.s. please obsolete old patches, it makes the bug easier to follow.
Created attachment 183871 [details] [review] javascript only implementation of the Natural Window Placement Strategy from KDE. All major functionality is working. Behaviour can be modified by constants at the beginning of workspace.js.
Created attachment 183886 [details] [review] javascript only implementation of the Natural Window Placement Strategy from KDE. All major functionality is working. Behaviour can be modified by constants at the beginning of workspace.js. Javascript object Rect functions are faster than using Meta.Rectangle functions. Made positionWindows more generic to make choosing/adding window placement strategies easier.
(In reply to comment #26) > Created an attachment (id=183886) [details] [review] > javascript only implementation of the Natural Window Placement Strategy from > KDE. > > All major functionality is working. Behaviour can be modified by constants at > the beginning of workspace.js. > > Javascript object Rect functions are faster than using Meta.Rectangle > functions. > > Made positionWindows more generic to make choosing/adding window placement > strategies easier. This will be the last version for now. Together with https://bugzilla.gnome.org/show_bug.cgi?id=645324 it's really usable. I added a javascript Rect object to workspace.js. You might maybe know a better location. So thanks for all your help and tips, especially to John and Owen! Please review! I will be pleased if this will show up in the main branch.
In the meantime, why not making a gnome-shell extension with the Natural Window Placement Strategy? I really like it, but it's a pain to re-apply the patches every time gnome-shell package is updated by the distribution.
Nice to hear that you like it! To make it an extension is a nice idea. But I don't know about creating extensions and won't have the time to look into it in near future. Feel free to do so!
Created attachment 187415 [details] extension: Native Window Placement Strategy as gnome-shell extension This is a gnome-shell extension bringing Native Window Placement Strategy to overview. It does the same like patch 183886. https://bugzilla.gnome.org/show_bug.cgi?id=645324 ("position window title overlay at the top of the windows (in overview)") is included. Configurable parameters can be adjusted at the beginning of extension.js. I attached the extension to this bug because in the wiki I didn't find anything about distributing extensions. Is there a better way or what is the process to move it to http://git.gnome.org/browse/gnome-shell-extensions/ ?
(In reply to comment #30) > Created an attachment (id=187415) [details] > extension: Native Window Placement Strategy as gnome-shell extension Awesome! > > I attached the extension to this bug because in the wiki I didn't find anything > about distributing extensions. Is there a better way or what is the process to > move it to http://git.gnome.org/browse/gnome-shell-extensions/ ? Nope, not yet. I suggest filing a new bug against the extensions component, or moving this bug there.
Created attachment 187623 [details] Layout changes when workspace switcher is visible (In reply to comment #30) > This is a gnome-shell extension bringing Native Window Placement Strategy to > overview. It does the same like patch 183886 [details]. > Awesome! thank you very much, it works perfectly! Just one issue: with many windows opened, often the layout changes significantly depending on the workspace switcher being visible or not (see screenshots), which makes everything look quite weird. Is it possible to fix this?
Based on earlier IRC comments, I don't think this is going to get adopted into core. Reassigning to extensions.
This was adopted in gnome-shell-extensions master. Closing.