Bug Hunting Session
Bug 115512 - Remove titlebar from UI in case of Gnome
Summary: Remove titlebar from UI in case of Gnome
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: needsUXEval
Depends on:
Blocks: Desktop-Integration UI
  Show dependency treegraph
 
Reported: 2018-02-07 11:59 UTC by Heiko Tietze
Modified: 2019-09-16 20:29 UTC (History)
7 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

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