> > If a switch to KWin4 would mean that new releases of TDE no longer work on
> > RHEL6 and clones then I think this is a very bad move.
> 
> Initially I would expect kwin4 to be shipped next to twin, so this issue
> will never occur.
> 
> Also, I do not think the impact of shipping a Trinity
> specific Qt4 that only contains the dependencies needed for kwin4 would be a
> huge issue. Maybe it is even possible to compile kwin4 statically on
> such platforms?
> 
> Basically what is needed now is that a Trinity (or maybe
> just a non-KDE4 specific package?) is provided. The next step would be
> testing.
> 
> Then maybe some work could be done to enable configuration
> in a proper way. Of course right now configuration would be a mess
> because each DE has its own Control Center/System Settings and the window
> managers that exist now all integrate into their original target DE only
> regarding configuration.
> 
> 
> My prediction, as someone who is just observing:
> 
> Nothing is going to happen on the Trinity side regarding
> this (soon). Not because people are not interested, but because of
> limited developer resources. Twin works and the work needed to get kwin4 is
> cleanly integrated at least _appears_ to be bigger than keeping twin
> fixed. Keeping twin fixed right now is just a single fix at a time.
> Integrating kwin4 is a single big job which would prevent regular fixing
> from the Trinity side only in the future. The big job is just not appealing at this time.
> 
> If the two steps I indicated above could be done by others,
> I would give kwin4 adoption by Trinity a much bigger chance of
> succeeding.
> 
> Maybe the kwin4 developers themselves could provide a
> stripped-down version of kwin4 for multiple popular distributions? I would
> imagine starting with adding a kwin-lite package to Debian/Ubuntu
> which would only have the limited set of dependencies. Maybe people on
> other DEs would like to use this package as well.
> 
> The second problem is the integration of the configuration.
> This is not a Trinity+kwin4 specific issue. Also KDE4 and Gnome for
> example have issues where two configuration panes are required to
> configure certain settings. It would be the cleanest to develop a generic
> solution for this through freedesktop.org that can be used by all DEs and
> WMs.
> 
> Once these two problems are solved, I expect Trinity would
> implement the required freedesktop.org standards to allow configuration
> pane integration with other DEs. I think there is already an
> option to switch to another WM in Trinity. I also think Martin's claims about
> the superiority of kwin4 over twin are true, so I would expect
> most Trinity users to switch to kwin4 because they will enjoy the better
> experience. At this point twin will be deprecated.

Those all are good points.

Tim has shared, several times, emphatically, that twin is going nowhere any time soon. In other words, don't panic.

With that said, Tim has provided initial hooks and foundations for other window managers. There is even a bug report addressing the issue.

The door is open and will remain open.

The question then is who wants to use a window manager other than twin? In the spirit of how these projects work, those who want window manager integration, including kwin4, will provide the necessary sweat equity. kwin4 --- adapted for Trinity, must be developed with full assurance that no KDE4 dependencies exist. Period. That is not negotiable. Word has been given that doing so is technically possible.

Those who want these new features must be prepared to accept responsibility. Whoever provides that sweat equity must perform significant testing and handling of all related bug reports. All issues must be resolved before the code will be considered mainstream and pushed to the main source tree.

Theoretically then, all that remains is sweat equity. Remember, the door is open. Put up or shut up.

Sharing code base is a non issue. A proverbial red herring. Trinity users either want other window managers or they don't.

Overall I wish folks would let this topic die. Or start hacking. Or block certain email addresses.

Darrell