This week there was an interesting, but too heated discussion on kde-devel about the feature or bug of dragging windows from any empty space. I don’t want to comment on the topic as I participated in the discussion and by that are biased and this is post is not about the feature but more about what we can derive from such discussions.
When we look at the thread, we can distinguish three groups of people participating:
- Users – they either like or dislike the behavior
- Application developers – they consider the behavior as a bug which breaks their application. They want the behavior either weakened or disabled by default
- Workspace developers – they consider the behavior as a feature provided by the workspace. It is not a bug that the window can be dragged. No application gets broken by it; in the worst case it’s an annoying, but very consistent behavior.
I would have expected a fourth group in the discussion, namely Application developers who don’t care and either like or dislike the behavior. Given that the discussion was quite heated this is not really surprising that they did not participate.
For the further discussion we do want to concentrate on the second and third group. The most interesting issue is the homogeneity of the two groups. The developers from both groups have a very clear and uniform opinion on the matter and both groups are completely disjoined. No workspace developer could accept that this is a “bug” and on the other hand no application developer could accept that it is a “feature”.
What I derive from this discussion (which also confirms what I have been thinking for a long time) is that application developers and workspace developers are different group of people with different interest. We are all united under the KDE umbrella, nevertheless applications and workspace do not always and must not always pull towards the same direction.
The workspace developers have I would say more the view on the big picture. For the workspace developer it is (to keep in the example from above) important that there is a consistent and predictable move behavior. We have eliminated the visual distinction between window decoration and window content therefore everything that is empty content has to be a target for window movement. If we look at other platforms this is quite acceptable. Examples are MacOS X or Ubuntu. The workspace defines the platform and behavior and the application has to integrate. If they don’t do they are forced by enabling such features by default.
We have seen such differences between workspace and application developers quite often lately. Other examples are the switch from Legacy Systray to StatusNotifiers. With Legacy Systray the application has control over behavior and visualisation of its icon, while with StatusNotifiers both is moved to the desktop shell. Another non-KDE example are the action-less notifications of Ubuntu. The application developer considers its notifications as important and wants actions while the workspace defines that there are no notifications so important that they should have actions on them.
To me this results in the question: Where does the workspace end, and where begins the application? What is allowed for a workspace, how far can we “break” the application?
The KDE workspaces are still very bad at providing such a unified workspace compared to our competitors. The shining examples in this area are clearly MacOS X and Ubuntu, but also GNOME is still doing a better job in that area. Lately KDE improved. This is mostly thanks to the efforts of the Oxygen team to develop a GTK+ style. Thanks to that GTK applications integrate wonderfully into our workspace from look and also behavior. Nevertheless there are still quite some blockers like the horrible file dialog (which is for me reason to not use any GTK application):
But even for the look there is still lots of work to be done. E.g. consider the following screenshot of a popular Microsoft VoIP software:
Although it is a Qt application there is no way to get it use our style and not even the Qt plattform integration kicks in. This is a clear candidate where it does not matter what the application actually wants. For the consistency which we want to provide the application has to follow what we want. If we look at other platforms we see that Skype integrates perfectly into MacOS X, so enforcing our own look’n’feel seems to be acceptable.
Another area of the workspace version application are the client side window decorations (CSD). As it’s probably known I am not a fan of CSD and see hughe advantages for classic decorations from the consistency and integration point of view. In fact I think the advantages of server side decorations are so many that a “break” of applications with CSD would also be justified. I am even considering to try the changes for 4.8. If we look at the EWMH we see that there is nowhere specified when a window should be decorated. It is up to the window manager to decide on sensible defaults. Chromium currently does not get window decorations as it uses a legacy Motif hint. In fact the EWMH clearly states that Motif is deprecated and we would be fine to remove it:
Rationale: This hint is intended to replace the MOTIF hints. One of the objections to the MOTIF hints is that they are a purely visual description of the window decoration. By describing the function of the window, the Window Manager can apply consistent decoration and behavior to windows of the same type. Possible examples of behavior include keeping dock/panels on top or allowing pinnable menus / toolbars to only be hidden when another window has focus (NextStep style).
The specification has last been updated in 2006, so yes removing legacy code is something we can think about.
Lately there has been some discussions about Wayland and Client Side Decorations and I have been asked why I don’t participate. From the issues I presented last year, some were X11 specific, but the general consistency problem remains. Therfore I see no reason why we should start to allow broken apps. (I also think that Wayland should concentrate on providing a good architecture and leave decisions on the workspace behavior to the various workspace implementations.) And for those not understanding why I consider all applications with CSD as broken: here a nice screenshot (I only enabled window decorations from Alt+F3 menu).
=-=-=-=-=
Powered by Blogilo
Just a note, about skype, because it annoyed me also. The trick is that it will in fact use the Oxygen style, provided you have the 32 bit library installed (easy fix). But it caused various crashes in the previous beta. The current beta behaves better, and hasn’t crashed yet…
As for the look and feel on foreign (non X11) platform, I think you should: on OSX there are bugs with the native style and the breadcrumb widget, and Oxygen would in any case not look that much out of place. On windows, no one seems to care about consistency, so go for the much nicer style 🙂
I wonder what the users’ split would be, not on the issue in question but on whether such things should be controlled per-application or system wide.
I personally don’t like the drag on empty space “feature” but I definitely prefer it to be consistent across the whole of my system, which also applies to client side decorations, they give too much scope for the application developer to do something unexpected (and therefore to my mind broken). One thing that I used to really hate about windows was how every little utility decided it needed to stick out like a sore thumb and re-design its own widgets and window decoration while I just wanted it to get the job done and get out of my way. . .
So for that reason I’d tend to side with the workspace developers’ love of consistency – otherwise you tend to find every application tweaked for the application developer’s favourite settings which are of course different for every developer which means the user can’t even learn to compensate for disliked “features” because there’s no consistency.
And for those not understanding why I consider all applications with CSD as broken: here a nice screenshot
Proof by example. 😀 But you are right…
Well, Martin broke it on purpose for the sake of the example. The preferences of Chromium default to “Use system title bars and borders” since a long time and it works fairly well. There are some nasty bugs and it’s not eye candy – but it works without any major visual flaws. To produce such a screenshot, you’ll have to disable the integration in Chromium and reinforce it with Alt + F3 > disable “No border”. Why would anyone do that? Chromium might be a good example, but this screenshot exaggerates it’s flaws.
I wouldn’t say that I broke it on purpose. I just used what it provides and it is obvious that it cannot handle the task. A proper implementation would forbid that the window manager can add decorations again or at least would notice that decorations are added and disable the own functionality again.
Martin’s example was of the brokenness of CSD. When you choose the “Use system title bars and borders” option, it is not CSD any more.
So, it is even a better of an example than you realized 🙂
Okay, got it. 😉
Yes please, “consistency” to the free Desktop. No more a Zoo of look&feel
The concept of “application” seriously needs to die.
I don’t think that was Martin’s point. Why do you think that?
I dont like their platform at all, but i think the approach of microsoft in windows mobile 7 of being user-centric/workflow-centric/workspace-centric rather than being app-centric, is the right one.
The concept of specialized applications can’t die completely, but (and especially on phones/tablets) an integrated workspace goes far beyond in terms of user experience for daily tasks : interacting with people and contents rather than with seperate non-communicant apps.
Screw the appmania (if you don’t have an iphone, you don’t have an iphone).
That “Microsoft VOIP application” has Oxygen integration, it’s just that it needs some 32bit KDE packages to be able to use it, as it has no 64 bit version.
http://blogs.skype.com/linux/2011/04/2_2_beta.html
However, you’re right with the other points…
well doesn’t change the statement at all if they fixed the integration.
haha.. i second that!!
btw.: how does this drag feature “break” an app? (in the application developers point of view) i didn’t get this.. sry!
FYI: The Skype issue has been resolved in the latest (beta) release.
Which has already been pointed out and Skype has been used here as an example. What I wanted to illustrate still holds true even if it is resolved!
I think applications should always adapt to workspace.
If there are features which break apps, like this drag anywhere, then the apps should ask the workspace developers for a solution, and the workspace developers should be receptive, but giving apps the control over this is definetly not a good solution.
Apps can be fixed to not interfere with this feature or vice-versa, but 1 thing is sure apps should not be able to decide nothing in their own about behaviour and look of components common to every app (window border, looks, behaviour), I think that is a VERY bad idea.
I acutaully googled around for disabling the drag from any empty space, on a touchscreen I frequently moved windows unintentionally. You might think thats not a big problem, but it is with fullscren windows that then jump out to be free floating. The issue is that touchscreens are not absolutely stable, so if I try to hit a too small button and miss the inherent vibration will move the window.
So I am all for features, as long as there are easy to find configuration options.
A touch screen comes with a different form factor where the drag feature (and others like quick tiling which is causing the “jumping”) does not make sense. That’s why we will disable the feature in Plasma Active. Without noticing you are agreeing to what I say: the control about such features has to be in the Workspace.
I am an application developer who likes the “drag from empty space” feature. The ktikz application of which I am the main developer has a preview panel in which the contents can be dragged. When the “drag from empty space” feature appeared, there was no interference with the dragging in the preview panel, so I was never forced to reimplement the dragging.
Given that not only KDE styles implement this feature, I think that there should be a variable in QWidget named dragOnEmptySpaceMovesWindow (or something like that) which if set to “No” completely disables the feature for this widget (this would allow to solve the problem of the original poster in the kde-devel thread in a cross-platform way). This can be implemented even though this functionality does not exist in Windows, because for example QSessionManager::saveState() exists, while its functionality is only available on X11.
Hi Martin, I was interested in the Kwin with opengl es, but when I downloaded the latest kdebase waorkspace 4.6.3, I couldn’t find Opengl ES related code in it. Where can I get it to test?
Thanks,
Ramesh
it’s only available in git master aka 4.7