trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: December 2011

Re: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4

From: Julius Schwartzenberg <julius.schwartzenberg@...>
Date: Sun, 11 Dec 2011 20:19:31 +0100
Martin Gräßlin wrote:
> On Sunday 11 December 2011 16:50:09 Luke Kenneth Casson Leighton wrote:
>> On Sun, Dec 11, 2011 at 11:38 AM, Martin Gräßlin <mgraesslin@...> wrote:
>>> If Trinity needs Trinity specific patches to KWin those would have to go
>>> into a branch.
>>
>>  ... where it would be better than nothing but would still ultimately
>> end up as bit-rot unless extreme care was taken.  whether the code
>> ends up as bit-rot or ends up properly incorporated into KDE very much
>> depends on whether the KDE team can develop trust of the Trinity team.
> KWin currently comes in master in two flavors and we are able to support that. 
> As well we currently have one long-living branch and due to feature freeze 
> several short living branches.
> 
> As long as Trinity developers follow the KWin development on the files they 
> change from time to time there should not be any problem. Even merging could 
> be done automatically.

The offer of a special branch seems nice. I suppose that the kwin
dependencies on libraries like kdelibs and Qt may not be that
sophisticated that it would be possible to have a KWin version that
compiles against the Trinity equivalents of these libraries. Maybe with
trivial improvements on both sides, for example making certain Trinity
APIs more KDE4-like or disabling certain advanced features on the KWin
side (when compiling with Trinity), I could imagine the current KWin
versions could be made source compatibile with Trinity.

In the end, the main question is whether it will be easier to maintain
Trinity's TKWin or enabling source compatibility with KDE4's KWin. If
you consider all the Freedesktop specs and how subtle WM bugs can be
with different applications, I can imagine the second option is indeed
the most attractive long term.