All users who do not use our default Oxygen widget style and window decoration might have had an unpleasant surprise after upgrading to 4.7. Our old shadow effect provided generic shadows for all windows no matter which widget style or decoration is used. In case the decoration provided its own shadow that one was preferred.
The new shadow system does not provide any generic shadow. The compositor is just providing a service to the widget style for rendering the shadow. This means that the widget style has to implement support for the new shadows. This has been done at least for Oxygen and Bespin, but it might also be added for other styles – so if you miss your shadows, check whether there is a new version of your preferred style, get in contact with the author of the style or best of all: provide a patch.
Of course there is also the option to add a generic implementation again to KWin (which seems to be a need), though I must say that I will not spend any time on that myself. Given the experience from our old shadow effect, it is my belief that you cannot have a generic shadow which looks good with all widget styles, windows and color schemes. Nevertheless I am open to patches which add a generic shadow which can be used if decoration and widget style do not provide a shadow. The basic ideas of the new Shadow system are documented in our wiki. If you want to work on it and have questions just get in touch with us through either #kwin or #plasma on freenode or kwin at kde dot org.
=-=-=-=-=
Powered by Blogilo
I for one *really* miss the generic shadow implementation. It seemed to work fine for me – at least I thought they looked fine with QtCurve.
Now every non-oxygen gtk style will not have shadows – whereas before they did. I cant see the Clearlooks authors creating shadows just for kwin. And even with Oxygen-Gtk, Firefox’s menu shadows produce garbage for me (KDE4.7, Firefox5, OxygenGtk 1.1) The pre-built Qt themes (plastique, cleanlooks, etc) also will not have shadows. The menus in LibreOffice (when styled with KDE) do not have shadows. etc, etc.
I can understand letting styles have the *option* to provide their own shadows. But if a style does not indicate it supports shadows, then the previous generic shadows should be used…
There is no previous generic shadow any more. One reason to implement the new system was the fact that it was impossible to port the shadow effect to the new OpenGL (ES) 2 compositor.
Could you not just take the oxygen code, and use that as a fallback for when a style does not support custom shadows?
Just seems odd forcing *every* theme (Qt, and Gtk) to implement the *same* piece of code for shadows – when previously there was a generic fallback.
As written in my blog post, I am not interested in doing anything about it except code review. If someone wants to have that, he should implement it.
OK, fair enough! Can you provide me with some pointers as to where to look? I’d much rather re-add a generic mechanism, than have to code two implementations (Qt and Gtk)
The best place to start is by looking at the pages on community.kde.org – there is documentation about the shadow, class diagrams, hacking guide and so on.
This is a troubling example of the GNOME-like, “forget-the-users” attitude that KDE has been showing more of over the past few years. In this case, working code for a feature that is used by many people is ripped out and replaced with nothing. The buck is passed to other developers, whose code is suddenly blamed for the lack of a previously-existing feature. The KDE response is, “If you don’t like it, fix it yourself,” which boils down to, “We’re doing what we want to do; we don’t care about the users. This is our playground.”
That’s exactly GNOME’s attitude with GNOME 3. And who suffers? The users: the people who actively support KDE and the FOSS movement. Working features are ripped out of their hands in pursuit of mythical perfection of code or API. Backwards-compatibility–no, wait: last release’s features–be damned. This approach is driving Amarok into the background of irrelevance, and it will hurt KDE as well.
When will the incessant rewriting-from-scratch of working code finally end? One cannot build if one keeps ripping out the foundations of his project! And no one will want to live or work in a building that’s constantly under major construction: it’s very unpleasant!
If a developer wants a playground to experiment in, that’s fine, that’s his business–but he shouldn’t use a major, functional, widely-used project as such. The arrogance of the attitude of, “I don’t care about what I broke or who was using it–they can fix it themselves” is an attitude to be ashamed of.
It’s necessary to approach the development of major FOSS projects like KDE with certain product-oriented goals in-mind–otherwise it will decline and fall into obscurity, frustrating millions of people and wasting man-years of time along the way. It’s for these reasons that projects like Trinity will gain ground, because someone has to focus on making a working product that doesn’t constantly take two-steps forward and one-or-more-steps backward. Make something that works, and then make it better. Stop throwing it away and starting over with every new release!
Regardless of the elegance of the underlying code, if the functionality degrades when the version number increases, the software wasn’t ready for release, and the process–and the product–has failed.
We did a new and better shadow system to give our users a more pleasant experience. I would say exactly the opposite of what you wrote is true.
The code was not working. Want to see the bug list, this one fixed?
We want to provide a great desktop experience. If the users want to replace part of our experience with something else, that’s fine, but they should not expect that all features are supported. Oxygen is part of our desktop experience and if you want to use something else, that’s fine, but don’t complain. The same is the case if you want to use Compiz instead of KWin
The code was not working.
The decision to write a new shadow system was not a one person decision. In the process was the KWin, Compiz, Plasma, Oxygen and other window decoration teams involved. It was a common decision that the old shadow system is broken and needs to be replaced. I am not ashamed of my attitude to replace a broken system, but must admit that I am proud when I see the new shadows.
Yes exactly that’s what we did. But it seems you think we should have other goals in our minds. Sorry but we are not able to read your mind.
“but must admit I am proud when I see the new shadows”
Sorry to say this but what shadows are you seeing?
Are you talking about oxygens shadows?
If so, I have always thought oxygen shadows look awful.
I use oxygen but always used oxygen-settings to set it to use kwin shadows because I thought they looked much better.
Also, oxygen shadows have very little room for tweaking/configuring without making them look even worse (either barely noticeable, fake looking or too dark and thick), which is ironic considering how famous KDE is for it’s level of user tweaking and configuration.
By doing away with generic shadows because they don’t look great with every theme (but look fine with 90% of them) we are left with many themes having a very ugly, 1px black border with jagged corners. How is that better?
So instead of acceptable generic shadows, users who like them or find them highly functional when it comes to window separation, are left to the mercy of individual theme creators to decide whether or not they wish to or can be bothered to update their themes to support the new system.
Or of course learn to code and fix it ourselves, which speaking personally isn’t an option 🙁
You know, taste differs…
The main reason for removing the shadows were the fact that they are broken (and have been so for at least a complete year) and that the source code was not in any state to be ported to the new compositor.
If this is so important for you, there are also companies which can be hired to implement it. Also please note that we removed the shadows in January which means half a year ago and nobody stepped up to implement a generic shadow system and almost nobody complained (I only know about one complaint beforehand). Given that we got zero feedback during the beta phase it seems like the feature is not in general requested. Developing software for a hand full of people is nothing which makes sense and which we could or should do.
“You know, taste differs…”
Exactly! So why not have made the oxygen shadows more configurable so they CAN suite different tastes? 🙂
You should ask the Oxygen Designers and Developers about it – I’m not responsible for the design code.
I apologize if my first post seemed rude. I am an enthusiastic KDE user and want to see it prosper and grow. As I said, there seems to be a general trend developing, which is concerning.
“The main reason for removing the shadows were the fact that they are broken (and have been so for at least a complete year) and that the source code was not in any state to be ported to the new compositor.”
What do you mean by “broken”? I thought they were working fine, and it seems like Shane did also.
Ok, the code was ugly, and it didn’t mesh with your new API or whatever. That’s fine. But the end result is still removing a working feature and replacing it with nothing. If someone wanted to make a new compositor that redid the shadows, it seems like he ought to be responsible for reimplementing existing functionality, rather than passing the buck to style authors.
Imagine if a kernel dev wanted to replace the USB subsystem with a better one, but didn’t want to program support for USB power-saving, and left that up to individual driver maintainers to reimplement. Needless to say, his code would be rejected until it supported all existing functionality. I’m sure Linus would laugh at him for even suggesting it.
I use QtCurve, and it doesn’t seem right to make style authors add shadow support, a function that ought to be provided by the window manager, and has been up to this point. At the VERY LEAST, style authors could have been contacted well ahead of time and helped to provide the functionality in their code, rather than ripping the rug from beneath style authors’ and users’ feet.
Do you want the list of bugs which got fixed with the new implementation? Seriously: it was broken and I think I am more capable of deciding whether it is broken than anyone else.
Please read: http://lists.kde.org/?l=kwin&m=129607406517609&w=2 and look at the date and who was in the cc list
Related to this, I see some double-shadow bugs in the default Air theme, in KDE 4.7.0. I’ll wait until my KDE-Redhat repos are updated to properly file bugs, but thanks for providing compositor-managed shadows.
The old shadow system didn’t work right on my NVIDIA card with blur enabled, so I’m just glad to now have working menu shadows and blur enabled at the same time. Sure, I do miss a few shadows here and there (particularly in LibreOffice, which has abysmal KDE theme integration), but Oxygen and Oxygen-GTK provide the majority of shadows that the old plugin used to handle.
That being said, it would be nice to have a fallback option, especially since there are cases where the shadows really are missed, and the authors of some themes (QtCurve for example) are not at all keen on being required to add shadows to their code.
BTW, I quite like the new Oxygen shadows. I think they look considerably better than the shadows provided by the old plugin.
My main concern with the oxygen shadows is that there is very little anyone can do with them but accept their defaults.
As mentioned before, any alterations make the shadows look either too dark, like someone has drawn around the windows with a marker, or completely fake looking.
Not only that but the menu shadows are quite light, I can’t change them and changing anything in oxygen settings makes no difference to the menu shadows.