Message: previous - next
Month: April 2012

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

From: Martin Gräßlin <mgraesslin@...>
Date: Mon, 30 Apr 2012 19:00:39 +0200
On Monday 30 April 2012 18:31:12 Julius Schwartzenberg wrote:
> One thing that is not fully clear yet however. Kwin4 is not able to
> integrate anymore with a Qt3 and kdelibs-v3 (Trinity) based environment
> as far as I am aware. Basically the sources have been migrated to the
> newer libraries
Yes, the sources have been adjusted to Qt4/kdelibs4 and I have no idea whether 
it would be possible to get it Qt3/kdelibs3 way again.

The sources will soon start to be adjusted to Qt 5 and kde frameworks 5 which 
will result in a much smaller library footprint, btw.
>, which is the reason for the current fork.
no, the reason for the current fork is that Trinity forked everything and the 
kitchen sync instead of concentrating on what is missing from KDE 3.5 in 
current KDE 4.x versions.

Applications like KWin should never had been forked in the first place. 
> In another message in this thread however, there was a mention that
> kwin4 still has references to kicker in its source. What about other
> facilities like DCOP?
DCOP has been completely replaced by D-Bus.
> Basically my question would be, which advantages would kwin4 have at
> this point over other window managers like Metacity or Sawfish regarding
> integration with the rest of Trinity?
You cannot easily switch window managers for a desktop environment. There are 
very often quite specific hacks and slight mis-interpretations of the EWMH 
specification and there are many KDE specific extensions to NETWM which only 
make sense in the context of a KDE desktop environment. 

It is unlikely that an application like Kicker would work correctly with 
another window manager. E.g. it never worked correctly with Compiz.
> The toolkit difference seems to be
> equal to me and I would expect the integration problems to be the same
> as well.
The toolkit difference is much smaller and actually a non-issue. As I 
mentioned in this thread a few times: the visual part of the window manager is 
the window decoration which is basically unchanged between KWin 3 and 4.

Apart from that there is the window menu which can be rendered using the 
Plastique Qt 4 style which is AFAIK the same as the one of KDE 3.

This means visually there is just no difference.

Furthermore any developer who worked with Qt 3 will be able to still work on 
KWin 4 - the basic concepts like Signal'n'Slot or C++ are unchanged.

Also it remains whether Qt 3 is the future of Trinity of whether the problem 
will go away by Trinity transiting to Qt 4. But that's nothing for this thread 
> The current advantage I do see for kwin4 over the others is that its
> behavior is the closest to twin, because it's the same code but evolved.
> Another is that the themes are the same. I guess there are more
> advantages though? It would be interesting to have a good overview of this.
A good plus is that the code is maintained (which is not the case for Metacity 
for example), actively being developed, bugs get fixed in a short time. Crash 
free, one of the three largest window managers in use (together with Mutter 
and Compiz). Supports Desktop Integration through for any desktop environment 
through KWin scripting. Allows adjustment of window manager behavior for 
basically any use case through scripting (side note: my talk at this years 
Akademy has the title "Window Manager construction toolkit").

Overall KWin has features to build your own window manager for your desktop 
shell. That's something no other window manager provides to my knowledge. We 
already can serve as the Window Manager for three desktop shells, which can 
also not be reached by any other window manager.

KWin scored 4th place in the category "best window manager" of this years 
Linux Questions Member Choice Awards although KWin does not belong in this 
category (it means "standalone" window managers). It scored first place in the 
category of best Desktop Shell, though :-)