So finally I know who had the idea of client side decorations: it’s Canonical. Why didn’t I think of it before? I have been aware of the fact that GTK wants to do client-side window decorations since it was mentioned on the EWMH mailinglist and I think it is a completely stupid idea which has the potential to destroy one of the most important advantages of the free desktop: a consistent client handling.
For those who don’t know what client-side window decorations are: the window client, that is the application draws the titlebar instead of the window manager as we have it today. I will discuss the disadvantages of this approach later in the post.
Up to today I have not found any valid reason why you should even think of client-side window decorations. Well Mark provides a reason: windicators. A kind of Statusnotifier inside the application. As the window decoration cannot do it (today) it is the logical consequence to remove decorations. It would not have been possible to extend an existing framework.
Well to be honest we get request to add arbitrary functionality like a mute button in the decoration about once a month. And we always say no, because it is not possible as there is no common interface. With something like a dbus protocol these "windicators" would be possible, not that I’d think it’s a good idea.
But apparently Canonical did not think of extending the existing functionality, but to remove the functionality. There is already one application which uses those client-side-decorations and it’s called Chromium. If you want to have an impression on the consequences of client-side decorations, just go through all open KWin bugs and look for the mentioned applications. I think you will know which one is currently my most loved application from a wm-dev perspective.
So what will we lose due to client-side decorations?
- Consistent behavior between all applications no matter if it is a Qt or a GTK or $Toolkit application
- Window Tabbing (KWin specific)
- Window rules like always show a close button even if the window is not closeable
- Accessibility features like big border and button sizes for all windows
- Easily changeable window themes
- Shadows which are part of the theme (KWin would not paint shadows for a client-side window-decorated window)
- …
In general up to now I always read of the same advantages, like it saves space. But that is just not true. The KDE Plasma Netbook Shell illustrates in a perfect way how we can use space more efficient. I also have some ideas for Aurorae like decorations on the left/right (implemented) and autohiding decorations for maximized windows (due to upcoming feature freeze probably 4.6). Also I think that Rekonq is a nice example to show how we can use the limited vertical space in a well thought way. Yes I agree that statusbars are somewhat useless and outdated, but just look on Rekonq’s clever behavior for statusbars. Or think of KDevelop’s (congrats to the release, I love your application) usage of the empty space next to the menu bar. Of course we have some problems of space wasting, but that is no reason to break with working solutions.
To summarize: client-side-decorations will destroy more than they benefit. Please devs at Canonical, please think of the consequences. Please think about the fact that you have to change all applications, please think about that your Upstreams might not like the idea, please think about more than one or two years. Please have a look on the Microsoft Windows platform and the totally inconsistent window behavior. Think about how the free desktop could look like if we start to use client-side decorations allowing each program to enlighten us with their preferred idea of window management. If we get client side decorations, Mac OS will be the last useful system with a consistent behavior and I think we can agree that this is not a nice few. Please remember that a window manager is called a manager, because he manages the windows. I do not like to see mistakes fixed ten years ago in the window managers to be present again (what about a drag delay in moving windows on free space in the new Ubuntu GTK theme?).
As far as I followed the small discussion on the EWMH specific mailinglist, the idea is that the window manager has to announce that client-side-decorations are allowed. This means that we as KDE have the option to not implement this "feature" so that our desktop will still have a consistent user experience. It’s also our chance to raise the concerns again when it is discussed on the mailinglist in more detail (which has not happened, there has not been any discussion, if we want client side decorations or not). Given that Metacity is developing a new theme engine, I hope that also the GNOME community opposes such ideas.
I also hope that Canonical will start to discuss such ideas with their upstreams. There has been no discussion about NotifyOSD and their removal of actions. With the "Panel Indicators" I though that Canonical mastered this part of their history and starts to collaborate. Now it looks like alea iacta est again, without any chances for the upstream to raise concerns 🙁
=-=-=-=-=
Powered by Blogilo
I think we have to talk to Aurélien and/or Jonathan ASAP before they even think to implement this crap on behalf of their employer.
I don’t know if it’s possible, but could the title bar and statusbars be made to use only part of the window by the wm? And could they be made to auto hide and be painted on top the main frame of the window?
I remember seeing, in Adobe Reader I think, something like it – the statusbar with pointer place info would fade in and out when the cursor came to the lower left corner.
About the autohiding: as mentioned in the blog entry I do plan to add something like that in Aurorae. If it works well that could be moved to the decoration library so that it can be used by all decorations.
Completely agree. As for Chromium, I keep it with ‘use system title bar and borders’ option set on.
Cheerio!
I believe that client side decorations are better, since there will be a single place of theming. Currently we have two – one in window itself, and one in window decoration. It causes problems with consistency right now (yeah, the consistency you’re trying to defend so hardly). Look at KDE default theme, Oxygen. It draws a nice looking gradient in a window decoration. It’s fine with Qt apps that draw their window with the same theme, but not with GTK – there is a cleanly visible difference between window decoration and the windows itself – and there is no way to make it look smooth.
Also, client side decorations will allow to put various things to the decoration (like in Microsoft Office or Google Chrome). Currently Linux lacks any good way to do this.
Ideally, there should be a library, let’s call it libLinuxGUI, that should implement all theming and drawing of controls, windows decorations, and so on, and GTK and Qt should use it. Only this way real consistency can be achieved.
“It causes problems with consistency right now (yeah, the consistency you’re trying to defend so hardly).”
It does not in whole situation. Now you are looking only the app and wm themes alone. Only a very small single point.
What the blogger tried to say, is that we have now the whole workspace themed as one. Now, since begin, we have got a desktop what looks same. Only problems have been between GTK+ and Qt apps. But those have problematic because lacked API’s. Now with good styles, we can have GTK+ and Qt apps looking same. Example with QtCurve. The current only problem is that when you open the save/open dialog, you get the GTK+ or Qt version in KDE SC. Or vice versa. When we get that fixed (so that we get KDE SC dialoges in GIMP and Firefox) there is not such problems.
If every application starts drawing it own decoration and app theme. We end up to situation what is currently in Windows. Many applications looks very differently to each other. The usability is VERY BAD. Applications does not look to fit to each other at all when they have themed in client side. User has more problems to learn new applications because they can not have intuition so easily.
Example the MS Office http://cybernetnews.com/wp-content/uploads/2006/03/MicrosoftOffice2007.jpg and Nero http://www.brothersoft.com/screenshots/n/nero_7_ultra_edition-45110-1.jpg.
Those are just two examples how two very popular application looks very different. Even when Microsoft itself tried to make guidelines with Aero that every application use same decoration so they would look same. Not even themselfs follow those guides.
“there is a cleanly visible difference between window decoration and the windows itself – and there is no way to make it look smooth.”
Yes there is. Just go to Oxygen options and turn of the gradient. Then you can tweak it with colors to match KDE apps settings from GTK settings.
btw, how do you believe you could tweak the application match the whole workspace when every application rules alone their outlook?
That is just impossible!
“Also, client side decorations will allow to put various things to the decoration (like in Microsoft Office or Google Chrome). Currently Linux lacks any good way to do this.”
And what good is on them? Both suffers many usability problems. They does not look same for all other applications.
“Ideally, there should be a library, let’s call it libLinuxGUI, that should implement all theming and drawing of controls, windows decorations, and so on, and GTK and Qt should use it. Only this way real consistency can be achieved.”
There is no need. Just check out the current ways and you notice we already are there. I use themes what are available for both platforms (KDE platform and GTK+) and I have very seamisly looking workspace. Already what you suggest is impossible as well because GTK+ and KDE apps use different guidelines about UI design. You can not join both apps together anyway better way than already you get.
A mute toggle-button in the window title bar would be nice, especially if the window is rolled up. But I dont see a valid reason why the windowing manager couldnt do this. Just look in the X resources of the root window to find the pulse server and if there is a stream for the application providing that window show the button. Nice and clean, wouldnt even need a single line of change in any application. And everything else can be handled via dbus, so the desktop theme rules can decide if notifications will be displayed in the title bar or somewhere on the desktop (the notification plasmid for example). Apps should do as less as possible, so one can possibly set up to use an external notify method (like sending a sms for really really important things) without requiring changes.
Btw, I mostly use windows without decorations, no borders or title bar, to save space (panel it set to auto-hide) and focus my concentration, so any approach relying on a title bar will fail and a forced title bar will distract me (which is bad for work).
Mhh.. couldn’t the StatusNotifier API be used to implement this feature in the Window manager?
Maybe a flag for a Notifier Item like “show in window area”.
Also, the DBus Menu is coming, that could be used here as well.
I haven’t read any of the related Canonical publications but I also found the implication that windicators are client side decorations a bit strange.
As far as I understand the ideas behind the status notifier rework something like this is exactly what it solves, i.e. allow different hosts for formerly client side UI.
In this case allow the window managers to show UI on behalf of the client, thus achieving the same effect as client side decoration without having them
I don’t think all of your criticisms are completely fair, if (hypothetically) KDE had decided it wanted Client sided decorations, I imagine the first step would be to take the decoration drawing code and convert it into a library that the applications can use.
They would then all have a consistent UI (throughout KDE applications)
They would have all the accessibility items
I’m sure kwin could paint the shadows if there was an effort to make it do so.
And for all the positives – we could easily have combined menu and title bars, we could put application tabs in there, status’ all sorts of possibilities.
For Canonical to do it alone, I think we would end up in a bit of a mess in the ways you point out, and I agree it is a bit mean of them to roll something out without letting people discuss it, but that doesn’t make it a terrible idea.
It looks like QT did this already in “LightHouse”.
Annoytify-OSD would be horrible even with the actions. It doesn’t follow themes, has a fixed position and pixel size, can’t be dismissed, and stays up forever, or until it thinks it should go away (depending on CPU busy). It is huge and intrusive on my netbook screen, but when I plug in the HD it becomes tiny and almost invisible (dark theme, usually the window isn’t all the way to the right). I also don’t expect them to fix it anytime soon – you can find the launchpad reports.
This will stay broken. Grub2 will stay broken (I wouldn’t mind as much if they would actually work properly). These will be broken when they add the decoration breakage.
Shuttleworth is getting to be like Steve Jobs.
I’m already looking into alternatives.
Or we need a GNUbuntu that removes the shutlleworthless elements.
I think it is a insult to call Mark Shuttleworth is getting to be like Steve Jobs, against Steve Jobs.
Canonical has shown for years that they have some purposes to be “Microsoft in Linux world”. They want to rule how the “Linux world” works. What and how software gets developed etc. You can find proofs from Mark Shuttleworths own blog. And there have already been many collisions with the open source community when Mark Shuttleworth has said how he wants it to work. Example of the release dates that upstreams should follow Caonicals 6 months release plan. Then as example OSD what you mentioned. And now latest this client side decoration. And these three are not just the only ones. There is plenty of more when just looking the ubuntu forums and ubuntu fans/devs blogs.
And it is spreading like a fire in forrest among ubuntu users. You can find plenty of questions what has the point “Dont take Linux, it is hard and difficult and ugly. Take Ubuntu, it is easy and good looking OS!”. You get the idea.
GNU should already liberate us from Canonical and Ubuntu. People should start understanding that they are not doing good for the whole FOSS community. They do not work with upstreams, especially with the important softwares what makes Linux so great OS. They just use and does not even give credit back for them who does the biggest work. Example of Kubuntu and KDE. Where Kubuntu people thanks themselfs how they made KDE SC so stable and good. While forgetting totally the KDE! Many people have started to be very angry about Canonicals and Ubuntu community actions so they have started to avoid those at all costs.
Part of the open source was that we can discuss about the development together and plan how everyone can help the community and all other users. Because of Canonical, we have started to loose many great such features when they are raping the FOSS ideology for their own purposes what is not good for the community!
If Shuttleworth is indeed embarking on this attempt, he’s heading for a big fall. FOSS is ultimately a meritocracy. Nobody can dictate anything to users and developers. If things become unbearable enough, they will switch and patch and ultimately fork.
Uhm, no, the KUbuntu community are some of the most involved people upstream.
I disagree on the consistency front. There are all kinds of different conventions and styles on the desktop, and only a few of them are enforced technically. From fundamental things like “clicking on a button activates it” to the exact look of a menu. None of those things are enforced now by our current framework. They simply come about from conventions and using similar library code. Unfortunately, in the Linux world, we have this terrible balkanization between the GTK+ and Qt camps, but this is a problem we have to solve anyway. And indeed, much of the consistency Mac OS X provides does not come from Cocoa, but from Apple’s meticulously specified style guides.
The question isn’t “will things be inconsistent?”. The question is “can things be different when it is better?”. Application developers should be able bend a few conventions when it fits their needs better. To give an example, I’m fairly annoyed that Chromium does not have a nice KDE-looking title-bar, but I happily enable the client-side window border. It works much better for the app. Now, ideally there’d be some way for them to do this while matching the platform’s feel, as it does in OS X and Windows, but that’s hard without our balkanized platform.
We do not lose “Consistent behavior between all applications no matter if it is a Qt or a GTK or $Toolkit application” by moving things off to the client. We lose that with our balkanized platform. That we already have some semblance of consistency now is because we’re thankfully not balkanized to the point that “left-click to activate buttons” no longer is agreed upon.
Frankly, I think the KDE desktop will look more consistent with client-side decorations. Right now, Oxygen has this lovely gradient behind windows that requires coordination between the client and the window manager. This looks great, but clashes horribly with every other toolkit. (It also looks bad in GNOME.) I have to manually filter out the gradient on GTK+ apps individually. Were I using system window decorations in Chromium, I’d have a similar issue.
But if GTK+ and Qt were in charge drawing their own decorations, we wouldn’t have this problem. Qt apps would know that they should draw the gradient, and GTK+ apps wouldn’t bother. Sure, the two apps would look quite different, but at least they look internally consistent. I will take a hodge-podge of different but consistent apps over a melting pot of Frankenstein apps any day.
I submit that this means that poor application authors will have even more room for poor decisions, but poor application authors will do the wrong thing anyway. The solution to that is to make it easy to do the correct thing, and more importantly, judge this as a bug in the program. Trying to force it is akin to Apple’s decision to ban unofficial development environments on the iPhone. Indeed it should be harder to use client-side (or at least custom) window decorations. Unless you know you want them, the standard set (be they provided by the toolkit or the window manager) is probably what you want. The proper response to abusers be the same as if they implemented button-looking widgets that act wrong. But for the sake of the few apps which correctly use client-side decorations, the free desktop should not treat them as second-class.
I would argue this is a short-coming of KWin.
I think that client-side window decorations are the right approach. See http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html for the reasons why window managers were a big mistake.
Regarding problems with client-side decorations:
> Consistent behavior between all applications no matter if it is a Qt or a GTK or $Toolkit application
True – at the expense of inconsistent behavior/appearance between the application itself and its titlebar. For example, KDE applications seem to draw the background in a way that blends in with KWin’s titlebar background, but it makes Gtk+ applications look ugly.
Perhaps sharing a common library for drawing window decorations would be a better idea? They don’t need to be drawn by a separate process to be consistent.
> Window Tabbing (KWin specific)
First, it’s a very recent addition to KWin.
Second, does KWin have an API that would allow applications take advantage of tabs? Could Chrome use KWin’s features to implement its tabs instead of drawing the window decorations manually?
> Window rules like always show a close button even if the window is not closeable
I didn’t even know such a feature existed. In any case, what’s wrong with right-clicking the taskbar entry and selecting “close”?
> Accessibility features like big border and button sizes for all windows
Just have a common library for drawing the window decorations that supports all these features.
> Easily changeable window themes
Same as above.
> Shadows which are part of the theme (KWin would not paint shadows for a client-side window-decorated window)
Why can’t KWin paint shadows for those windows? Is there some technical reason?
> Consistent behavior between all applications no matter if it is a Qt or a GTK or $Toolkit application
“True – at the expense of inconsistent behavior/appearance between the application itself and its titlebar. For example, KDE applications seem to draw the background in a way that blends in with KWin’s titlebar background, but it makes Gtk+ applications look ugly.”
that could be easily fixable with some more communication between the windowmanager and that application, like “do you have my same style?” and abjust painting by consequence
> Window Tabbing (KWin specific)
“First, it’s a very recent addition to KWin.
Second, does KWin have an API that would allow applications take advantage of tabs? Could Chrome use KWin’s features to implement its tabs instead of drawing the window decorations manually?”
If is something that would be considered useful an api could be added, and even made it a freedesktop specification. That would be the proper way to do it, versus a quite dangerous “easy” shortcut
> Window rules like always show a close button even if the window is not closeable
I didn’t even know such a feature existed. In any case, what’s wrong with right-clicking the taskbar entry and selecting “close”?
keyword is “right click”
> Accessibility features like big border and button sizes for all windows
Just have a common library for drawing the window decorations that supports all these features.
> Easily changeable window themes
Same as above.
as long as comes an aplication that doesn’t care and it would do in its own completely custom way
> Shadows which are part of the theme (KWin would not paint shadows for a client-side window-decorated window)
Why can’t KWin paint shadows for those windows? Is there some technical reason?
i guess would be somewhat possible, but harder to get right and even harder/impossible to make it work with crappy video drivers (at least if you want rounded, antialiased borders with still a matematically correct shadow behind it)
If an application doesn’t care and wants to draw its own decorations, it can do it already. Why would a common library make things worse?
There are problems with trying to do windicators like libdbus menu in general as well (moreso in gtk than in kwin).
I think the main reason Mark wants to do this is because both metacity and the compiz gtk window decorator just draw a straight image to the window border and don’t have any concept of gtk widgets (and implementing them would pretty much mean rewriting both gwd and metacity).
Unfortunately, he seems to have forgotten that other desktops exist too and they already have methods for widgets in the window decoration :/
to those thinking it will increase the consistency: think about it. think about the fact that an application has to support it or the window manager will draw the deco. think about all those legacy applications and that there is no such thing as a libdecoration. think about that the deco buttons will look different cause different toolkits are used. think about all the proprietary apps wanting to use their branding in the app like we know from ms windows.
i’m not just thinking about these issue since yesterday, but for months.
I think Java AWT uses client side rendering to some extent and it’s a complete disaster.
Because of the way how they handle input it completely breaks usage of Java apps in Enlightenment (DR 16) and maybe some others (I heard complains from WindowMaker users). If you dare to resize the window painted by Java AWT, the “active” elements stays in it’s original position. I guess that it’s not very clear so I’ll try to describe it using an example:
I start JEdit (AWT application) and it doesn’t take all the space on screen. So I hit maximize button. The window is resized correctly. Now I want to open some file using “File” menu. So I hit File and… the menu opens and immediately closes. If I want to select anything in menu I have to move the mouse cursor to the position where the menu originally was and do it blindfold.
I’m afraid that this kind of bugs would become much more frequent.
We have so many problems in Linux yet they invent new ones. That’s just silly :\
>See http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html for the reasons why window managers were a big mistake.
Window Managers are a bad idea now?! I think not! I like having free choice of WMs, unlike in Windows and Mac OS. And some of the stuff in the Unix Haters Handbook was questionable as an argument a decade ago (even snarky and biased tone aside). Now about 90% of it is obsolete, plainly wrong or both (not that Unix or Linux is perfect or anything, but the UHH is not a good chronicle of its problems).
I fully agree. In addition to what you mention, I see a major problem with this that it requires a significant change in the interaction with the GUI. For many, not only a one-time change, but a constant change when they work with more than one computer running e.g. different distributions.
A related problem is how to these apps will stay portable between the different incarnations of the GUI: this probably introduces additional code complexity. And it will introduce additional GUI complexity: how many indicators will there be on each title bar? How are they arranged on windows that belong to the same app, on dialog windows etc.? To what extent will they duplicate what is in the panel or what is in the main window area (e.g. multiple volume controls).
I really do not see many advantages in this idea that would outweigh all the problems introduced by it.
I understand the problems connected with having the applications draw their own border, but IMHO it is not wise to ignore the demand for more flexibility in what is shown in the applications title bar. Also, the problem with an application border not matching the inside window should not be thrown aside so lightly. For a user, the border and the inside of the window is the same. It is all just the application. And that application looks bad if the toolkits of the window manager and the application itself do not match.
I think the request to be able to put other things in the title bar is a valid one. Why do you just deny requests to be able to put a mute button there? Why not think about ways to perhaps be able to put the menu in the title bar, or some other small useful things. Because you fear some company will put it’s logo there? If that application looks ugly, isn’t it the users’ choice to not use it? I don’t think it reflects bad on the window manager if some applications choose to mess up their application.
I understand that you have been thinking about this for quite some time, but that in itself is not a good argument. Perhaps you should explain how you came to the conclusion that “windicators”, mute buttons, menus and the likes are not a good idea to put in title bars. And yes, of course an application needs to gracefully fall back to a more conservative representation if such options are not available in the window manager of choice.
I think Canonicals move may not be nice for you, but your reaction to it isn’t the right one either. It would have been nice if they consulted with the upstream developers, but at the same time you say that you don’t like it if applications want to put their special buttons in the window decorations. You are ignoring a demand that is there, whether you like it or not. It is up to you to either
* convince everyone that this is not a good idea, but that will take arguments and not “I don’t think it is a good idea, and I have been thinking about this for months”, or
* you and/or other upstream developers coming up with a better solution on how to accommodate the demand for these kind of features
* you swallowing your issues and accept that somebody else decides to go in a different direction.
Isn’t the open source adagio “who codes, decides” equally valid if Canonical decides to start coding a feature for which there is obvious demand?
“I think Canonicals move may not be nice for you, but your reaction to it isn’t the right one either. It would have been nice if they consulted with the upstream developers, but at the same time you say that you don’t like it if applications want to put their special buttons in the window decorations. You are ignoring a demand that is there, whether you like it or not. It is up to you to either”
the point is, client side decorations have exactly nothing to do with those icons, it would be even easier and a cleaner job with a proper windowmanager, I guess the problem comes from they relying upon two windowmanagers depending if composite is available or not, but still a common library between those would have caused way less damages.
“Well to be honest we get request to add arbitrary functionality like a mute button in the decoration about once a month. And we always say no, because it is not possible as there is no common interface. ”
The point is – you have kept saying “no” when there has been a problem your users want solved… (monthly requests and you consistently ignore it — this consistent pattern in open source is souring)
… and now you are saying no to someone creating a solution.
Why not just write a new fresh blog post outlining the problem Canonical is trying to solve (try to understand what they are doing) and then propose the solution you think would address it (and it’s short comings) better.
To summarize … open source has far too much “no this won’t work” instead of I see what you want to do, here is a different solution that I perceive addresses everyone’s concerns. (and just pushing the conversation towards if canonical does anything, it sucks, is not helpful to anyone’s community)
“I also have some ideas for Aurorae like … autohiding decorations for maximized windows (due to upcoming feature freeze probably 4.6).”
How does this relate to BorderlessMaximizedWindows=true, which works just fine on my system?
It would allow you to have controls even for maximized windows without seeing the decoration all the time. When I implement it I will blog about it 🙂
If it was a matter of flexibility, then sure. But it’s not. This was only done so that Canonical can further impose the Ubuntu identity on gtk+/gnome and decrease the importance of the voice and opinions of the rest of the gnome community.
From a business perspective, I can completely understand Canonical’s move. They want Ubuntu to be preinstalled on hardware and they want to distinguish themselves (among others) with a modern notification system. So instead of going through endless discussions with the community and waiting for the “right” technical solution, they rather invent their own solution for their _own_ product *now*.
Given they aim for the non-geek user market, consistency is perhaps not even a big deal for Ubuntu. Their target users have their couple of standard (GNOME) applications installed, which Canonical will make sure to be working nicely with the rest of the system.
Speaking of consistency, the KDE desktop does really pretty bad, IMHO: There are two different widget systems with a completely inconsistent look and feel. Moreover, its notification system isn’t particularly usable, neither: Notifications get ripped off of their contexts and a huge, annoying tooltip is displayed, often covering the screen space of totally unrelated windows. Canonical, on the other hand, is showing real innovation exactly on that frontier, and the statistics say that they’re right.
If only KDE could generate some commercial interest… *sigh*
I think the idea of using the free space on the window title is really healthy and I would love it, probably technical implementation should be discussed in a deeper way.
I don’t think it would be too bad if window manager would grant a rectangle on a window title for application’s internal needs – like puting its own icons and actions there.
The mocup gave me an impression that this stuff might look just like system tray, but with context-specific icons.
We already have new nice flexible system tray – and it seems that there are no problems with it – why not making similar things for window decorations?
The app would put its own icons there and would communicate with them over dbus – just like it does now with system tray, and window manager would handle all the rest – put the “tray” rectangle on the desired place on the window title, handle painting and icon theming etc.
How about situations where there is no window decoration available? Where should those functions go what are place there? I have all decorations disabled on Netbooks. I can not have anything placed there. Otherwise the application becomes handicapped.
In this case this would be on behalf of window manager where to put this “context-dependent tray rectangle”. If decorations are available – put in on the decoration, if not – put somewhere else (for example, on a panel – near system tray plasmoid (so it should be available as plasmoid too)).
And logically continuing this idea – part of window decorations could be just converted to a nice plasma containment, where any plasmoid could be placed – including “content-dependent tray” 🙂
Anyone else find it ironic how this looks like the notification area that they are getting rid of? (especially given how cluttered it is shown) Just xembed something like a slightly modified stalonetray into the titlebar and you get flexibility, cross-toolkit compatibility, it working in a different thread, and don’t even need to teach developers anything new.
This solution is too easy though, works too well with everything by default, and doesn’t build upon (and actually is very contrary to) the current polarizing appindicator infrastructure.
GNUstep has always been able to do client-side window decorations, though it’s not the default. I don’t think it’s such a bad idea.
Settle down, people. This is just an experiment, and if it turns out that it doesn’t work well or doesn’t gain us anything then we just won’t use it. This started out as just wanting to explore doing things differently and see if we can re-evaluate some assumptions, and I don’t think this is a bad thing at all.
Client-side decorations is not something that will ever be forced on anyone. It’s enabled at runtime by the theme.
And although it seems like you want to pretend there is some Canonical conspiracy where Mark Shuttleworth is trying to push windicators on the world, that’s not really how this got started. I think he was just interested by my work on this and wanted to explore possibilities in the same way that I was exploring possibilities with this. That’s a really, really young idea still and I think it’s interesting and worth looking into but it was never a driving force behind client-side decorations. The reality is that client-side decorations is something I proposed, and there has been interest in it from Intel, Red Hat, Google, and now Canonical. I’ve even mentioned it to someone at Nokia once and he seemed at least interested in it.
So please, calm down. I honestly don’t think this is going to affect you in any way. If you’re running KWin or whatever, and you run a GTK+ application under it.. just don’t run a theme that enables client-side-decorations if you’re concerned about how it’s going to fit into your environment. 🙂
Just a nitpick, but isn’t krh the guy who proposed it first 3 years ago ?
see http://people.freedesktop.org/~krh/client-side-decorations.txt
Seems so and even he fails to see that decorations is not just about themeing.
I have read your article on http://www.freiesmagazin.de/magazin. There you give an example with Google Chrome to prove your statement. Did you see Google Chrome on Mac OSX? There is no inconsistency. The decoration is the same like the native ones. Window buttons are on the right site. The question would be, why doesnt work this on linux systems? Framework? UI Guidelines?
Mac OS enforces to use the decorations provided by the system. That’s why I wrote in the blog post, that if there will be client-side-window-decorations only Mac OS X will have a consistent user behavior for windows.
And that’s just one of the several things in your post that is obviously incorrect. Compare the window controls in the Finder with, for example, those in iTunes (smaller corner radius than normal), GarageBand (extra vertical band at each end), and Adobe Illustrator CS4 (taller title bar containing extra buttons and a search field).
And what does that have to do with client-side-window decorations on Linux? Ok, then MacOS is incorrect.
If you have any reasons why my position is wrong, please share it with the community. Up to now I can only see the points mentioned on the GNOME Wiki and they are not valid.
Developers want flexibility, do you want KDE to be “the less flexible toolkit”?
Old apps will work like they did, check
This is just an experiment like 100 other Linux distros, check
I see “this may create problems” here, but what about the problems it solves:
– This allows Wayland to replace X, the only (so-far) irreplaceable Linux Desktop component
Also, the community has been doing this for years:
– GTK has ClientSideWindows
– QT has Lighthouse
– These allow framebuffer implementations as well
wayland? come on – this is nowhere nere to replace x11. let’s start argument with it, when it is somewhat useable. my personal opinion is that it will never replace x
I’m doing free software because I want to provide the best possible user experience to the user. Client-side-window-decorations will destroy the user experience, because it gives devs the flexiblity to do stupid things. Yes in that regard I do not want to have a flexible toolkit.
And that’s exactly the issue! We have then two different sets of window control without any consistency. That’s exactly the reason why I wrote the blog post. It would destroy something that works (all windows have the same decoration) with something that is completely broken (different controls, different user actions, etc. etc.).
[sorry for the repost… to avoid being buried as I’m into the conversation late…]
“Well to be honest we get request to add arbitrary functionality like a mute button in the decoration about once a month. And we always say no, because it is not possible as there is no common interface. ”
So there is a problem your users (or in this case other developers) want solved… and you keep saying no, and now some proposed solution is a bad idea. And I’m not sure why Canonical meeting their needs is somehow any different than any other company programming/implementing their own solutions, some of which are more broadly adopted and some not. If the idea has merit, it will catch on, otherwise it won’t.
If there are real issues with client side decorations here (and I’m not saying there are not) … Why not just write a new fresh blog post outlining the problem Canonical (or any clientsiders) are trying to solve (try to understand what they are doing) and then propose the solution you think would address it (and it’s short comings) better (window manager/theming manager improvements). I for one like Chrome’s non-standard UI… it doesn’t seem to waste as much screen real-estate as the other 90% of the open source.
Propose solutions, don’t just point out problems. (and don’t push the conversation to Canonical=evil, that helps neither the community nor the conversation)
Sorry, but you are completely missing the point. I was not argumenting against the windicators but against client side window decorations. There is no reason why windicators should not work with normal decorations. Mark Shuttleworth updated his blog post and stated that csd is not a requirement for windicators, unlike the statement at the time of the writing of the blog post.
I am only argumenting against csd. Windicators is a different topic.