[RFC]: Drop support for Compiz in KDecoration

[Martin Gräßlin]

Hi all,

this is a small request for comments where I would like to get some comments
for. That is I don't want to go ahead without consensus.

Since [1] KWin has the internal KDecorationBridge as a public part of the
KDecoration API to allow Compiz to implement it. This is rather unfortunate as
it makes our life more difficult as we cannot extend our internal API without
doing subclassing and all that effort (see for example [2]).

Given that it seems like nobody is still using Compiz instead of KWin I do not
see why we should continue to support it. Therefore I want to request to make
KDecorationBridge private again by unexporting the header file. If we agree on
that I'm going to inform kde-packagers about it, so that they can conflict the
4.10 package with compiz-kde.

To back my claim I checked various distributions:
* Ubuntu is not shipping kde-window-decorator in compiz-kde since precise and
doesn't ship compiz-kde since quantal [3]
* Arch is shipping an outdated version in the community repo [4]
* openSUSE is shipping an outdated version [5]
* Gentoo is shipping an outdated version which is patched for 4.10 [6]
* Fedora is shipping an outdated Compiz version, but seems to not ship compiz-
kde [7]
* Mageia is shipping an up to date version of Compiz (!), whether it includes
compiz-kde I couldn't figure out [8]

In all cases where I wrote outdated version it is the 0.8 branch of compiz,
while Canonical is at 0.9.

If Compiz still wants to support our decorations (which I doubt, though
support for appmenu got added end of last year) they would only need to fork
the header file and ensure by themselves that it works correctly.

Comments?

--
Martin GrÀßlin

[1] http://commits.kde.org/kde-workspace/4933f08ae49328e36e2654434d28917310882ee5
[2] http://git.reviewboard.kde.org/r/103948/
[3] http://packages.ubuntu.com/search?keywords=compiz-kde&searchon=names&suite=all&section=all
[4] https://www.archlinux.org/packages/community/x86_64/compiz-decorator-kde/
[5] http://software.opensuse.org/package/compiz-kde4
[6] http://packages.gentoo.org/package/x11-wm/compiz?arches=prefix
[7] https://apps.fedoraproject.org/packages/compiz/overview/
[8] http://mageia.madb.org/package/show/name/compiz

[Sebastian Kügler]

Post by Martin Gräßlin
this is a small request for comments where I would like to get some
comments for. That is I don't want to go ahead without consensus.
Since [1] KWin has the internal KDecorationBridge as a public part of the
KDecoration API to allow Compiz to implement it. This is rather unfortunate
as it makes our life more difficult as we cannot extend our internal API
without doing subclassing and all that effort (see for example [2]).
Given that it seems like nobody is still using Compiz instead of KWin I do
not see why we should continue to support it. Therefore I want to request
to make KDecorationBridge private again by unexporting the header file. If
we agree on that I'm going to inform kde-packagers about it, so that they
can conflict the 4.10 package with compiz-kde.
* Ubuntu is not shipping kde-window-decorator in compiz-kde since precise
and doesn't ship compiz-kde since quantal [3]
* Arch is shipping an outdated version in the community repo [4]
* openSUSE is shipping an outdated version [5]
* Gentoo is shipping an outdated version which is patched for 4.10 [6]
* Fedora is shipping an outdated Compiz version, but seems to not ship
compiz- kde [7]
* Mageia is shipping an up to date version of Compiz (!), whether it
includes compiz-kde I couldn't figure out [8]
In all cases where I wrote outdated version it is the 0.8 branch of compiz,
while Canonical is at 0.9.
If Compiz still wants to support our decorations (which I doubt, though
support for appmenu got added end of last year) they would only need to
fork the header file and ensure by themselves that it works correctly.

Maybe interesting to know: Did you get any bugreports regarding use of compiz
in Plasma Desktop lately? And: Compiz is dead upstream, isn't it?

[Martin Gräßlin]

Post by Sebastian Kügler

