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.
(In reply to Heiko Tietze from comment #0)
> 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.
Created attachment 139671 [details]
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.
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.
Created attachment 139866 [details]
rough concept of LibreOffice with GNOME-style CSD
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).
Created attachment 139867 [details]
rough concept of LibreOffice with macOS-style CSD
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, ...
+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
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.
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.
++ 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)
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.
IMHO => WF
Not yet solved? please consider to hide the title bar for Gnome-based systems, title bar takes up space that could be better used.
(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
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.
No need for title bar in tabbed mode
I think Libreoffice should look to modern HIGs such as Gnome’s to improve the dated feel of the suite.
*** Bug 146085 has been marked as a duplicate of this bug. ***
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.
Created attachment 176839 [details]
(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
> 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
> 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
Created attachment 176840 [details]
And here is another version using the "old" style (in this case the Ubuntu 21.10 system theme).
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.
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.
(In reply to andreas_k from comment #23)
> I really like how VS Code use the window decoration area
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 
But hey, if we did that we would get working DE theming and ability to build for other UWP platforms ;-)
(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...
Created attachment 176845 [details]
GTK4 libadwaita CSD when run on KDE Plasma 5
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.
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
(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
> This would save vertical space but would be the same UI than on other
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 :)
Created attachment 176850 [details]
GTK4 Libadwaita CSD inkl. GtKPopupMenuBar and various themes in comparison
(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.
(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:
> 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.
> I do not have the title bar. It is easy to obtain with a Gnome extension.
> I use this one:
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.
> 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.
They’re only more space-efficient because the Adwaita title bars are huge, lol. The Ambiance theme was very space-efficient and had excellent density, despite many apps having title bars </off-topic> </not-really-going-against-you-despite-what-you-say-on-Twitter-we-all-want-CSD>
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.
I think this is brilliant and commend Christian on this hard work, it's great to see this type of work being done. It makes me wish that the Windows version of LibreOffice would be able to have this.
Bravo again Christian, I look forward to seeing this soon. It would be brilliant to be able to also have ability to add our own launchers (or modify) on that toolbar, personally I would like to be able to replicate the look of Microsoft Office 365 for the people that I support and it would be an aid for me when I am supporting migrations to LibreOffice. Who knows, maybe an extension in the future with that layout?