Download it now!
Bug 113388 - Support for Client Side Windows Decorations in LibreOffice
Summary: Support for Client Side Windows Decorations in LibreOffice
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.4.2.2 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 114687 124009 124290 124373 (view as bug list)
Depends on:
Blocks: Desktop-Integration UI 125443
  Show dependency treegraph
 
Reported: 2017-10-23 18:42 UTC by haevalencia
Modified: 2019-05-22 13:24 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description haevalencia 2017-10-23 18:42:01 UTC
Description:
Today, the main operating systems support the idea of using CSD, in addition, there are initiatives for the design of the decorations are consistent and respect the configuration of users (eg window controls).

With CSD LibreOffice you would gain more vertical space by making better use of the available space, something necessary for small monitors and the new layouts of MUFFIN. On the other hand it would gain visual consistency with the applications of the different operating systems supported.

Steps to Reproduce:
0


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Comment 1 V Stuart Foote 2017-10-24 14:15:34 UTC
We already pick up OS DesktopEnvironment theme details cross platform and use them in the LO user interface(s) implemented as needed for each OS.

Doing more "native" decorations depends on interest of devs (e.g. implementing separate gtk3 support). But while appealing to some, and getting some dev attention, overall integration as native OS UI and widgets is not a design or development goal for the project. 

We use the published IDL and API for the OS DE, but are not well served doing more to follow the whims of DE for each OS in a cross-platform project.

IMHO => WONTFIX
Comment 2 Heiko Tietze 2017-10-24 14:42:07 UTC
Don't we have CSD since 4.x? Meaning you can do everything with the gen vcl theme to make it look completely different (see also bug 106878). Didnt find the ticket about vcl switcher but the idea was to be able to toggle between vcl plugins on-the-fly. 

When you understand CSD as relevant for the title bar only, it's up to the OS/DE to support this.

