[Panel-devel] Pager extended for "viewports"

Timothée Lecomte timothee.lecomte at ens.fr
Thu Sep 21 12:44:29 CEST 2006


Dirk Mueller wrote:
> On Thursday 21 September 2006 02:47, Timothée Lecomte wrote:
>
>   
>> Well, give a try to what I sent and tell me what you think.
>> For the impatient, here is a screenshot with a desktop made of 8
>> viewports in 2 rows:
>> http://tipote.free.fr/compiz-pager-screenshot2.png
>>     
>
> I have thought about this some more. For a correct viewport-simulating window 
> manager support, we have to adjust a lot more. for example the various 
> taskbar implementations either show all windows or all windows on the current 
> desktop. Currently, with such a window manager, this setting is broken and 
> doesn't do anything. Well, it still works like it is working technically, but 
> for the user, it is perceived as broken. For the same way the current 
> minipager was perceived as broken for the user - even though it did exactly 
> what it was supposed to do.
>   

You're right, but that's not the pager's problem. The taskbar has to be 
adjusted to show only the apps from the current viewport (conditionnally 
to the settings "display windows from all desktops" probably).


> There might be a window manager out there, either now or in the future, that 
> supports both desktops and viewports at the same time. What I'm thinking 
> about: should we really bother the KDE user with the difference? Does he care 
> if it is a viewport or a desktop?

The only reason a window manager would support both at the same time is 
precisely because there's a difference between the two: viewports have 
some "physical" meaning as a tiling of a larger desktop, whereas virtual 
desktops are disconnected. That's a good reason to make the difference 
visible in the pager too, and to show that the tiling is there for 
viewports.

> The funny thing is that the viewport 
> implementation in compiz doesn't actually allow to scroll the viewport by an 
> arbitrary amount - it only simulates a desktop tiled over it. The major 
> difference is that the context menu has an option "move to left viewport, 
> move to right viewport, move to above viewport, move to below viewport". Does 
> the cube plugin in compiz support desktops above and below?
>   
That's the purpose of the "plane" plugin in compiz (in David Reveman 
cvs). When you click on a different viewport in the pager, you "fly" to 
this viewport. You expect to have the same "flight" on the screen as 
what you can see from the pager preview.


> The more I think about it, the more I believe we should not bother the user 
> with this difference. does the user really care if he moved the stuff to the 
> desktop "above" or below?
I think it's more important than it seems. Compiz success comes in part 
from the fact that it adds some visual consistency when switching 
viewports as sides of a cube or tiles of a large plane.


>  And if, can't we just simulate that like we do now 
> with desktop implementation under kwin as well (by doing a two-row desktop 
> layout)?

Right, I thought about it too. That's an implementation choice.

> Does the user care about if he moved it to desktop 1, viewport 2 or 
> desktop 2 viewport 1? Why should he?
>   

If somebody starts to use this kind of feature from a window manager, I 
think that's because he cares...

> The moment we switch to viewports as children of desktops, the user is 
> confused: the desktop labels are not applied to viewports, the documentation 
> is all wrong, there are a lot of configuration settings in various 
> applications to be duplicated (each desktop related setting has to be 
> duplicated into a viewport related setting).
>   

I agree with the problem with desktop labels.
But I don't understand what you mean about the documentation and 
configuration settings. Can you give an example ?


Timothée


More information about the Panel-devel mailing list