https://extensions.gnome.org/extension/1267/no-title-bar/
This is an actively maintained fork of pixel saver which brings also some nice additions.
“Can’t live without it.” “Total disaster”<- just trumping a bit
No really, it’s really good if you come from unity =)
1 Like
This extension depends on some Xorg utilities
Are we sure it works on wayland?
1 Like
But since more and more applications switch to headerbars, it isn’t that big of an issue.
1 Like
Thank you!!! I just installed it in Wayland with Ubuntu 18.10 -> looks great!
https://extensions.gnome.org/extension/1250/gnome-global-application-menu/
https://www.reddit.com/r/gnome/comments/9m2duk/are_there_any_plans_to_add_a_global_menu_to_the/
not usable any more on gnome 3.30 … and especially not supported any more in future gnome versions . 
not usable any more on gnome 3.30… and especially not supported any more in future gnome versions .
Yes true. The Ubuntu developers decided not just discontinued Unity, but also they remove the patches to the core Gnome applications like is Nautilus and that was the way to support the Global Menu in that applications.
In that context a third party developer will have only a few alternatives as solution options:
1- Hack the GNOME core applications by himself and add again the menubar.
2- Continue the develop of an extension without give support to the GNOME core applications.
3- Discontinue the extension.
The option #1: This was frustrated when the Gtk developers also decided no support general-purpose modules
The option #2 This have not sense, as will be implement something that can not be used with the most commons applications.
The option #3 This was the option that was taken as is the more reasonable in this context.
Well yes, is worse than just the discontinuation of an extension, because was discontinued Unity, the intention of the global menu, the support for it and then the last and less important thing, was discontinued that extension.
The discontinuation of the extension finally was as a normal consequence to all that previously things. Swimming against the river flow is of course difficult.
Please, do not include any of these extensions by default. All of them are based on very rough hacks, AFAICR using xwininfo or xprop and resorting to heuristics and trickery to infer X client ids. Also I remember unpleasant visual artifacts when resuming a suspended session. And this won’t change without Gnome support; indeed, Gnome has recently removed support for a Gtk X property that hid titlebar on maximization. Everything in Gnome has been moving to CSD headerbars for a long time now. By chosing Gnome, Ubuntu has bought this, whether you like it or not. Some things can be adapted to keep the old experience but this is not one of them.
2 Likes
Only Gnome apps use headerbars, I use PyCharm daily and having such extension is so much welcome (using Unite) as otherwise Gnomes wastes like 1cm of pixels on the top.
Note how this is similar to the space used on a mac:
Mac uses thin decorations for apps with no headerbars, while in Gnome they’re always fat, so wasting space for the sake of consistency.
2 Likes
Another option would be to use another flavor. Plasma and MATE support global menu (and Ubuntu MATE has HUD support by default, too). And I think Budgie, does support it, too but don’t quote me on that.
Are you talking about some very recent change which will only show up in future Ubuntu releases?
Because I’ve been using Unite for the last few weeks, and it’s been very solid (unlike similar extensions I tried before). It would be too bad if it finally has to be discontinued.
Thanks. This seems about tiled windows in particular, however.
I’m running GNOME 3.32.1, the Unite extension works fine, and it seems to have more features than Maximal.
I’ve already commented about the way those extensions are implemented and about the way upstream support for implementing them right is not going to happen. The above was only an example showing the direction things are taking. Number of features implemented on top of horrible hacks is not related to the point I’m making.
1 Like
There are people here that just are speaking without be a developer or know anything really about what happen. You can find useful information of what exactly was removed in what context and for what Gtk version here.
FWIW, it’s not so clear for me from that thread either.
One comment says “please don’t remove [a feature]”, while another says “The motivation for these patches is to support extensions like pixel-saver and maximus on wayland”. Was the actually committed patch the one or the other? Will it help the said extensions?
The version is clear, though (GTK 4).
One comment says “please don’t remove [a feature]”, while another says “The motivation for these patches is to support extensions like pixel-saver and maximus on wayland”
This issue was create to improve the support of that feature in Gtk and it ended up in the remove of it for Gtk4. So, probably that is the reason of your confusion.
Was the actually committed patch the one or the other?
See the list of patches and the one that say committed is the committed one. It was: Remove GtkWindow::hide-titlebar-when-maximized.
Will it help the said extensions?
Not at all.
1 Like
Thanks for the explanation. And oh well.
There’s still Qt, I guess.
I also wonder how Mate is going to adapt: the titlebar-less maximized windows are among its official supported features.
I also wonder how Mate is going to adapt: the titlebar-less maximized windows are among its official supported features.
Not one in Mate is develop Gtk, so in theory they can no do anything, but in practice the support for that feature can be reintroduced as a distro specific patch to Gtk (probably for all distributions that want to fully support the Mate desktop). This is of course complex and is not fully on the hands of the Mate developers. Also i’m not saying here that the Mate team will used that idea. What i said it’s just that, an idea. Also I said that only because it’s how this was resolved before in similar situations.
What catches my attention is to see how there are external people who completely omit that Linux is more than a particular environment (for example: GNOME) and they try to give recommendations that can probably improve the user experience in a particular environment, but undoubtedly this will break the user experience as a whole outside that particular environment.
If all people would realized that there is a world out there somewhat farther from where they reach their sight, we probably had a better ecosystem in Linux.
Are you saying that at a Gtk developer?
IMHO it’s quite normal to give GNOME users advice how they can configure their environment. And it’s just fine if the said advice wouldn’t hold in different environments.
The toolkit’s role in that is to support the necessary capability, at least in the environments where that’s possible.
Any conflict that I can think of may arise when some developers write their programs in a way that would only work in e.g. GNOME.
Are you saying that at a Gtk developer?
No, I’m saying this as general concept. People tends to omit the preference and the work of others… I think it’s not good that this happens and this is without enter in details of if was an specific user or a developer. But yes this is an specific example, and you can find specific affected people here. I guess the ideal world, where all try to help all does only exist in my imagination, but not in practice.