Bug 115512 - Client-side window decorations (remove titlebar from UI when running GNOME with some toolbar view modes)
Summary: Client-side window decorations (remove titlebar from UI when running GNOME wi...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL: https://blogs.gnome.org/tbernard/2018...
Whiteboard:
Keywords:
: 146085 (view as bug list)
Depends on:
Blocks: Desktop-Integration UI
  Show dependency treegraph
 
Reported: 2018-02-07 11:59 UTC by Heiko Tietze
Modified: 2021-12-13 18:19 UTC (History)
18 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot (1.22 MB, image/png)
2018-02-07 18:11 UTC, Bastián Díaz
Details
rough concept of LibreOffice with GNOME-style CSD (40.83 KB, image/png)
2018-02-13 13:53 UTC, Tobias Bernard
Details
rough concept of LibreOffice with macOS-style CSD (41.60 KB, image/png)
2018-02-13 13:55 UTC, Tobias Bernard
Details
lo-csd-gtk4-libadwaita-examples (179.87 KB, image/png)
2021-12-10 04:21 UTC, christian.ohrfandl
Details
lo-csd-gtk4-libadwaita-oldstyle-examples (199.29 KB, image/png)
2021-12-10 05:17 UTC, christian.ohrfandl
Details
GTK4 libadwaita CSD when run on KDE Plasma 5 (151.09 KB, image/png)
2021-12-10 14:50 UTC, christian.ohrfandl
Details
GTK4 Libadwaita CSD inkl. GtKPopupMenuBar and various themes in comparison (347.32 KB, image/png)
2021-12-10 18:32 UTC, christian.ohrfandl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Heiko Tietze 2018-02-07 11:59:35 UTC
The contemporary Gnome UI style is without title bar. While LibreOffice is prepared for most situations with the Notebookbar it's not in this case. We should a) consider to hide the title bar for Gnome-based OS and b) add instead a small bar to make sure the user can move the window. This approach is known for instance in Chrome. Alternative ideas are welcome.
Comment 1 Maxim Monastirsky 2018-02-07 12:41:29 UTC
(In reply to Heiko Tietze from comment #0)
> We
> should a) consider to hide the title bar for Gnome-based OS and b) add
> instead a small bar to make sure the user can move the window. This approach
> is known for instance in Chrome.
Chrome isn't a good example, as in addition it also does c) make use of the free space on that dragging frame (by putting there the tabs bar and the user switching button). And so should we, if we ever decide to hide the system title bar. Just replacing the system title bar (which we get for free from the system), with our own implementation (which we'll have to maintain) makes no sense.
Comment 2 Bastián Díaz 2018-02-07 18:11:19 UTC
Created attachment 139671 [details]
screenshot

I think Mozilla Firefox offers a better solution by providing white space at the beginning and end of the tabs (when the window is not maximized), in addition to useful white space like the one on each side of the address bar.

On the other hand, a small bar is a bad idea, since it is a difficult target to hold with a pointer and even more if we talk about touch devices. GNOME HIG for example recommends not using small targets. GTK Headerbar allows you to drag the window from anywhere -including buttons- and other office applications allow you to drag the window of any blank space available in the toolbar.
Comment 3 V Stuart Foote 2018-02-11 15:06:09 UTC
@Heiko, *

Why would we treat GNOME based DE any different than other requests (e.g. bug 113388) for Client Side Decoration control of the application frame? Or likewise not support native application styles from Apple HIG for macOS builds, or implement Windows UWP support.

