[Panel-devel] Pager extended for "viewports"

[Timothée Lecomte]

Aaron J. Seigo wrote:
> On Thursday 21 September 2006 4:44, Timothée Lecomte wrote:
>   
>
>>> 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.
>>     
>
> however this doesn't make sense at all.
>
> it does on a technical level. it does on a "if you wish to be pedantic or are 
> a window manager weenie" level. but you know what? that's not our target 
> audience. the % of people who use kde who care about this is vanishingly 
> small and, more importantly, it's simply a bad, bad, bad idea.
>
> it's like so many other choices made in the past in our UI: yes, we COULD do 
> it, and because we COULD we DID never asking ourselves SHOULD we. what does 
> multiple desktops per viewports (or vice versa) get one? nothing much except 
> the possibility to make a very confusing system.
>
> this is one reason (there are a few) i believe the compiz people have their 
> heads screwed on backwards.
>   
lol
I'm not going to argue about compiz design decision, that's not my 
problem (right now, it only has viewports).
Let's just precise that the idea of multiple large desktops is 
implemented by fvwm: 
http://www.fvwm.org/screenshots/desktops/Windows95-desk-1280x1024/screenshot.png

Anyway, let's come back to KDE.

I don't have a strong opinion between the two alternatives:
    -One KMiniPagerButton per desktop
    -One KMiniPagerButton per viewport: it's a little easier in terms of 
implementation, more flexible in terms of space consumption in the panel 
(it seems to be very important, a couple of users on compiz.net already 
reported it). We lose the visual correspondance between the pager 
miniature and what the user see when he switches its viewports, but it's 
easily fixed by manually choosing the number of rows of the pager.

(When discussing with Dirk on #kde4-devel, we noticed that the specs 
talk about viewport scrolling, where the viewport is not obliged to be 
snapped on a grid. The desktop size is not even obliged to be a multiple 
of the viewport size. However, this clearly falls into the category of 
"window manager weenies" ;)

I conclude that Dirk idea is better. Let's do it with one 
KMiniPagerButton per viewport.

But I suddenly have another idea: it seems that your point of view, Dirk 
and Aaron, is that the user should not see the difference between 
viewports and desktops. Why don't we go further and make so that all KDE 
applications don't see the difference by modifying the underlying 
libraries, kwin.h and kwinmodule.h ?

What I mean is that even after we will have fixed the pager, the taskbar 
and kdesktop remain to be fixed. As said before, the taskbar should only 
show tasks that are on the current viewport and kdesktop should be able 
to recognize that we can put a different wallpaper on each viewport.
This could be easily done if we could abstract the difference between 
viewports and desktops in KWinModule and KWin.

The current "desktop" index would be something like:
    currentDesktop*number_of_viewports + currentViewport
and all the corresponding functions would be modified accordingly.

For example, the following have to be modified:
- KWinModule::numberOfDesktops() [would return 
number_of_desktops*number_of_viewports]
- KWinModule::currentDesktop() [would return 
currentDesktop*number_of_viewports + currentViewport]
- KWinModule::currentDesktopChanged() [would be signalled also on 
viewport changes]
- KWinModule::numberOfDesktopsChanged() [would be signalled also on 
desktopGeometry changes]
- ...
- KWin::setOnDesktop()
- KWin::setOnAllDesktops()
- KWin::setCurrentDesktop()
- ...
- KWin::WindowInfo::isOnDesktop()
- ...

That way, it would be transparent for the taskbar, for kdesktop, etc.

What do you think about that ?

Best regards,

Timothée