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
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
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.
(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.
(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.
> 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.
(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.
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/
(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/
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
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.
*** Bug 114687 has been marked as a duplicate of this bug. ***
*** Bug 124009 has been marked as a duplicate of this bug. ***
*** Bug 124290 has been marked as a duplicate of this bug. ***
*** Bug 124373 has been marked as a duplicate of this bug. ***
*** Bug 140001 has been marked as a duplicate of this bug. ***
*** Bug 152502 has been marked as a duplicate of this bug. ***
Created attachment 184358 [details] small improvement in the LibreOffice interface a small improvement is needed in the LibreOffice interface, a better redistribution of the interface, I will give you a concept in image of what I am talking about
Back for UX-Advise consideration. But, nothing has changed, status quo as in my comment 9 Nothing "compelling" a move UI elements into CSD support and a incurring the dev effort and native source maintenance tail placing UI into CSD would require. -1, and IMHO => WF
Have seen many mockups with CSD, and the number of duplicates also shows the interest. Both Windows and Gnome do it in native apps. So we better keep this ticket, IMO.
Would be nice if someone with some authority would post a poll about this, because I'd like to be able to demonstrate that I oppose (initiatives like) this without having to spam comments, and I expect others do too.
(In reply to third='beedell', first='roke', second='julian lockhart' from comment #20) > ...I'd like to be able to demonstrate that I oppose... You disagree with CSD? Comments are welcome. If you want a pull, happy to put it on Twitter or Mastodon. What do you want to ask exactly (given ordinary users have no idea of CSD)?
(In reply to Heiko Tietze from comment #21) > (In reply to third='beedell', first='roke', second='julian lockhart' from > comment #20) > > ...I'd like to be able to demonstrate that I oppose... > You disagree with CSD? Comments are welcome. If you want a pull, happy to > put it on Twitter or Mastodon. What do you want to ask exactly (given > ordinary users have no idea of CSD)? I don't want to ask anything. I want to allow people to oppose or support this initiative, but without notifying everyone subscribed. GitLab provides reactions for issues, but Bugzilla doesn't.
(In reply to third='beedell', first='roke', second='julian lockhart' from comment #22) > GitLab provides reactions for issues, but Bugzilla doesn't. Up and down voting... would be nice. Btw, you can tag comment as off-topic.
I think it is a great idea to have the CSD, nowadays not only PC apps but also browsers are using CSD a lot, so what do other ux designers say?
(In reply to Shu Zhang from comment #24) > I think it is a great idea to have the CSD, nowadays not only PC apps but > also browsers are using CSD a lot, so what do other ux designers say? It is *not* a UX design issue. We'd love to have it--it is a dev and implementation issue 'cross platform'. If we touch the CSD we would have to maintain it everywhere, all os all DE. It is not critical and does not impact usability of the project--purely cosmetic to place controls as CSD--with a horrendous support tail incurred. Just NO!
I wonder if we can simply hide the system titlebar and replicate it manually.
Just no. While technically feasible, CSD remains a UX-advise and dev decision to start down this path. IL advised on multiple issues, with design--implementation--and support issues cross platform. If it is to be done, needs to be well thought out and the cost in dev effort really examined.
(In reply to V Stuart Foote from comment #27) > If it is to be done, needs to be well thought out and the cost in dev effort > really examined. UX advice: Make it optional
(In reply to Heiko Tietze from comment #28) > (In reply to V Stuart Foote from comment #27) > > If it is to be done, needs to be well thought out and the cost in dev effort > > really examined. > UX advice: Make it optional However, heiko.tietze@documentfoundation.org, that's obviously the problem — it's a damn lot of code complexity for such little benefit, if any at all, which much of the user base (especially outside specifically GNOME) wouldn't ever use.
(In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #29) > (In reply to Heiko Tietze from comment #28) > > (In reply to V Stuart Foote from comment #27) > > > If it is to be done, needs to be well thought out and the cost in dev effort > > > really examined. > > UX advice: Make it optional > > However, heiko.tietze@documentfoundation.org, that's obviously the problem — > it's a damn lot of code complexity for such little benefit, if any at all, > which much of the user base (especially outside specifically GNOME) wouldn't > ever use. A small comment here: Why do you define it as if it were a Linux issue? Titlebars are generally no longer used in the most used operating systems such as Windows and macOS. Microsoft Office or OnlyOffice among others no longer use titlebar. I understand that this is a huge effort and I agree that it is more important to polish functionalities or interoperability with the OOXML format, however, I think that if the titlebars disappeared and that were the default option, most users I wouldn't touch the settings to go back. The use of vertical space and aesthetics are things considered by the end user. I remember similar discussions that resisted the existence of a ribbon-like interface or that the first thing the user saw was the dialog that allows them to change the interface (I think it now appears as the first tip of the day, although I haven't restarted my profile in a long time). The end user values consistency and modern look when using an application unfortunately. Well, my point is that this is not something that only benefits GNOME users. Cheers
(In reply to haevalencia from comment #30) > (In reply to `{third: "Beedell", first: "Roke"}`{.JSON5} from comment #29) > > (In reply to Heiko Tietze from comment #28) > > > (In reply to V Stuart Foote from comment #27) > > > > If it is to be done, needs to be well thought out and the cost in dev effort > > > > really examined. > > > UX advice: Make it optional > > > > However, heiko.tietze@documentfoundation.org, that's obviously the problem — > > it's a damn lot of code complexity for such little benefit, if any at all, > > which much of the user base (especially outside specifically GNOME) wouldn't > > ever use. > > A small comment here: Why do you define it as if it were a Linux issue? > Titlebars are generally no longer used in the most used operating systems > such as Windows and macOS. Microsoft Office or OnlyOffice among others no > longer use titlebar. > > I understand that this is a huge effort and I agree that it is more > important to polish functionalities or interoperability with the OOXML > format, however, I think that if the titlebars disappeared and that were the > default option, most users I wouldn't touch the settings to go back. > > The use of vertical space and aesthetics are things considered by the end > user. I remember similar discussions that resisted the existence of a > ribbon-like interface or that the first thing the user saw was the dialog > that allows them to change the interface (I think it now appears as the > first tip of the day, although I haven't restarted my profile in a long > time). The end user values consistency and modern look when using an > application unfortunately. > > Well, my point is that this is not something that only benefits GNOME users. > > Cheers You make a good point, but it depends significantly upon the software the user tends to use. I only know of a few applications which override the titlebar, especially because on Windows, I use mostly WinUI applications, which although perfectly able to use CSD, in my experience tend to not. Likewise, the few Win32 tools I have certainly don't either, although I'm aware that MS365 and some game launchers do for supposed aesthetic reasons. Of course, on KDE, almost nothing does, so solely GNOME appears to at least be consistent in their usage of it.