Re-enable traditional titlebar on 'gnome-but-not-shell' sessions too

In fact, the question should be: do we have to re-enable the traditional titlebar on Gnome Fallback sessions too?
I guess it's a question for Ubuntu Gnome, Ubuntu Desktop and/or Ubuntu Design teams, no?

I'm proposing a patch (see the branch linked to this bug report) which currently only enable the new titlebar (CSD) on Gnome-Shell.
Note that if we want to have this new titlebar on Gnome Fallback sessions too, we can simply replace:

    g_strcmp0(g_getenv("DESKTOP_SESSION"), "gnome") == 0

by:

    g_str_has_prefix(g_getenv("DESKTOP_SESSION"), "gnome")

Thanks Matthieu, those bars should be enabled until under gnome-shell imho, I'm going to have a look to your changes today

> On my session, XDG_CURRENT_DESKTOP=GNOME

that seems buggy, what is setting that variable? it should be set by gnome-session (if you use it) to whatever session you use, that's what we use to specify behaviours for GNOME and Unity specific differences. That seems a bug in your environment/whatever sets it for you rather than one in nautilus

Yes this environment variable is set by gnome-session.
In fact, this Cairo-Dock session is like the former Gnome Panel session but with another panel. So I guess we can see it as a Gnome Fallback session where XDG_CURRENT_DESKTOP=GNOME and DESKTOP_SESSION is not set to gnome (but gnome-fallback or something like that).

This is why I think the question should be: do we have to re-enable the traditional titlebar on Gnome Fallback sessions too?
Currently, when using Compiz on a Gnome session, it's not possible to easily resize the window (except with Alt+middle click)

Only gnome-shell sessions should have "XDG_CURRENT_DESKTOP=GNOME", are you sure gnome-fallback/panel session using that as well (that would be wrong).

Yes I think that they always use the same XDG_CURRENT_DESKTOP env variable but DESKTOP_SESSION is different.
I can't test it right now but there you can see some reports by other users: http://ubuntuforums.org/showthread.php?t=2184682&page=19 and http://askubuntu.com/questions/70296/is-there-an-environment-variable-that-is-set-for-unity

(but it's also possible that since GNOME 3.10, they have change some env variables :-) )

> but it's also possible that since GNOME 3.10, they have change some env variables

No, it's nothing new, we have used that variable for some cycles now, see e.g
http://bazaar.launchpad.net/~ubuntu-desktop/nautilus/ubuntu/view/head:/debian/patches/16_unity_new_documents.patch#L108

The changes happened in the oneiric cycle, see
https://launchpad.net/ubuntu/+source/gnome-session/3.1.3-0ubuntu6

" * debian/patches/52_xdg_current_desktop.patch:
    - Set XDG_CURRENT_DESKTOP inside gnome-session based on a
      new key 'DesktopName' in gnome-session .desktop files."

You are right that the GNOME classic session seems to use "GNOME" as a session name though, maybe that should be changed

> You are right that the GNOME classic session seems to use "GNOME" as a session name though, maybe that should be changed

It depends of what we want to have :-)
For me, it's better that GNOME Classic and Cairo-Dock sessions are considered as a GNOME session.
We can change the value of XDG_CURRENT_DESKTOP for Unity because there are a lot of users/developers/testers than can help patching applications to have a different behaviour only for this session. But for GNOME Classic and Cairo-Dock sessions I think that it's better to keep this GNOME value because yes, it's a GNOME session (just with a different interface). Other applications just wants to know the desktop environment (is it GNOME, KDE, Unity, etc.) but it should be the same if we are using GNOME Classic with Metacity or Compiz or Cairo-Dock, etc.

For this problem here with Nautilus, I think it's a bit different: it seems that this new toolbar is only made for Gnome-Shell. Here with Compiz, I'm not able to easily resize the window because there is no border (and the size is growing each time I relaunch Nautilus). This is why I think we should only use this new toolbar on Gnome-Shell session (where XDG_CURRENT_DESKTOP=GNOME and DESKTOP_SESSION=gnome)