If consensus remains that project is cross platform, implementing CSD piecemeal for your favorite OS/DE (unless actually required--and this isn't) breaks that paradigm.
Comment 4 Tobias Bernard 2018-02-13 13:53:59 UTC
Created attachment 139866 [details]
rough concept of LibreOffice with GNOME-style CSD
Comment 5 Tobias Bernard 2018-02-13 13:54:46 UTC
Hi, Tobias from GNOME here.

CSD are most useful when they allow placing window controls and other interface elements in the same bar. That's the approach we take with GNOME apps. We have a widget in GTK called header bar, which automatically places window controls on the left/right side depending on system settings, so application authors don't have to deal with this.

I think when the Notebookbar is enabled, LibreOffice could relatively easily use GNOME-style CSD, by simply adding the window controls to the left/right of the top bar. This approach could also work on macOS and Windows (in fact, MS Office on macOS already does something very similar). One challenge is assuring that there is always some empty space to the left or right of the Notebookbar tabs, so users can move the window easily.

I've attached some very rough concepts of how the CSD solution I'm describing could look on GNOME and macOS. I imagine this would be easily adaptable to the style on other systems (e.g. by having three buttons on the right on Windows).
Comment 6 Tobias Bernard 2018-02-13 13:55:23 UTC
Created attachment 139867 [details]
rough concept of LibreOffice with macOS-style CSD
Comment 7 andreas_k 2018-02-13 15:26:06 UTC
I like the idea to put the window controls into the notebookbar but not in the regular toolbar layout.

Is it possible to add a show/hide window decoration button like we have it for menubar, sidebar, ...
Comment 8 Ariel 2019-02-10 16:04:22 UTC
+1 on this request. Now that notebookbar is no longer experimental, this is the only other key UI element (IMHO) that is making LO look dated in the modern GNOME desktop. Really looking forward to this
Comment 9 cranetester 2019-04-02 21:00:56 UTC
What if you don't want to use the ribbon? Most users hate it because it requires way too much mousework. It would mean an unconventional and arguably inferior user experience for most people.

Also the ribbon is nowhere to be found in the Gnome design guidelines. It's a not feature that GTK provides out of the box. So the ribbon will actually make the program fit more poorly into the Gnome desktop than it does now.

And finally, the no-tilebar feature will be solely for Gnome, at it well never look or function the same as a real headerbar.

Given all that, spending time on developing this particular feature does not seem wise. What's the benefit? I see only downsides.

If the goal is to integrate with the Gnome desktop, Libre Office could work with Gnome to develop a CSD library that would allow non-GTK programs to use real GTK headerbars. It should also work with them to finally create a *standard* and native replacement for menubars. This would be another library. 

At the moment, the Gnome design team doesn't even provide any sort of UI model that could replace menubars. So if Gnome wants apps like LO to replace the tried and tested features, it is Gnome's responsibility to explain how that might be done. One idea might be a large command pallete with widgets for various actions and a search interface.


The responsibility for desktop integration should be shared between app developers and the desktop maintainers. If Gnome pushes a new design then it should also help developers adopt it. Otherwise, just stick to the traditional design.
Comment 10 andreas_k 2019-04-03 05:32:31 UTC
Gnome is a good and nice desktop environmental and gtk a beautiful toolkit. But
- we don't have gnome icons cause there is no designer draw it. We use there elementary icons which is ok.
- csd would be nice that's the reason for this bug. But I agree it has massive open ui questions.
- libreoffice is not gnome only. As long as libo is no gnome app only it has to be always a compromise.
- nb is optional and was done for or win users cause someone was willing to make it.
Comment 11 Ariel 2019-04-03 13:51:51 UTC
++ on comment #10
To add: none of the keyboard shortcuts have to go. Further, the menus could stay, hidden until the user presses Alt, like VSCode and many other apps offer. Further, with CSD, a sidebar could be possible as an alternative or in addition to a better use of the top window decoration (like Tilix / VScode and other modern apps offer)
Comment 12 V Stuart Foote 2019-04-03 14:01:22 UTC
Just a simple No!

If it can't be done cross-platform it does not belong in the LibreOffice core. Show me the devs with commitment to work on macOS and Windows this and other native CSD schemes for those builds.

Crickets <chirping>....

IMHO => WF
Comment 13 Percy 2020-04-19 19:52:00 UTC
Not yet solved? please consider to hide the title bar for Gnome-based systems, title bar takes up space that could be better used.
Comment 14 Jean-Baptiste Faure 2020-04-19 20:49:07 UTC
(In reply to Percy from comment #13)
> Not yet solved? please consider to hide the title bar for Gnome-based
> systems, title bar takes up space that could be better used.

There is nothing to solve there, because there is no bug. Only a request for a change that is not an improvement, from my point of view.

Best regards. JBF
Comment 15 Heiko Tietze 2020-04-20 10:28:09 UTC
Let's remove needsUX since opinions have been made. Some pro some cons, low priority. The more people CC on a ticket the higher we prioritize it. And 6 is not so many.
Comment 16 izak 2020-06-29 04:56:34 UTC
No need for title bar in tabbed mode
Comment 17 TF 2021-01-03 07:36:46 UTC
I think Libreoffice should look to modern HIGs such as Gnome’s to improve the dated feel of the suite.
Comment 18 Heiko Tietze 2021-12-07 06:16:23 UTC
*** Bug 146085 has been marked as a duplicate of this bug. ***
Comment 19 christian.ohrfandl 2021-12-10 04:10:53 UTC
Alright guys, I did it! Got libadwaita (https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/) to work in LibreOffice GTK4 build :) Thx @caolan for hinting me at how to add new libraries to LO.

I tried to get interface done analogous to the mockup presented in https://bugs.documentfoundation.org/attachment.cgi?id=139671.

Attached to this ticket, you can see the pictures of the interface. Please let me know what you think so far :) In general I am very pleased with this toolkit; especially that it is “just” in the beta state and already delivering so much nice functionality to use. E.g. as you will see in the pictures, I used light and dark themes and also made advantage of a TitleViewer that adjusts to the horizontal space that is left in the titlebar.

