window-decorator cannot build with libmetacity 3.22

[luke]

This is with compiz source
compiz_0.9.13.0+16.10.20160818.2.orig.tar.gz
build on Debian Unstable (not Ubuntu) and GTK 3.22 and Metacity 3.22. Will become an issue for Ubuntu post-yakkety unless Ubuntu pins Metacity at version 3.20.

Metacity/libmetacity 3.22 introduced radical changes that totally break compiz's gtk-window-decorator,which can neither build nor run against it. I played with it, a whole bunch of things compiz needed to link against were removed. This was the first error resulting from an attempt to build against Metacity 3.22:

error: unknown type name ‘MetaButtonLayout’
     MetaButtonLayout button_layout;

The possible killer for Metacity theme support:

https://github.com/GNOME/metacity/commit/d7f2445ec7e70274c7501586a537c699f6628335
libmetacity: switch from .ssd to .csd

and some of the changes probably behind breaking the build:

https://github.com/GNOME/metacity/commit/2ee0ffbee0b52cb8fc3112906bea1eaa737559f7
libmetacity: don't expose MetaButton struct

https://github.com/GNOME/metacity/commit/eee199e3b7ce87cbd08b4b6e4c9c55c804c6ff5f
libmetacity: rename MetaButtonFunction to MetaButtonType

Not sure a port to 3.22 would even still give the ability to read Metacity themes anyway, given the first commit listed above.

Meanwhile, building gtk-window-decorator without metacity support at all was broken accidently in changes to support metacity 3.20 by using metacity version selectors but not checking to see if Metacity support is being used at all.

I build compiz for use in Debian Unstable (and offer my builds for public use) so I saw this a couple days ago. All I could so was switch decorators to Emerald (which compiz-reloaded has ported to GTK3) and use the Emerald pixmap engine to write an Emerald theme matched to my metacity theme. Ubuntu MATE may have to do the same post-Yakkety unless Ubuntu either pins Metacity, gets a 3.22 port to work and finds it handles metacity themes, or modified gtk-window-decorator to read metacity themes directly without using libmetacity.

[Cyril Brulebois (kibi)]

Thanks for sharing your findings.

FWIW I was looking at reintroducing compiz into Debian (that is: via unstable), and while it compiled mostly OK 2-3 weeks ago, I've just stumbled upon this FTBFS due to the (lib)metacity bump for GNOME 3.22.

Just out of curiosity, did you get in touch with GNOME people to mention this regression and to get advice on how to go forward on the compiz side?

[luke (lukefromdc)]

I've been able to keep using compiz, using Emerald as the window decorator and applying
an old, never-merged patch that restores proper transparency function for CSD windows.

https://code.launchpad.net/~albertsmuktupavels/compiz/add-gtk-frame-extents-to-net-supported

Ubuntu patches GTK instead to get compiz to work with CSD windows Their CSD results are said
noty to be not as good as mine, but their system has the advantage that when tiling is used and
the theme does not expliclty set tiles windows to zero margins and zero shadows they still line up
with no gaps.

If neither compiz nor GTK is patched, the result is black corners on CSD windows and the inabilty
of any CSD window to be transparent unless the code calling the window expliclity enable it:

https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1436553

The "fix released" appears to be the GTK patches, not a fix in compiz by Ubuntu.

I offer the compiz builds I use in Debian at
https://archive.org/details/DebianPackagesForMate-desktopWityGtk3AndCustomPanelTheme

I do get a couple timing issues on startup. To get compiz to fully start and connect to the window
decorator at session startup I have to use a script, and if the timing is exactly wrong mate-panel
has to be restarted. Compiz itself orignally restarted gnome-panel in session startups I recall.

Anyway, I've got it mostly working, with a little attention to that timing issue and the extents
patch, a better build than mine for Debian should be possible.