Wontfix IMHO.
Comment 3 haevalencia 2017-10-24 20:14:40 UTC
(In reply to V Stuart Foote from comment #1)
> 
> We use the published IDL and API for the OS DE, but are not well served
> doing more to follow the whims of DE for each OS in a cross-platform project.
> 

I understand your point and I see that I misread my comment, however, there is a certain consensus that among the operating systems for their applications to draw their own interface and I dont think it is just a whims IMHO since although it is irrelevant if we talk about functionality, consider that one of the criticisms of OOorg/LibreOffice has always had is that it "looks" like outdated software.
Comment 4 haevalencia 2017-10-24 20:21:33 UTC
(In reply to Heiko Tietze from comment #2)
> 
> When you understand CSD as relevant for the title bar only, it's up to the
> OS/DE to support this.
> 
Not really, but I dont understand why LO keep using a titlebar anyway.

I suppose I will have to address the VCL plugin developers, although I mentioned this here since the idea is to maintain a coherence in the interface between platforms (something distinguishable with LO). Thank you.
Comment 5 Adolfo Jayme 2017-10-24 20:54:26 UTC
> Not really, but I dont understand why LO keep using a titlebar anyway.

Ha, ha, ha.

A title bar is a perfectly functional widget and a basic, timeless component of modern user interfaces, despite all the GNOME Kool-Aid.
Comment 6 haevalencia 2017-10-25 00:52:03 UTC
(In reply to Adolfo Jayme from comment #5)
> > Not really, but I dont understand why LO keep using a titlebar anyway.
> 
> Ha, ha, ha.
> 

Sorry dude, I don't think it's a place to make fun of anyone ...

> A title bar is a perfectly functional widget and a basic, timeless component
> of modern user interfaces, 

Nowadays there are many widgets that are functional, but that are not used for many reasons. Keeping a horizontal bar that occupies several pixels just for the title and window controls seems debatable to me... that is the point.

> despite all the GNOME Kool-Aid.

Okay, I see a lot of bias in your comment. If I mention other platforms it is because both the macOS reference applications (core-apps) and the new Microsoft apps + UWP reference don't use titlebar and the new applications for those two platforms follow the same path.
On the *nix side only KDE (Kwin) has decided to force the use of titlebar decorated by server side. 

But the point is functionality. Several of my students use laptops with small monitors of 1366x768 or less resolution, where vertical space is prized, whereas the new favorite layout will be tabbed NotebookBar. For example WPS Writer hides the titlebar when the window is maximized and is not something that depends on the OS/DE, it is simply something useful and can be something totally optional.
Comment 7 Heiko Tietze 2017-10-25 07:06:23 UTC
Aren't you talking about different use cases? You will get more vertical space when the title bar is removed by the OS/DE. CSD is about adding functionality to the title bar, basically, and 'make use of this area'. I disagree with this idea because white-space is my friend, and picking up the window to move it around is what I do quite often. The advantage is clear on the other hand, and it's a nice design as shown here [1] for KDE.

(In reply to haevalencia from comment #4)
> I dont understand why LO keep using a titlebar anyway.
> 
> I suppose I will have to address the VCL plugin developers...

LibreOffice uses the system window, and draws controls with the system theme. Starting with a different VCL never changes the window. 
And we do not have dedicated VCL developers.

[1] https://kver.wordpress.com/2014/10/25/what-if-kde-started-using-client-side-decorations/
Comment 8 haevalencia 2017-10-25 13:48:00 UTC
(In reply to Heiko Tietze from comment #7)
> Aren't you talking about different use cases? You will get more vertical
> space when the title bar is removed by the OS/DE.

Not really, but what you propose is not a reality either, since it doesnt happen (KDE Netbook only and the extinct Unity -with great inconsistency- in gnu/linux side). It is not possible at will in macos or windows to remove the titlebar and if it were to do so it loses functionality (like window controls).

> CSD is about adding
> functionality to the title bar, basically, and 'make use of this area'.

That's the way it is and by using that space efficiently, the total space occupied to draw the interface is reduced. 

 
> I disagree with this idea because white-space is my friend, and picking up the
> window to move it around is what I do quite often. 

Mozilla developers have worked on this problem in their implementation for gnu/linux by adding white-space when the window is not maximized among other things. (https://bugzilla.mozilla.org/show_bug.cgi?id=1399611). Something similar was already being done on its other supported platforms.

In other office applications there is always clickable white-space to move the window, something that doesnt happen in LO (toolbar or tabs of notebookbar white-space is not clickable).

> The advantage is clear on
> the other hand, and it's a nice design as shown here [1] for KDE.
> 
> (In reply to haevalencia from comment #4)
> > I dont understand why LO keep using a titlebar anyway.
> > 
> > I suppose I will have to address the VCL plugin developers...
> 
> LibreOffice uses the system window, and draws controls with the system
> theme. Starting with a different VCL never changes the window. 
> And we do not have dedicated VCL developers.
> 

ok

> [1]
> https://kver.wordpress.com/2014/10/25/what-if-kde-started-using-client-side-
> decorations/
Comment 9 V Stuart Foote 2017-10-25 15:58:47 UTC
Windows allows this using Desktop Windows Manager (DWM) APIs and extending the Client Frame [1] replacing the Standard Frame.

IIUC macOS AppKit does also, from the NSWindow/NSView -> NSAppearanceCustomization [2], but as we make no use of NSAppearance (taking defaults) for the NSWindow/NSView and stylemask(s).

So both of these would require entirely new development in native code to do any sort of client side decoration.

While on Linux--X11, and now Wayland, there are multiple code paths for doing this depending on the DE supporting GUI toolkit being supported.

So, while it could be done--there is no _compelling_ requirement to do so, and a whole bunch of pain involved in trying to implement cross platform with any consistent fashion. Allowing  OS and DE defaults just makes more sense from a UX position.

Again IMHO => WONTFIX

=-ref-=
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/bb688195(v=vs.85).aspx

[2] https://developer.apple.com/documentation/appkit/nsappearancecustomization
https://developer.apple.com/documentation/appkit/nsappearance
Comment 10 Heiko Tietze 2017-10-26 14:40:44 UTC
Asked devs and got the confirmation that the outer frame is generated by the OS. So any change to it is notourbug/wontfix. Everything inside is covered by the discussion of notenookbars.
Comment 11 V Stuart Foote 2017-12-25 04:27:49 UTC
*** Bug 114687 has been marked as a duplicate of this bug. ***
Comment 12 V Stuart Foote 2019-03-12 12:50:26 UTC
*** Bug 124009 has been marked as a duplicate of this bug. ***
Comment 13 V Stuart Foote 2019-03-23 20:14:47 UTC
*** Bug 124290 has been marked as a duplicate of this bug. ***
Comment 14 V Stuart Foote 2019-03-27 18:26:37 UTC
*** Bug 124373 has been marked as a duplicate of this bug. ***