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