This weekend I was at FOSDEM and attended a talk about Wayland for application developers. One thing that came around multiple times was that “applications have to provide the decorations”. Every time I had to cringe, because it’s just not true and I find it sad that people who give presentations about Wayland repeat that.
Nothing in the Wayland protocol requires Client Side Decorations or forbids Server Side Decorations. And that’s not surprising as it just should not matter to a protocol. The same is true for the X11 protocol, there is nothing said about window decorations. Just on X11 people realized that server side decorations are the better choice, but still there are applications doing client side (maybe people think that the possibility of re-parenting says anything about window decorations, it doesn’t you don’t need re-parenting to provide server side decorations). What is true is that the reference implementation of a Wayland compositor, Weston, requires Client Side Decorations, but it’s just one implementation and doesn’t say anything about other implementations. And here it’s important to remember that Weston is not Wayland.
There are good arguments pro and contra client side decorations. The most commonly listed ones pro client side are:
- Only one texture needs to be rendered
- No aliasing when rotating/wobbling windows
- Application developers are free to experiment
The first two are true. I have to agree there. I know KWin’s OpenGL decoration rendering code and the problems with it. I do not like it and I do see the disadvantages. Also I do know that wobbling windows is not looking nice.
The third argument is more complex. Here I do not agree, because I have not seen any valid use cases for these “experiments”. All we have so far is the Chromium use case and since then nobody else came up with any use case. So somehow that shows that we are not restricting the application developers as some pro-CSD people would claim. In fact allowing CSD limits the possibilities of the workspace.
Plasma provides three workspaces: desktop, netbook and tablet. From KWin perspective the main difference is how window decorations are handled. On Desktop we have full decorations, on netbook we disable decorations for maximized windows (control moved to the Shell’s panel) and on active we don’t have any decorations at all. With client side decorations such possibilities are gone. We are no longer able to take the desktop further by just changing this aspect for all applications. Many KDE applications are useable on Plasma Active (tablet) without any adjustments. If they would use CSD they were not usable.
My main fear with CSD is that it ends up in a mess as we can see on Microsoft Windows. There CSD are common but applications don’t use it to do useful stuff, but to enforce their corporate design. This is bad for usability. Each application looking different? Stupid idea. Not even Microsoft is having a consistent decoration for their various products. Some have titles on the left, some centered. A complete mess. And my fear is that Linux would head there, too.
Is this fear valid? Well during said presentation Weston was running with two windows. They had different decorations. One was the terminal with minimize, maximize and close button on the right. One was a pdf viewer with a standard GNOME Shell decoration: minimize button missing. And during FOSDEM I had also a look on the decorations for Qt Wayland: again different decorations.
Now let’s take that further: an application for Unity will have the buttons on the left, a decoration for KDE will have two on the left and three on the right. Everything will look different, just on one system. Total mess and nothing I want to use (yes that would be a reason to switch to Mac if that would happen).
I had a talk with Andy from Qt Wayland fame about the CSD implementation and he explained me that inside Qt the CSD code gives some overhead and that they have a flag to turn them off. Which is great. And we in KWin already have server side decorations and will need to keep them around for legacy X applications. What’s the point then to use CSD in Qt if we already have the decorations and can give the application a better performance? Well none and that’s why I plan to use server side decoration in KWin on Wayland.
So if you read again somewhere that Wayland requires Client Side Decorations:
- Nothing in Wayland requires them
- QtWayland allows Clients to turn them off
- KWin as a Wayland compositor will use server side decorations
I do not want to go into the details of the contra arguments of Client Side Decorations as I have done that in the past. It’s a difficult topic as both pro and contra arguments are true. I personally see the contra arguments – especially the inconsistency – as much worse than the possible benefit of any possible pro argument. And please don’t come to my comments section and tell me that one can standardize on how the decorations should look like. If that were possible and feasible and would be used by application developers, we would not have already at least three different decoration implementations. It will end in the fancy I’m important mess from other systems.
I fear for the the Linux desktop future in general, as with Wayland, if KDE is the only one to stick with server-side decorations, and even Ubuntu comes with a home built display (http://www.omgubuntu.co.uk/2013/02/canonical-working-on-new-display-server ), things will be more and more fragmented…
I know nothing about Wayland internals, but hope not to see both a client and a server side decorations on applications…
So basically you are saying the pros of CSD is only for the compositor? I actually don’t really think making it easier to develop a compositor is a big deal…
One thing I am worrying about CSD in wayland is that I don’t think it will still be possible to have the lovely menu-in-titlebar feature of kwin 4.10 (or no?). (Basically what the hell are we doing by making menu bar global and let each program render there own decoration……..)
I thought wayland was sth like X without rendering protocol, but seems some useful features will become really hard to implement.
Wayland is basically a compositior protocol http://wayland.freedesktop.org/architecture.html
I can’t see why X can’t be made to support the Wayland *protocol*, NOT THE WAYLAND “DISPLAY SERVER”…
That explanation on fredesktop.org is very nice and dandy… hey!… but what *if* the client is not local but resides on a remote terminal ? … IS SOMEONE TRYING TO KILL LTSP (linux terminal server project http://www.ltsp.org/ ) and APPLLICATION SERVERS like 2X ( http://www.2x.com/applicationserver/ ) that work so nice with KDE environments even having windows apps, that are used in so many scholls (usually with poor resources) ??
Nothing understans better all the plethora of driver APIs in linux than X… and its not only KMS and evdev… so X should still be the “Display Server” and use the wayland protocol to put a “compositor” to talk directly with its pretinent clients and avoid the round trips -> to remenber that that compositor can be remote and local at the same time if X merges with NX (load balanced).
So most of those opendesktop arguments are null and void (wrote by Intel ?? .. or M$ ?? ), there isn’t the need for a “another” display server… there is need for better “compositors” that could understand the wayland protocol… ***wayland which shouldn’t be the compositor either***… something like plasma on wayland *protocol* would be much natural and better fit
So the *sht* you talk about has nothing to do with X per se… and the wayland *protocol* can even be a good thing… but the “Wayland Windowing System” smells like rotten dead to many great and superior Linux projects, if pushed hard by the moneyed inetrests…
With Wayland windowing sytem is DRIVER RE-WRITE allover again… perhaps some distros are convinved since almost none of their users pays for the software that they can sell drivers… which is quite ironic since this all movement started because Stallman wanted a free driver lolz…
Why the spree to kill X makes me wonder !… if the Art of War of Sun Tzu (http://en.wikipedia.org/wiki/The_Art_of_War) doesn’t apply here…
I suggest you try to learn more about X, Wayland and graphical toolkit. There is so many things that are wrong in your post that I there is no point in me repeating what others have already saying. Watch that http://mirror.linux.org.au/linux.conf.au/2013/mp4/The_real_story_behind_Wayland_and_X.mp4 and come later with better arguments if any.
There is so many things that are wrong that i don’t know where to begin… not in my “story”…
But one of the first strinking is why this “suicidal” tendency to re-invent the “whole wheel” when some nifty feature is to be introduced.
I even agree with most of the arguments pro-wayland, its a nice feature, and X11 is getting old and it shows… hey! but i can’t find an argument why can’t the “wayland” protocol be added to the current X implementation, and X itself be improved…
I thought that FOSS was about cooperation and colaboration !… but no!… Wayland will solve all the stuter, tear, inconsistency etc problems… great!… it will be better than Madonna will less than 20 years old, it will be like watching superball in a floating couchin in the carabeean sea with a pack of the favorite brew by the side pimpered by 2 hot chicks… marvelous!…
Just wonder how Wayland will accomplish the feat ???… will it target, DR1 , 2 or 3 drivers ?… mesa drivers (damn! this crap is very old and ultra obsolete!) ?.. will it target DRM drivers ? .. will it target Gallium3D drivers ?… KMS ? etc (sure forgot something)…
will it depend on crappy and or half finish drivers ? … that make a luck if a fortunated Linux user gets **half** of the functionality of their $200 card ??
Does that seem a consistent view for dispaly drivers to you ?… but no!… all the fault for the problems is in the X protocol…
Wonder how much stupid can it get !…
The problem IMHO, is that the debate about kernel space or user space display drivers was prematurelly set but in the wrong direction.
REALITY strikes hard (no matter how hard it takes to many)… the indisputable market leader in the client/desktop side as choosen, the GPU will be a prime time **PROCESSOR NOT A DEVICE**… for now on there will be only GP(general purpose) GPUs, that can even be bus masters and start a boot process(its possible in the current *HSA* references)…
Does the Linux kernel have userspace drivers for their many CPU uarch support ??? … **NO** !… then why would a GPGPU be any diffrent ???
That is the problem… the current X implementation reflects this in the many APIs that it has to support… as long as **devices** got more complex new interfaces were introduced (still are) that are only uggly patches to the needs… when the fundamental “VISION” problem got to 2th place according to some influencial interests that are on crappy obsolete GPU implementations…
That is why the NEW whole Wayland Windowing System instead of only a protocol… target something obsolete and diffrent from the main trend, optimizing for it, a feat that **NEEDS** all the community involvemnet, and only will get to somewhere if new drivers are developed and the APIs cleaned… not only the “compositor issue”…
Does that ring a bell… if outside partisan views are possible to you ??
I though that Linux was imune to the ultra-imbecile paradigma that goes in the Windoze world… but if some hot head gets it hotter wrong… the CLEAR indisputable leader of the client/desktop sector is ARM…
And its not a question of Apple being able to sell 5000 in less than 1 hour… matter of fact Apple is NOT the single most ARM seller… Samsung is… and Samsung happens to be on HSA also as prime founder…
No punctuation no tong in cheek, reality is that ARM by units numbers, sells more chips by their all ecosystems… in a couple of months… than Intel sells in a whole year…
Please, for the sanity of us all, go **educate** yourself will you? I can’t make any sense of what you’re even trying to say now.
The video Cedric suggested is actually perfect for your case, please watch it.
Also, I highly recommend you to checkout http://wayland.freedesktop.org/ , especially the “Architecture” and “FAQ” sites.
Hope this responds to Martin also, i don’t want to spoil his blog.
Just think about Android DS, no fuss no spin no hype… no rants… which is also very permature about wayland, because talk the talk is easy, but walk the walk is something else( and here are the suicidal hazards)…
… in 5 years, or better 10 years when wayland DS matches all the “network” functionality of X , perhaps we can continue the rant … lol…
“… please watch it… checkout “Architecture” and “FAQ” ”
did all-> very quick,
Wayland protocol, nice feature… to all FOSS DSs..
Wayland DS ? what for ? … specialy if it is to rely in all there is there already, what makes anyone think it will be much better, when the main problem is exactly in what is there, the all drivers, driver vision and architecture (half backed and or obsolete).
About SSD or CDS and consistency, specially in Kwin decorations, which is Martin work, not much he can do specially if it will be possible to change the window manager by another (matter of fact i like and used compiz with kde.. perhaps do it again in the future)
About overall look&feel, perhaps plasma that has a particular themeing engine, that i’m sure will evolve faster than any outside “vendor” could mess with, can be used as the main “compositor” for the wayland **protocol**… this could enforce some consistent look&feel.
I don’t think you got much of that video. Plasma won’t be the compositor, it will be KWin.
i was “suggesting”…
But thank you for your attention Martin, don’t really wnat to spoil anything.
But one thing that is very striking that should sound all alarm bells (the big sirens)…
What is wrong with X?
http://wayland.freedesktop.org/faq.html
“” For many things we’ve been able to keep the X.org server modern by adding extensions such as XRandR, XRender and COMPOSITE and to some extent phase out less useful extensions. But we can’t ever get rid of the core *rendering* API and much other complexity that is rarely used in a modern desktop”
http://wayland.freedesktop.org/architecture.html
“” The *compositor is responsible for rendering the entire screen* contents based on its scenegraph and the contents of the X windows “”
A CONTRADICTION… the target is not functionality, the target is anti-X itself
LTSP, network stuff depending on X, is quite secondary to this wayland author
Why wasn’t D-Bus used instead of the Wayland IPC mechanism?
” Second, everything is explicitly asynchronous, which is a really powerful feature in a protocol. ”
Redundand… XCB is already async, KDE uses dbus, X is positioned to use dbus, Linux kernel is positioned to use dbus internally(check LWN)… this Wayland author is pissing to all of you…
Is wayland replacing the X server?
” Further down the road we run a user session natively under Wayland with clients written for Wayland. There will still (always) be X applications to run, but we now run these under a root-less X server that is itself a client of the Wayland server. ”
How can KDE fall for this… “from the worse mouth” explicit attempt to break compatibilty with ith all growing FOSS app ecosytem ??… shouldn’t this ring all alarm bells ??
I run many GTK (gnome) apps under KDE, works great, what if gnome sticks with X, and it doesn’t work that great anymore if at all ? (even FatRat on qt and X could have problems)
And If
“” The Wayland architecture integrates the display server, window manager and compositor into one process. “”
Why can’t it integrate a striped down X server and spit the compositor out ? … use only the protocol??.. it makes much more sense, since its a mutiplexing protocol it could even have more than one “compositor” in one session, which could fit very well KDE..
All this is akin to go to the Linux ML, with ideas about breaking ABI compatibility, there this Wayland author would be properly received!… lol..
So sorry again, but in light of this all other problems are quite secondary, including the question of CDS…
Sorry, but you do not understand the problems at all. Work on a window manager for a few years and you see the problems. Also remember X network transparency is already dead.
I have to reply to the comment “Also remember X network transparency is already dead.” I’ve never understood that one.
I run remote X (not vnc) at work all the time. Today just to test it, I ran Firefox 17.0.2 & eclipse over the network from one of my servers. I wouldn’t do that normally, but it worked without any trouble or effort. I use terminals, editors and all sort of third party applications that way. How is it dead? Because I can’t play Quake that way? (Sorry if remote actually Quake works, I don’t have it installed to test out.)
The moment the distributions, toolkits, desktop environments or whoever start using the Wayland protocol exclusively is when remote X is dead. The only answer I’ve heard for remote computing with Wayland has been to use vnc (with the weight of a full remote desktop environment) on each remote host or that remote access will be another problem to be swept under the carpet of the toolkits (who will each inevitably solve the problem differently. “Is this a kde app or a gtk app? How do I run those remote again?”).
I get that there is kruft in X that we’d like to be free of. Wayland just keeps sounding like another case of a half complete replacement with the promise that the complete answer will come from some where some day. That’s getting too common on the Linux desktop and the users are getting shell shock.
If Firefox works for you on X11 network transparency, it will even work better on Wayland.
As Martin says if you did a window manager, a composite manager, a graphical toolkit or worked on X in the past, you will now that Wayland is going the right way. There is a reason why it did gain traction from everyone, it’s because it’s a needed evolution.
Do you have any idea why people working on Kwin, Enlightenment, Compiz, GTK, Qt, EFL, X think that the way to go ?
Mario, my blog is not the place to rant about Wayland. Please do that on your own blog. Further comments about Wayland here will be moderated, because they are completely off-topic.
Thank you for understanding.
Why is that only decoration matters to you consistency-wise? Why don’t you care that the window content is looking inconsistent?
Let’s look at current situation where to achieve consistent look of Qt apps in gtk+ environment, Qt has to mimic gtk+ widgets rendering. So apparently it is possible to achieve consistency client-side. Then why can’t we do the same with decorations?
It’s job of the toolkit, damnit. Apps will still be able to break consistency even if you “enforce” decorations server-side, simply by selecting type of window that is undecorated, and then painting them manually (like currently Chromium does). So there is no point. That’s not the way to achieve consistency.
Considering this, picking CSD is an obvious choice due to technical benefits.
Think about it.
yes Qt is able to do it: GTK+ isn’t, Mozilla and LibreOffice even less. Why am I presented with a useless File Open Dialog whenever I use a GTK+ application? Why are there different VFS implementation? That’s a situation that existed for years and doesn’t get fixed and I don’t trust toolkits to solve it.
The thing is, that even server-side decorations wont change the fact that applications like firefox or LibreOffice look inconsistent in KDE. If an application wants to look consistent in KDE then it has to use KDE libraries. With client-side decorations the application that tries to look consistent would have to use those style functions from the KDE libraries to draw its decoration. But additionally it could put stuff like tabs, search bars etc. in there.
I am a perfectionist, but I can live with a few bad applications. I feel it is more important that good applications are allowed to look as good as they possibly can. And for that there must not be any technical restrictions.
Get use to it, with SSD or CSD or not… there will be fragmentation (including look&feel) now that Linux desktop/client is gaining traction and wider attention, everybody will be trying to invent the next big thing for fame fortune and glory… nothing very wrong, only “human nature”…
unless!… like the LSB standard that was for very long only on paper and title… still is a little… but is gaining much support due to complexity and the “lib” hell jungle and perhaps many more “libs” can be included, the same in desktop!…
If a common engine for rendering is pushed ( the LSB of desktop rendering) there will be much more standard look&fell without any particular “lib”, BUT outside of X which is not designed for real 3D rendering, and could/should/must delegate the function to a “proxy” or “helper” engine.
NO this not endorses Wayland… which is another reinventing the wheel like many in FOSS, and doesn’t touch the real problem… more so becasue that LSB of 3D rendering should NOT be in the “windows” protocol or management, but outside of it… IMHO…
I vote for Plasma… perhaps “Gnome” and “E” etc… with good diplomavy and effort are presuaded to use plasma… which should be around the C++11 standard and “VERY WISE” also supporting/compatible with M$ AMP ( many don’t like or hate the idea, but KDE shell replacement for windows a sucess and KDE will be instant king of allover desktop/client world-> reality of working sucess never went in hand with politics of tastes or philosophies), and also OpenCL and OpenCL++ and derived scriting including Java…
… since the next big thing is “compute power” and the GPGPUs as full time general processores not devices… and the trend is clear, since ARM is big time (if not the main pusher inspite of it being initiated by AMD) on the HSA (heterogenous software architecture), and the MALI >400 will be also *real* fultime General Purpose processores (floating point/compute engines).
So the Gnome pleople don’t like C++ !?… perhaps they can be persuaded that is not a “fun club choice” but a standard, and the future standard is HSA if ARM continues to win like it has been, and ARM 64 will here in force in less than 2 years… perhaps superphones/tablets more powerful than the time of the athlons/core2… so there will be no diference or the question of “lighter” cause the processing power is much smaller
Plasma… desktop folder ? … why not a “desktop” as a HSA engine per se ? … i think the future, and the wisest thing to follow not a taste or a particular view of what the main display is…
So there is a need for a standard but not any standard… and in this i think Plasma is the right approach and very promissing for that needed standard underlying 3D engine (if not Plasma something like it).
There are a few things not clear after reading this :
-How is the qt ‘disable CSD’ flag triggered? (compile time, runtime?)
-What happens when the ‘disable CSD’ flag is enabled and there is no compositor providing decorations?
-And the opposite case : ‘disable CSD’ flag disabled (or non-existant) and decorations are provided server-side? (will it have 2 title bars?)
I guess these issues are still ways off, but still…
I haven’t looked in the details, but I would assume that it’s compositor talking with clients.
Fullstop. There’s nothing to add to this argument which i fully agree with. But i think you missed one important point: csd would prevent users from consistently configuring decorations the way they want them (i.e. changing button order in the oxygen decoration, which is such a great feature.
that’s all in the blog post I linked.
Probably I shouldn’t comment on blog posts after 12pm 😉 sry
Merci. This restores my faith in Wayland.
“No aliasing when rotating/wobbling windows”
I am a complete noob regarding window management and window decorations, but wouldn’t be possible to avoid this by composing both textures (the window contents and the window decoration) in the same buffer before transforming the contents (rotating, skewing, etc)?
Yeah, but then you use an extra buffer.
yes, but that’s of course overhead
Rotating/wobbly windows are IMHO a serious misfeature. They’re here “because we can” and because they look cool, but they end up being a pain to use and I don’t know anybody who didn’t eventually turned them off.
So if such a feature looks imperfect or has some overhead, it’s fine by me really. YMMV.
Then again, I’m surprised that the overhead of an extra buffer isn’t necessary for other features anyway ?
I’ve been using wobbly windows for years, and I still use them – and like them.
They make the desktop feel more organic, and they give me good UI hints that a windows just got bound to the side of the screen or another window: The fixed window position does not feel like a bug, since the wobbling shows that something happened.
So wobbly windows are an example for a feature which is both pretty and useful.
depends on personal taste. I currently have them enabled (since a week or so) and have the feeling that something is missing when switching to XRender. On the other hand I find it difficult to properly position a window with them enabled.
I am not sure why is that but moving windows with wobbly enabled seems much smoother .. it just feels like much better experience. I sometimes move windows for the sake of the experience. 🙂
On desktop maybe but think about (multi-user) touch devices. Besides it doesn’t hurt anybody couse afaik it’s not a hack or code overhead.
Apart from consistency, CSD can make it harder to manage (minimize, kill, etc.) nonresponsive applications without ugly hacks (IIRC, Windows will draw server-side decorations on top of a client window if it detects the client has been frozen for a few seconds).
I’m glad to see someone is looking at CSD. How will applications know they’re not supposed to draw decorations? Will you be defining a flag or something that implementors of server-side decorators will be able to pass to applications? (It might be interesting if this protocol allowed a mix of SSD and CSD, if the window manager wanted that.)
“IIRC, Windows will draw server-side decorations on top of a client window if it detects the client has been frozen for a few seconds” Yup, that’s the windows behavior, one of the few things done right in that OS. Might be considered by KWin
Kwin does not need that because it is not CSD. The windowed program may be frozen like hell, the decoration still works. You can drage, minimize and close a program when it crashed.
This is a very good thing. The next good thing, IMHO, is to create a common window manager library to be used by different window managers; something like libmutter, which is used by gnome end elementary. I don’t know if/how this can be done for Wayland, as I’m just a user, but my thought was that it would avoid duplication of effort and the current situation where we have many wm’s that are identical, but slightly different.
there’s no usecase for that. The window managers are too different from toolkit and programming language perspective.
Sweet! My biggest concern with the CSDs is what Unity and Gnome 3 currently do to the decorations….
But with this, I would think it would require a protocol for the server to tell apps not to draw the decoration, and for the client to tell the server it can draw a decoration? (and I think it would need to tell if the window is resizable or closable too?)
Couldn’t a simple, cross-platform (i.e. works with gtk, Qt, KDE or Gnome) library be written which reads a theme, tells the toolkit or compositor (KWin, in this case?) the size of the decorations and various details (where the buttons are, etc.), and provides some images or textures from the theme for the tk or compositor to do with what it pleases?
The compositor could then,
1.) create a single buffer for the window, including extra space for the decorations
2.) write the decorations to the buffer once, and paint the window in the empty space left over (should be easy with a simple translation)
3.) use whatever method to modify the buttons when pressed (another image, texture, an effect, or some combination)
Sounds like a nice way to get the “single texture” performance advantage back ?
In a world where both CSD and SSD will exist, we’ll need a negociation protocol anyway, to avoid client and server steping on each other’s toes. So if that protocol can integrate tricks like this for the SSD case, go for it 🙂
This is what I was thinking about too, a “libdeco” so to speak. With the upcoming subsurface work by Pekka Paalanen, it would be even easier: You would tell libdeco to start up, setup some common callbacks (minimize, close, resize etc), and it would give you back a subsurface to render all your content into, which would then at the end be surrounded by libdeco with 4 more subsurfaces to create the decoration around it.
The really cool thing about this is that it would mean that we could finally use exactly the same stlyes in different compositors, something that is hardly possible today where each compositor does its own thing.
If this libdeco started getting popular and stable, people would start writing themes for it that you could then use under any(!) compositor, yet again something that’s impossible today.
If you have the decoration rendered in the client independently, what’s the point of having CSD in the first place.
And it is impossible to easily add wm specific features to that lib.
In theme file:
Button_loc: x,y
Button_act: custom
Button_custom_name: menu_foo
In client or wm:
menu_foo() {
//do stuff when clicked
}
It’d be a bit more complex if Qt is handling the decorations itself, but not impossible. The custom action may not work with gtk_app_foo, but then it’s a non-native app anyway. At least the general appearance will be the same.
*Jan applauds! \o/
How will Gnome and other foreign apps run in KWin? Will they display their client-side decorations, and KWin will detect that to avoid using server side decs?
too early to tell. If it goes badly and GTK+ does not provide a flag at the time we go for Wayland, you will have two decorations.
We really need a plan for that. As a user, I’m all for SSD (I even disable the chomium CSD), but I know that some people will insist on CSD, so we need a sane way to negotiate which type of decoration to use.
I would not like if the next big thing on Linux concerning display servers would be one big compromise because of the legacy applications. I would much rather see new applications using newer versions of GUI toolkits would be the focus of this transition and legacy stuff to somehow make it work for a while but really not to focus on them anymore too much. To me personally this:
“Only one texture needs to be rendered
No aliasing when rotating/wobbling windows
Application developers are free to experiment”
This probably does bring us better performance and ease of use generally speaking and this is something we would like to achieve while moving away from X?
About inconsistency between apps and control over them because developers have more freedom we can expect majority of apps will follow some rules but maybe the future is different from the past because if we look at the web and web apps there really isn’t much developer couldn’t do and is this necessary a bad thing? Probably it comes down to personal preference.
You have much valid points but probably this is perspective from the past and i really don’t know how will average app or operating system look like in 5 years time for example and if by any chance average app will be some web app then i do imagine there really aren’t any limits on how it should look like and probably the browser running it will be in full screen mode most of the time.
What i am trying to say is Wayland/Weston is fundamentally different from what we use or have now and probably it wants to be this way? It doesn’t want to solve this anymore it’s up to the clients and developers and Linux distribution makers to figure it out how they want to roll.
For KWin you decided for example it’s KWin’s job to impose some rules to gain some features and consistency but who knows what would happen if this would not be the case. Sure there would probably be some inconsistencies but nevertheless it would be interesting to see how would it work out.
Anyway i wish you luck and thanks for your work and i imagine some will try this and some something else and in the end probably better approaches will prevail.
not everything has been bad in the past. Maybe it has just turned out to have server side decorations on the desktop to be a good thing? We should not throw out the things that worked well, just because we are switching technology. There are systems where CSD might make sense, but so far I have not seen one. On mobile it’s even more important to have control passed to the shell.
The thing is i agree with you 100% and trying for example default Openbox every application that uses different toolkit looks different and that is a pain. I don’t know if this is good example but it’s example of (design) inconsistency at it’s best. Running popular Openbox Linux distribution where developers think about this makes the experience good and that is why i am optimistic.
With CSD probably every app will/could look/behave a bit different i can agree because Steam client, Google Earth, Chrome, Skype… i do imagine each corporation would like to push it’s own style to differentiate it self from competition and to be honest they are already doing it right now?
I honestly do see this trend in the future as something that will probably happen and basically we are there already now when we have SSD? This is something that is coming or better is here already and there is little we can do to stop it?
Maybe now it’s the right time to change this fundamentally and do things differently. Why not? If somebody wants to implement minimize app in a way you have to rotate app 3 times around it’s center let him try. Users will be the judge if they like this or not because until now there really was only one way to achieve this task and a decade or two nothing much has happen to change this.
I am willing to give CSD a chance and to see how it goes.
But what do you do if we find out after three years that we f*** up? And here we know that it won’t work because there is a popular OS out there which uses CSD.
Basically the thing why i am willing to try this and be open-minded about it is X11/X.org is trying to do too much and it tries to be involved in just about everything. In the real world more and more we see developers are trying to do things differently and it just ends up problematic because the way to do this is to think how to bypass all the restriction that exist. SSD are there to enforce something a lot of popular software is already trying to bypass?
And looking at the current trend of web apps there really isn’t anything holding you back to do anything and i think we have to ask ourselves how much difference can SSD really make?
Will it serve us good or will it be there only as something we will be trying hard to bypass.
I don’t know i could be totally wrong but i think we can’t stop apps from looking/behaving differently in the future and this will happen one way or the other.
But i am not saying you are wrong and sure i could be totally wrong but i do see CSD as something that could do things differently from what we use now and by differently i am thinking in direction of you can do just about anything and sure that does bring us some inconsistency but the potential to bring us something better is there also in this is something i am willing to try.
Also interesting to see how it breaks, which is already happening on wayland in the area you don’t care about but is really important to other users.
Both the Steam and Desura/Desurium clients use client side decorations. I imagine their developers think it’s cool to be able to control that. As a user I don’t care for it personally.
Thanks for the extra example beyond chromium.
I use steam (under wine), and as a user I find the CSD and client-side window management (really ! when a modal window appears, you cannot do anything with the parent window. I’ll even play a sound whenever you try to interact with it) really annoying.
Just to reply to myself, I haven’t had much experience with client side boarders. I’ve discovered something new about the Steam client. This ill behaved little application maximizes when I double click the title bar/area. All my other windows roll up to just the title bar. Now I really dis-like client side boarders.
There’s no reason the application needs to define a different behavior and there is an easy way to stay consistent. They had to do extra work just to break consistency. Why? The best I can tell it is for vanity. But it’s worse than that. Looking different is one thing. Changing behavior of standard elements of my desktop is nasty. That’s malware fodder.
It seem that that moving decorations into the toolkits will only encourage more of this and instead of setting a sane default once, I’ll have to set it per-toolkit and perhaps in some one-off application. And that’s assuming I can find a decent theme and define the window behavior I want in all of them. Define (and enforce) basic app independent behavior outside the apps.
Also, to be fair to Desurium, I seem to have remembered wrong in my previous comment. It uses the regular window manager title bar. I think Desura used client side boarders because it had the wide, thin, red, windows-style close button instead of the one from my desktop theme.
I really hope vanity window boarder don’t catch on in Linux the way it sounds like it has in windows. I mean really, if anyone should be expressing their vanity on my desktop, it should be me.
There’s an important difference here:
With steam, it is drawing it’s own boarders. If it is using a toolkit for this (which I doubt it is, at least not gtk or qt), it’s not letting the toolkit decide what actions occur when the users perform some action on the decorations. This is not something that every app developer will want to do, because it’s extra work and (as you pointed out) does not match up with the rest of the desktop the majority of the time.
I would imagine the choice of “maximize on double-click” was one of legacy. “That’s what happens on Windows, that’s how it’ll stay until someone confronts us about it (because we don’t know)”. I don’t doubt KDE and Gnome’s defaults contributed to that end, at least somewhat, if it ever did come up in conversation.
Anyway, if they let the tool-kit draw the decorations, as most sane applications allow the window manager to do now, this would be a non-issue. I still see no reason why applications which have always let the window manager draw decorations would suddenly decide to write more code to implement their own decorations when the tool-kit will do it for them for free, just as the WM would, and they would look a lot better all the while.
But it still sounds like I’ll have to set my preferences for GTK, and again for QT. And another time for KDE apps. And then for WX. And what does FLTK use? Will there be another configuration for SDL apps? And do the various java toolkits all build off one of these toolkits or will I get to restate my preferences several times yet again? Will all of these toolkits offer the same default behavior? Will they offer the same configurability (or specifically the configurability that makes up my work flow)?
It’s easier and surer to pick a window manager or desktop environment and set my preferences once. Set and enforce policy once in one place. Otherwise you will get it wrong and there will be no common policy. I’ve already seen people complain about how toolkits vary on widgets, appearance and behavior. Client side decoration is just going to bring that same inconsistence to the most basic actions in a windowing environment. I don’t believe it will end with good results.
I hope that server side/centralized policies for window behavior will be the norm in Wayland if that does replace X. And I hope there will continue to be options for those of us who have grown used to a set of behaviors that are not necessarily inherited from Windows, MacOS or a toy computing device.
I’ve never had to configure anything for WX, FLTK, or SDL. They either looked fine, or looked horrible, and I don’t think server-side decorations will change that. Same for their controls.
The real solution, server or client-side, would be to establish a standard configuration (file/interface) for window controls (and decorations, and themes)…but apparently nobody is willing or able to come to a consensus about what that should be.
Regardless, what SDL, FLTK, or WX apps that continue to work with wayland will do is one is of two things…
X fallback: An X container will spawn for the window, and your compositor will add it’s own controls to it (which may or may not clash with the toolkit’s theme, but at least the controls are the same?). I guess this will be something like SSD.
Native: The toolkit will communicate with your compositor directly (rather than through X), and either (SSD) let the compositor decorate the window, or (CSD) decorate it’s own window. Either should look and work the same, except: With SSD if there is no common (decoration) theme interface, it will not look right, and themes may (but don’t necessarily have to) vary between toolkits; with CSD if there is no common control/layout interface, it will not work the same (but at least with CSD you don’t have Plastik decorations with a clearlooks theme?), and themes may (”) vary between toolkits.
Would a CSD only world basically cripple the possibility of tiling window managers? Something like PyTyle – which polls the current WM every however long – might be the only way to tile windows with CSD, which is extremely gross. Hopefully GTK, Qt, etc. will all allow server-side decorations.
tiling aspect is IIRC discussed in the linked blog post.
Well, if the “client” (in most cases this will be your tool-kit; GTK, Qt, etc.) lets you disable decorations (assuming you want them disabled), and provides some sort of scripting method, you should be able to tile windows just fine.
Qt provides a method of disabling decorations, and there’s QML, so you should be good if your environment is Qt based. Otherwise, who knows?
I totaly share your point of view. Thank you for your great work.
Well the good part is that we’ll have two methods. Time will tell which one is better. So maybe it’s a good idea to have server-side decorations. If they’re going to be a complete failure we’ll deal with the fallout later.
“We will fix it if it breaks” is never ever a reason, just like how someone breaks thousands of CJK users.
You missed the worse. Miss behaving applications.
Really it would be good if kwin could be intelgent about it. CSD on applications that behave and will render correctly where there is a performance gain. Server Side Dectorations on applications we cannot trust.
Really it would be handy if it was built into the wayland protocol to inform applications CSD or not CSD.
One argument I haven’t seen listed is the case of frozen applications.
Right now, if an application freezes, user can still move/minimize the window and if after clicking on the (x) button the window does not go away, KWin asks you if it should kill the process.
With CSD you would not be able to move/minimize frozen windows or get the process killed if it is unresponsive, since the client would be responsible for moving/minimizing/closing windows. Am I correct? If so, this is a big problem for CSD.
that’s considered to be solved by the fact that there is a ping protocol. Same exists in X11 already. I’m unsure about it as it affects also long running applications (yes one should use threads) and it would be nice to still move them around and no I don’t expect users to know the alt+left click trick.
For some reasons, I’m on Redmond OS now, so, I thought I’d post an screenshot with three highprofile apps from that vendor: http://imgur.com/uzdXImr
awesome 🙂 and I know even more decoration styles, the terminal emulator should come with the Win 95 decoration.
Unfortunately, nope: http://imgur.com/og5Sgvv – it’s current decoration style
oh that means they updated it. Used to be different in the past.
Aww, noo! I’ve forgotten about most important app – the one that lets internet explore your pc: Lo and behold, yet another style: http://imgur.com/IveMuD9
Agreed 100%. From an accessibility point of view the problem with CSD is even more worse since we would lose a common way to eg increase the decoration size/buttons/colors for all apps, to improve visible difference between focused and unfocused applications by changing apperance/color/size of the title-decoration, to attach extra buttons to all windows, to have a common window-menu reachable the same way, to have a common atspi-API per window, etc.
Thanks for the blog! 🙂
http://acc.nics.gov.uk/designers/consistency/consistency1.0.html
”
Consistency is one of the most important principles behind good interactive design and accessible design.
Consistency assists people to efficiently access and utilise the information and services you are providing, rather than wasting time repeatedly working out the interface.
A gentle introduction to the guidelines – if you remember nothing else from these guidelines remember to be consistent. Even consistently bad is far more accessible than inconsistently bad!
”
About accessibility-/consistency-problems with Chrome on Windows:
http://code.google.com/p/chromium/issues/detail?id=758
Hey Martin,
I disagree with your opinion. The problem with server-side decorations is that the server doesn’t know what the contents of the window look like and thus can’t draw the decorations so that the colors, gradients etc. fit together well with the contents of the window.
Recently, I tried to find a new window decoration that looks good with the colour scheme I’m using for my applications (the “Norway” scheme shipped with KDE). None of the decorations I could find (via GHNS) matched the contents of the windows, so I had to stick with Oxygen.
I think that it’s more important for the contents of a window to be consistent with its decorations than for the decorations of different applications to be consistent. Also, you can’t stop people from writing crappy applications and there’s no point in even trying. People deal with those applications by not using them. Experience suggests that this approach pretty much works. X applications can do all kinds of crap, like moving other windows around and yes, they can draw their own window decorations too. But they usually don’t, because developers realise that it’s a stupid idea.
I am not really familiar with a compositor but if it is really that important to have a consistency between the top edge (assuming the title bar is above the window) of the window content and the title bar, isn’t it possible to just let the compositor calculate the color of the title bar according to the color of the window content??
I think, the server can adjust the SSD based on the window contents.
The server will have to re-calculate the decoration colour, each time the client repaints the window contents.
It’s a kind of Ambilight Decorations (Ambidecos??)
😉
Martin – I see strong arguments/feelings for both CSD and server side – can there by a hybrid approach? Or if that is too difficult/messy, let us have both types of compositors – CSD and server side, and just make sure both are equally well developed – it’s not like there is not enough people who want to see Linux Desktop succeed.
I love the lively debate, people have valid opinions on why both are flexible/inflexible 🙂 – can this coexist? I hate when things degenerate into either/or types of arguments unless there’s a reeeeally overwhelming reason to do one over the other – technical primarily…
It would be great if KDE add an option “Use server side decoration” so the user can choose.
I think you are missing a point. It seems your preference of SSD is the ability to enforce a window border standard, and you see CSD as a shift to allow unneeded and undesirable variation. I see it totally different. CSD is a way to enable a more efficient protocol and to allow graphics toolkits to decide what the boarders would be, and how far developers can customize.
So to sum up, enforce your window boarder standards at the graphics toolkit layer, allow the compositing/input protocols be as efficient as possible, and realize that you will not be able to determine if there are CSD’s or not with wayland.
what if the environment doesn’t want borders (e.g. Window Tiling or Plasma Active).
you (or someone) already said Qt would provide a way to disable decorations. Problem one solved.
That does not mean you will be unable to control the windows, either. Qt could provide a programmatic/scripting interface for that, or an extension to the wayland protocol could be made which allows it.
Shouldn’t the user get to choose ? There will be people preferring one or the other.
The compositor could signal the compliant app(global default + optional per-app-setting), that the user prefers server side decorations and it would simply skip drawing the client side decorations.
Rather than having the religious war that has been raging for quite a while now, this would place the decision in the hands of those who should have the final say in how their desktops work.
I haven’t followed wayland’s development sufficiently closely to know whether this protocol signal i would like to see would skew input redirection or other bits and pieces, but it should still be doable with rather limited complexity overhead in exchange for plenty of freedom of choice..
my two €-cents
MaxxCorp
I think your fears are justifiable… now that FOSS is wining is torpedo time.. lol.. seriously lol… divergent pushes can be more effective than legal advertizing or trade blocking… and its all done for the good of the cause !!… lol
Anyway, i can’t find a valid reason for Wayland, besides being an Intel sponsored project(!$) .. Wayland is YAWS (yet another windowing sytem), nothing more nothing less, and it doesn’t bring anything new or indespensable…
There is nothing wrong with X per see… it only needs to shed all the driver clutter to other mechanisms (kernel & userspace).. and have a good but minimal support for GL composition(its close now)…
In that prespective what X12 (?) could have is good support for “proxy” servers, and in this case can’t find better “natural merging” than X with NX, since X is still one of the leanest and fastest (the fastest IMO) “network” comunication protocol around…
So a “windows manager” shouldn’t be the “main” GL composition engine either, but a complement to X… eeeh!!… likea proxy lol… what should be the “MAIN” GL composition engine is “PLASMA” itself IMO !!…
Favorable arguments – all elements inside a desktop would be 3D accelerated even the 2D elements.. and in this particular every PNG icon being animated with dynamic effects (including sound) …
For Tablet/Mobile (including here superphones)… THERE IS ALREADY A LIGHTER VERSION OF X… and being (should be) the main GL composition engine Active (plasma)… it could very well dispense with Kwin or have a very light version, that would be a “CLIENT” of plasma and a proxy of X, not the main kauna lol…
Perhaps wrong idea.. perhaps not… but even for “mobile web acess” instead of http… what about X ??… what about “http over X” ?..
… main connection is a REAL point-to-point connection delivering a “minimal plasma environment” virtue of X (server rendered… or load balanced ala NX).. and your wallpaper “IS” your web browser, with no windows to manage(virtue of plasma).. but with plasma elements(plasmoids) for the necessary menus tollbars tabs etc … this would be a real WebOS… with the right network approach…
Mattre of fact “ALL” the boxes inside an application window (example dolphin) should be “plasma spaces” or “plasma boxes” !… … in the example the “application” presents a box with the icons of files and folders of a FS place … why should it be different from the “Desktop” itself that has no windows ? … and those icons inside “dolphin” or “konqueror” could be animated with 3D effects and sounds like they could be on the main “desktop”… and who says the icons can ALSO say all the tool bars and menus -> this would be a REAL uniform look&feel, and implies that plasma is not only an engine for desklets that replace the traditional “user home” folder view into desktop, but the big kauna of all 3D rendering… and Kwin would have a secondary role in rendering (if any at all)…
Then Kwin could have all the CSD it wants that it doesn’t matter a bit… since it wont touch what makes a real uniform look&feel.
So in this “vision” the “favor” CSD arguments are null and void… up front everything is 3D, and textures inside a window are rendering only one at a time since Kwin is not the “engine” but a client or proxy… matter of fact in the above WebOS vision there is no need for Kwin.
So what *NOW* is pushed as no good and or unfit… could be the REAL NEXT big killer app… namely the “X protocol”… only needs to shed clutter and marry what it lacks, which is not 3D composition (X never was designed for real 3D) and which it doesn’t have to be (with something like plasma for the job)
I don’t know where to start from to do a proper answer to your post. So many things are wrong. You really need to learn how X, Wayland and a graphical toolkit work. I recommend you watch this : http://mirror.linux.org.au/linux.conf.au/2013/mp4/The_real_story_behind_Wayland_and_X.mp4 and maybe come back later.
see above