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 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.
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/compiz/+bug/1629749/+subscriptions