Created:
17th October, 2008
Last Modified:
20th October, 2008

Window shadows in trunk

A little while ago I merged the new Libkdecoration2 API into KWin trunk, with it came a lot of new shadow code. As the new shadow code is incomplete window shadows in trunk will be broken for a little while, it is merely a graphical glitch so if you can live with it for a week or so that’s good otherwise there is always the option to disable it. Maybe I chose a bad time to merge as the KDE 4.2 alpha 1 is about to be tagged, oh well, I think just reverting the effects/shadow.* files should fix it if it’s really that much of a problem. I promised the Oxygen team that it would be merged before soft freeze and here it is. =)

Update: After discussing this with various experts I will be renaming this API to something else and marking it as unstable. This is really just one huge hack so supporting this for KDE 4.3 and later is suicide. If any decoration developer wants to use this API they will have to keep in mind that it will only be available in KDE 4.2.

What does this merge mean to users and developers? Well for one shadows now wobble as well when using wobbly windows, but the most significant change is that decoration developers can now change the way the shadow looks and behaves—everything from position to textures to opacity can be customized if needed. For those who have seen the Oxygen mocks you know what to expect to come out of this for KDE 4.2. For those that don’t like the Oxygen shadows, there will always be the option to use the old-style ones.

Since last time

Comments

17th October, 2008mofux

great work!!! this will be the best shadow ever seen for operating system windows :)

17th October, 2008Yogesh

Has this any effect on non-rectangular windows (those without any decoration)?

17th October, 2008christoph

Will menus keep its shadow? Are we now able to use ARGB decorations? The current situation for shadows and ARGB windows is a mess.

17th October, 2008Lucas Murray

“Has this any effect on non-rectangular windows (those without any decoration)?”

Non-rectangular windows are a huge problem, there is really no way to efficiently shadow them while keeping things integrated.

“Will menus keep its shadow? Are we now able to use ARGB decorations? The current situation for shadows and ARGB windows is a mess.”

Menus still have shadows. ARGB decorations will not be supported until Qt itself supports it without hacks. Yes, things are currently a mess.

17th October, 2008Aaron Seigo

we also have a strange situation in plasma: when the panel “hides” all the animation happens inside the widget, though to the user it looks like it’s going away. so when the panel has a shadow, the shadow stays where it is but the panel “slides away”. i need to find a way to let the WM know that the visual edge of the window is not the actual edge. neat problem, huh?

really great to see the pace of things on the kwin compositing front; it’s very exciting times.

one thing that does concern me, however, is the disregard for the Oxygen artists by doing things like implementing their mockups sorta-kinda and then turning them off by default (as your post here seems to intimate), not to mention the occassional open hostility towards the artists on the mailing lists for no reason. the latter really needs to stop happening, and i’m very interested in finding a way for the kwin team to *trust* the art direction that is offered a bit more.

imho, the oxygen shadows ought to be the default along with the oxygen window deco theme. defaults are everything, and the artists tend to know what they’re doing there.

17th October, 2008Lucas Murray

 Aaron,

I love the Oxygen team and they love me. Lubos might have had past conflicts with them but I really like what they do and that’s why I’ve gone out of my way to rip up all the internals of KWin to add this. As for whether or not this is enabled by default or not depends on what it’s like during usage—if it actually works I would like it to be default, if it’s a little iffy then it’s disabled and I go discuss things a little more with the Oxygen team. I want this to be default, but I also want the default workspace to be inviting to new users—having something that looks and acts completely different than everything else might be good for bringing the desktop to a new level, but it also alienates users.

I should also mention that I am also with you on making Oxygen default and dropping Ozone, the only problem is that I’m not the maintainer and therefore cannot make that decision.

As for the panel shadow see my comment above, we have yet to work out how to do it correctly. =(

17th October, 2008Aaron Seigo

that’s honestly really great to hear. you’ve lessened my stress load for the day; thanks! =)

if it actually works I would like it to be default,”

there are three ways this can be measured:

  • technically - does it fit the resources requirements, does it not screw up other code, etc?
  • artistically - does it look “right”?
  • usability - does it accomplish, or at least not get in the way of, heightened usability?

personally, i think the kwin coding team should decide the first point, the kwin art team should decide the second and the kwin usability team the third. and they shouldn’t get in each other’s way =)

art is probably mostly Oxygen people supported by those doing the actual graphics coding (e.g the shaders and other OpenGL pixel pushing).

