JAN
23
2008

KDE4, KDE3 and viewports (the good, the bad and the ugly)

Submitted by Lubos Lunak

As of now [*], I hereby declare that KDE4 kind of supports viewports[^] (that is, the implementation of virtual desktops that Compiz and probably practically nobody else uses). Which means it possibly still sucks a bit here and there [x], but it's at least as good as in GNOME. In fact, after little checking[!], it appears that it is a bit better (try e.g. dragging a window in GNOME pager with Compiz running). Strange, I remember loads of people complaining about KDE, but not a single case about GNOME - maybe I just haven't noticed, or GNOME has less features that can break in the first place, or maybe that's what we here call 'one-eyed the king in the land of the blind'[-]. Anyway. The good news for KDE developers is that they don't have to care - viewports are mapped to virtual desktops by libraries[#] and only the pager seems to need few small tweaks. That in fact seems a much better solution than the KDE3 way of actually really trying to support viewports (I think I feel shame remembering I supported this and thought it was a good idea - one never stops learning). Which means a backport to KDE3 would be problematic, maybe I'll try for openSUSE11.0, but I'm not very confident that's a good idea. We'll see.

Time for the small print:
[^] Viewports suck.
[*] That actually means next Monday, when I enable one small check in pager that requires new kdelibs functionality added today.
[#] Well, at least the theory is that viewports can be transparently mapped to virtual desktops, reality may possibly decide to disagree on some aspects.
[x] Viewports will never be perfect [.].
[.] And, frankly, I'm not even that interested in making the support as good as possible[_]. Despite what some people might probably think, I'm still human and reasonably sane[y]. Years of working with Xlib and other things probably have increased my pain threshold, but I can still only take so much. Taking care of some minor details would be a major pain.
[y] Although I admit protecting others from these insanities may have some unpleasant effects. Caution suggested when approaching.
[_] That said, the support should be good enough, and, as said, probably better than GNOME's at the time being.
[!] I checked with GNOME shipped with openSUSE10.3, so maybe that's improved since then[?].
[?] I noticed that the SUSE packages for the related functionality in GNOME actually have patches with some viewports code added[/]. I wonder how it works elsewhere.
[/] It seems GNOME basically has code path for virtual desktops and then the same again for viewports. I guess Havoc wouldn't like that[@].
[@] There are many things about Metacity design I don't agree with, but I think I strongly agree that having both virtual desktops and viewports is crackrock[$].
[$] Well, here I wanted to note that this is a quote from Metacity's README, but while apparently many things are crackrock according to it, this subject seems only doesn't make sense, so that's me saying it, ok[+]?
[+] Well, I guess it saved some work in Compiz, but I have to wonder if the idea of going with viewports was really worth it.
[-] No warranty included at all.

Comments

Wow... you obviously aren't feeling very positve towards viewports right now, so I don't know if I should even mention this, but here goes: I feel like the DesktopGrid effect in KWin is incomplete. Since I started using it, I've started to think of my virtual desktops as simply parts of one big desktop, which is the sense I get from the (totally awesome!) DesktopGrid effect. This paradigm is also used in Plasma, with its Zoom In and Zoom Out buttons. It feels really intuitive, plus it's way more scalable than the Compiz cube. (You could have a 4x4 desktop grid, rather than a 16-sided polygon.) However, the illusion of "one Big desktop" is get broken when I move a window so that it overlaps two virtual desktops. The window gets cut in half and it only appears on one of the desktops. It just feels unnatural! Also, I'd like to be able to drag windows from one "part" of my desk to another (similarly to how windows can be dragged from one side of the cube to another in Compiz).[^]

On the downside, this would mean rewriting the virtual desktops' configuration dialog so that it asks for the number of rows and columns of desktops rather than just the number of desktops, but I think in the long run, this is a much better paradigm and provides a better basis for the effects in KWin (such as the windows sliding when you switch desktops[*]). In the worst case scenario, the user would put a window in a corner so it overlaps 4 desktops. Is the code you've written limited to "1 row by N columns" desktops (a la Compiz) or can it handle the 4 desktop scenario? I think the desktop would feel much more solid if the virtual desktops just felt like viewing portions of a larger desktop.

[*] I think the wallpapers should slide too during this effect, to solidify the sensation that the user is "panning" over the desktop. Perhaps you could make this an option?
[^] That effect could probably be pulled off without implementing viewports. Simply detect when a user is dragging a window, and if the cursor hits the edge of the screen, wait a moment, and then automatically switch to the virtual desktop in that direction. (Either above, below, to the left or to the right.) Consider that a separate feature request. :-)

By kwilliam at Thu, 01/24/2008 - 20:58

> The window gets cut in half and it only appears on one of the desktops. It just feels unnatural!

However unnatural is probably still better than annoying. I see it as an advantage that desktops are separate - imagine you moved one window a bit aside and it covered something on another desktop. And DesktopGrid is still only an effect that shows desktops in a special way, it can't work as if it was "real", certainly not now without input transformation support in X, and it's a question if it could even then.

> Also, I'd like to be able to drag windows from one "part" of my desk to another

You mean drag windows between desktops? That's been in KWin since ages, just enable the active borders option.

> rewriting the virtual desktops' configuration dialog so that it asks for the number of rows and columns of desktops

It's actually the pager that controls the layout - you can configure the number of desktops there and also the number of rows/columns.

> this is a much better paradigm

Well, I already disagreed above, and moreover just because you have pager in 2x2 setup and the DesktopGrid effect that doesn't mean you have to see it that way. There can be other effects presenting desktops in different ways, and I'm personally used to pager in 12x1 setup, thinking of desktops as completely separate things (and no sliding when changing them, I switch so often that it'd make me sick quickly).

> I think the wallpapers should slide too during this effect

I'm not going to do that, sorry. Virtual desktops are called virtual, because they are that, virtual. They don't exist, switching a virtual desktop means you hide some windows, show some windows and perhaps show something differently. There's only one wallpaper at a time, and only one (assuming you have just one indeed) panel at a time that is set to be on all desktops. Which is where the viewport representation starts to break. Wallpapers could be still done by using viewports (and wasting a lot of memory for such huge background), but with panel that'd mean having panels duplicated and scattered on the huge area.

DesktopGrid is not a view of the whole desktop, it's a representation of it. Think of it that way. The same way you think of the pager or, let's say, a paper map.

(Also, DesktopGrid sometimes showing a window overlapping desktop borders even when it's not being dragged is just a bug, and it needs to be fixed. I can also make the borders distinctive, if that helps with understanding that those things are still separate and that when you move a window you put it "above" the grid.)

By Lubos Lunak at Thu, 01/24/2008 - 21:48

(Sorry I didn't get back sooner - I forgot about this post until I was reading the Digest.)

Thank you for being clear! I appreciate that.

> You mean drag windows between desktops? That's been in KWin since ages, just enable the active borders option.

Thanks for pointing out the Active Border option - I've found it in my KDE3 settings now. If it hasn't been changed for KDE4, could I suggest changing the name or doing something so that it's meaning is more obvious? Such as "Drag Windows Across Desktops"? Lol. (That's awesome that it's in KDE3... KDE continues to amaze me in features.)

> It's actually the pager that controls the layout - you can configure the number of desktops there and also the number of rows/columns.

Brilliant solution, my compliments. Some reason I didn't remember it that way, though. I remember making it a 4x1 plamoid (floating on the desktop) and Kwin still treated it as a 2x2 grid. Maybe that was because KDE 4.0 was still in alpha? Or a restart would have been needed for changes to take effect? As long as it works now.

> Which is where the viewport representation starts to break. Wallpapers could be still done by using viewports (and wasting a lot of memory for such huge background), but with panel that'd mean having panels duplicated and scattered on the huge area.

Hmm, I didn't realize that was how viewports worked... I didn't think it would have to render ALL the desktops in it's memory all the time. Maybe that can be improved one day (but that would require complex changes in X I can tell).

> DesktopGrid is not a view of the whole desktop, it's a representation of it. Think of it that way. The same way you think of the pager or, let's say, a paper map.

Lol, I guess it's hard to treat it as a "representation" when it looks so damn good. More like looking at satellite imagery than a "paper map". But I get your point.

Admittedly, the panel didn't really fit in with a large-desktop metaphor, because either you would have lots of repeating panels (as seen in DesktopGrid) which isn't natural, or a single one that floated above the desktop, like what happened with the Zoom In and Zoom Out buttons in Plasma. Although, if I had to choose between the two, I'd choose the floating panel. I am kind of curious to know what the Plasma group was thinking with the half-finished ZUI, which I noticed was pulled before the .0 release.

> (Also, DesktopGrid sometimes showing a window overlapping desktop borders even when it's not being dragged is just a bug, and it needs to be fixed. I can also make the borders distinctive, if that helps with understanding that those things are still separate and that when you move a window you put it "above" the grid.)

Hmm... yes, that would help. You could add some borders to make it look more like a suped-up pager applet rather than a contiguous meta-desktop.

By kwilliam at Sun, 02/03/2008 - 00:35