Your definition of "GNOME" is not the one we have, some extra comments:
- gnome-session setting XDG_CURRENT_DESKTOP is an Ubuntu feature, not an upstream one, we use it change behaviour between Unity/gnome-shell
- the previous point means the things that use that variable are limited, they are basically distro change (so not as much work as your comment would suggest)
- we use "GNOME" as "gnome-shell" nowadays, that's what enable e.g shell menu, client side decoration (what is creating your issue here)
- our patches are usually "do something specific under Unity|gnome-shell, have normal/fallback behaviour otherwise", I think if you are not Unity or gnome-shell you are likely to be always fine with the fallback behaviour (Unity specific bits are integration with e.g the launcher, gnome-shell ones are the ones I listed before)

Do you have any example of thing that would stop working if you changed your DesktopName to be "cairo-dock"?

With gnome-flashback, I did the following change:

$ grep DesktopName /usr/share/xsessions/gnome-fallback.desktop
X-LightDM-DesktopName=FGNOME

Logout/login, my environment now is:
DESKTOP_SESSION=gnome-fallback
SESSIONTYPE=gnome-session
XDG_CURRENT_DESKTOP=FGNOME

And, nautilus 1:3.10.1-0ubuntu2 is still not showing the titlebar, was it supposed to?

gnome2/compiz sessions such as flashback and cairo-dock, should really not be using "GNOME", this is mostly gnome-shell specific.

GNOME Classic, should probably be using "GNOME" since it is gnome-shell based. Although that makes it impossible to have different behaviour in classic vs gnome-shell.

Using anything other than Unity or GNOME should work, however I suspect there is some fallback to gnome2-ish behaviour lumped under "Unity", especially in cases where the default upstream GNOME3 behaviour has changed significantly.

Sorry for the delay...

@Sebastien:
> Do you have any example of thing that would stop working if you changed your DesktopName to be "cairo-dock"?

Yes, I guess that if we change the DesktopName to "Cairo-Dock" (or something else), we will have problems with programs which are launched at startup.

    $ grep -rn GNOME /etc/xdg/autostart |grep -e OnlyShowIn -e AutostartCondition
/etc/xdg/autostart/gnome-keyring-ssh.desktop:6:OnlyShowIn=GNOME;Unity;MATE;
/etc/xdg/autostart/nautilus-autostart.desktop:5:OnlyShowIn=GNOME;Unity;
/etc/xdg/autostart/gnome-user-share.desktop:9:OnlyShowIn=GNOME;Unity;
/etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop:9:OnlyShowIn=GNOME;XFCE;Unity;
/etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop:11:AutostartCondition=GNOME3 unless-session gnome
/etc/xdg/autostart/gnome-settings-daemon.desktop:5:OnlyShowIn=GNOME;Unity;
/etc/xdg/autostart/gnome-keyring-secrets.desktop:6:OnlyShowIn=GNOME;Unity;MATE;
/etc/xdg/autostart/gnome-sound-applet.desktop:16:AutostartCondition=GNOME3 if-session gnome-fallback
/etc/xdg/autostart/gnome-keyring-pkcs11.desktop:6:OnlyShowIn=GNOME;Unity;MATE;
/etc/xdg/autostart/at-spi-dbus-bus.desktop:5:OnlyShowIn=GNOME;Unity;
/etc/xdg/autostart/onboard-autostart.desktop:9:OnlyShowIn=GNOME;Unity;
/etc/xdg/autostart/telepathy-indicator.desktop:12:OnlyShowIn=GNOME;Unity;
/etc/xdg/autostart/telepathy-indicator.desktop:13:AutostartCondition=GNOME3 unless-session gnome
/etc/xdg/autostart/gnome-screensaver.desktop:7:OnlyShowIn=GNOME;Unity;
/etc/xdg/autostart/gnome-screensaver.desktop:8:AutostartCondition=GNOME3 unless-session gnome
/etc/xdg/autostart/evolution-alarm-notify.desktop:10:OnlyShowIn=GNOME;Unity;XFCE;Dawati;
/etc/xdg/autostart/vino-server.desktop:6:OnlyShowIn=GNOME;Unity;
/etc/xdg/autostart/gsettings-data-convert.desktop:8:OnlyShowIn=GNOME;Unity;
/etc/xdg/autostart/orca-autostart.desktop:9:OnlyShowIn=GNOME;Unity;
/etc/xdg/autostart/user-dirs-update-gtk.desktop:7:OnlyShowIn=GNOME;LXDE;Unity;
/etc/xdg/autostart/gnome-fallback-mount-helper.desktop:10:OnlyShowIn=GNOME;Unity;
/etc/xdg/autostart/gnome-fallback-mount-helper.desktop:12:AutostartCondition=GNOME3 unless-session gnome
/etc/xdg/autostart/gnome-keyring-gpg.desktop:6:OnlyShowIn=GNOME;Unity;MATE;