usability could likely be filled by consulting with people such as Celeste or myself, supported by whomever has usability knowledge and interest in kwin.

this is exactly what we’ve done in Plasma, not to mention other apps around KDE4 (dolphin, gwenview, etc, etc). it works really well, but the biggest challenge is to brave that first plunge of letting someone else have a significant say in the final look of the software even though they don’t write code.

this is all a long-winded way of saying that the kwin coding team could be a bit more accommodating of these other experts-in-their-own-field.

and sometimes that means someone in the team standing up and saying exactly that.

i really hope you and the others can bring some more sanity to the graphical presentation of kwin. you’re all doing an awesome job with the effects, and it’s very encouraging to hear that the art and usability direction is being brought in closer.

don’t let people, even the maintainer of the window management parts of kwin, get in the way of that. and remember that while you may not be the maintainer, you are an important part of kwin by being an active and committed developer, along with Rivo and the others. you *do* have a say in things and you *do* have the right and ability to make your voice heard within the project. it’s a collaboration, not a dictatorship; we maintainers are here simply to ensure final continuity. a lot of the time that means we (maintainers) simply have to know when to say yes, no or to just get out of the way and let others do what we’re not great at.

> but it also alienates users.

keep it in perspective, of course: we’re talking about shadows, and those graphic designs of Pinheiro for the windows resonate very deeply with very nearly everybody i’ve ever shown them to. for the remaining 5%, which you can never get rid of and who may end up being vocal, that’s why we have the configuration options ;)

> panel shadow see my comment above, > we have yet to work out how to do it correctly

yeah… it’s not an easy one. maybe we (plasma and kwin devs) can work on it together in 4.3?

17th October, 2008dr.schnitzel

Why does the konsole window have the points “bookmarks” two times?

Besides that, awesome, dude! Keep on rocking!

Do you think it will ever be technically be possible to merge the window bar (“kwin bash”) and the menu bar “File Edit…”) into one row? This would be awesome!

17th October, 2008jorge

 Hi,

really nice work there!

Is there a way to disable shadows for a specific window? I mean, I’m working with ARGB and non-decoration windows and I would love not to see shadows there.

something like: setWindowFlags(NoShadowEffect)?

Keep the great job! Oxygen rocks!

17th October, 2008parena

Sounds good! All the progress I read about, it’s really great. :) One question, though: What exactly is so special about “Oxygen shadow”? Is it the fact that you can have different colors? I don’t see any significant difference between what I’m using (in 4.1.2 openSUSE Factory) and the mockup you’re referring to.

19th October, 2008Lucas Murray

“Do you think it will ever be technically be possible to merge the window bar (“kwin bash”) and the menu bar “File Edit…”) into one row? This would be awesome!”

As the window manager and application are two separate processes in X doing this is unfortunately impossible. There is a decoration that puts the buttons and stuff inside the window around somewhere, but it covers up parts of the menu accidentally.

19th October, 2008Paul

Great work Lucas. A small question: is the shadow drawn behind the window, even in areas where it would not be visible? I ask because when I enable Konsole translucency, the terminal appears a slightly transparent grey (as I use a white background for my terminal and the shadow behind it is black). Will this happen with the new, pretty shadows?

Regards, Paul

19th October, 2008Lucas Murray

“Great work Lucas. A small question: is the shadow drawn behind the window, even in areas where it would not be visible? I ask because when I enable Konsole translucency, the terminal appears a slightly transparent grey (as I use a white background for my terminal and the shadow behind it is black). Will this happen with the new, pretty shadows?”

When using new shadows this problem will no longer occur, if you are using a decoration that doesn’t support the new shadows then it will still be there.

20th October, 2008Rotary Evaporator

We still need to clearly distinguish the active window from the inactive. It’s still too difficult. Shadows help for some users, but we can’t rely on special effect to fix a usability problem.

Have your say

Markup

Because some people like to be stupid HTML is not allowed in comments, instead feel free to use the following:

  • __Bold__
  • ___Italic___
  • [Hyperlink](http://address.com)
  • [[quote source]]…[[/quote]]
  • [[code:language]]…[[/code]]

Unordered and ordered lists have each line prefixed by either a dash, asterisk, hash or a number. Your choice.

All comments are heavily moderated, if you are off-topic your comment will not be published (But I might reply by E-mail).

Be careful! Once posted you cannot edit your comment.