Created attachment 15757 [details] Image with mockup and ideas. While Scale is a great improvement to the usability of any desktop, I believe its usefulness is reduced by the way it presents windows when they are zoomed out. Improving the algorithm for window placement in Scale is an important step towards presenting Compiz as not just eyecandy, but also a good usability milestone for GNU/Linux. The purpose of scale is to recognize and select windows quickly. But we recognize objects (for example, around our desktop) based largely on: 1. Their placement in space. 2. Their shape. In the case of Scale, of course, both placement and size have to be shifted around in order to show all windows, but they should be preserved as much as possible. In general: - A window should remain where you leave it. - A window should keep the size you gave it. Or put other way, the priorities of Scale should be: 1. Prevent window overlapping. 2. Keeping proportions between windows. 3. Keeping position relative to other windows and screen. 4. Making good use of screen estate (i.e. windows as big as possible, reasonable spacing). Examples of other projects or situations where the placement/shape criteria are applied are: - Road signals have distinctive shapes. - The icons of the Tango set (aspire to) have distinctive silouettes. .- Spatial file managers are based largely on these same ideas. - Apple's Exposè works on these principles too. Previous versions of Beryl used to have an "Organic" mode for scale (which is still accessible, but very broken). This could (or could not?) be a good starting point.
> 1. Their placement in space. [...] > 3. Keeping position relative to other windows and screen. While version 1:0.7.8-0ubuntu4 does a fine job of this, I think it would be even better if it expanded "space" to include windows on other workspaces (when using desktop wall) when those are shown too. Consider the following example: workspaces are numbered 1-4 in western reading order. On each of ws{1,3} I have a maximized window. On ws4 I have four xterms, each very close to where they're put with single-ws scale. In an all-ws scale, it would make sense to have the windows of ws1 and ws3 on the left (1 above 3), and none of the rest crossing each other on the path to their destination (i.e. in their "natural" place, like single-ws scale but with the two extra windows tacked on). As an addendum to "1. Their placement in space.", I think placement in space relative to other objects matters; under that falls distance and angle, as well as whether any object is between them. Take the above example; on ws2, add two xterms in opposing corners (see ws2.png). Now scale; see scale.png. It would make more sense if the four xterms with no directory listings (from ws4) were put together in one lump, with the two maximized windows (firefox and the xterm with lots of blue) on the left hand side with the logical vertical relationship (ws1 over ws3).
Created attachment 20010 [details] all workspaces (Duh, I can screenshot all workspaces, not only ws2. Here they are)
Created attachment 20011 [details] Scaled from ws2
So, if I understand what you mean correctly, what you want is to have windows from other workspaces, when doing an "all windows" scale, to be placed accordingly to the workspace where they reside, right? I see some problems in this, for example, when you have workspace arrangements like 1x4. This would cause the scaled windows to form a somewhat long stripe filling only part of the screen, which would go against priority 4. That said, it is necessary to find a way to fix the scale mode for all windows from all desktops, that is true. Marginally, your comment brought me to think: do we need separate wall / expo / scale-from-all-desktops plugins? Why not merge them all into one? Wall and expo aren't really that different, and showing scaled windows from all desktops could be done in a way similar to expo, save for the fact that (single)clicking on a certain window would give it focus and place the user in the appropiate workspace. Weniger, aber besser, I say (*). G. (*) -- Well, Dieter Rams. (In reply to comment #1) > > 1. Their placement in space. [...] > > 3. Keeping position relative to other windows and screen. > > While version 1:0.7.8-0ubuntu4 does a fine job of this, I think it would be > even better if it expanded "space" to include windows on other workspaces (when > using desktop wall) when those are shown too. > > Consider the following example: workspaces are numbered 1-4 in western reading > order. On each of ws{1,3} I have a maximized window. On ws4 I have four > xterms, each very close to where they're put with single-ws scale. In an > all-ws scale, it would make sense to have the windows of ws1 and ws3 on the > left (1 above 3), and none of the rest crossing each other on the path to their > destination (i.e. in their "natural" place, like single-ws scale but with the > two extra windows tacked on). > > As an addendum to "1. Their placement in space.", I think placement in space > relative to other objects matters; under that falls distance and angle, as well > as whether any object is between them. > > Take the above example; on ws2, add two xterms in opposing corners (see > ws2.png). Now scale; see scale.png. It would make more sense if the four > xterms with no directory listings (from ws4) were put together in one lump, > with the two maximized windows (firefox and the xterm with lots of blue) on the > left hand side with the logical vertical relationship (ws1 over ws3). >
Err, bug trackers are better left for bugs... Please use either the compiz fusion (soon to be just compiz) forum or the development mailing list, as the audience is bigger. At any rate, we're closing off bugs on this tracker so as to only use bugs.opencompositing.org... Sorry for the inconvenience.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.