As we can see here, every time we have GNOME in the OnlyShowIn key, we also have Unity. So if we change the session name, we should do the same for Cairo-Dock.
Maybe we can patch all these applications to add "Cairo-Dock" in the OnlyShowIn key but I don't know if it's a good idea because we will also have to maintain these patches (except if Ubuntu Desktop and Gnome teams can help us by checking that when they change this key, they also notify us or add/remove Cairo-Dock from this key too).

When looking at the AutostartCondition key, we can see: "GNOME3 unless-session gnome" which means that this application is launched when: XDG_CURRENT_DESKTOP == GNOME but DESKTOP_SESSION != gnome (on a GNOME session but when it's not Gnome-Shell).
Why can't we do that for Nautilus?

@Alkis: I think there is a typo in Ubuntu's patch.
Can you stop nautilus ("nautilus -n") and then try to launch it with:

    $ env XDG_CURRENT_DESKTOP=GNOMEF nautilus

@Tim:

> especially in cases where the default upstream GNOME3 behaviour has changed significantly

Yes, I agree that Cairo-Dock and Flashback sessions can't be considered as a Gnome-Shell session and some changes in GNOME 3.10 apps are now too specific to Gnome-Shell.

But I think it can be interesting to have a default mode for all sessions started with Gnome-Session (Unity, Gnome-Shell + Flashback, Cairo-Dock and many others) but still having the possibility to have some tiny differences when using one of this session. I'm not sure that a session launched with Gnome-Session but with another session name than Unity or GNOME will be usable (according to the OnlyShowIn keys in these files: /etc/xdg/autostart/*.desktop).
Currently, it seems that some programs are specific to Unity OR Gnome-Shell but not all other GNOME sessions.

We can imagine having that:
 * OnlyShowIn=Gnome-Session # => Gnome-Shell, Unity, Flashback, Cairo-Dock
 * OnlyShowIn=Gnome-Session
       AutostartCondition=GSession unless-session gnome # => Unity, Flashback, Cairo-Dock, etc. excepted Gnome-Shell
 * OnlyShowIn=Unity # => only on Unity session

What do you think about that?

@Alkis Georgopoulos (alkisg): I guess you've this bug: LP #1277963

Sorry: LP: #1277963
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1277963

@Matthieu, I was discussing this mitya57 the other day with respect to -flashback. it seems that it would be best to move the GNOME2/Compiz sessions to using "Unity", since that is far closer to the legacy environments that these sessions require. Things are just going to diverge further in the gnome3 land (for e.g. all legacy code will be dropped from g-s-d, g-c-c this cycle once the unity ports are complete).

There will be a few .desktop/autostart files that need tweaking but otherwise it should be straight forward to switch over.

@Tim: yes, currently it's maybe the best solution if we don't have to patch .desktop/autostart files.

But it can also be interesting to have a default mode for all sessions started with gnome-session (Unity, Cairo-Dock, Flashback, etc.) with some exceptions for Gnome-Shell (or Unity if it needs to start some specific apps, e.g.: the future file manager instead of Nautilus).

On Feb 9, 2014 8:50 AM, "Tim" <email address hidden> wrote:
> @Matthieu, I was discussing this mitya57 the other day with respect to
> -flashback. it seems that it would be best to move the GNOME2/Compiz
> sessions to using "Unity", since that is far closer to the legacy
> environments that these sessions require.

Yeah, this is in my TODO queue, I hope I will get to it by the week end.

> @Alkis: I think there is a typo in Ubuntu's patch.
> Can you stop nautilus ("nautilus -n") and then try to launch it with:
> $ env XDG_CURRENT_DESKTOP=GNOMEF nautilus

For some reason `nautilus -n` didn't do it, but `killall nautilus; nautilus` did the trick.

I.e. after the `killall nautilus` command, XDG_CURRENT_DESKTOP works fine, I don't get a title bar when it's GNOME, and I do get the traditional title bar when it's not GNOME.

So I clicked "affects me too" on LP: #1277963,
thank you. :)

I notice that Nautilus > preferences can't be accessed in Xenial, sort of like Nautilus should be using the Unity style menus rather than those used by gnome-shell???

