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
Attachments: