On Friday 01 May 2009, David Nolden wrote: > >On Friday 01 May 2009, David Nolden wrote: > >> This already looks quite nice. But since many plasma themes have a > >> glassy look, they highly profit from something more shining through > >> them, since that's the only way they can retain that look. Transparency > >> is not > > > >and if you want that, use compositing. > > Composition is simply not an option. And for some users, it never will.
that doesn't mean we need to, or should, try and fill in that gap. > >it's not a must-have feature and is > >exactly the kind of "well, we'll just cheat a bit when it's not > > compositing" feature i am so not favor of. it leads to: > > > >* more configuration UI > > Useful configuration every configuration is useful to someone. that is not a justification, and it certainly doesn't help the people who have no need for it but who have to put with having to figure out the resulting configuration systems. this is not kde3. this is not a dog's breakfast of shitty dialogs with dozens and dozens of configuration widgets in them each. > >* people using compositing asking for it > > Then don't deny it from them, it's a nice feature for everyone right, which means the configuration UI braindamage extends everywhere, we end up with "theming" now being a chimera of multiple code paths spread across libplasma and/or the shells ... no. > >* more difficulty in q/a as we have more variables to test for and code > > around > >the idea really is to degrade gracefully *from* compositing to non- > >compositing, not to add features to non-compositing that aren't available > > in the compositing case. > > > >non-composited desktop should look good and work well, but they are not > > the primary target. they are a supported secondary target. > > Plasma is an essential part of KDE. Now you define that non-composition > users are not the primary target of KDE? Why is about 50% of all users not > the primary target? * their computers are not the primary target; they can always get a different computer and enjoy it. this is not about the *user* but about their *hardware*, so it's not a bias against a certain group of humans. * as time goes on more and more of the systems people have do compositing very nicely. many do already and in the not so distant future it will account for the overwhelming majority of systems in use. * i'm not willing to commit to supporting what amounts to work arounds and/or additional code paths (and all the complexity and half-proper features they bring), given the above (btw, by "half-proper" i mean things like "doesn't actually fully work or look correct"; that's not a "code correctness" issue but a "doesn't look like a joke" issue.) > >because the next step along this path is "why don't we show window > > thumbnails using screen grabs in the tooltips when there is no > > compositing" and on and on. result? a bloated, horrible mess that has > > lots of sorta-kinda working features in the non-compositing case. > > As an intelligent human, you should be able to compromise. i am quite capable of compromise. i also know when not to. just because one can compromise does not mean it is what one does in every single situation. > You have learnt > from the mistakes done in kicker, and you don't have to repeat them. But well, you're kind of asking me to. > still you cannot deny some essential features, eg. a nice looking Desktop, the desktop looks nice. > from such a large number of people. i completely reject that it's a significant %, esp in relation to the % of people it would end up affecting negatively due to configuration UI additions and complexity of the code base. it's a struggle to keep it as uncomplex as possible but no more so (in other words "as complex as it absolutely needs to be") > I agree that this is very close to the > border, but you can also say "until here and no step further". thank you for recognizing that. and in case you haven't noticed by now, i've been saying that. it's not where you want the line to be drawn, but that's just how it goes sometimes. > >the colour does not belong in the config file. it should come from the > > theme itself, allowing it to track the desktop colour scheme if that's > > how the theme is set up. this could be overridden by the active wallpaper > > for that screen/desktop, perhaps, so that wallpapers can say "here's a > > good matching colour". > > The color needs to find its way from the desktop shell into krunner, kwin, > etc., so how should that happen without a configuration file? let me rephrase then: the colour does not belong in the plasma-desktop config file as some part of the configuration of that application. it belongs with the theming support and should have zero user interaction (as in "if the user changes it, it will likely be overwritten") -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
