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


