On Sunday 22 April 2012 00:10:36 Nix wrote:
Just for the record, 4.9 (current development) does not depend on libkephal, does not depend on libkworkspace4 and that should also remove the dependency to libnepomuk4 (though that could be a dependency of kdebase-runtime)
So... you suggest that Trinity switch to KWin4, even though in order to avoid depending on big chunks of KDE4 this would require us to switch from a stable window manager to the *trunk* of kwin 4 -- this in a system for which stability is the entire reason for its continued existence...
First of all you should not imply that the stability of "trunk" is a problem at all. KWin has a policy to never introduce stability issues. We have many developers running the KDE Plasma Workspaces from git master and of course we never want to break their setup.
Furthermore I have been using KWin from git master for several years now without any issues. Trust me I don't want an unstable window manager - that really sucks.
Now to whether I want you to depend on the git master version: we are two or three weeks before feature freeze of 4.9. At the time of feature freeze the version is "done" and we developers start to concentrate on the next version 4.10. So yes if I want that Trinity is using KWin I suggest to use 4.9 which is from developer perspective already the current version.
and even though this would suddenly mean that we would completely lose kcmshell integration (since kcms for kcontrol 4 are hardly going to work in kcontrol 3).
No, you missed an important part I already pointed out: our configuration modules have hardly changed since 3.5 due to the fact that they don't use ui files. You can just continue to use kcontrol 3 modules to configure a KWin 4. There are things which have new controls but in that case the functionality did not yet exist and the configuration of the window manager is accessible without using kcontrol or systemsettings at all.
You suggested running 'kcmshell4 style' by hand, but I hope you were joking: we can't expect end users to do that for no reason other than 'keeping Martin happy'.
No I'm not expecting users to do that. I'm expecting that TDE would install a default configuration file with the appropriate setting. My understanding is that this is a developer mailinglist, so what I write here is addressed at *developers* and not at *users*. Giving *developers* the information how to setup is the requirement that *developers* are able to ensure that *users* don't have to do so.
This change would also foul up the look and feel, since Qt4 and Qt3 themes simply do not look that similar -- even what is allegedly the same theme has disconcerting differences in appearance, and now those differences would be reflected in the decorations of every single window.
No the decorations do not use the Qt style at all. Decorations use the KWin style and the style does the complete rendering. E.g. the KWin style Plastik (used to be the default in KDE 3) has not changed at all in KWin 4.
This is not looking like a net benefit. Not at all.
So you say it's better to keep a fork alive which you cannot maintain because the looks mismatch instead of just implementing a theme which looks pixel perfect the same. Good idea!
Cheers Martin