On 10/21/2016 at 10:01 AM, "Cyril Brulebois" <email address hidden> wrote:
>
>Thanks for sharing your findings.
>
>FWIW I was looking at reintroducing compiz into Debian (that is:
>via
>unstable), and while it compiled mostly OK 2-3 weeks ago, I've just
>stumbled upon this FTBFS due to the (lib)metacity bump for GNOME
>3.22.
>
>Just out of curiosity, did you get in touch with GNOME people to
>mention
>this regression and to get advice on how to go forward on the
>compiz
>side?
>
>--
>You received this bug notification because you are subscribed to
>the bug
>report.
>https://bugs.launchpad.net/bugs/1629749
>
>Title:
> window-decorator cannot build with libmetacity 3.22
>
>Status in Compiz:
> New
>
>Bug description:
> This is with compiz source
> compiz_0.9.13.0+16.10.20160818.2.orig.tar.gz
> build on Debian Unstable (not Ubuntu) and GTK 3.22 and Metacity
>3.22. Will become an issue for Ubuntu post-yakkety unless Ubuntu
>pins Metacity at version 3.20.
>
> Metacity/libmetacity 3.22 introduced radical changes that totally
> break compiz's gtk-window-decorator,which can neither build nor
>run
> against it. I played with it, a whole bunch of things compiz
>needed to
> link against were removed. This was the first error resulting
>from an
> attempt to build against Metacity 3.22:
>
> error: unknown type name ‘MetaButtonLayout’
> MetaButtonLayout button_layout;
>
>
> The possible killer for Metacity theme support:
>
>
>https://github.com/GNOME/metacity/commit/d7f2445ec7e70274c7501586a5
>37c699f6628335
> libmetacity: switch from .ssd to .csd
>
> and some of the changes probably behind breaking the build:
>
>
>https://githu...

[luke (lukefromdc)]

I haven't spoken with the GNOME people about this, I don't think they would
consider the failure of any non-GNOME package to build against a GNOME
package other than GTK to be a bug, or the report to be a feature request.

It would be possible to fork and rename libmetacity 3.20. It would be complex
to drop it directly into the compiz source as compiz uses cmake and GNOME
packages use automake. To port compiz to 3.22 would not bring back metacity
theme support I'm pretty sure, instead giving support for using the GTK CSD
theme as Metacity itself has done for a couple releases now. GNOME simply
does not use this code anymore and does not even ship metacity themes.

My advice: the compiz package depends on Emerald for now,

On 10/21/2016 at 10:01 AM, "Cyril Brulebois" <email address hidden> wrote:
>
>Thanks for sharing your findings.
>
>FWIW I was looking at reintroducing compiz into Debian (that is:
>via
>unstable), and while it compiled mostly OK 2-3 weeks ago, I've just
>stumbled upon this FTBFS due to the (lib)metacity bump for GNOME
>3.22.
>
>Just out of curiosity, did you get in touch with GNOME people to
>mention
>this regression and to get advice on how to go forward on the
>compiz
>side?
>
>--
>You received this bug notification because you are subscribed to
>the bug
>report.
>https://bugs.launchpad.net/bugs/1629749
>
>Title:
> window-decorator cannot build with libmetacity 3.22
>
>Status in Compiz:
> New
>
>Bug description:
> This is with compiz source
> compiz_0.9.13.0+16.10.20160818.2.orig.tar.gz
> build on Debian Unstable (not Ubuntu) and GTK 3.22 and Metacity
>3.22. Will become an issue for Ubuntu post-yakkety unless Ubuntu
>pins Metacity at version 3.20.
>
> Metacity/libmetacity 3.22 introduced radical changes that totally
> break compiz's gtk-window-decorator,which can neither build nor
>run
> against it. I played with it, a whole bunch of things compiz
>needed to
> link against were removed. This was the first error resulting
>from an
> attempt to build against Metacity 3.22:
>
> error: unknown type name ‘MetaButtonLayout’
> MetaButtonLayout button_layout;
>
>
> The possible killer for Metacity theme support:
>
>
>https://github.com/GNOME/metacity/commit/d7f2445ec7e70274c7501586a5
>37c699f6628335
> libmetacity: switch from .ssd to .csd
>
> and some of the changes probably behind breaking the build:
>
>
>https://github.com/GNOME/metacity/commit/2ee0ffbee0b52cb8fc3112906b
>ea1eaa737559f7
> libmetacity: don't expose MetaButton struct
>
>
>
>https://github.com/GNOME/metacity/commit/eee199e3b7ce87cbd08b4b6e4c
>9c55c804c6ff5f
> libmetacity: rename MetaButtonFunction to MetaButtonType
>
> Not sure a port to 3.22 would even still give the ability to read
> Metacity themes anyway, given the first commit listed above.
>
> Meanwhile, building gtk-window-decorator without metacity
>support at
> all was broken accidently in changes to support metacity 3.20 by
>using
> metacity version selectors but not checking to see if Metacity
>support
> is being used at all.
>
> I build compiz for use in Debian Unstable (and offer my builds
>for
> public use) so I saw this a co...