Post by Martin Gräßlin
this is a small request for comments where I would like to get some
comments for. That is I don't want to go ahead without consensus.
Since [1] KWin has the internal KDecorationBridge as a public part of the
KDecoration API to allow Compiz to implement it. This is rather unfortunate
as it makes our life more difficult as we cannot extend our internal API
without doing subclassing and all that effort (see for example [2]).
Given that it seems like nobody is still using Compiz instead of KWin I do
not see why we should continue to support it. Therefore I want to request
to make KDecorationBridge private again by unexporting the header file. If
we agree on that I'm going to inform kde-packagers about it, so that they
can conflict the 4.10 package with compiz-kde.
* Ubuntu is not shipping kde-window-decorator in compiz-kde since precise
and doesn't ship compiz-kde since quantal [3]
* Arch is shipping an outdated version in the community repo [4]
* openSUSE is shipping an outdated version [5]
* Gentoo is shipping an outdated version which is patched for 4.10 [6]
* Fedora is shipping an outdated Compiz version, but seems to not ship
compiz- kde [7]
* Mageia is shipping an up to date version of Compiz (!), whether it
includes compiz-kde I couldn't figure out [8]
In all cases where I wrote outdated version it is the 0.8 branch of compiz,
while Canonical is at 0.9.
If Compiz still wants to support our decorations (which I doubt, though
support for appmenu got added end of last year) they would only need to
fork the header file and ensure by themselves that it works correctly.

Maybe interesting to know: Did you get any bugreports regarding use of
compiz in Plasma Desktop lately?

No, which is a strong sign that it is no longer used given bug 143419.

Post by Sebastian Kügler
And: Compiz is dead upstream, isn't it?

For certain definitions of dead: yeah. Compiz has turned into an in-house
product of Canoncial for Unity. That's to my knowledge the reason why most
distros are still on 0.8 if they include it at all. This branch is quite dead.
The Compiz 0.9 branch seems to be actively maintained given the history on
launchpad [1]. But as outlined in the summary above only Mageia is shipping
this branch apart from Ubuntu.
--
Martin GrÀßlin

[1] https://code.launchpad.net/~compiz-team/compiz/0.9.9

[Thomas Lübking]

Post by Martin Gräßlin
Since [1] KWin has the internal KDecorationBridge as a public part of the
KDecoration API to allow Compiz to implement it. This is rather unfortunate as
it makes our life more difficult as we cannot extend our
internal API without
doing subclassing and all that effort (see for example [2]).