As far as I've seen ATM only Nautilus is affected by that in Xenial but I need to have a closer look at some of the other GNOME specific apps to be certain of that.

Lance, nautilus was reverted to the version from 15.10, so it should be the same as there. What desktop is this happening under?

Sorry Tim, I forgot to mention this is a flashback problem. I brought the issue up on their mailing list.

GNOME Flashback in Ubuntu has "GNOME-Flashback:Unity" as XDG_CURRENT_DESKTOP so most likely it should use Unity settings, but nautilus has at least few patches that tries to detect Unity incorrectly... git_multiple_desktop_names.patch is only patch that correctly detects Unity.

It is time to switch back to GNOME-Flashback:GNOME...

Since in a normal GNOME session you access "preferences" and some other things by right-clicking on the nautilus tab in the top bar when nautilus is open, how would that be accessible in gnome-flashback?

@ Tim Lunn, there is another nautilus bug that affects both gnome-shell and gnome-flashback, bug #1554171.

In normal GNOME session preferences is available in appmenu, no? in GNOME by default that menu is displayed in top panel, but it is possible to change that so this appmenu is displayed by nautilus. At least it was possible in nautilus 3.18 and is still possible in nautilus 3.20.

GNOME Flashback 3.18 has workarounds module that changes Gtk/ShellShowsAppMenu to false. Check System Monitor - there is appmenu button and under that has preferences. Nautilus 3.18 had that too...

If ubuntu will continue to use "GNOME-Flashback:Unity" then for example 0002-Only-use-a-header-bar-in-GNOME-shell.patch must be fixed. It detects GNOME-Flashback as GNOME Shell session:
desktop = g_getenv ("XDG_CURRENT_DESKTOP");
if (desktop && strstr (desktop, "GNOME"))

Then restore-traditional-menu-bar.patch also looks wrong. nautilus-app-menu.ui (Where Preferences is available) is only used when shell shows app menu and shel does not show menubar. I think it should be used also when shell shows app menu is false as it indicate that application should show app menu in window...

The usage of XDG_CURRENT_DESKTOP in nautilus should be fixed. Most of the patches predate the standardisation of XDG_CURRENT_DESKTOP which now allows for multiple desktop names.

As for "GNOME-Flashback:Unity" vs "GNOME-Flashback:GNOME", switching would mean going back to gnome-settings-daemon/gnome-control-center. Does flashback have full support now for monitor config, idle monitor, input device settings and other bits that were removed from gnome-settings-daemon since 3.10. You will probably find that many apps will also switch to using CSD's and appmenu's (as a button), rather than traditional menus.

Why don't we use it like gedit? i.e

+static gboolean
+in_desktop (const gchar *name)
+{
+ const gchar *desktop_name_list;
+ gchar **names;
+ gboolean in_list = FALSE;
+ gint i;
+
+ desktop_name_list = g_getenv ("XDG_CURRENT_DESKTOP");
+ if (!desktop_name_list)
+ return FALSE;
+
+ names = g_strsplit (desktop_name_list, ":", -1);
+ for (i = 0; names[i] && !in_list; i++)
+ if (strcmp (names[i], name) == 0) {
+ in_list = TRUE;
+ break;
+ }
+ g_strfreev (names);
+
+ return in_list;
+}

Then we can use : if (in_desktop ("Unity"))

And no I don't like going back to GNOME-Flashback:GNOME. Many things will be broken. Lots of things need to be patched which we don't want in LTS.

(BTW, In Ubuntu, we can still reach nautilus preference if we add indicator-applet-appmenu to the panel. Although its a personal choice)

On Wed, Mar 9, 2016 at 5:16 AM, Tim <email address hidden> wrote:

> The usage of XDG_CURRENT_DESKTOP in nautilus should be fixed. Most of
> the patches predate the standardisation of XDG_CURRENT_DESKTOP which now
> allows for multiple desktop names.
>

Did you upload new nautilus package? When I wrote it it was about patches
in last uploaded version in xenial. Also it is not only about old
patches/code, same problem is with new patches/code - mostly it is simple
g_strcmp0...

As for "GNOME-Flashback:Unity" vs "GNOME-Flashback:GNOME", switching
> would mean going back to gnome-settings-daemon/gnome-control-center.
>

That is right thing... GNOME Flashback should work with GNOME components
not Unity.

> Does flashback have full support now for monitor config, idle monitor,
> input device settings and other bits that were removed from gnome-
> settings-daemon since 3.10. You will probably find that many apps will
>

Yes at least for monitor config, idle monitor.

> also switch to using CSD's and appmenu's (as a button), rather than
> traditional menus.
>

That is how it should work.

On Wed, Mar 9, 2016 at 6:48 AM, Khurshid Alam <email address hidden>
wrote:

> Why don't we use it like gedit? i.e
>
> +static gboolean
> +in_desktop (const gchar *name)
> +{
> + const gchar *desktop_name_list;
> + gchar **names;
> + gboolean in_list = FALSE;
> + gint i;
> +
> + desktop_name_list = g_getenv ("XDG_CURRENT_DESKTOP");
> + if (!desktop_name_list)
> + return FALSE;
> +
> + names = g_strsplit (desktop_name_list, ":", -1);
> + for (i = 0; names[i] && !in_list; i++)
> + if (strcmp (names[i], name) == 0) {
> + in_list = TRUE;
> + break;
> + }
> + g_strfreev (names);
> +
> + return in_list;
> +}
>
> Then we can use : if (in_desktop ("Unity"))
>

I guess something like that could be part of glib API...

And no I don't like going back to GNOME-Flashback:GNOME. Many things
> will be broken. Lots of things need to be patched which we don't want in
> LTS.
>

Be more specific - please give me list of broken things so I can fix that.

> (BTW, In Ubuntu, we can still reach nautilus preference if we add
> indicator-applet-appmenu to the panel. Although its a personal choice)
>

Not a solution.

--

There was time when GNOME Flashback was really in bad shape upstream, but
things have improved - it definitely is not that good as I would like, but
it should be usable.

Arch has added GNOME Flashback back to community repository with message -
"It became usable with GNOME 3.18". From ubuntu forum:

In my case, I've rebuilt some flashback packages with git codebase and now
> it works almost fine with Gtk+ 3.19.3, Gdm 3.19.2 and much more the
> bleeding-edge codebases...
>
> By the way, now I think we might be able to say good-bye to
> 'unity-related' packages. Actually my flashback could run with
> gnome-settings-daemon and without any indicator packages... But ibus seems
> to tweak a bit more to run automatically when login into flashback though.
>

P.S. The problem is not only with nautilus. Looks like Ambiance is and ...

On 09/03/16 16:59, Alberts Muktupāvels wrote:
> Did you upload new nautilus package? When I wrote it it was about patches
> in last uploaded version in xenial. Also it is not only about old
> patches/code, same problem is with new patches/code - mostly it is simple
> g_strcmp0...
No I meant "needs to be fixed", I filed bug 1554878 to track XDG_CURRENT_DESKTOP issues, feel free to add any other affected packages to that
bug. I will try and fix/upload nautilus over the weekend.
> That is right thing... GNOME Flashback should work with GNOME components
> not Unity.
OK, Flashback was set to unity, it did not have support for current GNOME components
>
>
>> Does flashback have full support now for monitor config, idle monitor,
>> input device settings and other bits that were removed from gnome-
>> settings-daemon since 3.10. You will probably find that many apps will
>>
> Yes at least for monitor config, idle monitor.
ok maybe input settings is a 3.19 thing
>
>> also switch to using CSD's and appmenu's (as a button), rather than
>> traditional menus.
>>
> That is how it should work.
Ok, but its up to the maintainers (Dmitry) to switch it back
>
>
> I guess something like that could be part of glib API...
Yes it would make sense in glib, but not sure where it would live..
>
> P.S. The problem is not only with nautilus. Looks like Ambiance is and will
> be Unity only theme. It not updated to support csd windows. It does not
> work good with mutter, metacity - CSD windows are not resizable, windows
> has problem with rounded corners...
There was meant to be some work on this, not sure if it was ever completed, maybe chat to larsu
>

On Wed, Mar 9, 2016 at 9:27 AM, Tim <email address hidden> wrote:

> > That is right thing... GNOME Flashback should work with GNOME components
> > not Unity.
> OK, Flashback was set to unity, it did not have support for current GNOME
> components
>

I know that.

>> Does flashback have full support now for monitor config, idle monitor,
> >> input device settings and other bits that were removed from gnome-
> >> settings-daemon since 3.10. You will probably find that many apps will
> >>
> > Yes at least for monitor config, idle monitor.
> ok maybe input settings is a 3.19 thing
>

What do you mean with input settings? Input sources? Than it is already
available, but disabled...

>> also switch to using CSD's and appmenu's (as a button), rather than
> >> traditional menus.
> >>
> > That is how it should work.
> Ok, but its up to the maintainers (Dmitry) to switch it back
>

I think that he is/was thinking about switching back, but not for 16.04.

On 09/03/16 18:57, Alberts Muktupāvels wrote:
> What do you mean with input settings? Input sources? Than it is already available, but disabled...
input device settings, i.e. mouse, touchpad etc. These moved out of g-s-d mouse plugin, into a mutter libinput based backend, but as mentioned
thats probably 3.19. The inital movement in 3.18 was just the gsettings keys, but I patched u-s-d for that, so you should be ok.

@Alberts,

> P.S. The problem is not only with nautilus. Looks like Ambiance is and will be Unity only theme. It not updated to support csd windows. It does not work good with mutter, metacity - CSD windows are not resizable, windows has problem with rounded corners...

The problem for rounded corners should be fixed in the latest version. For resizable windows — will lp:~albertsmuktupavels/ubuntu-themes/csd-window-shadow-and-resize-area fix that? If you have addressed Lars' concerns, I can ping him about re-reviewing that branch.

> I think that he is/was thinking about switching back, but not for 16.04.

Funny enough, the log for *this* bug earlier says we should move XDG_CURRENT_DESKTOP from GNOME to Unity. Now as it seems that people request moving back, I can do that for 16.10.

On Fri, Mar 11, 2016 at 7:11 PM, Dmitry Shachnev <email address hidden> wrote:

> @Alberts,
>
> > P.S. The problem is not only with nautilus. Looks like Ambiance is and
> will be Unity only theme. It not updated to support csd windows. It does
> not work good with mutter, metacity - CSD windows are not resizable,
> windows has problem with rounded corners...
>
> The problem for rounded corners should be fixed in the latest version.
> For resizable windows — will lp:~albertsmuktupavels/ubuntu-themes/csd-
> window-shadow-and-resize-area fix that? If you have addressed Lars'
> concerns, I can ping him about re-reviewing that branch.
>

I have made some changes after his comment. GTK_FRAME_EXTENTS still not
supported so I think it will not be merged... You can try to ping him, I
can update branch if needed, but I will do it only if I will know that it
will be merged.

P.S. Just logged in Ubuntu session and opened polari. It has black
corners... Adding margin just added black borders so merging that branch
would cause problems... We need GTK_FRAME_EXTENTS support in compiz...

> I can update branch if needed, but I will do it only if I will know that it will be merged.

Actually, can you repeat this on your own merge proposal? The reviewers don't receive mails about code changes by default, only about comments. If you get no reply after that, I'll ping Lars elsewhere.

> Just logged in Ubuntu session and opened polari. It has black corners...

Ah right, the fix was on Unity side, so Metacity/plain Compiz don't have it (it was lp:~3v1n0/unity/gtk-border-radius-support).

> We need GTK_FRAME_EXTENTS support in compiz...

I don't think we should care much about GNOME-Flashback Compiz session, if you the theme can be fixed to work fine with Metacity, it will be fine.

On Fri, Mar 11, 2016 at 8:29 PM, Dmitry Shachnev <email address hidden> wrote:

> > I can update branch if needed, but I will do it only if I will know
> that it will be merged.
>
> Actually, can you repeat this on your own merge proposal? The reviewers
> don't receive mails about code changes by default, only about comments.
> If you get no reply after that, I'll ping Lars elsewhere.
>
> > Just logged in Ubuntu session and opened polari. It has black
> corners...
>
> Ah right, the fix was on Unity side, so Metacity/plain Compiz don't have
> it (it was lp:~3v1n0/unity/gtk-border-radius-support).
>

It was in Unity...

> We need GTK_FRAME_EXTENTS support in compiz...
>
> I don't think we should care much about GNOME-Flashback Compiz session,
> if you the theme can be fixed to work fine with Metacity, it will be
> fine.
>

Theme changes will fix csd windows under metacity or mutter, but will cause
problems in both compiz sessions - flashback & unity. Because of margin
there will be black border. You can try:
- add .window-frame { margin: 10px; } in ~.config/gtk-3.0/gtk.css
- open polari or any other csd window that is not patched to use ssd

I opened bug 1565780 to address the missing nautilus preferences menu in Xenial.