On Saying "No"
When someone sends in a patch that they feel should be applied, it's always a difficult decision when the patch really shouldn't go in. After all, someone has probably put a good amount of effort into it: they've thought about the problem, come to a conclusion, plunged into the source code, altered it, tested it (well, hopefully :), then sent the diff in to be reviewed and commented on by their peers.
So when a patch just doesn't make the grade .. what do you? I hate saying "No." It's a lot less fun than saying "Yes." because "Yes" makes the person right in front of you happy. Unfortunately, when you are looking after a project (and everyone involved with a project ought to be striving to do that) there is more than just the person in front of you. No matter how loud they are, no matter how much hyperbole they throw at you, no matter how right they think they are .. they are not the only concern.
Casual contributors often lack the deep insight into the code base and design, something those who work on it a lot of time in the project probably have gained over time the hard way. I know that I've submitted patches to projects that have been met with the ominous "No" because I don't have that deep insight into the codebase. I'm a casual visitor to many of the projects I send little patches into, and I try and respect that.
When you are the one who has to say "No", however, there is a way to pay respect to the person's time and effort so it doesn't go wasted: explain the why behind the "No" in clear terms. This not only might help the submitter understand how things work a bit better (passing on your earned knowledge to them), but it will give everyone else in the project a chance to coordinate on a consensus on the matter. When you say "No", the rest of the project deserves an answer why.
Of course, the submitter is likely to respond in turn. If they don't, then you've either laid out a very persuasive line of reasoning or they weren't very sure in their thinking in the first place. Software developers (among others) really, really like being sure about things. As such, you can expect to get a dissenting reply to your "Why I'm saying 'No'" most of the time. Often they'll bring up new questions and thoughts along the way. It may challenge what you think on the matter. It may even change your mind. It also might not.
Trying to work towards consensus, as long as its possible to achieve, should be the goal. Sometimes it's not possible, of course. Such is life, but don't get stuck in a "no decisions made" trap. Take all the input, weigh it, come to a decision as is fitting the context as best you can. (Often "you" means a group of people, not just an individual.)
When there's nothing left to discuss, move on. This requires cooperation from both sides: the person saying "No" needs to both communicate that it's time to move on as well as provide a way to move on, such as setting another destination that can be agreed on and arrived at, and the person who is being told "No" should find a way to respect that. It sucks not getting what you want, but what you want isn't always best.
Trust me, I have a nine year old son and he wants all sorts of stuff that isn't the best for him. We tend to get better at this as adults, but never 100%. Often a lot less than 100% better, in fact. :)
On Realistically Measuring Cost and Benefit
The patch that Dave submitted in this case provides a "fake" translucency for panels that shows the "desktop wallpaper" (a concept that doesn't actually exist in that form in Plasma) not unlike what we had in kicker in KDE3.
Here's how my decision making on the patch went:
- Is the code style compliant and reasonably written? Yes. So far so good. :)
- Is this implementing a feature fully and properly? No; for instance, it doesn't show windows in between the panel and desktop layers.
- Could it be the basis for implementing the feature fully and properly? No, only with compositing can we do this fully or properly. This is a complete dead end approach with a very real limit to the approach that falls below "proper and fully".
- Are there aternate ways to achieve the same thing in a full and proper way? Yes, and we already support this, but it requires compositing support.
- Does the patch incur a positive, negative or neutral cost to the code? Negative: it makes the code harder to maintain by introducing another special case; and we quickly identified at least one situation where this work around probably will require another work around.
- Is this feature critical to functional use? No: there is no functionality that is positively affected by it's existence and, conversely, no functionality is negatively affected by its absence.
- Is this feature important for non-functional attributes, such as aesthetics? Translucency is indeed something that can noticeably impact non-functional attributes, such as aesthetics. However, this approach comes at the cost of some (though thankfully not huge amounts of) performance, and it also runs the risk of coming across as rather amateurish compared to "doing it right" (just as kicker's translucency did). It is possible to make things look very nice without translucency (I know, because right now I'm using a system without compositing :), and there is a way to achieve it properly.
Following this train of thought, it was clear that the feature came quite clearly under the "no hacks for non-critical things" act and was therefore not accepted.
It's interesting that Dave noted how small the patch is, because I know how much code was scattered all over Kicker and its applets to make it work at all there. The difference between doing it in Plasma and doing it in Kicker (both of which I worked on, including the translucency support in both) is that Plasma was designed for flexibility, clarity, cleanliness and maintainability. Accepting patches that work in the opposite direction of that is therefore pretty crazy. We need to use those benefits for things that are critical, differentiating and truly valuable features, not for things that erode those benefits for features that aren't any of those things.
Does it suck that poorly supported or older hardware doesn't support all the bling? Yes, it does. It also sucks that my car isn't an expensive sportscar that can go 200km/hour. I don't insist on trying to make my car look sporty by adding a big fin on the back of it. "Look how sporty it looks now!" would be met with "But it's still slow and crappy ... and now it looks tacky, too."
We have a solution for translucency, and it's called composite. It works on the bulk of systems out there right now and will work on even more systems with each passing year. The number of bugs and improvements that have made their way into various parts of Qt and x.org because of our unflinching insistence to rely on these lower layers in the stack to do the job they are supposed to is pretty impressive and would probably still not have happened if we hadn't. Meanwhile, we have a clean code base that we can work on very efficiently, which is why things can improve and change so quickly compared to Kicker which was quite a bit less complex in concept.
For the systems things like composite don't work on, we work on graceful degradation paths that preserve functionality and as much of the prettiness as is reasonable. KWin took this to a new level with it's auto-detection capabilities, and Plasma's theming adapts to compositing and color depth.
We do have more that we can do here, such as using a color from the theme's color scheme (or the system's color scheme if the theme uses that) as the background color of the PanelView so that even themes with no opaque/widgets/panel-background.svg stand a chance of looking better. That's something that Dave suggested, actually, so good things do come of these exercises. :)
While I don't think there's any benefit to Plasma in discussing this all over again via blog, I hope that there are interesting bits of information about Plasma itself and project guidance in general to be gleaned from all of this. :)
Anyways .. back to krunner hacking for me ... I've implemented the multi-line display as I mentioned yesterday, tidied up a couple of bugs that remained and am now onto working on displaying action buttons so we can have back cool things like "Run as different user"!
63 comments:
I'm live in Brazil, lot computers use video card SIS and VIA, with bad support for composition.
This patch is very good for 3rd world.
Sorry for bad english.
You better not tell ME no! I'll whine and pout and stamp my foot and have a temper tantrum! :)
@O tudo e o nada...: it's not good for anyone to ship harder to maintain software that performs worse just to accomodate a purely cosmetic feature.
@Jaye: hehe.. yeah, i know. just like i know to beware anytime you say, "Hey, Aaron!" :P
(p.s.: for others, Jaye is my sister ... my older sibling who oscillates between protector, advisor and puckish troublemaker in my life ;)
Hi Aaron,
My system is able to do composition. I'm not whining about delay in the composition (you're right keith 'n'co have done a wonderfull job) but it's still not prefect (see ubuntu UXA refusal...).
So basically you're still saying that you're refusing this because of code cleanlyness... I see the next "I know what my user need more than they do" in your word. This is sad as this is one of the reason why gnome felt behind.
More on the focus, I hope I'll not end up not being able to bug report my distrib or the kde projet just because I applyed his patch manually... Cause I need it badly : kwin disable compositing (without a way to re-enable it different than logoff-logon) when it feel it was too slow. but how can my compositing stay snap enouth when my machine is under 10 of load ????
At least plasma should be able to show it's glory while not that costing...
Even if "history" have proven you right on the part "don't hide other's bugs". But how fixing UXA on my system will help reduce a load of 10.... And I'm not the only one.
Cheers from Québec ++
@Sebastien: hi! =) Talking about UXA, from my point of view, what would be bad is having two different behaviors for the same thing: when composite is on the panel is truly translucent, showing the windows (for example) below it and when composite is off the panel will not show them. I can already see some bugs on bko due to that ;). Maybe the experience can be improved for composite off ? Maybe yes, but I really don't think this patch was the way to go. And it's funny that we don't see people trying to work around different behaviors of KWin regarding composite on/off =P
Cheers
Wow, I didn't realize so many people would be so persistent about a minor cosmetic change.
Personally, I run one computer with effects (a laptop) and one without (a desktop on which I play 3d games).
It doesn't bother me at all to have no effects/composting. Although I do enjoy wiggling a wobbly window while I think about something, it soothes me.
Also, a question to the people who have to have this. If you don't like the way most themes look without a transparent panel, modify them or make your own. Is that not a viable solution?
@Aaron, after reading through your blog I can't see how anyone would disagree with that, very well layed out.
Sorry, but I have to say it. This is really an unfortunate decision coming from a KDE developer.
It doesn't show windows between the panel and the desktop? So what? How many windows do you place there?
The background doesn't slide when auto-hiding? Not a problem, just a minor "glitch" that will only affect a small number of users (those who need fake-trans AND auto-hide).
It doesn't handle different desktops? Well, that could be fixed.
It makes the code harder to maintain? Every single feature you can imagine will fit that description. It is not a real reason to drop a feature that would serve well so many people. I'm pretty sure you didn't have such reasoning when developing the rest of Plasma, so why does it apply now?
If code is really that hard to maintain, you always have the option to brainstorm the idea and refactor the code until its added complexity reaches a minimum. This is specially achievable when using object-oriented languages. But of course, as an experienced developer, you should already know that.
@Juliano: it's about striving for quality. it can take a while to get there, but we'd be guaranteed to never really reach it if we compromise poorly along the way.
"It makes the code harder to maintain? Every single feature you can imagine will fit that description."
absolutely; which is why we don't shove every possible feature in there but just the ones we feel we can maintain and make to co-exist peacefully with others.
"It is not a real reason to drop a feature that would serve well so many people."
see, that's exactly it: it wouldn't serve that many people that much. the cost to benefit ratio does not work out.
"I'm pretty sure you didn't have such reasoning when developing the rest of Plasma, so why does it apply now?"
yes, actually, i did have exactly this reasoning when developing the rest of Plasma: what are the costs, what are the benefits; what ways are hacks, and what ways are actual proper implementations?
that has been a constant and one of the overriding principles.
it's not about the "easy way out", it's about taking an approach that will pay off today and tomorrow and the next day, even if it's a harder way.
kicker was a bunch of "easy way outs" piled on top of each other. and we've gone, in a couple years, way farther than kicker ever did or realistically would have despite it having been around for 8 or so years.
*shrug*
when it comes down to it, it's about design.
@Sébastien: hello from Alberta! :)
"At least plasma should be able to show it's glory while not that costing."
i absolutely want plasma to show its glory. but i want it to be glory, not hacks that kind-of-sort-of look like glory but are really just disguises, especially not ones that leave the code in a bit of a mess which we'll have to maintain for years and years to come.
this is the kind of patch that results in bug reports that are simply not fixable, because they don't work properly and people end up noticing. we had a lot of those bugs in kde3 because of these kinds of features :(
"But how fixing UXA on my system will help reduce a load of 10.... And I'm not the only one."
making x.org actually rock and be reliable is what we are all working towards.
i know, having to be patient sucks. you should see how much hair i've torn out over problems in x.org and Qt in the last few years. :)
but when i see fixes in, say, nVidia's drivers that mention KDE4 and Plasma by name (several releases in the last 1.5 years have done just that), i know it's paying off and we're doing the right thing.
consistency in experience, demanding the promises of lower layers of software to be upheld.
Why does transparency work with say folderviews and not the panels. Am I missing something?
The transparency of folder-views here seem to be real, moving them over a note widget, or any other widget reveals the underlying widget. Couldn't such an option exist for the panel? I think this may have to do with windows vs. widgets but I'm still curious as to the "official explanation".
While it would be nice to have everyone's desktop use compositing with minimal fuss, I must say that kde4 w/o a composited panel doesn't ruin your experience of kde4. I have a video card that "supports" compositing and at reasonable speeds. Yet, I don't find a need to keep it on. I still enjoy kde4 and all it's functionalities.
If say, compositing the panels allowed for special functionalities then I could see where the massive objections will be worth while and vaild.
In any case this is open source, so if this feature is that important, I imagine some distro will take this patch and apply it to their packages so that their user base can use it, just like any individual can recompile the relevant packages from their distribution to support this. Somehow I don't see anyone doing this though.
It's interesting to see what issues the FOSS community jump on. Panel compositing as opposed improving plasma's speed to run better on older hardware or something (hint! hint!).
@AhmedG: "Why does transparency work with say folderviews and not the panels"
translucency works on the desktop and within the panel itself because we are doing all the painting ourselves. so Qt is doing all the compositing there.
the panel and the desktop (and the dashboard, and krunner, and the plasma dialogs..) are all separate windows, however, and windows are managed by the window manager and drawn by x.
to composite windows you need support and help from a compositing manager, which these days are generally built into the window manager so that the compositing and window management can be coordinated properly.
plasma isn't a window manager, however, and doesn't provide an x compositing manager. that's the job of kwin (or compiz, etc.).
and so plasma (like any other application) can't randomly composite different windows together.
there are ways to "fake" it, as in the patch in question, but it's not perfect and the performance will be worse rather than better.
"Panel compositing as opposed improving plasma's speed to run better on older hardware or something (hint! hint!)."
well, we're working on performance as well, right across the stack, and there have been (and continue to be) improvements there, too. :)
but yes, there are more important things than panel tranlucency to work on and worry about.
(and there's more to the blog entry than just that, too; more interesting things imo)
A small anecdotal comment: When i a year and a half ago was in the market for a new laptop, i had a few requirements. Firstly, of course, i wanted a laptop with the best open source graphics drivers our there, and my research indicated that that would be the Intel graphics chips named X3100, their flagship. So far so good. My second requirement was a high resolution screen at 15". Well, i found two laptops (one of which i bought) with a 1680x1050 screen resolution.
Now, what people at the time have not checked out, it seems, was that the Intel graphics chips do not handle high resolution displays particularly well, and as a direct result of this, my desktop will slow to a crawl if i've more than two windows showing at any one time with compositing enabled. This goes for vista and compiz as well, i should add, on at least two (very) different distributions, so it's not a driver/setup/whatever problem - the chip simply is not up to the job.
The short of the long is: My otherwise really powerful laptop has to run with compositing turned off, if i want to do anything more than just show off Plasma and KWin being cute and pretty.
i will not argue for or against your choices when it comes to patches, that's entirely up to your team. Just thought i would put it into perspective - you don't need bottom of the line hardware for the snazzy stuffs to not work. It is the case for top-of-the-line hardware as well.
P.S.: i understand that the Intel X4500HD performs better, but until i see that chip in action on a Full-HD display, i'll reserve my judgement on that one.
Without looking a the patch, is this Xrender? if so, its no hack, even kwin has Xrender support.
if it is, we should be including it. If it's not Xrender, then it's a hack.
@leinir: "you don't need bottom of the line hardware for the snazzy stuffs to not work"
oh, absolutely. there's lots of brokenness out there to be found.
that doesn't budge the cost/benefit of this feature one bit, of course, since it's not based on "does compositing work for everyone?" we know the unfortunate answer to that one already :)
it is sad that we're still seeing hardware and drivers being pushed out into the market that are so sub-par, and it's doubly sad that it pushes huge amounts of pressure as we go up the stack as we can see here with people willing to sacrifice quality and long term maintainability to make up for the crapitude of hardware and software we have to deal with. :/
it is one of the nice things for Apple: they just ship hardware they *know* works and so they don't have to deal with this stuff. that really simplifies things in a lot of ways for them, i'm sure.
@Aaron:
There is a very basic problem with your reasoning. This patch is written for the case that composition is not available, for whatever reason.
And for this case, there is no "proper"/"better" solution, so you've got to remove that point from your decision tree. It cannot be part of the solution if it's not available.
If you don't accept this as a special case, then it basically means that you simply repetitive ignore a large part of the users.
Ohhh come on now, compositing in general is pure crap, and having almost all plasma themes look crap, because not having it turned on is even crappier.
Ok, you can say that I'm not Joe user, that's why I don't use compositting, well one thing I do, that Joe user does, is play games, but compositting doesn't play well with 3d games, and as I see, it never will, cause I want the most FPS when playing. Well I can turn compossiting on/off, but that's the really hacky way of doing things.
Man like it would be so damm hard to add a "Fake transparency" option with a dialog explaining the inconsistencies...
If kwin's code is so good, as pointed out, it must allow this to be achieved via plugin.
There is something wrong in your reasoning though. You consider composition as a part of the "better" solution, although this patch is written for the case that composition is not available. In that case, composition is no viable solution, and that point should be removed from the decision tree.
If you don't consider this as a special case, then it essentially means that you're not interested in giving a nice desktop experience to about a half of the users. Do you seriously expect them to buy new laptops, new graphics-cards, and/or wait for perfect drivers until 2020?
The non-composition users are a very large, and very homogenous special-case, and thus relatively easy to support. Even any closed-source software company would decide supporting such a group if it was up to question, after all they're not even a minority. Still you refuse to support them and seem to be taking them as political hostages (Trying to push hardware-vendors to create better drivers), which simply isn't fair to those users.
"It is possible to make things look very nice without translucency (I know, because right now I'm using a system without compositing :), and there is a way to achieve it properly."
I am curious, what's your secret solution ?
I'd just like to say that I have a crappy graphics card which can only just handle compositing, so I leave it turned off, but I support your decision not to put dirty hacks into the plasma codebase.
(Partly because I used Kicker for years and know what a pile of hacks on top of hacks can end up like, and partly because I can always hope to get a better laptop one day!)
The problem IMHO is the following: have you seen any benchmark evaluating the 2D or desktop performance of a new graphics chip? I rarely have. It usually comes down to: FPS EGO shooter 1 at various resoultions and AA settings, the same with 10 other 3D games. Maybe some video playback tests.
No word about how the drivers handle everyday desktop use.
At the same time, even new graphics chips or their drivers cannot handle simple 2D operations like drawing circles or squares efficiently. I have done a lot of benchmarks and was shocked how slow operations are, even compared with 10 year old hardware.
So the point is: we should make the press aware of that problem everywhere we can so they include benchmarks of desktop use into their GPU reviews.
it is one of the nice things for Apple: they just ship hardware they *know* works and so they don't have to deal with this stuff
Amusingly, my WLAN card simply doesn't work with several of my friends' routers... when using OS X. Linux and ath9k work fine.
I'm glad to hear that you've taken on board some of the issues raised by the patch in the interests of graceful degradation. Is there any way to have an aesthetically acceptable set of defaults in the case where a theme doesn't handle corner cases?
I don't want to see windows between panel and background.
I don't want to see windows between my console in KDE3's konsole and background
I don't want to see windows between chat panel in X-Chat and background
I don't want to see windows between the game windows in KDE3's Tetris and background
Real translucency looks cool in many cases. Pseudo trancsucency looks cooler in many other cases.
So why new technology has to look less cool?
Another addition I would like to make is that while David's patch made the panel fake translucent, most problems with which have been very well explained in this blog article, this also doesn't change the fact that even with that patch plasma dialogs for example still have to be opaque. I'd rather have a nice looking fully opaque theme then an inconsistent theme: just think about what it would look like if you pop up the calendar from your shiny fake translucent panel, to see that the calendar is completely opaque. Worse then having an opaque panel imo.
Anyway, David had a good idea on how to make translucent themes look better in plasma properly without compositing: allowing to set a background color or image that is used as background when rendering the svg's. And then we'll have a solution that also works for dialogs and what not, without the hackiness. Much better right?
OK, I understand your point of view on the patch but you must also understand that there is an actual needed for the kind of hack it offers.
Maybe the problem is not your decision but the KDE's development method, that is maybe you should have some kind of branch with "ugly hacks" that distros can merge if they want that particular feature, although you do not officially support it.
I guess when you switch to git or similar this will be easier so that anyone can apply this patch and add an "enable fake transparency when possible" check box option. Maybe even other patches from OpenSUSE (such as remove the cashew) could live in that hacks/ branch.
This way you do not pollute the code and still allow for others to chose hacks for themselves even if future versions might break those hacks...
@leinir
i use a 13" sony vaio notebook with intels 4500MHD chip with kubuntu 8.10 and their kde 4.2.1 build from the private package archives with compositing enabled.
performance is quite decent and the system is more or less stable, too. though i expirience problems with kwin indeterministicly disabling compositing on suspend/resume (due to some slowness/timeout i expect).
like you i explicitly bought a notebook with an intel graphics card in order to leverage floss drivers. i was very disappointed when discovering that it did not work at all (except in vesa mode). after some months of tinkering with xorg/drivers it worked and now kubuntus PPAs provide patched packages, too.
out of the box none of the distributions i tried (kubuntu, opensuse, mandriva) shipped a working driver.
@aaron
with some expirience in maintaining software i can only fully support your way of dealing with such hacks. your work is (due to the miserable linux graphics stack) ungrateful but much appreciated at the same time =)
Well, for all the work that's supposedly going into performance, I sure haven't seen any results. Compositing works great in KDE 3.5. I can smoothly resize many KDE 3 apps with kompmgr running. Shadows work. Translucency works. And more importantly, it's fast. It's about as fast as without compositing. Now, why can't that be the case with KDE4 on the same hardware? Why is KDE4 so terribly slow and every release of Qt 4 slower than the last? Don't tell me it's the drivers, because they do fine with EVERY OTHER COMPOSITING MANAGER (xcompmgr, kompmgr, compiz, e16, xfce).
I just don't think the KDE4 devs really care about polish, only about glitz and glam that works on their machines. I really do like a lot of the work you've done, Aaron, with Plasma, but the rest is a terrible mess. Workarounds like the one that triggered this blog post are just indicative of a bigger problem. We wouldn't have to have workarounds like this if KDE4 was at least somewhat performant with compositing. Alas, it is not, and it doesn't look like it ever will be at this rate.
@Aaron
I appreciate your efforts to communicate the motivation behind the decision process in this or similar cases, and I thank you also for trying to explain the reasons for the "discrepancy" between transperency in plasmoids / and panels.
This may be a stupid question etc.
but why *has* the panel to be drawn by the Window Manager?
What would be the drawbacks of
* allow different panel configurations for different activities (which may be already an area of ongoing development), including the ability to remove the panel completly in certain activities while keeping the "default" panel in others
* provide a plasmoid that mimicks the panel (or at least the subset of operations a QGraphicsView handled panel could handle reasonably well without compromising the integrity of libplasma), including the ability to emply the same "fake transperency" hack as for example the folderview plasmoid.
I would be very grateful if you could comment on the merits of such an approach.
(for the record: Due to nvidia legacy drivers for some of my older graphics cards, compositing is disabled on most of my workstations. And so far, I was able to fend of the desire to have a transparent panel, so I can definitly live with the current implementation. I'm just curious what limitations in plasma and/or the "desktop metaphor" imposed by for example the wm would be, that would prevent such a solution)
I've had to use KDE 4.2 without compositing at work, and I can say that, aside from the initial adjustment it took to get used to a noncomposited desktop, its been a sheer joy to use.
I still get the nice hover tweens and animations that make KDE seem responsive, my panels look good, as do my plasmoids. There have been cases where I feel that the degradation could be a little better, but having been using KDE4 since the 4.0 release, I know that it just gets better from release to release.
FYI, the Elegance theme looks really nice without compositing.
I respect the need for code cleanliness over having bugs that are much harder to trace due to changes for cosmetic purposes. I also understand why this shouldn't be hacked in a half working application to application way (code duplication etc) so it really should be in X if anywhere.
What I don't get is how come full application translucency worked in Windows XP and it doesn't appear to have been hacked because it is very smooth and what should appear through the window does. (I'm looking at a little app Floppy Image 1.5.2 that can use it and I am also told Winamp could do it) All this 8 years before indirect rendering.
I remember X having something like that added some time ago but it ran quite poorly on the same machine if it did work at all and had to be activated by changing the xorg file.
Is this due to a lacking in X compared to the graphics server in XP or something way more complex.
Good decision, but I really wish that e.g. the nvidia drivers were more up to par.. I'm sick of all the visual blips that come with compositing, but I *do* want pretty!
@zwabel: "And for this case, there is no "proper"/"better" solution, so you've got to remove that point from your decision tree. It cannot be part of the solution if it's not available."
the proper solution is to use compositing. what's broken isn't plasma, but x.org, the drivers or maybe your hardware.
and i'm not about to compromise plasma's codebase for that, not for something as insignificant a feature a this.
"then it basically means that you simply repetitive ignore a large part of the users"
and making an unmaintainable mess that results in unfixable bugs and nobody working on the codebase because it's so rediculously bad in a couple years is responsible? of course not.
you have simply lost all form of perspective on this matter, Dave. you think that panel translucency is a critical feature and that code quality matters for nothing. that is so backwards it makes me choke.
@AIM: "compositting doesn't play well with 3d games, and as I see, it never will, cause I want the most FPS when playing"
for full screen games (and other full screen apps), kwin now auomatically turns off compositing.
@zwabel: "then it essentially means that you're not interested in giving a nice desktop experience to about a half of the users."
i'm very interested in giving people a nice desktop experience. and we do give people a nice desktop experience. more importantly, i'd like to continue giving people a nice desktop experience.
"non-composition users are a very large, and very homogenous special-case, and thus relatively easy to support."
... at the expense of maintainability and at the expense of looking amateurish.
"Still you refuse to support them and seem to be taking them as political hostages"
keeping the code base clean and maintainable isn't taking anyone hostage. we can afford to do this because there is a working solution today (composite) that is being improved and worked on so that it will be everywhere.
@Cryille Berger: "I am curious, what's your secret solution ?"
use compositing, and be happy with a pretty but non-translucent panel otherwise.
@James Ots: thanks :)
@MB: today's cards are dropping 2D support and mostly doing it through the 3D silicon.
still, that's almost neither here nor there on this one, as compositing using openGL is a purely 3D silicon issue.
@necaris: "Is there any way to have an aesthetically acceptable set of defaults in the case where a theme doesn't handle corner cases?"
yes, and i mention one such thing near the end of the blog entry :)
@LXj: "So why new technology has to look less cool?"
well, you're pretty firmly in the minority there. i don't know many people who look at kwin, krunner and plasma in kde4 and think it looks worse than kwin, kdesktop and kicker in kde4.
the important point is keeping plasma maintainable and flexible so we can continue to add to it. it's not about how many ways we can hang bling off it for the purpose hanging bling everywhere, but how we can make things look attractive, perform well and continue to shape it and improve it indefinitely.
@rpi: "And then we'll have a solution that also works for dialogs and what not, without the hackiness. Much better right?"
agreed.
@mootchie: "that there is an actual needed for the kind of hack it offers."
there's a *need* for it? no there isn't. there's a desire amongst some who don't care if it's a half-ass visual effect nor if it's harmful to performance or the codebase and future maintainability. those people are willing to make that tradeoff at everyone else's expense. i'm not. but there is no "need" here.
"maybe you should have some kind of branch with "ugly hacks" that distros can merge if they want that particular feature"
yes, that's one of the great things about free software. you can modify it and redistribute your modified versions.
it doesn't make it a good idea nor will it get my support, but that's something up to the downstreams.
the only downside for the plasma team is that we then get an increase in bug reports and user support load.
@Michael: "like you i explicitly bought a notebook with an intel graphics card in order to leverage floss drivers"
the last releases of the intel drivers have been a complete butcher job. it seems there is positive work going on now, though, so i'm hopeful. but yes, i'm in the same general boat as you now: deeply disappointed with the current state of the drivers.
"your work is (due to the miserable linux graphics stack) ungrateful but much appreciated at the same time =)"
thanks :)
@Joel: "Now, why can't that be the case with KDE4 on the same hardware? Why is KDE4 so terribly slow and every release of Qt 4 slower than the last? Don't tell me it's the drivers, because they do fine with EVERY OTHER COMPOSITING MANAGER"
i think you are confusing a few things here. first, if it's slowing "with every release of Qt4" you aren't talking about compositing performance, you're talking about toolkit performance which is entirely what is inside the windows, not the window management and compositing.
the reason for problems with Qt4 is a combination of drivers and Qt4 itself. both are generally being improved, though in some cases (e.g. the recent Intel drivers) we've seen some massive regressions in driver capabilties.
keep in mind that plasma (and some parts of Qt) stress drivers in different ways from most other applications, and as a result a number of previously uncared for or undetected problems have come to light.
"I just don't think the KDE4 devs really care about polish,"
i can only say that that isn't true at all.
"Workarounds like the one that triggered this blog post are just indicative of a bigger problem. We wouldn't have to have workarounds like this if KDE4 was at least somewhat performant with compositing."
the compositing performance has nothing to do with KDE4. compositing for plasma sucks just as badly on the affected chipsets with compiz as it does with kwin.
i think you're taking shots in the dark here and it's not fair to the people getting hit by your assumption based missives.
@setec: "I appreciate your efforts"
thanks :)
"but why *has* the panel to be drawn by the Window Manager?"
it's the only way to get panels on top of other windows. we could draw it on the desktop canvas, but then you couldn't have autohide, windows-can-cover-panels that pop up when your mouse hits the screen edge or even just slide a window down the screen and under the panel.
if we didn't want panels to ever be on top of windows, then no, it wouldn't matter at all :)
@Mr. Spontaneous: glad to hear :)
"There have been cases where I feel that the degradation could be a little better"
yes, there's one example given in the blog entry even; probably will see it in 4.3 :)
===
on a side note, it occurred to me to day that we reversed the flow of time and those complaining above had had plasma first they'd be shocked, horrified and aggrieved at having to use kdesktop/kicker due to all the things it lacks, the general lack of polish and what not.
what, no ability to manually group and order windows in the taskbar?! no compositing support?! no google gadgets or other desktop widgets?! and whats up with that horrible configuration dialog?!
funny ...
"i think you are confusing a few things here. first, if it's slowing "with every release of Qt4" you aren't talking about compositing performance, you're talking about toolkit performance which is entirely what is inside the windows, not the window management and compositing."
I am well aware of the difference between the two. I was rather pointing out that both compositing AND plain Qt drawing performance have suffered with KDE 4 as compared to KDE 3. Unfortunately, my hastily written post made that unclear.
"the reason for problems with Qt4 is a combination of drivers and Qt4 itself. both are generally being improved, though in some cases (e.g. the recent Intel drivers) we've seen some massive regressions in driver capabilties.
keep in mind that plasma (and some parts of Qt) stress drivers in different ways from most other applications, and as a result a number of previously uncared for or undetected problems have come to light."
Why are these issues not being fixed? I watch the Xorg commit logs and mailing lists regularly, and occasionally check the bugzilla and I never see these issues being addressed, at least in the open source Radeon drivers.
Also, if the drivers do have issues, why can't KWin fallback to using a smaller subset of features so that it can have performance on the same level as what I can get with the other compositing managers? I mean, all xcompmgr does is blit window and shadow images to the root window using XRender. Certainly KWin could have a simple fallback case (perhaps user-configurable) that would provide much better performance for people in my situation. As it stands, the XRender mode of KWin is almost worse than the OpenGL mode.
"the compositing performance has nothing to do with KDE4. compositing for plasma sucks just as badly on the affected chipsets with compiz as it does with kwin.
i think you're taking shots in the dark here and it's not fair to the people getting hit by your assumption based missives."
I can tell you with a straight face that compositing does NOT suck on the same chipsets with Compiz as for KWin. I have such a machine. Perhaps it is in a strange minority, but I very much doubt it. And as I indicated before, XRender-based compositing managers simply fly on my hardware, with the sole exception of KWin.
A well laid out piece on your reasoning. I can fully understand why you have made the decision you have especially when the codebase for Plasma is so young and under such intense development.
I'm a little lost on the whole compositing issue as it has never been an issue for me..... it's either worked or it hasn't and if it hasn't I work with what I have. Your point about a car could not be more spot on.
I'm happy that kwin supports(or at leas tries) games.
But I still can't understand this, cause this is a very simple hack, I can't imagine how will this affect the long term.
A lot of users, just want their desktop to work, and it's a very idiotic thing to make my machine slow as hell, just so that most of the themes will not look ugly.
It's just one damm hack, if plasma's code would be so great, than this would be a simple plugin. But how can you say that plasma's code is maintainable if small changes like this require core code, to be touched.
I understand how bad it is to work with hacks, and I don't think that there is any other place that has more hacks than web development. But a developer develops for the user, not for himself, and if something is badly needed by the user, it has to be done.
People don't care about code quality, they don't see the code, and they will never bother to look at it. And I don't understand, how come plasma renders transparency using software rendering? Isn't that a total waste of CPU power?
But seriously, how come this hack can't be achieved via plugin so it would not make plasma/kwin "dirty"?
But you can continue to ignore the wishes of the users, you can call them minority and strange people, and so on, but all I think you will ever achieve is a worst desktop than Vista+Aero, and you will loose your users, cause all you see on the Internet is people complaining about KDE4.
Aaron, I am aware of that. That's why it takes good drivers to produce efficient 2D on 3D hardware.
What I was trying to say is that reviews should include 2D tests, for two reasons:
1. I don't care whether good/bad performance is the result of the hardware or driver, but I want to know about how the card will perform on my desktop before I buy a card.
And 2, more importantly, only if such benchmarks are published, GPU producers will react and improve their product (incl. drivers) with respect to 2D.
@Joel: "I was rather pointing out that both compositing AND plain Qt drawing performance have suffered with KDE 4 as compared to KDE 3"
ah, yes, that wasn't clear. so .. the Qt issues have a lot to do with how Qt4 paints vs Qt3. some of it is Qt's fault, some of it is the sad state of xrender. there's a lot of work going on in Qt to improvement painting performance (visible in 4.4 -> 4.5) and xrender's days do seem to be numbered (thankfully) but we'll be stuck with it for a while. hopefully drivers get better at accelerating those calls.
"Why are these issues not being fixed?"
depends on who we are talking about. the nVidia team has been doing a great job of fixing problems as they are found. core x.org is a bit slower, though we now have things like "argb windows overlapping other windows result in holes in the other widnows until tey repaint" fixed now.
so they are being fixed, it's just not a trivial amount of work to get x.org (and in some cases, Qt4 code) to where it needs to be.
"XRender-based compositing managers simply fly on my hardware"
ah, XRender ... yes, that might vary radically between kwin and compiz. i really haven't tested that at all; the bulk of the effort these days is going into the OpenGL rendering in kwin, so i wouldn't be surprised with that.
@TheGreatGonzo: =)
@AIM: "But I still can't understand this, cause this is a very simple hack, I can't imagine how will this affect the long term."
i've explained how: by making the code more difficult to maintain, by impacting performance, by not actually being a complete solution that will therefore cause further complaints due to it being incomplete (and incompletable!)
"A lot of users, just want their desktop to work, and it's a very idiotic thing to make my machine slow as hell, just so that most of the themes will not look ugly."
first off, having random themes look great when that random theme is designed for compositing only is something we can only mitigate, not fix. the default theme we ship looks great in both composited and non-composited forms. that's our baseline.
as for not making things slow, that's one reason this patch was rejected.
"But a developer develops for the user, not for himself, and if something is badly needed by the user, it has to be done."
how badly is this needed by the user? it's really not a critical feature, nor does it impact any functionality.
"People don't care about code quality"
they sure do when it makes the code impossible to work with. people sure as hell cared about kicker's code quality when it came to the point that we tossed it out the side window and had to start from scratch.
people may not care about code quality itself, but they certainly do care about the *effects* and *consequences* of code quality.
@MB: "1. I don't care whether good/bad performance is the result of the hardware or driver, but I want to know about how the card will perform on my desktop before I buy a card."
that would be nice in those reviews, yes.
to make the information actually useful, they'd also have to test it with different toolkits as they stress the drivers in different ways and with different real world apps which also do the same.
it's a pretty difficult thing to measure objectively .. :/
@AIM:
"It's just one damm hack, if plasma's code would be so great, than this would be a simple plugin. But how can you say that plasma's code is maintainable if small changes like this require core code, to be touched."
sounds like another guy who latched on to the "plugin" buzzword and treats it like a panacea.
"I understand how bad it is to work with hacks, and I don't think that there is any other place that has more hacks than web development. But a developer develops for the user, not for himself, and if something is badly needed by the user, it has to be done."
Right, you sound like a web developer. So let's explain it in terms that you (may) understand. Remember when IE6 ruled the roost? All of us had to maintain conditional comments all over our code just to hack things into working for the average Windows-toting Joe.
Now we're starting to get public user-serving sites who actually have the gall to use conditional comments just to lay a notice on the user saying "you're using a piece-of-crap browser, upgrade or live without our cool Ajax shit". Why? Because it's plainly apparent that there're enough users using standards-compliant browsers.
How do the developers know? It's simple for the browser market 'cos every hit registers a user agent on the logs and there're people making a living collecting statistics on things like this. So right now, things are just starting to get better for us 'cos we can finally throw out them bunches of ie.js code we've spent up to 40% of our time maintaining.
Now let's relate this scenario back to KDE. I'll equate KDE3's time to the time when IE6 was the king of the hill. KDE developers had a fat chance of even hoping hardware manufacturers would give them the light of the day in terms of releasing decent drivers. So,hack after hack was introduced just to give KDE3 the excellent reputation that it deservedly has.
Now, Linux in general has some form of recognition. PC sales statistics are inaccurate because most of us run Linux on machines that came bundled with Windows. But in general, everybody is coming to terms with that fact that this particular group of Linux users no longer can be ignored.
So, if we don't make a stand right now and let the manufacturers know that it's their responsibility to ship proper working drivers for their hardware, how would they become convinced that the Linux market has become too large for them to ignore?
This cannot be accomplished by smoothing things over just to ensure that the average Linux-toting Joe has all the desktop bling-bling that he demands. And given that Linux desktop users typically got their operating system for free, some of these same users sure make it sound like they just shelled out for a copy of Vista Ultimate.
"People don't care about code quality, they don't see the code, and they will never bother to look at it."
They will when some flaw appears due to unclean code and hacks. And then they start blaming the same developers for not coding cleanly in the first place. This happens to all forms of software development, be it web or otherwise.
AIM, you make no sense and some of the other facts that you stated in your comment are just plain wrong.
It is really confusing how the plasma team uses double standars to meassure things, sometimes they reject or aprove something because according to them "It is what users are asking" and sometimes the meassure is with "is not good for the code".
It wouln't be bad but one thing just contradicts the other, and the question is, what are the priorities? Users or code.
I can see the reason why that hack would be rejected, but the excuse used to rejecteit is not the right one.
For example, an option to removing the cashew it is what users are asking but they get the answer "It would make the code complex", oh come on, we are not 10 years old and we can see is a no brainner, now, if the excuse is "We think the cashew gives some identity to plasma and KDE and we think is the right desition to leave it there", now that is a credible excuse.
In summary, I think KDE4 needs a fork.
@Wong: "sounds like another guy who latched on to the "plugin" buzzword and treats it like a panacea."
Well actually it's not just a buzzword, it's the right way of doing things, allowing people to modify the behavior of your application without forking your code is the modern way, I don't think you can argue with that.
"Right, you sound like a web developer. So let's explain it in terms that you (may) understand. Remember when IE6 ruled the roost? All of us had to maintain conditional comments all over our code just to hack things into working for the average Windows-toting Joe.
Now we're starting to get public user-serving sites who actually have the gall to use conditional comments just to lay a notice on the user saying "you're using a piece-of-crap browser, upgrade or live without our cool Ajax shit". Why? Because it's plainly apparent that there're enough users using standards-compliant browsers."
You forget that they have got there with conditional comments and IE hacks in the first place.
"How do the developers know? It's simple for the browser market 'cos every hit registers a user agent on the logs and there're people making a living collecting statistics on things like this. So right now, things are just starting to get better for us 'cos we can finally throw out them bunches of ie.js code we've spent up to 40% of our time maintaining."
No we don't we still have IE7, and it still dominates the market, and it still has no clue about web standards, I hate it, but that's no excuse. I can't tell 60% of the visitors that the bad rendering is their browser's fault. Ignoring IE would not make the browser look bad, it would make the website look bad. It's not fun, it's mostly hell, but that's what the user's demand.
"Now let's relate this scenario back to KDE. I'll equate KDE3's time to the time when IE6 was the king of the hill. KDE developers had a fat chance of even hoping hardware manufacturers would give them the light of the day in terms of releasing decent drivers. So,hack after hack was introduced just to give KDE3 the excellent reputation that it deservedly has."
Yes, the same reputation that it's loosing at the moment.
"Now, Linux in general has some form of recognition. PC sales statistics are inaccurate because most of us run Linux on machines that came bundled with Windows. But in general, everybody is coming to terms with that fact that this particular group of Linux users no longer can be ignored."
Now is the time, where the Linux desktop needs to attract the most users, but how will it, if some things appear broken?.
"So, if we don't make a stand right now and let the manufacturers know that it's their responsibility to ship proper working drivers for their hardware, how would they become convinced that the Linux market has become too large for them to ignore?
This cannot be accomplished by smoothing things over just to ensure that the average Linux-toting Joe has all the desktop bling-bling that he demands. And given that Linux desktop users typically got their operating system for free, some of these same users sure make it sound like they just shelled out for a copy of Vista Ultimate."
No matter how good the hardware gets, compositing will still be an unnecessary resource hungry optional feature.
"They will when some flaw appears due to unclean code and hacks. And then they start blaming the same developers for not coding cleanly in the first place. This happens to all forms of software development, be it web or otherwise."
Ok, two steps, make a directory called "ugly_hacks" and put all your .cpp's .h and .js there, and you are done, that wasn't that hard was it?
"AIM, you make no sense and some of the other facts that you stated in your comment are just plain wrong."
Ask the users and you will see if I'm wrong or not.
@Aaron:
Thanks for responding. If I understand your correctly, then it seems that for a large part of the non-compositing audience (e.g. those folks that have a vanilla-always-the-same-size-always-on-top panel) a "paneloid" would allow for fake-transperency without needing corner-case hacks like in the proposed case.
Are there any plans for supporting different planel - configurations per activity in the nearer future?
@AIM:
"I understand how bad it is to work with hacks, and I don't think that there is any other place that has more hacks than web development."
As an Ex-Webdeveloper and someone who is nowadays as an software developer for embedded software, I have to respectfully and strongly disagree on this (don't get me started, really).
"But a developer develops for the user, not for himself, and if something is badly needed by the user, it has to be done."
The question how "badly needed" something is should of course be open for discussion, at least if the said piece of software is not developed for a single purpose or group of customers as per spec but has to work in a lot of different, probably even mutual exclusive secnarios?
Plasma is generally criticised for putting form (e.g. bling) over function. I don't necessarily share this opinion (my desktop is the un-blingiest thing in the world, sometimes, especially when I'm bitten by the nhilist bug, I even opt for a non-chromatic black wallpaper :-D ), so why is it that a hack that is really just a superficial sugarcoating (as stupid as it may sound to an old-fashioned guy like me, but a "real" transparent panel which allows for windows below it has some tangible uses, apart from its looks) is suddenly the litmus test which helps us decide whether the plasma devs are bunch of self-centered bastards or responsible and benevolant community players?
"Once you had a good excuse, you opened the door to bad excuses" Terry Pratchett - "Thud!"
@Ramsees: There you go: http://imagebin.ca/view/kYPOOY.html
@setec: "a "paneloid" would allow for fake-transperency without needing corner-case hacks like in the proposed case."
yes; we don't have the ability to choose the kind of panel containment you want in your panel like you can for the desktop and dashboard views, but that's because nobody's added such a thing to the panel configuration.
it already supports this "out of the box" and while such a PanelContainment plugin would have to do some fairly ugly things to accomplish it, it might even work better than Dave's patch.
in theory, it could look through corona()->containments() for a DesktopContainent with matching desktop() and put a sceneEventFilter on it (though this wouldn't work too nicely if the user switches desktop containments) and whenever there is a paint event that intersects it's screen position (built in assumption is a single view; would break if we ever support multiple views, e.g. to have panels span multiple screens) then call paint(..) on its view with a QPainter on a local pixmap. not pretty and with lots of assumptions in it, but that's kind of how it is.
Come on everybody, all Aaron is saying is that he doesn’t want to include a patch for a minor cosmetic feature which doesn’t meet his standards for code maintainability and structure. Ask for better compositing support and ask for themes which look great without translucency (yes, that’s possible) and I’m sure he’s happy to support you and you get a good-looking desktop as well. Remember: He has to maintain the code and work with it every day and if you think that fake transparency is SUCH an important feature for a panel I’m sure you won’t be held back by having to compile it by yourself.
@setec: "As an Ex-Webdeveloper and someone who is nowadays as an software developer for embedded software, I have to respectfully and strongly disagree on this (don't get me started, really)."
Try me.
"The question how "badly needed" something is should of course be open for discussion, at least if the said piece of software is not developed for a single purpose or group of customers as per spec but has to work in a lot of different, probably even mutual exclusive secnarios?
Plasma is generally criticised for putting form (e.g. bling) over function. I don't necessarily share this opinion (my desktop is the un-blingiest thing in the world, sometimes, especially when I'm bitten by the nhilist bug, I even opt for a non-chromatic black wallpaper :-D ), so why is it that a hack that is really just a superficial sugarcoating (as stupid as it may sound to an old-fashioned guy like me, but a "real" transparent panel which allows for windows below it has some tangible uses, apart from its looks) is suddenly the litmus test which helps us decide whether the plasma devs are bunch of self-centered bastards or responsible and benevolant community players?"
Just go over the themes, and compare them, how do they look when compositing is on and when it's off, you will get the picture of what's the problem here.
I really don't care what's under my panel, if I would, I wouldn't have put it there in the first place. But that's just half of it, I however do care about my panels blending in with the wallpaper, if the theme was designed to do so, and that in my humble opinion has nothing to do with the first thing.
Same goes for yakuake, it's cool that it blends in with the wallpaper(KDE3) but it's uncool that it wastes my time, in KDE4 just because it shows what's under it, again, this is a case where fake transparency is cooler. Even if yakuake would be as fast as it used to be with "real" transparency I would prefer fake transparency just because I don't care what's behind a yakuake console.
The reason I don't use the KDE4 desktop is because it's eighter ugly, or slow and does a lot of useless things. I prefer neither of them, cause KDE3 is both beautiful and fast.
And I could not care less about how many hacks kicker contains, because at least I can place an applet where I want to without using hacky panel spacers and friends(I already wrote about this).
One must love FOSS!
So much fight for transparent panels, which are not really transparent to start with!
Ok, I might start blabbering gibberish so, take it with a grain of salt.
Instead of all this fuss, why cant we allow the panel to be "themed" with its background wallpaper? Let plasma have an interface for a plugin to demand the wallpaper pixmap and then statically theme the panel. PS: You need to call the "plugin" every time the wallpaper is changed.
So someone can make this as a theme, and then be the one to maintain the hacks!
@AIM
"Try me."
Ok, I guess we could exchange war stories forever, I'm a bit sensitive to this topic because I recently had to deal with a share of "customer specific hacks" that resulted in destroyed hardware (two rather expensive, high speed cameras, for example) whereas the biggest crime in terms of web development I had the dishonor to deal with merely made the w3c validator go spare while producing gibberish on browsers different to IE 5.0 (it's been some time since I had to work in the CMS salt mines, bear with me).
If you insist, we can call it a tie.
"Just go over the themes, and compare them, how do they look when compositing is on and when it's off, you will get the picture of what's the problem here."
Judging the aesthetical quality of themes is highly subjective, but at least oxygen, sculpture and aya look fine to mee even if compositing is turned off, which is all I ever used and feel qualified to compare. In fact, I was rather astonished that suddenly my panel was blueish when I finally did the upgrade to KDE 4.2.0, took some time to realise that the translucency of the panel defaulted in my installation to "on" if capable hardware was found.
"I really don't care what's under my panel, if I would, I wouldn't have put it there in the first place. But that's just half of it, I however do care about my panels blending in with the wallpaper, if the theme was designed to do so, and that in my humble opinion has nothing to do with the first thing."
I've seen people making use of the screen real estate behind the panel on small netbook displays, especially with sparely populated vertical panels.
There may be different useage scenarios for placing windows below a panel that I can't think of at the moment, because the whole Idea of a transparant panel is a bit lost on me.
Yet there certainly are other options worth exploring to better integrate themes with wallpapers: Theme creators probably should spend more time trying to improve the look of their creations in the absence of compositing effects, using the color of the wallpaper portion behind the panel may be used to hint the colouring into the right direction, the idea mentioned below with the background image in the panel may or may not be cleaner than the proposed patch, etc. .
And while I don't want to comment on the relative importence of fake- vs. true transperance with respect to your use patterns, I can understand very well why the plasma developers decided that this issue was of not high enough importance to warrant an exception to the "no hacks, please" rule,
especially since the job description of a panel contains transperancy not necessarily within the first 100 items or so.
I really hate to turn this argument in that particular direction, but keeping the code base clean is in the long run objecte as legitimate as pleasing all potential or actual users, especially given that users seem to have been statisfied with kicker in the past, yet finding developers who were willing and capable to do the grunt work was obviously not that easy. The ball is - in the end - in the half of the developers who have to work with the code.
I have to agree with aseigo. This fake-transparency, i hate it soo much. How does it help?? It's not even transparency! It's the background wallpaper somehow hacked into the panel... and if you move the panel, the wallpaper in it has to be updated.. if you move widgets on it too... it's a big mess not to forget updating the panel... just remember how it was with kicker!
please guys... if you like to have a clean solution, take composite. And if it doesn't work for you, don't blame KDE, but blame xorg/nvidia/ati whatever. I basically like it how we did say goodbye to this fake stuff and have a clean solid background instead. Just like the e17 crew didn't use fake transparency too, but use xshape instead ... *that* is till better than this screenshot-fake crap because it's *real* transparency - with 1 bit alpha channel depth.
Also remember the Qt3 days where you had shadow for the menu, and when you opened another menu, text of the previously opened menu appeared in the shadow of the now-opened menu, because the window below it didn't redraw fast enough... what a mess.. i'm glad those days are counted.
It's amazing how patient you are Aaron.. :)
Hugs from Bologna, Italy
Although i would have liked fake transparency, I can pretty well understand why you rejected it. As far as I understood, KDE4 is a complete rewrite of the KDE Desktop, and I see it is very important to keep the code clean.
Furthermore, this is a feature of very low importance, and should therefore only be implemented if it doesn't taint the rest of the project (which it apparently does).
I read somewhere that KDE4 should be developed for the present and not for the future; that's (sorry) not what I think. I think it is a wise decision to develop it for the future, simply because the overall result of the development will be just better in this case.
Best regards,
Sven
Hello, thought I'd add my two cents to the discussion:
As far as KDE 4.3 goes, one of the selling points seems to be "it's pretty". More specifically, the new Air theme which is absolutely gorgeous.
Problem is, this isn't pretty at all:
http://zwabel.files.wordpress.com/2009/03/non_transparent_panel.png
@Aaron, as you said, the solution generally is to enable compositing. I understand you can't do jack about KDE-look themes that look like crap without compositing. But you KDE folks can do something about Air looking like crap without compositing.
Two suggested fixes:
1. Ship another theme with KDE, say, Air_noncomposite or something, which has a different panel graphic that isn't a crap-looking gray bar when compositing is turned off.
2. Is it feasible to add/modify theme construction so that each theme would include two panel graphics, one for compositing, one for vanilla settings, and have a tickbox to change which panel is being used?
This way the non-compositing people could have a nice-looking desktop like the rest of us.
Blimey, what's with all the people complaining? I hated Gnome's fake-transparency option, I hated Kicker's fake-transparency option and, quite frankly, if I want my computer to look pretty I'll buy a computer that can look pretty.
It's like suggesting that Windows XP works great on old hardware, but you won't use it because the panel isn't transparent. Get a grip!
There is a troubling sentiment in many posts here: That people with non-composited desktops aren't entitled to a pretty desktop, and that compositing is The Only True Way To Prettyness (tm). To me, this sounds like a load of bullshit.
Even if it's becoming more and more common every day, compositing is still somewhat of an extra feature, and, even if the compositing-enabled customer is the main one, it's no reason to treat non-compositing customers as second-class citizens. Fake compositing brings problems, so I see two simple solutions which I outlined in my post above.
On top of it all, making a new panel graphic for Air and including this non-composite version shouldn't be hard at all to do and would drastically improve many people's user experience of KDE.
@Teron: "That people with non-composited desktops aren't entitled to a pretty desktop, and that compositing is The Only True Way To Prettyness (tm)."
compositing is the only correct way to certain kinds of pretty effects, but that doesn't mean that systems without compositing available can't be pretty. so you've erected something of a strawman there.
"compositing is still somewhat of an extra feature"
so is panel translucency.
"no reason to treat non-compositing customers as second-class citizens"
stop making this into a "we're treating people badly" thing. this is a computing issue not a "person's feelings" issue.
and yes, computers that can't do compositing _are_ second class computers.
just like computers that can only do 256 colours at a time are second class computers.
when a computer can do more things, it gets to present more features. it's really that simple.
"2. Is it feasible to add/modify theme construction so that each theme would include two panel graphics, one for compositing, one for vanilla settings, and have a tickbox to change which panel is being used?"
a tickbox isn't needed; it already switches between them automatically when compositing is on or not.
we _do_ care about the non-composited situation and that's why i implemented such a feature way back in 4.0
How come plasma widgets get transparency at all costs and the panel doesn't?
I appreciate the fallback feature in the themes, I really do, but it's a shame that Air's fallback seems a little disappointing, it's way better than Oxygen, so the guys who made it are heading in the right direction, but I feel that, it could have been a lot better.
"How come plasma widgets get transparency at all costs and the panel doesn't?"
plasma widgets are all drawn in the same window so Qt is able to do the translucency and all the fancy painting itself.
the panel, however, is a top level window. blending top level windows together requires cooperation from the x server via composite.
so it is two _completely_ different issues.
(faking panel translucency (poorly) by painting bits of the background wallpaper directly is a non-starter for reasons i've already covered above.)
So this means that the X server sucks for not giving a feasible option for this like Qt does?
@AIM: must everything suck to you?
@Wong: What if I say yes? It's my opinion, right?
What if I say no? There are so many projects out there surely one must "not suck" to me.
Either way it's my own opinion, which people may or may not care about.
But anyway this was not even an opinion, it was a question.
grrr, pressed the wrong button on the comment moderation panel and there's no "undo" (gah! stupid web apps!). here was a comment from "Roxas Hitachi":
@OP:
I agree completely about the keeping the code clean. One of the reasons
I think that GNOME is so random, glitchy, and ridiculous is the lack of
clean coding. In my experience, code that is overly cluttered just
creates mountains of bugs. If something is going to get done, it might
as well be done the right way. Props to the devs who make KDE possible!
Post a Comment