[Cyril Brulebois (kibi)]

Thanks for the Emerald tip, but I've been warned against it since it might be undermaintained.

Another approach might be to look into libmarco, which seems to be a mate fork of libmetacity; I haven't looked into it yet though (but plan to if time permits).

In the meanwhile, I've prepared a few patches against latest compiz trunk, so that compiz builds against Debian unstable. Pointers to the git repository and to the Debian packages for amd64 can be found here: https://compiz.alioth.debian.org/ — the patch series contains a workaround for this FTBFS by disabling libmetacity: https://anonscm.debian.org/cgit/compiz/compiz.git/commit/?h=unstable-v1&id=c36fa3cf661eb363f75ca54fe642bad0f0377f40

I have only performed build tests for the time being, and made sure packages are installable.

They're probably suboptimal since a bunch of things needed be disabled to build against Debian unstable, but the idea was to see whether we could bring back compiz to Debian, and then improve incrementally.

[luke (lukefromdc)]

The compiz-reloaded folks are maintaining a branch of Emerald which has
been ported to GTK3 and just had its last commit yesterday to fix some
GTK 3 deprecations. This is a currently maintained branch. Compiz-reloaded
itself is a branch of compiz 0.8.8 (which as of a month ago did not work with
GTK 3.22) but their Emerald package works just fine with upstream compiz
0.9.13, which is what I am using.

https://github.com/compiz-reloaded/emerald

On 10/23/2016 at 8:50 PM, "Cyril Brulebois" <email address hidden> wrote:
>
>Thanks for the Emerald tip, but I've been warned against it since
>it
>might be undermaintained.
>
>Another approach might be to look into libmarco, which seems to be
>a
>mate fork of libmetacity; I haven't looked into it yet though (but
>plan
>to if time permits).
>
>In the meanwhile, I've prepared a few patches against latest compiz
>trunk, so that compiz builds against Debian unstable. Pointers to
>the
>git repository and to the Debian packages for amd64 can be found
>here:
>https://compiz.alioth.debian.org/ — the patch series contains a
>workaround for this FTBFS by disabling libmetacity:
>https://anonscm.debian.org/cgit/compiz/compiz.git/commit/?h=unstabl
>e-v1&id=c36fa3cf661eb363f75ca54fe642bad0f0377f40
>
>I have only performed build tests for the time being, and made sure
>packages are installable.
>
>They're probably suboptimal since a bunch of things needed be
>disabled
>to build against Debian unstable, but the idea was to see whether
>we
>could bring back compiz to Debian, and then improve incrementally.
>
>--
>You received this bug notification because you are subscribed to
>the bug
>report.
>https://bugs.launchpad.net/bugs/1629749
>
>Title:
> window-decorator cannot build with libmetacity 3.22
>
>Status in Compiz:
> New
>
>Bug description:
> This is with compiz source
> compiz_0.9.13.0+16.10.20160818.2.orig.tar.gz
> build on Debian Unstable (not Ubuntu) and GTK 3.22 and Metacity
>3.22. Will become an issue for Ubuntu post-yakkety unless Ubuntu
>pins Metacity at version 3.20.
>
> Metacity/libmetacity 3.22 introduced radical changes that totally
> break compiz's gtk-window-decorator,which can neither build nor
>run
> against it. I played with it, a whole bunch of things compiz
>needed to
> link against were removed. This was the first error resulting
>from an
> attempt to build against Metacity 3.22:
>
> error: unknown type name ‘MetaButtonLayout’
> MetaButtonLayout button_layout;
>
>
> The possible killer for Metacity theme support:
>
>
>https://github.com/GNOME/metacity/commit/d7f2445ec7e70274c7501586a5
>37c699f6628335
> libmetacity: switch from .ssd to .csd
>
> and some of the changes probably behind breaking the build:
>
>
>https://github.com/GNOME/metacity/commit/2ee0ffbee0b52cb8fc3112906b
>ea1eaa737559f7
> libmetacity: don't expose MetaButton struct
>
>
>
>https://github.com/GNOME/metacity/commit/eee199e3b7ce87cbd08b4b6e4c
>9c55c804c6ff5f
> libmetacity: rename MetaButtonFunction to MetaButtonType
>
> Not sure a port to 3.22 would even still give the ability to read
> Metacity themes anyway, given the first commit listed above.
>
> Meanwhile...

