as you wanted to have a mail with all my concerns about client-side-window-decorations (CSD), here is a very long mail presenting all my concerns what will not be possible any more with CSD and why I think that these particular features will be impossible. The list is based on KWin’s current feature set.
Please see this mail as an offer to help. I could also just say “what do I care? We won’t support it in KDE, so let them destroy their desktop if they want.” But I do care. I do not want to blame your work, but I fear that you just don’t see the disadvantages and that CSD will be pushed onto the users without considering all pros and cons. That’s why I decided to CC the Ayatana mailinglist and publish this letter as an open letter on my blog. CSD is a topic that is important for every user and nothing we should discuss in a small group.
As you probably have noticed I oppose the introduction of CSD. I think they will have more disadvantages than benefits to the user. In fact I do not see any pro argument for CSD. All the pros I found during hours of research on some wiki pages, GNOME Shell design documents, blog posts, etc. do not give one valid reason. In fact most of the pro arguments are already present in KWin. I will refer to the arguments for CSD again at the end of my mail. If there are any other pro arguments not recorded on the Wiki page, please publish them.
- Consistent window decorations: This in fact is my greatest doubt. The current situation is that all windows have the same window decoration. For CSD to work applications have to be changed to support them. This will render the changed applications using CSD while all other applications are decorated by the window manager. I think it is impossible to have the same behavior for both CSD and wm decos. I think there are lots of legacy applications which cannot be changed, for example Amarok 1.4 which is still used by many users even in GNOME. I doubt you will be able to change Qt 3 to use CSD. My bigger concern is that we will end up with applications shipping their own style and doing their own kind of decorations. So we end up with situations like one window has buttons on left, one on the right, one in order close, maximize, minimize, the other in close, minimize, maximize, etc. Why do I have this concern? Well let’s just look on the Microsoft Windows desktop to see what proprietary applications tend to do when they get the chance to influence the decorations. I expect the same thing to happen on free desktops as we already have such style issues with proprietary applications. For example Google Earth and Opera both do not use the default Qt style but ship their own one. In case of Google Earth it’s even bundled with an own Qt copy so you cannot even overwrite the setting. I also expect that “free” software will do such issues – to get a famous example: launch Chromium in Ubuntu Lucid. It has the decoration handles on the wrong side. And for the user experience this is very bad.
Now I want to explain why it is impossible to have consistent decoration handling between CSD and wm decos in the case of KWin. KWin has a default button layout (Menu, sticky on the left, (help), minimize, maximize, explicit spacer, explicit spacer, close on the right), which is hardcoded into the source code. The layout could change at any time if the KWin developers and the usability team decide that there is a more usable layout! Each decoration plugin is allowed to overwrite the default button layout (which is done by the default decoration Oxygen). In case of my theme engine Aurorae each theme is allowed to overwrite the default layout. However, that’s not all – the user is allowed to customize the layout. So to get it right CSD would have to check which decoration plugin is loaded and would have to know how the button order is defined. As this layout is also hardcoded this is just impossible. The CSD would have to guess KWin’s default layout and check KWin’s settings if the user has changed the layout. I doubt you want to add KConfig support to GTK CSD. The whole situation becomes more complicated if a user is using Compiz in KDE. In that case the CSD would have to check if kde-window-decorator is used, which would require to parse the KWin settings or to read Emerald or whatever. Let’s just forget about other window managers as the point is already obvious: a client-side-decorated window cannot know how the layout of decoration buttons in the window manager decorations is set. In order to get CSD working properly all windows would have to use CSD and as said before this is just impossible due to legacy applications. There is one more important thing to know: KWin guarantees binary compatibility for the decoration API for the lifetime of KDE platform 4. We cannot change the decoration API in order to support CSD without breaking BC and all decorations!
- Closing hung applications: Currently there is an easy way to close a hung application. You click the close button in the decoration and the window manager will notice that the application does not response any more and will offer to forcefully close the window. With CSD this is impossible. The close button is part of the hung application and so the click event cannot be recognized. I do not expect users to know shortcuts like ctrl+alt+esc to forcefully close a window and so they will be stuck with an unresponsive application. In case the application is caught in an endless loop this would render the system unusable and an unexperienced user has only one choice: force the system to reboot by the power switch.
- Consistent user actions between decoration and task manager: KDE keeps the context menu of the decoration and the tasks applet in sync. It uses the same order of options, the same look&feel and the same wording. If a change is required it has to be manually submitted to both menus. I can’t see how a non-KDE application wants to be in sync with KDE’s context menu. I don’t think I have to mention that the context menus are currently all using a Qt style. As we all know GTK does not look like Qt in KDE. So there will be a visual inconsistency in context menus. (Seems that I mentioned it nevertheless) Btw different window managers offer a different set of features. So one menu for all window managers just doesn’t work.
- User actions menu in general: This brings us to the next topic: What happens in response to right clicking a CSD. KWin by default shows the user actions menu including KWin internal options like window tabbing (if the decoration supports it), opacity and the option to configure the window behavior. Will a CSD be able to populate KWin specific options? How do I access the window behavior settings from a client side decoration? What happens when I use the shortcut to show the menu (alt+f3) which is handled by KWin? Why is it a different one for CSD, while it is the same for all other windows? Another case of inconsistent behavior.
- One place to configure mouse actions: Another point directly motivated by the one before: what actually happens if I left, right, middle click the decoration. KWin provides completely configurable actions in the user interface. I wanted to present all possible options but there are too many, so I just write down which different actions are supported:
- doubleclicking the decoration (just titlebar, not border)
- mouse wheel the decoration (just titlebar, not border)
- different settings for what happens when you left/right/middle click the decoration (titlebar and border) for active and for inactive window.
The settings include things like open context menu, place window to the back, raise window, start window tab dragging, etc. etc. If you want a complete list of options please have a look on the settings. I do not see how a CSD can know about what is configured in KWin. This just has to result in inconsistent behavior and complains by users because right click opens the context menu and does not move the window to the back.
- Different settings for the maximize button: KWin supports to configure the action which should be performed when left/middle/right click the maximize button: maximize horizontal, maximize vertical or maximize both. This is an issue where I ask myself: will this be supported at all and of course the same as above: the CSD cannot know KWin’s setting.
- Differentiating between window and decoration: KWin currently supports different actions when you click the window and the decoration. E.g. it’s possible to raise a window by clicking the titlebar, but clicking the window content will raise and activate it. As there is no decoration provided by KWin any more this functionality would be lost completely. Removing title bar actions means that many useful features are lost, like wheel on titlebar raises windows or changes opacity. You don’t want that functionality in the window as the window needs the wheel event to scroll the content.
- Window Shading: window shading is a tricky operation for CSD and I don’t see how you could get it working. I just had a look at the KWin code and it seems like window shading requires wm decos. The window get’s unmapped and only the deco is shown. I don’t know how KWin would behave if the window is undecorated, but I think that window shading is not possible any more. Even if it were possible we would have again a very inconsistent behavior as the decoration handling would switch from client-side to wm. To this point I want to quote the NETWM spec:
Some desktop environments offer shading (also known as rollup) as an alternative to iconification. A shaded window typically shows only the titlebar, the client window is hidden, thus shading is not useful for windows which are not decorated with a titlebar.
- Adding additional buttons: KWin allows to add additional buttons to the decoration. Our default decoration provides buttons like keep above, keep below and shade. By default a sticky button is used. Our default layout has more buttons than all the decoration themes provided by Ubuntu. I am very concerned that CSD will not have the same set of buttons and that it is not possible to globally add/remove buttons as it is possible today. The reasons why that is not possible have been presented in the fist topic.
- Remote X-Clients: If a session includes remote X-Clients using CSD these will use the GTK style of the remote system resulting in inconsistency. Currently this works fine as remote clients are treated like every other client.
- Shadows: A CSD window will not have a shadow provided by KWin. Shadows are an important feature to distinguish the active from inactive windows. As it is not obvious why we cannot provide shadows for CSD windows I have to explain how the shadow works. Since 4.3 the decorations are able to paint shadows. This is a KWin internal thing: the decoration provides a padding region and this region is internally ignored for things like window snapping and to ensure that the shadow is not clickable (as the decoration is a widget this is important). Currently Oxygen and Aurorae are the only default shipped decorations making use of this feature. If a decoration does not provide it’s own decoration the shadow effect will draw a shadow. There is exactly one variant of shadow to suit them all. And this is just impossible. If you have a dark widget theme a dark shadow is a bad idea. The shadow is a texture which is painted below the window texture. This means if the window has an alpha channel the blending will be done to the shadow and not to the windows below which looks really bad. Just search for images showing a translucent Konsole in KDE 4.x with x < 2. Now I still haven't mentioned why a CSD decoration won't have a shadow. We see why it would be a bad idea (as you want to have an alpha channel) but there is more in it. I assume that you want to have round corners in your decoration. So you have to set a shape or your corners will be clickable (bad idea). If a window has a custom shape the shadow effect will not apply the shadow to the window as it doesn't know the shape. We could just paint the shadow but in most cases it would look really bad or we could find some tricky logic that looks where the window is painted and how to draw the perfect shadow. We haven't found a solution to this problem during the last 2,5 years and I do not expect that we find a solution to this issue in the future. It would require shaders so it is not an option which would work for all users and I think that the shadow inside the decorations is the better approach. Oh and what we currently do to decorations cannot be done by windows as that requires changes in the NETWM protocol and in the window managers. As you might guess I am not interested in spending time on adding stuff to KWin required to make CSD work ;-)
- Tooltips: KWin has a setting to provide tooltips when hovering decoration buttons. I do not see how this can be consistent between CSD and wm decos. Obviously the tooltips won’t look the same as the one is GTK and the other is Qt. Furthermore I don’t think that the titles of the tooltips can be the same and even if they were the same I don’t think that they would be translated in the same way in all existing languages. This is another case of inconsistency.
- Netbook mode: KWin has a special netbook mode to hide the decoration for maximized windows when the netbook mode is chosen. I do not see how a GTK CSD window can honor such a setting.
- Accessibility: KWin provides globally customizable border sizes. Some decorations (Oxygen and Aurorae) also provide customizable button sizes. Both sizes are dependent on the decoration or in case of Aurorae from the theme. So there is no way for a CSD to get the same border size. I think accessibility is a very important feature. In fact Aurorae allows to change two settings: border size and button size, everything else is defined in the theme.
- Window Tabbing: KWin’s window tabbing is part of the decoration API. A window which does not have a decoration cannot be included in window tabs. So it destroys a useful functionality.
- Numbering in window title: KWin provides a feature to number the windows. So if you have two windows foo, the second will be called foo <2> in the decoration. This is specified in the _NET_WM_VISIBLE_NAME hint, so in fact it is possible to implement this feature.
- Forcefully adding buttons: KWin allows to add buttons to window decorations even if the window does not provide the action. E.g. if a window is not closeable we can force it to be closeable by a window rule to get the button back. My concern is that with CSD the application would not add the button again as it has in the internal logic that there is no close button for this window. The same obviously applies for maximize button, etc. KWin allows to overwrite any of the settings a window might set, which is the right of a window manager.
- Changing themes: KWin and also Metacity allows to change the themes for all window decorations at one place. If we introduce CSD we have some applications having a wm themed decoration, some applications with a GTK themed decoration and some with a Qt themed decoration. If we introduce CSD the current setting dialog is more than confusing and would have to be removed. Btw I just want to mention that I rewrote the KWin decoration selection module for 4.5. More on the work going on in KWin regarding decorations later in this mail.
- Probably much much more I just have not thought about yet or forgotten to mention in this list. I think the point is obvious: we have a well established system and there have to be good reasons to change something so fundamentally to the window behavior.
This brings me to the next topic: The pro arguments of CSD. The point is: I do not know of one pro argument. I thought a lot about why do they want CSD and all I can come up with is that you want RGBA windows, but this is no reason to go for CSD. This is perfectly possible with KWin since 4.4, so I do not see why you would want to go for CSD. If there are other reasons please communicate them. And please use this list as a starting point to step back and think about what you want to achieve and if CSD is the right approach to achieve it. If all you want is RGBA it will be easier to extend Metacity to support it or (in case of Canonical) switch to a default window manager which supports it. I assume that Ubuntu 10.10 will be shipped with Compiz 0.9 so you could get a window manager which supports both non-compositing and compositing and alpha in the decoration. And I just want to mention that Ubuntu has another window manager in the main repository which supports all the required features, but I don’t expect Ubuntu switching to KWin as the default window manager 🙂
So let’s look again on the list of pro arguments on the GNOME wiki:
- Fix issues with the non-reparenting window manager Compiz: Not an issue any more as Compiz 0.9 is a reparenting window manager. Nice this one is done
- Have a good reason for RGBA: As mentioned KWin supports this by extending the window decoration behind translucent content (http://blog.martin-graesslin.com/blog/2009/11/window-decoration-behind-translucent-windows/). So you could go for this approach. Just as a note: KDE does not make use of this feature, but it is supported. so not valid.
- Possible performance improvements: please test if it is really an improvement. Considering KWin’s approach to RGBA decorations I don’t think it is. Just the idea that there could be improvements is not a valid argument.
- single source for theming the application and decoration: that would be nice, but as my concerns in this mail show, the opposite is most likely true. I love that idea, but could you please first fix GTK to use the Qt style in KDE environment? That would be nice from an integration point of view. So not valid.
- Get gtk+ working on Wayland: I don’t see how Wayland can be an argument for CSD. Could we consider Wayland as unimportant till it is looking like something is actually going on? I checked the commits in 2010 in the public git repository and well it looks like KWin has more commits per day. It’s nice that you think of the future, but please don’t use it for argumentation. So also not valid.
And that’s the problem I have with CSD. I have a very long list of issues, so to say the cons and there are no valid pro arguments. I like innovation, but I completely dislike innovation for the sake of innovation. I also dislike to break with existing solutions. If we break existing solutions there has to be a good reason for it. And here I am still missing the good reasons.
Now last but not least I want to present some of the work going on in KWin for decorations. Decorations are currently the most actively developed part of KWin. In 4.3 we added support for translucent window decorations, in 4.4 we added support to paint decorations behind translucent windows and we received window tabbing support. Currently there is a very active development in our default decoration Oxygen and in my theme engine Aurorae. I initially implemented Aurorae for 4.3 to have a decoration which makes use of translucency. Since 4.4 Aurorae is part of KWin and I have spent much time on improving it for 4.5. So it is now based on the Qt GraphicsView framework, it allows to place the decoration to the left or right to make better use of vertical screen space. The theming support is improved, so it’s possible to have one common background for a button group. That’s something the Canonical designers might like – in fact this feature is inspired by the brokeness of the new Ubuntu theme during the beta phase of Lucid 😉 I started to work on a designer application for Aurorae themes. The decoration configuration module has been reworked and allows to directly install new themes for kde-look.org through GHNS. I have some more ideas for Aurorae in 4.6. So I want to make the decoration auto-hiding for maximized windows to save more vertical space. I am thinking about adding a special element for fullscreen applications to easily switch back to normal mode. I plan to make Aurorae a common library which can be used not only in KWin but also directly in Compiz. In fact the Aurorae code does not have a KWin dependency any more. This was required to get the designer work and is also used to render the previews in the configuration module. I think it would be a pity to abandon all this work and to replace it with something that is not on par from the feature side of view. And AFAIK also in Metacity there is some work going on to design a new theme format.
So as expected this mail has been rather long and I think I missed probably have of the points I had in mind. Thanks for taking the time to read it and thinking about if CSD are the right way to go. If you have questions how to get your wished features to work with existing technology please do not hesitate to ask and I will try to help you. I am sure the Compiz devs will also offer their help to get required features implemented.
39 Replies to “Open Letter: The issues with client-side-window-decorations”
Wow that’s a long post – but a convincing one… I don’t want these clientside windows decorations anymore after I read this :-/
To everyone who just read the first paragraph and then skipped to the comments: Please read the blog post, it’s really worth the time… I dunno how long he wrote it but it has to be hours! :-O
something like three hours
And those were very well spended three hours!
Thanks for such blog post what was not a short version with unexplained opinions and rant. Good to see that there is more such people who like to spend time for what they want to say. I learn lots of things about KWin because this and I believe many will as well.
Thanks for your article, I wasn’t even aware of some of the great features of kwin, even after using it for years, e.g. right/middle-clicking the Maximize button… that’s really useful!
Being a fairly happy Kubuntu user so far, your article does make me nervous about these CSDs. I’ll definitely keep watching the arguments of both sides, but so far I find the whole idea of CSD rather annoying (I say this even though or maybe because I am a fulltime chromium user).
Wow, me neither! Kwin will never stop surprising me. Each day I discover a new feature, whereas conversely Canonical and GNOME remove a new one each day, and impose unwanted features the other, marketing them as necessary innovation. This post was so informative, thanks for sharing your thoughts! Please, do not let that infection spread all over KDE…
Right/middle clicking on the maximise button for vertical/horizontal maximise also works in GNOME (Ubuntu Lucid) although I don’t know if one can customise the action per button.
“Please see this mail as an offer to help. I could also just say “what do I care? We won’t support it in KDE, so let them destroy their desktop if they want.” But I do care. I do not want to blame your work, but I fear that you just don’t see the disadvantages and that CSD will be pushed onto the users without considering all pros and cons.”
I must say that is right attitude!
We all need to take care of each others. We need to take care of our neighbors children’s, others parents, our neighbors and our friends.
We need to take care as well GNOME as we take from KDE SC. We need to stand now together against Canonical for their purposes to support only their own market share. We are one big community and not just developers or clients for Canonical.
If Ubuntu fans can not see the terrible effect what this would do for the whole community and how it would make Canonical stronger by expensive of others.
Haven’t found on https://lists.launchpad.net/ayatana/threads.html
Could you please provide a link to the mailing list thread?
I’ll post a link as soon as the mail is available. Seems to be in a moderation queue, although I have not received a notification mail, yet.
Very well said.
I believe this is all in reseponse to Mark Shuttleworth’s proposal of window decorators, and a lot of people assumed that meant Client Side Decorations.
From http://www.markshuttleworth.com/archives/333 last paragraph
“Under the hood: d-bus menu transport
The technical approach we are taking in this work is to build on the d-bus menu work that Cody Russel and Ted Gould have pioneered for our work on indicators.”
That doesn’t like CSD to me.
That may be a later edit by Mark, or it may have been missed by you. I don’t know, but it makes this ‘open letter’ less important.
On a personal aside surely:
If a program wants to draw stuff in the window bar, the cleanest approach is for them to draw the window bar. Sure you lose consistency between task manager and window bar, but you gain consistency between the app being run and the window bar. Every argument has an alternative side.
*shrug* – it all seems like it’s a non-issue anyway.
Sorry, I copied that quote from the wrong place (an article about “global menu”)
however, my point remains. It’s in the comments of the place I linked to:
Mark Shuttleworth: Yes, you’re right, that’s the right approach. I wasn’t clear, CSD provided the *inspiration* for giving that space back to the application, but this should be supportable with standard themes and window managers that watch d-bus.
Yes, but nevertheless they want CSD. It is completely unrelated to windicators. Mark mentioned on the IRC interview that they will ship RGBA windows and that means in the GNOME world currently CSD.
Yes windicators do not imply CSD. Nevertheless Canonical wants to ship CSD, in fact they already wanted to ship it in Lucid.
CSD would be very bad in usability point. You would never have same UI for whole environment and THAT is such point what can not be braked anyway. If we want easy to learn and easy to use environment, we need to stick on that basic idea that everything what belongs to same thing, works by same way.
Window management should work with same principles and ideas. CSD does not offer anything what would help the user. If application developer can not follow the usability guidelines, then the application should not be even be offered.
You have demonstrated, at the same time, why CSD are a bad idea and why KWin is superior to the other WM’s out there.
I think the idea here is that apps can have their unique look while using system libs and being light-weight.If an application wants its to have its unique look it would still have it but could behave badly(*cough* Mozilla XUL based apps*cough*)
kwin is a really a great window manager. Thanks for your time and effort in helping make kwin great and writing this blog too.
While I totally agree with your statements about CSD, thought I might just clear up this misconception between both the GTK and KDE devs about Compiz and reparenting decorations:
“Fix issues with the non-reparenting window manager Compiz: Not an issue any more as Compiz 0.9 is a reparenting window manager. Nice this one is done”
I think that the issue they are trying to target here is the fact that there is a a visible tear between the window decoration and the window area when using effects like wobbly. Although we are reparenting now, you will still see this issue because we only reparent into an non visible window and the decorations are still drawn as textures on the screen by the decoration plugin (and not by the decorator as a window itself, where the client is reparented into it.
However, I think when we start having the window decorator drawing the background of the window this will go away.
Also, I believe that ubuntu wants to drop CSD anyways in favour of rewriting gtk-window-decorator in compiz and more importantly the ancient metacity decoration interface to support real widgets in decorations.
ah so that’s what they mean with it. Well kwin has the same problem in wobbly, but it is hardly visible and probably it’ better to fix the wm or turn wobbly of 😉
For me, as a NVidia GeForce 8600 user it is rather regularly than hardly visible on KDE 4.4.2, so I don’t think it’s such an uncommon problem. Not good for the user experience anyway.
I think we do not even have a bug report for it, which is in general a sign that it does not affect many users. In fact I even worked on it some time ago and hope to be able to tackle the issue with rewriting some parts of the code for 4.6
There are some kinds of action which should not be implemented by normal applications. A normal application should not listen for alt+tab and look for another window, even if there would be a comfortable library. And a normal application should not manage moving, closing, hiding, keep on top, etc. actions itself, these are actions which cannot be imprisoned into the abstraction of independent windows, this blog-post explained the problems (hanging applications, rollups…). There is a program called window-manager having the power to manage such stuff like a semi-god. CSD-fans say that the title-bar needs to much space which should be used by the application. Did I speak about a title-bar before? No, there are certain actions which have to be displayed by the window-manager in a certain form. Title-bars are one possibility taking some place, but the window manager could also use shortcuts-only, hidden Plasma-panels, actions in the middle of the window or twinkle-detection using the webcam. Obviously there are good ways to do it and there are bad way to do it. And there is a lot of innovation, there is no longer a title-bar, there are actions display somewhere, e.g. in combination with window-tabs or have a look at the Plasma-netbook-mode. And it is always connsistent. It is up to the wm-developers to implement more flexible and more powerfull user interfaces for certain actions, not to provide libraries to create inconsistent interfaces.
What about kscd? i can’t get my kwin menu by right-clicking the title bar…. And your telling others they can”t provide such apps while you are doing it with your KDE SC?
“Why do you look at the speck of sawdust in your brother’s eye and pay no attention to the plank in your own eye?”, Matthew 7:3
Yes KSCD is a perfect example why you should not do it. Luckily nobody is using KCSD any more, because the use case is non-existent any more in the time of mp3. Unfortunately I do not have the power to remove KSCD from KDE SC.
Speaking of which, is there any reason CD playing can’t be included in Juk?
KSCD has always felt really ugly, whenever I have the curiosity and misfortune to open it :/
Thanks. Nothing more to say, except that I’d like to read a posting of the opposing side, supporting CSD. There are always two “point of views” to look at.
This post (hmh, article?) was really great and very interesting to read.
I’d like to read the same. I can give you a summary on the posts/notes I know off:
Blog Post on Planet GNOME: http://www.hadess.net/2010/05/client-side-windows-and-misconceptions.html
Wiki Page to CSD: http://live.gnome.org/GTK+/ClientSideDecorations
GNOME Shell Design Paper – sorry no link for that, but easy to find
Of more I do not know and that’s one of the reasons why I wrote the post: there are no arguments for implementing CSD.
Well said, I think the world had enough of Canonicals “innovations”….
Raster here – from the enlightenment crew. I’m with you 100% on this. canonical are going entirely the wrong way. X11 != windows gui. the fact we can move windows even if the app is hung with a quick drag on the titlebar… is because we DONT do client-side decorations. the whole concept throws the baby out with the bathwater.
if kde want to do something – a sane standard involving properties, client-messages and so on to have the wm display “indicators” that can show some sort of state, even be interacted with (with little popup sliders, menus, whatever), so long as these elements can be made to display in a consistent way with the rest of the wm (as opposed to toolkit the app uses), then i’m all in on supporting that. it’s a sane way to go.
Hell yeah, Raster!
If there’s anyone that’s demonstrated the power and flexibility in server side window decorations, it’s the enlightenment crew.
The inconsistency of the windows desktop these days is a hideous hideous disaster. Fight all attempts to move us into that direction.
Yes, enough of Canonical’s “innovations”.
they should stop copying mac os x and start looking at gnome 3 release plan if they want to help
Thank you for posting this, Martin. It’s much more specific than your original post on this topic.
I have a simple question. Chromium uses a custom title bar and windowing controls, even when running with a window manager that does not use client-side window decorations — for example, Metacity in Ubuntu 10.04. Do the problems you describe already exist in Chromium? If they do, then how can client-side window decorations possibly be the cause of those problems?
Yes they all exists with Chromium at the time. E.g. you cannot use window tabbing, Chromium doesn’t honor the titlebar positions, it has a completely inconsistent UI, etc. etc. Chromium has it’s own kind of “client-side-decorations”. The only difference to the CSD proposed by the GTK developers is, that it is just one window instead of several windows drawing own decorations.
So I cannot answer your second question as the one doesn’t imply the other. Chromium has a kind of CSD which shows us the problems we will have as soon as all applications move the window control into their window. That’s why I always mention Chromium as the example: it’s the only commonly known application which uses “CSD”.
Even though it took me several days to find time to really sit down & read your blog post, it was well worth the time. Thanks for that.
Please follow up on any responses you get from Canonical; even though I don’t use their flavours I’d like to follow this discussion.
PS: I hope Chromium will gain the ability to use KWins tabbing, at some point.
You’re so right. This is full of shit!
All good we could possibly ever get from this: First-class tabs in the window-title-bar like Chromium.
But I guess this would be possible by a “grouping” option in the WM.
Either way, NOT worth all the drawbacks.
hi i want to put image in place of titlebar minimize,maximize button.
will u help me
I recommend you to have a look at Aurorae as this does not involve development at all. I will not give any comments to coding in comments on a blog post. There are more suitable systems to ask such questions 😉
Comments are closed.