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