P.S.: Do not fear that libadwaita is only made for mobile devices; I have configured the interface in a way, that it will not take advantage of the small views.
Comment 20 christian.ohrfandl 2021-12-10 04:21:29 UTC
Created attachment 176839 [details]
lo-csd-gtk4-libadwaita-examples
Comment 21 christian.ohrfandl 2021-12-10 04:22:36 UTC
(In reply to christian.ohrfandl from comment #19)
> Alright guys, I did it! Got libadwaita
> (https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/) to work in
> LibreOffice GTK4 build :) Thx @caolan for hinting me at how to add new
> libraries to LO.
> 
> I tried to get interface done analogous to the mockup presented in
> https://bugs.documentfoundation.org/attachment.cgi?id=139671.
> 
> Attached to this ticket, you can see the pictures of the interface. Please
> let me know what you think so far :) In general I am very pleased with this
> toolkit; especially that it is “just” in the beta state and already
> delivering so much nice functionality to use. E.g. as you will see in the
> pictures, I used light and dark themes and also made advantage of a
> TitleViewer that adjusts to the horizontal space that is left in the
> titlebar.
> 
> P.S.: Do not fear that libadwaita is only made for mobile devices; I have
> configured the interface in a way, that it will not take advantage of the
> small views.

You can also view the pictures here: https://ask.libreoffice.org/t/development-exchange-libreoffice-main-frame-with-a-gtk4-one/71248/8
Comment 22 christian.ohrfandl 2021-12-10 05:17:48 UTC
Created attachment 176840 [details]
lo-csd-gtk4-libadwaita-oldstyle-examples

And here is another version using the "old" style (in this case the Ubuntu 21.10 system theme).
Comment 23 andreas_k 2021-12-10 06:24:57 UTC
It's really cool. As libo has to work on all platforms and toolkits, how would it look like if you show the menubar or the tabs of the tabbed layouts at the CSD.

I really like how VS Code use the window decoration area https://docs.microsoft.com/de-de/azure/search/media/search-get-started-rest/create-document-2.png

