This bug report aims at reaching an agreement on the fact that having a default theme and icon set is a good thing.
Currently, the appearance of LibreOffice varies, depending on the operating system, the desktop shell, the used custom theme. In some cases the functionality is narrowed because graphical elements are difficult to see or almost completely hidden. Sometimes the colors of the theme and icon set don’t match well, resulting in an unaesthetic appearance. Also the size of visual items differ. The described issue existed already in OpenOffice and was never fixed.
By changing the operating system theme – an action not in control of LibreOffice – the functionality can be reduced up to the point where certain actions are not possible, because widgets blend with the background.
* Current appearance is inconsistent across installations.
* Current appearance is neither beautiful nor aesthetic (debatable, I know).
To highlight some problems, I appended screenshots showing:
Pic 1 - LibreOffice on FreeBSD, using the i3 desktop shell with a dark theme
Image shows that the theme and icons set have a very bad contrast. The functionality is reduced, some features are not usable at all, because UI elements can not be differentiated from the background. The overall appearance is unaesthetic, almost unpleasant.
Pic 2 - LibreOffice on OpenSUSE Tumbleweed
The UI is not fully functional, because the blue – coming from the a custom system theme – is too light and makes therefore the paragraph-highlighting almost unusable. The blue dots from the paragraph-highlighting are hard to identify between the words and the small light-gray background dots (a.k.a. the visual-grid).
Pic 3 - The fallback theme (SAL_USE_VCLPLUGIN=gen ./soffice)
Icons are too small, therefore hard to identify. The toolbars have a curved background-style, not used in any other of my LibreOffice installations. The UI elements feel out-of-place, the overall appearance is unpleasant, might remind users of UI’s created in the nineties.
By using a single theme and icon set we could not only solve the above described major problem – changes outside of LibreOffice would not affect its appearance nor have possible usability impacts – it would also allow us to improve the UI and make it beautiful and aesthetic by carefully arranging used colors and shapes.
By controlling the theme and icon set we could also make sure the UI works for color blind (approximately 4.5 % of the population) or slightly visually impaired people.
Having a single theme and icon set means:
* Would allow us to define color palettes and use them everywhere.
* Would allow us to make sure that icons have a nice contrast relative to their surroundings.
* That the used visual style and the >>iconography<< are consistent.
* Would allow us to make the UI pixel-perfect, by defining precisely the size and form of every visible item.
A consistent single UI is easily recognizable, people get used to it, it is what people love about a product beside the functionality. Therefore a stronger branding by having a default UI – which uses the same colors… – would be an improvement.
Almost granted, but in this context should maybe be said, almost every well-known application ships with a single default UI (some allow to switch to a dark theme, but lets ignore that topic for now).
Have a preference setting to allow current behavior
To please power-users and preserve the current theming capabilities there should be a check-box in the preferences to use the theme and icons from the operating system.
I’m aware that this issue report might touch on a highly controversial topic. I would love to hear your opinions/thoughts about why things are the way they are, and how the situation could be improved.
Steps to Reproduce:
User Profile Reset: No
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Created attachment 132131 [details]
pic1 - FreeBSD, i3, dark theme
Created attachment 132132 [details]
pic2 - openSUSE, i3, paragraph highlighting issue
Created attachment 132133 [details]
pic3 - LibreOffice fallback theme
Sounds like a great idea.
Makes perfect sense.
Consistency is one of the stated UX goals.
Why would any of this be controversial?
To comment on the mailing list discussion, where Firefox was mentioned: https://lists.freedesktop.org/archives/libreoffice/2017-March/077408.html
Mozilla has not refused system integration feature requests, like this for KDE: https://bugzilla.mozilla.org/show_bug.cgi?id=528510
So given the manpower and a solution, Firefox could ship with a proper KDE integration and openSUSE's hacky solution could be dropped.
I'm not sure what the scope of Thibaut's suggestion is vs. our current backends. Would we still adapt window and dialog widgets, buttons and checkboxes etc. to the desktop env or operating system? Is the proposal only about unified colors and icons?
> I'm not sure what the scope of Thibaut's suggestion is vs. our current
> backends. Would we still adapt window and dialog widgets, buttons and
> checkboxes etc. to the desktop env or operating system? Is the
> proposal only about unified colors and icons?
I wrote by purpose nothing about details. After we decide to go with a default theme and icon set, we could discuss how fare these changes should reach, if we use native or custom widgets... and what the advantages of either of them are. For now the issue is primary about having a default theme and icon set.
Caolán McNamara replied at the mailing list:
On Fri, 2017-03-24 at 22:15 +0100, Heiko Tietze wrote:
> In tdf#106756  the fundamental idea to blend LibreOffice well into
> the system theme is challenged. While we may be able to solve most of
> the issues the idea is tempting to have a unique look and feel with
> the possibility to customize the default according the system.
I very much disagree, I want the gtk3 LibreOffice to blend in with the
system gtk3 theme. And in some places we are using the native gtk3
stuff directly so it's out of our hands already, e.g. menubar, menus,
file picker, tooltips, popovers, whether modal dialogs are locked in
position or not. I'd like to go further there and use more native
widgets rather than the current scheme of using our own widgets and
using the gtk theming apis to render them.
I think the specific bug should be split up into the pieces that are
causing problems and see if they are currently been taken from the
wrong parts of the system theme and can be individually improved.
As we talked in the Design meeting, we cannot force a default here - clearly we don't have any good one that would work on all platforms, ESC was against too, and some more points are in the comment 8.
What you can do though is improving the "fallback theme" so that it evolves into something beautiful. This fallback theme can be forced on all platforms (export SAL_NO_NWF=1 was mentioned - but when it is good enough, we can surely make it easier). Any improvements in this one would be much appreciated.
As such - I think it's best to close this bug as WONTFIX, and instead it would be great if you can create a new bug for improving the "fallback theme" step by step.
Such an effort would be very appreciated, and I'm happy to provide you with code pointers where to hack. Tomaz also had good ideas there - I think he'd be willing to help you too; CC'ing him. I hope this works for you?
I have the impression that the arguments for a change to a unique theme & icon set have not been perceived. In the issue I point at problems which exist today and are caused by using the system theme as default. Even if there is right now no replacement for the native theme, the discussion could take place here. Also the potential of having more control over the visual and possible branding implications might be worth some words.
Spending time on improving the fallback-theme makes only sense if the result is later somewhat used/seen by users. In the case of that there is no interest in changing the theme from native to a default, the fallback can maybe stay as it is. If there is interest, we should outline how such a unique theme & icon set should look, how it could be implemented, what limitation exist...
Anyway, I gladly accept the offer to point me to relevant code paths to learn about how the fallback works.