[Alberts Muktupāvels (muktupavels)]

Branch with needed changes/fix is available! It was available in same day when Metacity 3.22.0 was released.

"Not sure a port to 3.22 would even still give the ability to read Metacity themes anyway, given the first commit listed above."
How about doing some research before speaking about something you have no idea? Metacity can still use Metacity themes.

"libmetacity: switch from .ssd to .csd"
This commit has nothing to do with Metacity themes. Metacity now supports both - GTK+ themes and also Metacity themes. Your mentioned commit affects only GTK+ theme.

"I haven't spoken with the GNOME people about this, I don't think they would
consider the failure of any non-GNOME package to build against a GNOME
package other than GTK to be a bug, or the report to be a feature request."
I have always updated gtk-window-decorator for all changes I have made to Metacity. Otherwise gdw probably would still use GTK+ 2...

"It would be possible to fork and rename libmetacity 3.20."
Ah, forking, world saver, right?

"To port compiz to 3.22 would not bring back metacity
theme support I'm pretty sure, instead giving support for using the GTK CSD
theme as Metacity itself has done for a couple releases now."
You are so wrong...

"GNOME simply does not use this code anymore and does not even ship metacity themes."
I removed Metacity themes, because:
- metacity by default use GTK+ theme
- all metacity themes was unmaintained

[luke (lukefromdc)]

OK, I can confirm that your branch sucessfully builds a working gtk-window-decorator,
and that the resulting binary can even be dropped into an install of current compiz 0.9.13.0,
I will be uploading a compiz Debian package with both this and your older gtk-extents patch
to my Archive site tonight.

Sorry about any mixups concerning the code: the metacity changes apparently looked more
intrusive than they actually were. I never saw your new branch, I even looked for it figuring
there might be one but didn't find it.

