unity-design team mailing list archive

[Lance <lbsolost@xxxxxxxxx>]

It appears that my "cc:" was wrong and this did not get sent to the Ayatana list and others so I'm trying again with great caution.

Apologies to Mark.

--- On Fri, 5/28/10, Lance <lbsolost@xxxxxxxxx> wrote:

From: Lance <lbsolost@xxxxxxxxx>
Subject: Re: [Ayatana] Fwd: Open Letter: The issues with client-side-window-decorations
To: "Mark Shuttleworth" <mark@xxxxxxxxxxxxx>
Date: Friday, May 28, 2010, 4:35 PM

Thanks for sharing this. I've had concerns but I'm sure you know by now I have trouble articulating my concerns.

While some movement is always necessary we must never confuse "movement" with progress ;^)

It's always better to make wise decisions rather than have to "walk back" said decision. Among the most compelling arguments:

" 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."

"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."

That one is incredibly
 rough on hardware, particularly PSU's!

While a good deal of that has to do with KDE  I do share some concerns. Depending on how things work out with the Gnome desktop I've even considered contacting Martin Pitt about expanding his gnome-stracciatella-session project to provide a more "pure" Gnome desktop as another "optional" desktop.

Again thanks for sharing this with the community. I'm looking forward to Maverick Alpha 1 iso-testing.

Lance
aka: Erick Brunzell
aka: kansasnoob

--- On Fri, 5/28/10, Mark Shuttleworth <mark@xxxxxxxxxxxxx> wrote:

From: Mark Shuttleworth <mark@xxxxxxxxxxxxx>
Subject: [Ayatana] Fwd: Open Letter: The issues with client-side-window-decorations
To: "Ayatana List" <ayatana@xxxxxxxxxxxxxxxxxxx>, "Martin Gräßlin"
 <kde@xxxxxxxxxxxxxxxxxxxx>
Cc: "Cody Russell" <cody.russell@xxxxxxxxxxxxx>
Date: Friday, May 28, 2010, 1:11 PM





 


Thanks to Martin for raising this issue here. Not sure why the list was
bouncing his mail, but it should let it through from me. Please keep
Cody and Martin on cc for the thread.



Mark



-------- Original Message --------

  
    
      Subject: 
      Open Letter: The issues with client-side-window-decorations
    
    
      Date: 
      Fri, 28 May 2010 19:30:53 +0200
    
    
      From: 
      Martin Gräßlin <kde@xxxxxxxxxxxxxxxxxxxx>
    
    
      To: 
      mark@xxxxxxxxxxxxx
    
  





Hi Mark,

sorry to write to you directly, but I tried to send this open letter, which I 
also published on planetKDE, to the ayatana mailinglist twice and each time 
the mail has not appeared in the public archive without any notification to 
me.

I'm sending this letter to you as it is an important issue. Canonical is going 
to introduce CSD in Ubuntu 10.10 - in fact it's already enabled in the 
development version - and your team should be aware of the disadvantages of 
CSD and that it does not have any advantages.

I kindly ask you and your team to rethink the decision on CSD. If you visit 
the comments to my blog posts you will see that the maintainers from KWin, 
Compiz and Enlightment agree to the facts mentioned in the letter.

Yours sincerely
Martin Gräßlin

Hi Cody,

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.

Regards
Martin Gräßlin


 

-----Inline Attachment Follows-----

_______________________________________________
Mailing list: https://launchpad.net/~ayatana
Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp