Removal of headerbar patches and impact on Unity

Desktop Ubuntu Unity Development
1

Jeremy started this thread on #ubuntu-desktop
https://lists.ubuntu.com/archives/ubuntu-desktop/2017-November/005275.html

Issue:
Ubuntu patches Gnome apps to use tradition titlebar and menubar (in some apps) so that it can work well under Unity (Specially for LIM). This patches are set to apply in two ways:

  1. It will show titlebar only for Unity session.
  2. It will show headerbar only for Gnome session.

Since Elementary and others also use headerbar, (2) is the problem. One solution is to convert (2) into (1), which is fairly simple thing to do (And I have already converted many (2) into (1) on the bug report: Bug #1719322 “Remove patch to remove headerbar” : Bugs : file-roller package : Ubuntu).

But he also explains why Canonical doesn’t want this.

One of the Desktop Team goals was to reduce the Ubuntu-specific
patches we are carrying. We made great progress in Ubuntu 17.10 by
dropping Ubuntu Online Accounts, but we are still carrying a lot of
patches.

There are two major kinds of headerbar patches… One replaces the
headerbar with a patch to add a separate titlebar. These patches was
more important when non-GNOME desktops and themes had trouble with the
headerbars.

The second kind of patch restores a traditional File/Edit/View (FEV)
menu to apps that have removed theirs. This is nice for Unity’s
menubars, but in my opinion aren’t necessarily better for users in
other desktops. There is resistance to upstreaming these patches to
Debian GNOME because they add lots of translatable strings without
providing translations.

The FEV patches potentially are more difficult to maintain. For
instance, we kept the titlebar patch for Nautilus in Ubuntu 16.10 and
17.04 but not the FEV because no one volunteered to do the work.

There is a large and growing number of apps that have headerbars that
Ubuntu never patched. Also, more apps are converting to them (for
instance, I expect Firefox to get headerbars before Ubuntu 18.04 is
released). I think there’s a strong argument that can be made that
Ubuntu should generally distribute apps as intended by the developers
unless we are fixing a significant bug.

Solutions:

Jeremy proposed two solutions for default Ubuntu:

  1. What to do with all the headerbar patches?
    Bug #1719322 “Remove patch to remove headerbar” : Bugs : file-roller package : Ubuntu
    a. We could drop the ones that haven’t been pushed upstream (to GNOME)
    b. We could keep them but set them to only apply against Unity

For (b), I already explained above and converted those apps into (1) from (2)

For (a), I propose any of following:

  1. Use gtk-shell-show-appmenu=true for Unity session.

This can be done using:

gsettings set org.gnome.settings-daemon.plugins.xsettings overrides '@a{sv} {"Gtk/ShellShowsAppMenu": <int32 0>}'

This will show shell-appmenu in the app itself. See screnshot: https://i.imgur.com/wWwnP6o.png

However if user doesn’t use LIM, he will end up using duplicate menus: one on the panel and one on the app.

  1. Make unity-session depends on gtk3-nocsd
    gtk3-nocsd package : Ubuntu

gtk3-nocsd will automatically force all applications to use traditional titlebar. No patches required.

(Although if a gnome app (like d-feet) doesn’t use standard gtk3-api to set gtk_window_set_titlebar (GTK_WINDOW (window), headerbar), it won’t work with gtk3-nocsd either. But that’s a small issue.)

Thoughts?

3 Likes
2

Thanks Khurshid for opening this discussion here! It’s a good idea so I think we’ll want to continue the discussion here instead of on the mailing list.

@seb128 asked on the mailing list

Do we have any upstream application using headerbar and a menubar?
Usually those new interfaces have an hamburger menu so there shouldn’t
be any issue with lim in Unity?

  1. Baobab 3.27 accepted our patch to use a titlebar instead of headerbars on Unity. The developers did not want this applied to desktops that are not Unity.

  2. gedit upstream offers traditional File/Edit/View menus for Unity, but the title bar patch is Ubuntu-specific just for Unity.

  3. The LIM (locally integrated menus) issue is that the program’s App Menu (the single menu in the top bar of GNOME Shell) is not accessible when that Unity option is enabled. There are usually important functions in the App Menu that are not duplicated elsewhere (like Preferences). The App Menu is different than the ☰ hamburger menu.

1 Like
3

Oh and Simple Scan of course supports traditional menus and title bar when run outside GNOME.

1 Like
4

Showing appmenus inside of application windows works fairly well, and it what we do in elementary OS (since our shell does not display app menus outside of the app windows). That would make sense for Unity as well, unless Unity’s panel was updated to show appmenus as well as menubar contents.

I agree that headerbars create an issue for locally-integrated menus, but that’s the nature of client-side decorations and headerbars, which GNOME and the larger GTK-using community has largely adopted.

In my opinion, the following makes the most sense to both reduce the maintenance burden and to align best with upstream:

  1. Remove LIM from Unity in versions going forward. Since—as I understand it—Unity is effectively deprecated, removing problematic behavior is probably the path of least resistance here.

  2. Remove headerbar, menubar, and non-GNOME-behavior patches from upstream GNOME/GTK 3 apps. These apps were designed around the concept of a headerbar, and in the default GNOME-based Ubuntu session, these apps operate as designed.

  3. Show appmenus in app windows in the Unity session. This retains the vital functionality of headerbar client-side decorated apps in a way that is supported by GNOME itself, and has been used in the last couple of releases by elementary OS.

2 Likes
5

LIM is beloved by many Unity 7 users who hope to continue using Unity 7 installed from Universe. What’s more, community forks of Unity 8, such as Yunit, currently support LIM, and I would assume hope to continue supporting LIM, where possible.

For these reason, I do hope that, where possible, GNOME apps will continue to be patched to support LIM for at least as long as Unity 7 remains available in Universe, and ideally long thereafter, provided Yunit (or some other Unity 8 fork) ever gains momentum.

6

Clearly LIM is useful for a number of projects, but are distro patches the most effective way to support them?

Distro patches are a form of “technical debt”, they involve a continuing cost of maintaining the patch where the underlying code can change without the upstream developer being aware of the impact. This is something that ought to be resolved properly: by moving the functionality upstream.

Canonical developers have been maintaining the patches for reasons related to Canonical’s projects. Those reasons are gone, so it is right and proper for them to consider whether, for Canonical, they are worth the cost of maintaining them.

The best outcome for everyone would be that representatives of the interested projects persuade the app developers to accept the patches upstream.

2 Likes
7

Probably not for the long-term. But perhaps for the near-term, for the reasons that I provide below.

Agreed!

But Canonical dropped Unity 7 and Unity 8 development very suddenly, and “representatives of the interested projects” haven’t yet had much chance even to coalesce, much less organize into groups capable of persuading anyone to do anything.

So, at least during the coalescence/organization phase, I hope that Canonical will: (1) continue to maintain the patches, perhaps through 18.04; and/or (2) exert its influence on behalf of the yet-to-be-formed “interested projects” to “persuade the app developers to accept the patches upstream.” And actually, I’m all for pushing the patches upstream.

As an aside, I’m curious about the following:

Does gtk3-nocsd have the potential to render moot this entire discussion?

8

But Unity isn’t officially supported - Ubuntu is supposed to devote man hours to something they no longer support? My understanding is that these patches are work intensive to keep up. So, most likely these finite resources could be used elsewhere for supported software.

9

Yes, in one alternative, I’m suggesting that Canonical support these patches during a transitional period, namely at least through 18.04.

1 Like
10

There are two types of patches, a) headerbar patches and b) horizontal menubar (FEV) patches. FEV patches are more difficult to maintain. In past whenever Ubuntu sent patches to upstream, they sent both of them and Gnome took a very strong stand specially against the menubar patches. So may be this time we should try to push only header-bar patches which are nothing but well supported feature of gtk3-api. I modified headerbar patches so that it will only effective in Unity. So may be we can keep the headerbar patches for 18.04.

Without FEV we will still have vertical menus which, in my experience works well in combination with gear menu.

11

Is a horizontal menubar (FEV) needed for proper global menu function in DEs such as Unity 7, MATE, etc? (I assume, yes, but want to be sure.)

12

FEV is not essential global menu to work. FEV just makes vertical app-menu (shell app-menu) horizontal menubar with other menu options. In Gnome, vertical menu just contains preferences, quit etc for some apps. Other menu options are distributed among gear menu, headerbar button etc.

Without FEV, global menu will still work but it may not look good or may not be consistent with non headerbar apps.

2 Likes
13

@khurshid-alam what’s the status of this? Is the Unity Remix ready for the Ubuntu Desktop team to drop the headerbar patches?

14

Not yet, we haven’t got our meta package in the universe. Hopefully soon.

Btw, I converted patches for all the apps mentioned in the bug report from (2) to (1). So they only affects unity now. So my question is can Ubuntu keep them for 18.04 cycle?

15

Does gtk3-nocsd work about as well as patching all those apps?

16

Atm, Nautilus (3.26.x) is crashing with gtk3-nocsd and not all the apps will work with it. That’s why I prefer patched apps.

17

Nautilus runs fine without crashing here. (I commented on the bug you filed). What apps don’t work with gtk3-nocsd?

If you can find a solution that doesn’t require distro patches, it’s better for efforts to run Unity or Unity features on other distros.

18

For example, d-feet. Although that’s not a default app.

19

Ok, now that Nautilus appears to work with gtk3-nocsd, it feels to me like it might be a good choice for you and allow these patches to be dropped. If you make gtk3-nocsd a Recommends, it will allow people to uninstall it if they prefer headerbars.

d-feet appears to be a rare exception; I haven’t found other apps that don’t work with gtk3-nocsd. d-feet would lose the About, Help and Quit menu items if System Settings > Appearance > Behavior > Show menus > in the window’s title bar is selected. The Help is pretty minimal (and can also be accessed with F1). I would accept a distro patch to fix or workaround this issue.

20

Another one is gnome-tweak-tool