22 Apr
2012
22 Apr
'12
10:05 a.m.
On Sunday 22 April 2012 00:10:36 Nix wrote:
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.
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... 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