setting default widgetStyle (and ColorScheme)

[Martin Graesslin]

On Monday, November 30, 2015 3:01:40 PM CET René J. V. Bertin wrote:
> Martin Graesslin wrote:
> > what you put on review board is in my opinion not a minimal modification.
> > That are lots of ifdefs and each ifdef is a huge burden for the
> > framework. It means
> ...
> 
> > Given that: we need to be extremely careful when we consider adding
> > platform specific code and need to evaluate very careful the advantages
> > for it.
> I won't argue that, and I'll repeat that I have no issues splicing the code
> into a few dedicated files, moving the "ifdefs" to the CMake file.
> It's what I ended up doing with the changes required for kdeinit5, but that
> concerned a lot more ifdefs.
> 
> That'd put the maintenance burden on people who care about the code and the
> platform on which it's supposed to function.

That is in deed a better approach. I'm still questioning whether it's the 
right thing to do on OSX, but that would then be up to the OSX developers to 
decide on. 

But if the platformtheme plugin does get moved to Plasma I would say that it 
doesn't belong there as I think Plasma should only care about targeting X11 
and Wayland. That's something the Plasma team needs to decide on, though. At 
the moment we (to my knowledge) don't have a restriction on that. Only KWin 
specifies itself to only target xorg windowing systems (that is X11 and 
Wayland).

> 
> >> Would there be a point in disallowing someone to run a full plasma
> >> session
> >> on a platform that allows it and that isn't Linux?
> 
> ...
> 
> > So there is no point discussing that. It will never be possible to use
> > Plasma on OSX or Windows as it's at least not possible to port KWin to
> > these platforms.
> 
> "Never say never" mean anything to you?

Sure! It's not possible to exchange the Quartz compositor. This means: never. 
Sorry to say, but I have been in the WM business a few years now and I know 
what's possible and what isn't ;-)

And that doesn't restrict to OSX. It's also not possible to get Plasma on 
GNOME Shell or Plasma on Unity for pretty much the same reason: it's 
impossible to exchange the window manager.

> 
> Regardless, my remark was a purely rhetorical question (OS X is indeed not a
> platform that currently allows to run a full Plasma session without severe
> hacking). With all due respect, your reaction sadly supports an impression
> I have been getting that I probably best leave unvoiced publicly...

Better state clearly what you mean instead of hinting things.

> 
> So KF5/Plasma removed the possibility to use a window manager that's not
> KWin?

No. But Plasma is a coherent product consisting of well integrated components. 
If you talk about Plasma as a product it includes KWin as the window manager. 
If you remove KWin as the window manager, you might be using plasmashell, but 
that's not Plasma anymore in my book (and probably also for all other Plasma 
devs).

> > I don't think we should add the ifdefs you proposed in the review request
> > because you don't like OSX default settings. We need to look a little bit
> 
> It's not just I, and it's about just as much to do with the general
> princpiple of allowing user choice (something *I* am -almost- religious
> about) and not introducing regressions w.r.t. KDE4 .

Honestly: if the "allow user choice" means introducing ifdefs, then I don't 
care about it. Everybody is free to have all the choice they want, but don't 
make your wish for user choice cost for others.

That's similar to running Plasma without KWin: yes it's possible, but don't 
expect us Plasma devs to spend time to fix issues you get when not using KWin. 
You have the freedom of choice, but don't expect that anybody else cares about 
that ;-)

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151130/dd48bef2/attachment.sig>