Actually it makes the bridge more or less pointless :-(

Post by Martin Gräßlin
Given that it seems like nobody is still using Compiz instead
of KWin I do not see why we should continue to support it.

Even iff, there's no discontinue at all - there's just a coordination issue between two projects.

Post by Martin Gräßlin
Comments?

I'm not 100% sure, but if compiz/libdecoration.so is (rather?!) ABI stable, whoever wants to maintain compiz-decorator-kde (unlikely canonical...) could preferably do in KDE (/extragear?) where we can easily keep it compatible (to the internal KWin API) resp. it would then release in sync with KDE (or later on KWin)

If it's a complete Janusproject (depending on two actually internal APIs) if would have to run any release cycles and ship new versions whenever necessary.

Cheers,
Thomas

[Martin Gräßlin]

Post by Thomas Lübking

Post by Martin Gräßlin
Since [1] KWin has the internal KDecorationBridge as a public part of the
KDecoration API to allow Compiz to implement it. This is rather unfortunate as
it makes our life more difficult as we cannot extend our
internal API without
doing subclassing and all that effort (see for example [2]).

Actually it makes the bridge more or less pointless :-(

Post by Martin Gräßlin
Given that it seems like nobody is still using Compiz instead
of KWin I do not see why we should continue to support it.

Even iff, there's no discontinue at all - there's just a coordination issue
between two projects.

Post by Martin Gräßlin
Comments?

I'm not 100% sure, but if compiz/libdecoration.so is (rather?!) ABI stable,
whoever wants to maintain compiz-decorator-kde (unlikely canonical...)
could preferably do in KDE (/extragear?) where we can easily keep it
compatible (to the internal KWin API) resp. it would then release in sync
with KDE (or later on KWin)

I had suggested that to the Compiz devs years ago, but they didn't want. [1]
--
Martin GrÀßlin
[1] http://lists.freedesktop.org/archives/compiz/2011-January/003451.html

[Thomas Lübking]

Post by Martin Gräßlin

On Freitag, 15. März 2013 14:38:45 CEST, Martin Gräßlin wrote: ...

I had suggested that to the Compiz devs years ago, but they didn't want. [1]
--
Martin Gräßlin
[1] http://lists.freedesktop.org/archives/compiz/2011-January/003451.html

"Interesting"
Short version: KWin should freeze it's internal API so that "we no more take community patches" Compiz does not have to care about it's external. Great :-\

Ok, proposal:
---------------------------
* We turn back the bridge private, that's pretty much why it exists anyway
* kde4-window-decorator has to copy the private header and keep it up-to-date
* libkdecorations exports its internal API (not like it would not be named...)
* kde4-window-decorator can then check the KDecoration internal API and whether it matches the one it was compiled against
* whenever we break ABI, we CC distros (sth. like that would in theory have happen to enable them to recompile 3rd party decos when the deco ABI breaks)
* whenever we break API, we additionally CC compiz devs.

Of course several things have happened since that conversation and maybe the response is that kde4-window-decorator is dead anyway or ppl. would now prefer to develop it under the KDE hood - that would still be an option, i'd say.


The kde4-window-decorator maintainer has to be informed about the upcoming ABI version export and that kde4-window-decorator should start reading it.
My Personal suggestion is to contact D. Baumann (or whoever maintains kde4-window-decorator currently) directly.
Only if that does not lead to anything, contact Canonical officially about it (recently too much bad blood ;-)

Cheers,
Thomas

[Martin Graesslin]

Post by Thomas Lübking

Post by Martin Gräßlin

On Freitag, 15. März 2013 14:38:45 CEST, Martin Gräßlin wrote: ...

I had suggested that to the Compiz devs years ago, but they didn't want.
[1] --
Martin Gräßlin
[1] http://lists.freedesktop.org/archives/compiz/2011-January/003451.html

"Interesting"
Short version: KWin should freeze it's internal API so that "we no more take
community patches" Compiz does not have to care about it's external. Great
:-\
---------------------------
* We turn back the bridge private, that's pretty much why it exists anyway

agreed

Post by Thomas Lübking
* kde4-window-decorator has to copy the private header and keep it up-to-date

agreed

Post by Thomas Lübking
* libkdecorations exports its internal API (not like it would
not be named...) * kde4-window-decorator can then check the KDecoration
internal API and whether it matches the one it was compiled against

can we turn it around? That KWin/kde4-window-decorator export the API version
and libkdecoration checks it? It sounds dangerous but might help blocking
unmatching versions.

Anyway I want to invest as little as possible into compat. It's up to Compiz
to ensure it works.

Post by Thomas Lübking
*
whenever we break ABI, we CC distros (sth. like that would in theory have
happen to enable them to recompile 3rd party decos when the deco ABI
breaks)

I hope that won't happen in the Qt4 timespan anymore :-)

Post by Thomas Lübking
* whenever we break API, we additionally CC compiz devs.

If we find any :-)

Post by Thomas Lübking
Of course several things have happened since that conversation and maybe the
response is that kde4-window-decorator is dead anyway

As written: app-menu support got added though I don't understand why. No
distro is going to ship that...

Post by Thomas Lübking
or ppl. would now
prefer to develop it under the KDE hood - that would still be an option,
i'd say.

Personally I'm no longer for getting it under KDE hood.

Post by Thomas Lübking
The kde4-window-decorator maintainer has to be informed about the upcoming
ABI version export and that kde4-window-decorator should start reading it.
My Personal suggestion is to contact D. Baumann (or whoever maintains
kde4-window-decorator currently) directly. Only if that does not lead to
anything, contact Canonical officially about it (recently too much bad
blood ;-)

I tried to figure out the activity to the directory (did I mention that
bazaar's web interface sucks). It seems like Danny has not contributed to it
since 2009. Though I cannot be sure as the history is totally messed up since
they made the switch to bazaar. From looking at the old git history it seems
to fall under the default maintainership model.

So if we go ahead I say we just ccmail compiz list in the commit which does
the change.

Cheers
Martin

[Thomas Lübking]

Post by Martin Graesslin
can we turn it around? That KWin/kde4-window-decorator export
the API version
and libkdecoration checks it? It sounds dangerous but might help blocking
unmatching versions.

I do not think that this would work.

This way some class in libkdecoration would have to either:
- apply a version check to every function call
- wait for the eventloop to start up, hook onto that, test the version and "act" on that.

The problem here is that kde4-window-decorator can make about as many ABI incompatible accesses to the lib as it wants - and segfault as if there was no mechanism in place at all.

(Though i'm not sure at hand whether you can just additionally dlopen an also linked shared object and resolve a function name, what needed to be done to protect the decorator running into an outdated libkdecorations)

Post by Martin Graesslin
Anyway I want to invest as little as possible into compat.

Actually agreed, thus suggested to add a hint - rest would be the decorators job then (in contrast to the variant where libkdecorations tries to determine the running process)

Post by Martin Graesslin
It's up to Compiz to ensure it works.

Post by Thomas Lübking
*
whenever we break ABI, we CC distros (sth. like that would in theory have
happen to enable them to recompile 3rd party decos when the deco ABI
breaks)

I hope that won't happen in the Qt4 timespan anymore :-)

If we'd add the hint for quicktiling w/o moc, we'd have done so.
Same case for moving kdecorationunstable functionality into kdecoration.

That's aPi stable (and i do certainly not want to break aPi) but not aBi stable - distros would have to relink deps.

Post by Martin Graesslin
As written: app-menu support got added though I don't understand why. No
distro is going to ship that...

I take that looking at http://cgit.compiz.org/ is completely wrong and no real development happens there?

Post by Martin Graesslin
Personally I'm no longer for getting it under KDE hood.

If C. drops it and someone's eager to develop it somewhere but C. won't let him ("no upstream patches") it would be not very KDE-alike to deny playground or extragear (they could also move to SF.net, but KDE has the advance that we can just keep it compiling "by the way")
I was not meaning to suggest that C. can maintain it on a "no one else touches!" agreement on KDEs git repo - and doubt they'd want to.

Post by Martin Graesslin
I tried to figure out the activity to the directory (did I mention that
bazaar's web interface sucks)

Apparently cgit is wrong - google doesn't know what one does not ask.
Iven Hsu reports bugs to KDE, he might be an interested developer.

Post by Martin Graesslin
So if we go ahead I say we just ccmail compiz list in the commit which does
the change.

That would be sufficient.
(And it's not like we could accept a "kwin must not touch it's *internal* ABI" veto anyway)

Cheers,
Thomas

[Martin Graesslin]

Post by Martin Gräßlin
* Mageia is shipping an up to date version of Compiz (!), whether it
includes compiz-kde I couldn't figure out [8]

Looked again: it's not included. Summary: no distribution of the top ten on
distrowatch is shipping compiz KDE integration in an up to date version.

/me is going to prepare a review request.

Cheers
Martin

[Kai-Uwe Behrmann]

Post by Martin Graesslin

Post by Martin Gräßlin
* Mageia is shipping an up to date version of Compiz (!), whether it
includes compiz-kde I couldn't figure out [8]

Looked again: it's not included. Summary: no distribution of the top ten on
distrowatch is shipping compiz KDE integration in an up to date version.

http://software.opensuse.org/package/compiz-kde4
is in past 12.2, actual 12.3 and Factory

This compiz-kde4 version is 0.8.x.

kind regards
Kai-Uwe