Message: previous - next
Month: April 2012

Re: Re: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue

From: Martin Gräßlin <mgraesslin@...>
Date: Sun, 22 Apr 2012 12:05:21 +0200
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!