Version: (using KDE 4.0.83) Installed from: Ubuntu Packages Unlike KDE3, the user cannot specify the transparency of the KDE4 panels. By reading other similar bugs, I think that the canned response would be that the panels, and therefore the transparency, is handled by themes. If this is so, then I trust that Plasma has the technology to add a generic 'transparency' option that would be independent of the current theme. The advantage of this would be that _all_ themes would then support transparency, and that each theme would not have to implement it separately. This RFE is asking for the ability to configure the panels' transparency at the Plasma level, not at the theme level.
configuration options everywhere versus allowing the artwork to do what it should. > each theme would not have to implement it separately of course, this is just a matter of adjusting the translucency level of items in inkscape. there's no actual code involved. note that the best we could do in plasma is make *everything* equally translucent in the image. there's a reason we're relying on the svg: it can make just the elements that make sense translucent.
> note that the best we could do in plasma is make *everything* equally > translucent in the image. There is at least one advantage of this -- no transparency. Set once, for good.
actually, it wouldn't work that way. you'd still get whatever translucency was in the svg.
Oh, wait -- here is the point -- in svg you would set the transparency for elements, right (balance). But the global transparency would have different meaning then -- intensity. From -1 (flat, no transparency), 0 (balance preserved, like in theme) to +1 (flat again, everything is transparent). For example: 0.1 would be a bit all more elements are transparent, balance between elements is almost preserved.
> of course, this is just a matter of adjusting > the translucency level of items in inkscape. > there's no actual code involved. Please excuse me if I'm wrong, Aaron, but this sounds like the translucency would be hard wired. Is that correct, that the way Plasma is written translucency is determined when the theme is created, and cannot be adjusted afterwards?
I'd also plead for having a speperate transparency control for each plasmoid independent of the plasma theme. Expecially for menu bars (kicker replacement) this would be nice since I'm really happy with my two fully transparent menu bars in KDE3 - which don't disturb the wallpaper impression. Maciej Pilichowski's idea seems really nice to me as long it's doable in code...
*** Bug 188174 has been marked as a duplicate of this bug. ***
Created attachment 32416 [details] Screenshot demonstrating problem > actually, it wouldn't work that way. you'd still get > whatever translucency was in the svg. Can a coloured background be simulated behind the SVG, so simulate non-transparency? I'm serious, this is quite an annoying issue and it makes using auto-hiding panels impossible: I cannot see their content when they pop up because the image behind them show through. See screenshot.
I believe it is up to the theme developers to decide the look - users can change themes, so what's the problem? The themes are basic svg files so anybody can modify them, and there is always ctrl-shift-F12 to turn off transparency for a few seconds. Having all kinds of ugly hacks to have some fake kind of transparency - I'd be against that, esp if it would hurt performance (and I rather see devs spend their time on something actually useful). If it's easily done and somebody is interested, go ahead, but until then I'd say spend your time on useful stuff.
This is not about changing the whole theme. There are themes that I really like but I'd still prefer having the panel applet background fully transparent without having to fiddle with SVGs. (Of course I'm capable of doing that but it's not the lean way imho.) But problems might occur if the background is made up from several svg objects which is kinda often the case I guess. One would be able to control transparency of one of them, but what about the others? And how does plasma know which object to modify?
Well, you could simply select another theme for the taskbar alone. That's what the theme config tool is for (I don't know the name but it's the tool you can use to modify plasma themes by mixing them and creating a custom one from SystemSettings). Maybe having an option over THERE to completely disable transparency for a given theme element (panel, widget, clock etc) would be useful and might not be too hard to do. You could ask the developer of that tool if he could have a look...
That's a good idea (although I think the whole thing with the config tool is too circuitous) - but then we'd also want an option for completely disabling the background (-> 100% transparency).
Just one note -- providing themes for each element change, e.g. theme A theme A' -- more blue theme A'' -- even more blue and so on is impossibility and a mistake from design POV. So we need some kind of customization (but easy way) of themes.
@Dotan Cohen: "the way Plasma is written translucency is determined when the theme is created, and cannot be adjusted afterwards?" when the theme is loaded, yes. we defer these decisions to the artwork. the explanations have already been provided. "Can a coloured background be simulated behind the SVG, so simulate non-transparency?" possibly; it would require knowing the shape of the panel (we can mostly get this, but it's not 100% pixel perfect). it still wouldn't look great (i'm guessing you don't particularly care) and would mean introducing a set of configuration widgets to manage this. in a world where we provide virtually infinite flexibility by "you choose a theme you like, or theme elements you like" it's really hard to justify adding yet more knobs, levers and buttons for something like this. "I'm serious, this is quite an annoying issue and it makes using auto-hiding panels impossible: I cannot see their content when they pop up because the image behind them show through. See screenshot." either use a different theme, or have that theme modified. (is that the oxygem theme?) @Marcel B.: and a config option to mess with the transparency of one element when it's used in one particular situation isn't circuitous? @Maciej: "So we need some kind of customization (but easy way) of themes." there's a control panel in system settings.
I understand, Aaron. From a technical point of view I understand the difficulties of implementing a way for the user to control transparency, however, from a user's point of view this is a necessary addition. I believe that you are making a mistake by WONTFIXing this, despite the technical challenge, however as the lead Plasma dev that is your choice to make.
I want to suggest one last thing, although it's kinda unrelated to this bug: At least in KDE 4.2.1 (Debian Experimental) the config panel has to be opened from kcontrol, but one has to explicitly select the custom plasma theme in the appearance dialogue. A button to the config panel in the appearence dialogue would speed up things when fiddling with a theme... (Atm it's not obvious that one can select widget-specific themes from there, too)
Is there no way to pass a transparency value to the SVG? It would still be up to the theme to decide if/how to use it.
@Marcel B: there's already a report about that, actually, a couple other usability related issues with that control panel :) @Helge: "Is there no way to pass a transparency value to the SVG? It would still be up to the theme to decide if/how to use it." SVGs are not executable code. it would be an all-or-nothing application of translucency. if you read the above comments, i explain the issues with this.
*** Bug 193840 has been marked as a duplicate of this bug. ***
I read through this bug, and as a user I can't understand. I am trying KDE4.3 at the moment, and I can't configure my "kicker" background and it's annoying to me. Whatever background the screen designer might have put there I want to be able to change this to a color or image or whatever. Just like it was before in KDE3. And going to change the whole theme to adapt it to my needs seems to be a bit complicated for me. The same for all the little things I can put on the desktop now. I think you call them plasmoids or widgets (sorry for the lack of vocabulary). thank you Karl
@karl: it is possible to only change elements of the theme using systemsettings -> advanced -> desktop theme details. Still, it works very different from the 'old ways'. It is a different way of thinking to not configure every element separately but all together in one big swoop. But I doubt you don't see the advantage in that either, as it makes changing the look of the desktop much easier for newbies. You also don't have to hunt for a matching theme for every element separately (as was the case with superkaramba We have a dutch saying: every advantage has its disadvantage.
I found it: 1) I've tried to change some of the settings, but no result. Nothing changed. 2) While reading through the list, I don't understand what these points refer to 3) While changing the global design I don't get the "save" button activated. I have to change one by one I think that while KDE4 will get more configurable this list will get less and less understandable. Otherwise you have to refer not only the elements, but also the different places where this element is used... And then again it would be easier for everybody to just click on the "property" button of the element that you want to change, change it... done. No need to find the central configuration place, no need to find yourself through cryptic descriptions. No need to figure out what is meant through try and error. Just straight configurable and intuitive. Are we going away from the "intuitive" behavior of the desktop? I don't understand this change of philosophy. What was wrong with simply clicking on the object you want to change and change it?
> We have a dutch saying: every advantage has > its disadvantage. Linux Torvalds has a saying: better old bugs than new bugs. Voltaire had a better saying: A witty saying proves nothing. In any case, no matter who we are quoting, users need to change the transparency of the panel without changing their entire theme. In the advanced tab of System Settings I found my way to "Customize individual desktop theme items" in which one could choose individual items from different themes. However, one still cannot change the _transparency_ of the current theme as this bug requests. Furthermore, making changes in that location, even after logging out and back in, seem to have no effect. Tested in Kubuntu and OpenSuse. I will probably file that as a separate issue.
"users need to change the transparency of the panel without changing their entire theme" this keeps getting repeated as if it's some axiom of the universe. i completely agree that some people want to change the translucency level (e.g. with a slider or whatever) but i don't agree that that want is a must have. the reason for not simply fulfilling the want because it exists is that we're trying very hard not to end up with a horrible mess of UI configuration options, keep things in the hands of the artists as much possible/reasonable and have decent results. adding translucency control grants a negative effect on all of those points. therefore there must be a counterbalancing benefit to it. Dotan: or maybe we should just fill the config with less useful crap so that there isn't room for things like "manual hiding"? ;)
I think this axiom should be respected. At least it was under KDE3... Right now the artist work of oxygen is slowing down my system to uselessness. I don't want to be obliged to have the whole artwork on my system. I want a system that I can configure concerning my needs... What was wrong with the configurability of KDE3?
@Karl: you haven't explained why it's an axiom, this has nothing to do with performance or lack thereof or about oxygen. i am also not even remotely interested in a conversation about the configurability of KDE3 seeing as KDE4 is not KDE3 and, for that matter, already has many options KDE3 never did (and never will) have. unless someone can actually add something new to this discussion, such as explaining why translucency control separate from theme elements is a requirement, i've already marked this request as rejected and will not be posting further to it.
well then... thanks for your time Karl
> unless someone can actually add something new to this discussion, such as > explaining why translucency control separate from theme elements is a > requirement, i've already marked this request as rejected and will not be > posting further to it. Fair enough. I _cannot_ use anything transparent in my desktop environment. I find it too distracting and difficult to parse. I do not understand why one must be able to see what is below the element that he is working with, quite the opposite, I find that this effect makes me loose focus of which element I _am_ working with and I try to interact with the element underneath. This leads to potentially dangerous actions being taken as I try to interact with the wrong element in a worse case scenario, and an extreme annoyance in the best case. This is an accessibility and usability issue, two fields which have been severely ignored in KDE 4 despite the fact that KDE 3 was a shining example of usability. Just as I do not have the resources to learn to use the tools needed to work with SGVs and themes and image editors and vector-whatnot, I do not expect you to have the resources to study usability and accessibility. However, I do expect you to trust those of us who take an express interest in the field, and those of us who are sensitive to usability or accessibility issues. Even the non-sensitive benefit and enjoy the program when it is more usable, even if they have a hard time pointing out just which "little things" they are that make the program great. Those "little details" are what made KDE 3 so great to use. It is not just panel transparency, or just multiple desktops, or not just feature XYZ, but rather the total that is more than the sum of the parts. It is a shame to see all that go to waste in KDE 3++. KDE 4 really is a nice piece of work, especially Plasma which is what people really means when they say KDE 4, but it needs to incorporate all the "little details" that made KDE 3 not "a nice piece of work" but rather a great desktop.
Being able to force non-transparency without manually setting KDE_SKIP_ARGB_VISUALS (or making it so things actually remember it when they crash and restart) is also something to consider. I have a visually-impaired friend who, when experimenting with Linux, has to stick to KDE 3 or GNOME because translucency doesn't give enough contrast.
@Stephan: then use a theme without translucent items.
Point, I suppose. Once KDE 4.3 gets unmasked (Gentoo), I'll have to see if I can root out any more "reset to default" bugs.
Oh yeah, I remember why it was an issue... last we checked, every theme we tried had translucency unless KDE_SKIP_ARGB_VISUALS was set. I'll assume that has changed since last time, but it does seem to be the new "You're not cool unless..." thing for theme designers. (Sort of like how, with KDE 3, "All KDE-compatible icon themes must be either monochrome or glassy with eye-burningly bright colors")
@Stephan Sokolow: try the Aya theme. It does not do transparency afaik and follows the desktop theme. @all I understand it is difficult to accept but KDE 4 is very different from KDE 3. If something was possible in KDE 3.x and not in 4.x that does not mean it has to be added to 4.x, sorry. The desktop in 4.x is far more flexible than the 3.x version and far more customizable. It's just different - and some things aren't as obvious as they were, which is due to both the new technology (SVG) and the desire for usability. If somebody can write a patch which does not make plasma harder to use and configure, does not degrade performance or heavily decrease maintainability, I think it has a very good chance of getting in. Meanwhile, the plasma developers have different priorities - changing the transparency separate from theme, no matter how important to some, is not something 99% of the users care about.
@jos: No, last time I checked, Aya used transparency, just as any other theme I tried. It doesn't use much, but still enough that the panel doesn't look homogeneous anymore and distracts me from work. It is kind of funny that KDE has to run into the same debate that already took place for Macs years ago until some kind soul provided a hack for it and eventually Apple came around and made it configurable (e.g. http://www.peterkrantz.com/2007/leopard-menu-transparency-fix/). I understand why some like transparency to get cool desktop screenshots but from a usability standpoint it doesn't add anything and makes things harder to read. Looking at things like http://www.notmart.org/images/mid_newspaper.png really makes me wonder if more transparency is really the way to go. But anyway, people are different and I understand that you don't want to add a lot of code just for this. My suggestion would be to provide an easy way in the options to use the opaque version of a theme instead of the transparent one (the one that is used when compositing is disabled). This should be very easy to do and shouldn't break anything. Another possibility would be to provide a conservative theme (just a grey panel as in KDE3 or Gnome) as another default theme. This is the way, Microsoft has done it for years with Windows and a lot of people at work I know use this old "grey" theme because they get distracted by the colored task bar. If you want people to use KDE for work as well, you should thing of them, too. But please don't make us dig around for a theme that doesn't use transparency. Or at least suggest a well-maintained theme, that really does not use any transparency or strange background patterns (No, Fluffy Bunny does not count :) )
http://www.notmart.org/images/mid_newspaper.png is rather old.
I know. I just wanted to show an extreme case of why I don't think transparency is leading to a nicer and cleaner desktop.
You didn't give me a chance :-) so I tried to figure out how to change a theme just to have the background of the "kicker" changed. I searched on the internet for a documentation how to do that. I clicked through the files of the oxygen theme. I found docs about how to program themes, plasmoids in C++, Java even Ruby. But I couldn't figure out how to change the background of the "kicker". Can you please send me a link to a doc?
*** Bug 212440 has been marked as a duplicate of this bug. ***
I just run into the same problem using KDE-4.6. I can hardly read the information provided in the plasmoids I tried (weather forecast and system monitor). Newspapers are printed on paper and not on plastic foil for a reason - readability! How can this be RESOLVED WONTFIX when there are no themes *WITHOUT* transparency provided per default so that a mortal user even has a chance of changing the setting?