On 10/25/2016 at 4:31 AM, "Alberts Muktupāvels" <email address hidden> wrote:
>
>Branch with needed changes/fix is available! It was available in
>same
>day when Metacity 3.22.0 was released.
>
>"Not sure a port to 3.22 would even still give the ability to read
>Metacity themes anyway, given the first commit listed above."
>How about doing some research before speaking about something you
>have no idea? Metacity can still use Metacity themes.
>
>"libmetacity: switch from .ssd to .csd"
>This commit has nothing to do with Metacity themes. Metacity now
>supports both - GTK+ themes and also Metacity themes. Your
>mentioned commit affects only GTK+ theme.
>
>"I haven't spoken with the GNOME people about this, I don't think
>they would
>consider the failure of any non-GNOME package to build against a
>GNOME
>package other than GTK to be a bug, or the report to be a feature
>request."
>I have always updated gtk-window-decorator for all changes I have
>made to Metacity. Otherwise gdw probably would still use GTK+ 2...
>
>"It would be possible to fork and rename libmetacity 3.20."
>Ah, forking, world saver, right?
>
>"To port compiz to 3.22 would not bring back metacity
>theme support I'm pretty sure, instead giving support for using
>the GTK CSD
>theme as Metacity itself has done for a couple releases now."
>You are so wrong...
>
>"GNOME simply does not use this code anymore and does not even
>ship metacity themes."
>I removed Metacity themes, because:
>- metacity by default use GTK+ theme
>- all metacity themes was unmaintained
>
>** Changed in: compiz
> Assignee: (unassigned) => Alberts Muktupāvels
>(albertsmuktupavels)
>
>--
>You received this bug notification because you are subscribed to
>the bug
>report.
>https://bugs.launchpad.net/bugs/1629749
>
>Title:
> window-decorator cannot build with libmetacity 3.22
>
>Status in Compiz:
> New
>
>Bug description:
> This is with compiz source
> compiz_0.9.13.0+16.10.20160818.2.orig.tar.gz
> build on Debian Unstable (not Ubuntu) and GTK 3.22 and Metacity
>3.22. Will become an issue for Ubuntu post-yakkety unless Ubuntu
>pins Metacity at version 3.20.
>
> Metacity/libmetacity 3.22 introduced radical changes that totally
> break compiz's gtk-window-decorator,which can neither build nor
>run
> against it. I played with it, a whole bunch of things compiz
>needed to
> link against were removed. This was the first error resulting
>from an
> attempt to build against Metacity 3.22:
>
> error: unknown type name ‘MetaButtonLayout’
> MetaButtonLayout button_layout;
>
>
> The possible killer for Metacity theme support:
>
>
>https://github.c...

[luke (lukefromdc)]

I just uploaded a hybrid build of compiz for Debian Unstable to
https://archive.org/details/DebianPackagesForMate-desktopWityGtk3AndCustomPanelTheme
with a "new update" notice.

This is compiz 0.9.13 from the current Ubuntu tarball with a build of gtk-window-decorator from
https://code.launchpad.net/~albertsmuktupavels/compiz/gwd-support-metacity-3-22
substituted, works fine and is the latest of both.

Question: how much of Metacity/libmetacity does gtk-window-decorator actually use to implement
reading and rendering metacity themes? I assume no code related to the themes themselves
comes from Metacity anymore and that is entirely contained in compiz/gtk-window-decorator
and only elements used to render now come from Metacity?

On 10/25/2016 at 4:31 AM, "Alberts Muktupāvels" <email address hidden> wrote:
>
>Branch with needed changes/fix is available! It was available in
>same
>day when Metacity 3.22.0 was released.
>
>"Not sure a port to 3.22 would even still give the ability to read
>Metacity themes anyway, given the first commit listed above."
>How about doing some research before speaking about something you
>have no idea? Metacity can still use Metacity themes.
>
>"libmetacity: switch from .ssd to .csd"
>This commit has nothing to do with Metacity themes. Metacity now
>supports both - GTK+ themes and also Metacity themes. Your
>mentioned commit affects only GTK+ theme.
>
>"I haven't spoken with the GNOME people about this, I don't think
>they would
>consider the failure of any non-GNOME package to build against a
>GNOME
>package other than GTK to be a bug, or the report to be a feature
>request."
>I have always updated gtk-window-decorator for all changes I have
>made to Metacity. Otherwise gdw probably would still use GTK+ 2...
>
>"It would be possible to fork and rename libmetacity 3.20."
>Ah, forking, world saver, right?
>
>"To port compiz to 3.22 would not bring back metacity
>theme support I'm pretty sure, instead giving support for using
>the GTK CSD
>theme as Metacity itself has done for a couple releases now."
>You are so wrong...
>
>"GNOME simply does not use this code anymore and does not even
>ship metacity themes."
>I removed Metacity themes, because:
>- metacity by default use GTK+ theme
>- all metacity themes was unmaintained
>
>** Changed in: compiz
> Assignee: (unassigned) => Alberts Muktupāvels
>(albertsmuktupavels)
>
>--
>You received this bug notification because you are subscribed to
>the bug
>report.
>https://bugs.launchpad.net/bugs/1629749
>
>Title:
> window-decorator cannot build with libmetacity 3.22
>
>Status in Compiz:
> New
>
>Bug description:
> This is with compiz source
> compiz_0.9.13.0+16.10.20160818.2.orig.tar.gz
> build on Debian Unstable (not Ubuntu) and GTK 3.22 and Metacity
>3.22. Will become an issue for Ubuntu post-yakkety unless Ubuntu
>pins Metacity at version 3.20.
>
> Metacity/libmetacity 3.22 introduced radical changes that totally
> break compiz's gtk-window-decorator,which can neither build nor
>run
> against it. I played with it, a whole bunch of things compiz
>needed to
> link against were removed. This was the first error resulting
>from an
> atte...