This would save vertical space but would be the same UI than on other platforms.
Comment 24 Heiko Tietze 2021-12-10 06:41:04 UTC
Mind to share the patch so testing locally is possible? Not sure if it works at all on my KDE system. Or becomes themed into native Qt look and feel.
Comment 25 V Stuart Foote 2021-12-10 14:29:05 UTC
(In reply to andreas_k from comment #23)
 
> I really like how VS Code use the window decoration area
> https://docs.microsoft.com/de-de/azure/search/media/search-get-started-rest/
> create-document-2.png
> 

Me to, but can't get there from here. VS Code is a UWP XAML (WinUI) application. Without a massive move of LO to UWP, we will remain limited to CSD of DWM for a Win32 application [1]

But hey, if we did that we would get working DE theming and ability to build for other UWP platforms ;-)

=-ref-=
[1] https://docs.microsoft.com/en-us/windows/win32/dwm/customframe
Comment 26 christian.ohrfandl 2021-12-10 14:49:13 UTC
(In reply to Heiko Tietze from comment #24)
> Mind to share the patch so testing locally is possible? Not sure if it works
> at all on my KDE system. Or becomes themed into native Qt look and feel.

Yeah, I'll share the code once it is in better shape; I am currently at the stage of "playing around" and finding my way into LO. But I'll deliver some merge requests little by little. I would actually want to talk to the main devs about how such an introduction of GTK4 CSD and libadwaita could be done from an architectural POV, because in the longer term this would take some major refinements of gtkframe.cxx (e.g. making use of .ui files et cetera).

However, I got you some KDE pics attached in the next images. IMO libadwaita is shown quite nicely on KDE aswell; some icons seem to not be found by the theme; but these are details...
Comment 27 christian.ohrfandl 2021-12-10 14:50:22 UTC
Created attachment 176845 [details]
GTK4 libadwaita CSD when run on KDE Plasma 5
Comment 28 Michael Warner 2021-12-10 15:13:15 UTC
Personally, I don't like the CSD design. I find it much easier to select and move windows around and also to tell which document is open with a dedicated title bar. Screen space is not a problem for me. Therefore, if this feature is ever implemented, I request that it be optional.
Comment 29 Jean-Baptiste Faure 2021-12-10 18:00:26 UTC
I disagree this request: I use LibreOffice under Ubuntu 20.04 with Gnome and, already, I do not have the title bar. It is easy to obtain with a Gnome extension. I use this one: https://extensions.gnome.org/extension/2015/no-title-bar-forked/
Using a Gnome extension is better for me as it let the user configure its LibreOffice as they want, with or without a title bar, and without development effort from LibreOffice side.

Best regards. JBF
Comment 30 christian.ohrfandl 2021-12-10 18:31:14 UTC
(In reply to andreas_k from comment #23)
> It's really cool. As libo has to work on all platforms and toolkits, how
> would it look like if you show the menubar or the tabs of the tabbed layouts
> at the CSD.
> 
> I really like how VS Code use the window decoration area
> https://docs.microsoft.com/de-de/azure/search/media/search-get-started-rest/
> create-document-2.png
> 
> This would save vertical space but would be the same UI than on other
> platforms.

So I was investigating your Request about having the MenuBar in the HeaderBar integrated as e.g. VS Code does. To my surprise: I got this to work :D I don't know whether the GTK Designers had this in mind (using a GtkPopupMenuBar in a HeaderBar), but due to the fact that this is a GtkWidget, it works actually flawlessly.

I put some examples in the screenshot that I am about to upload right away. Additinally I put together a bunch of themes for better comparability (there is of course room of improvement, just POC).

Have fun :)
Comment 31 christian.ohrfandl 2021-12-10 18:32:20 UTC
Created attachment 176850 [details]
GTK4 Libadwaita CSD inkl. GtKPopupMenuBar and various themes in comparison
Comment 32 christian.ohrfandl 2021-12-10 18:35:37 UTC
(In reply to Michael Warner from comment #28)
> Personally, I don't like the CSD design. I find it much easier to select and
> move windows around and also to tell which document is open with a dedicated
> title bar. Screen space is not a problem for me. Therefore, if this feature
> is ever implemented, I request that it be optional.

It can be optional, I would not disagree. However, there are so many applications that support CSD (e.g. Firefox, Chrome), some of them even having CSD as default option. Also Microsoft office "kind of" has CSD as default

In my opinion, especially the younger generation and of course Mac and Gnome users may be pleased by CSD. Therefore, I would of course see this as an option, especially, because it may attract new users from other office software to LO.
Comment 33 christian.ohrfandl 2021-12-10 18:43:58 UTC
(In reply to Jean-Baptiste Faure from comment #29)
> I disagree this request: I use LibreOffice under Ubuntu 20.04 with Gnome
> and, already, I do not have the title bar. It is easy to obtain with a Gnome
> extension. I use this one:
> https://extensions.gnome.org/extension/2015/no-title-bar-forked/
> Using a Gnome extension is better for me as it let the user configure its
> LibreOffice as they want, with or without a title bar, and without
> development effort from LibreOffice side.
> 
> Best regards. JBF

Sorry but I have to disagree here; it is not about removing parts of a software for visual space reduction by extensions that may or may not be supported in the future, but making use of toolkits to integrate into existing software ecosystems' look&feel. In addition, especially GTK4 and the bleeding edge Libadwaita toolkits are state-of-the-art also from a technical POV; it just feels so smooth to work with it once it is activated. And it has great potential for future UX aswell.

But of course, it does not need to be the default; just remember e.g. the tabbed toolbar layouts that were gradually introduced in the last couple of years. There is a UI switcher windows letting you choose what you want.

So I see no problem in having the options, especially if new users feel welcome about it.
Comment 34 Jean-François Fortin Tam 2021-12-12 15:13:04 UTC
JBF said:

> [...]
> I do not have the title bar. It is easy to obtain with a Gnome extension.
> I use this one:
> https://extensions.gnome.org/extension/2015/no-title-bar-forked/
> [...]

With all due respect, that's a hack, not a designed solution. It nukes the titlebar (hence document title) for all non-CSD applications (not just LibreOffice) and I've seen it break the behavior/workflow of such apps. And it can be buggy on its own, too (from my previous experience; even now I can see it is reportedly broken, unsurprisingly*)

Whatsmore, believe it or not, there are multiple other desktop environments outside of GNOME that benefit from client-side decorations and wish to have apps that use them, so you can't just say "oh, just use a GNOME Shell extension".

In UI/toolbar layouts where no menubar is used, client-side decorations are an overall better design, especially on laptop screens. They're just measurably more space-efficient, no matter how you look at them.

If it were just me, in a theoretical world, I would not make it an option and would just say, "This is how it is, *one* code path that's 100% tested & maintained", but I know this is not how it works here, and that y'all have to deal with the nightmare of 7 different UI layouts ;) with that said, Christian is dedicated enough to accept the complexity of making it optional instead of a single code path for the notebookbars... so at this point, let's please not be "stop energy" discouraging new contributors like him from trying to solve a design problem the right way (in the app, rather than the window manager). I'm very grateful for someone finally attempting an implementation for this, so thank you Christian.

*: GNOME Shell "extensions" break all the time since there is no API ("extensions" are just duck-taping hacks live on top of a moving foundation.
Comment 35 Adolfo Jayme 2021-12-13 07:20:55 UTC Comment hidden (off-topic)
Comment 36 Jordan Maris 2021-12-13 18:19:19 UTC
I definitely think this should be an option for users, and considering a user has made the effort to take this from a concept to actual code, I think it more than deserves consideration. It would also help Libreoffice fit in on the linux desktop.