[Alberts Muktupāvels (muktupavels)]

Not sure if I understand question... First gtk-window-decorator can use cairo or libmetacity (previously libmetacity-private) to draw window decorations. Gwd does not know anything about metacity themes, it just use public API from libmetacity.

https://git.gnome.org/browse/metacity/tree/libmetacity
This library does all needed work - loads theme (from css or metacity-theme-x.xml), calculates frame size, draws it...

https://git.gnome.org/browse/metacity/tree/theme-viewer
Theme viewer also use same library, just like metacity and gtk-window-decorator. So just study code if you want to know how things works.

[luke (lukefromdc)]

I thought from looking at the commits that metacity had removed code
gwd would have to use to read metacity themes at all, or removed code
needed to draw server-side decorations. As I understand it metacity itself
has used the GTK theme and not the metacity theme for a while, so I
thought the code for both reading metacity themes and for drawing
decorations other than CSD had been removed by the commits mentioned.

I don't have the understanding of the underlying code here that I do for the
mate/GNOME-panel or of Caja/Nemo/Nautilus.

On 10/26/2016 at 6:02 AM, "Alberts Muktupāvels" <email address hidden> wrote:
>
>Not sure if I understand question... First gtk-window-decorator
>can use
>cairo or libmetacity (previously libmetacity-private) to draw
>window
>decorations. Gwd does not know anything about metacity themes, it
>just
>use public API from libmetacity.
>
>https://git.gnome.org/browse/metacity/tree/libmetacity
>This library does all needed work - loads theme (from css or
>metacity-theme-x.xml), calculates frame size, draws it...
>
>https://git.gnome.org/browse/metacity/tree/theme-viewer
>Theme viewer also use same library, just like metacity and gtk-
>window-decorator. So just study code if you want to know how
>things works.
>
>--
>You received this bug notification because you are subscribed to
>the bug
>report.
>https://bugs.launchpad.net/bugs/1629749
>
>Title:
> window-decorator cannot build with libmetacity 3.22
>
>Status in Compiz:
> New
>
>Bug description:
> This is with compiz source
> compiz_0.9.13.0+16.10.20160818.2.orig.tar.gz
> build on Debian Unstable (not Ubuntu) and GTK 3.22 and Metacity
>3.22. Will become an issue for Ubuntu post-yakkety unless Ubuntu
>pins Metacity at version 3.20.
>
> Metacity/libmetacity 3.22 introduced radical changes that totally
> break compiz's gtk-window-decorator,which can neither build nor
>run
> against it. I played with it, a whole bunch of things compiz
>needed to
> link against were removed. This was the first error resulting
>from an
> attempt to build against Metacity 3.22:
>
> error: unknown type name ‘MetaButtonLayout’
> MetaButtonLayout button_layout;
>
>
> The possible killer for Metacity theme support:
>
>
>https://github.com/GNOME/metacity/commit/d7f2445ec7e70274c7501586a5
>37c699f6628335
> libmetacity: switch from .ssd to .csd
>
> and some of the changes probably behind breaking the build:
>
>
>https://github.com/GNOME/metacity/commit/2ee0ffbee0b52cb8fc3112906b
>ea1eaa737559f7
> libmetacity: don't expose MetaButton struct
>
>
>
>https://github.com/GNOME/metacity/commit/eee199e3b7ce87cbd08b4b6e4c
>9c55c804c6ff5f
> libmetacity: rename MetaButtonFunction to MetaButtonType
>
> Not sure a port to 3.22 would even still give the ability to read
> Metacity themes anyway, given the first commit listed above.
>
> Meanwhile, building gtk-window-decorator without metacity
>support at
> all was broken accidently in changes to support metacity 3.20 by
>using
> metacity version selectors but not checking to see if Metacity
>support
> is being used at all.
>
> I build compiz for use in Debian Unstable (and offer my buil...

[luke (lukefromdc)]

Found rising RAM use (possible memory leak) in your branch
supporting Metacity 3.22. After a few hours running and a
video editing session gwd was using 127MB of RAM. Restarting
it dropped it to 24.5MB, then opening and closing a half dozen
windows raised it to 28.5 MB.

Opening one Pluma window added 500kb to RAM used by gwd,
but closing it only freed 200MB. Similar behavior was observed
in Emerald, BTW. Wonder if some kind of issue outside the window
decorator (X itself maybe?) has a hand in this?

On 10/26/2016 at 6:02 AM, "Alberts Muktupāvels" <email address hidden> wrote:
>
>Not sure if I understand question... First gtk-window-decorator
>can use
>cairo or libmetacity (previously libmetacity-private) to draw
>window
>decorations. Gwd does not know anything about metacity themes, it
>just
>use public API from libmetacity.
>
>https://git.gnome.org/browse/metacity/tree/libmetacity
>This library does all needed work - loads theme (from css or
>metacity-theme-x.xml), calculates frame size, draws it...
>
>https://git.gnome.org/browse/metacity/tree/theme-viewer
>Theme viewer also use same library, just like metacity and gtk-
>window-decorator. So just study code if you want to know how
>things works.
>
>--
>You received this bug notification because you are subscribed to
>the bug
>report.
>https://bugs.launchpad.net/bugs/1629749
>
>Title:
> window-decorator cannot build with libmetacity 3.22
>
>Status in Compiz:
> New
>
>Bug description:
> This is with compiz source
> compiz_0.9.13.0+16.10.20160818.2.orig.tar.gz
> build on Debian Unstable (not Ubuntu) and GTK 3.22 and Metacity
>3.22. Will become an issue for Ubuntu post-yakkety unless Ubuntu
>pins Metacity at version 3.20.
>
> Metacity/libmetacity 3.22 introduced radical changes that totally
> break compiz's gtk-window-decorator,which can neither build nor
>run
> against it. I played with it, a whole bunch of things compiz
>needed to
> link against were removed. This was the first error resulting
>from an
> attempt to build against Metacity 3.22:
>
> error: unknown type name ‘MetaButtonLayout’
> MetaButtonLayout button_layout;
>
>
> The possible killer for Metacity theme support:
>
>
>https://github.com/GNOME/metacity/commit/d7f2445ec7e70274c7501586a5
>37c699f6628335
> libmetacity: switch from .ssd to .csd
>
> and some of the changes probably behind breaking the build:
>
>
>https://github.com/GNOME/metacity/commit/2ee0ffbee0b52cb8fc3112906b
>ea1eaa737559f7
> libmetacity: don't expose MetaButton struct
>
>
>
>https://github.com/GNOME/metacity/commit/eee199e3b7ce87cbd08b4b6e4c
>9c55c804c6ff5f
> libmetacity: rename MetaButtonFunction to MetaButtonType
>
> Not sure a port to 3.22 would even still give the ability to read
> Metacity themes anyway, given the first commit listed above.
>
> Meanwhile, building gtk-window-decorator without metacity
>support at
> all was broken accidently in changes to support metacity 3.20 by
>using
> metacity version selectors but not checking to see if Metacity
>support
> is being used at all.
>
> I build compiz for use in Debian Unstable (and offer my builds
>for
> public use) so I saw th...