Bug 106756 - Default Theme and Icon Set
Summary: Default Theme and Icon Set
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevAdvice, needsUXEval
Depends on:
Blocks: UI-Theming
  Show dependency treegraph
 
Reported: 2017-03-24 18:48 UTC by Thibaut Brandscheid
Modified: 2017-03-30 16:51 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
pic1 - FreeBSD, i3, dark theme (50.18 KB, image/png)
2017-03-24 18:50 UTC, Thibaut Brandscheid
Details
pic2 - openSUSE, i3, paragraph highlighting issue (147.83 KB, image/png)
2017-03-24 18:51 UTC, Thibaut Brandscheid
Details
pic3 - LibreOffice fallback theme (55.90 KB, image/png)
2017-03-24 18:51 UTC, Thibaut Brandscheid
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thibaut Brandscheid 2017-03-24 18:48:37 UTC
Description:
This bug report aims at reaching an agreement on the fact that having a default theme and icon set is a good thing. 

The issue
=========

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.


Major problem
-------------
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.

Sub-problems
------------
* 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.

Suggested Solution
==================

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:

More control
------------
* 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.

Branding
--------
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.


Conclusion
==========

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:
see description

Actual Results:  
see description

Expected Results:
see description


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 Thibaut Brandscheid 2017-03-24 18:50:04 UTC
Created attachment 132131 [details]
pic1 - FreeBSD, i3, dark theme
Comment 2 Thibaut Brandscheid 2017-03-24 18:51:09 UTC
Created attachment 132132 [details]
pic2 - openSUSE, i3, paragraph highlighting issue
Comment 3 Thibaut Brandscheid 2017-03-24 18:51:45 UTC
Created attachment 132133 [details]
pic3 - LibreOffice fallback theme
Comment 4 Heiko Tietze 2017-03-24 21:05:50 UTC
Popcorn!
Comment 5 LibreTraining 2017-03-24 21:20:52 UTC
Sounds like a great idea.
Makes perfect sense.
Consistency is one of the stated UX goals.

Why would any of this be controversial?
Comment 6 Buovjaga 2017-03-25 07:41:24 UTC
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?
Comment 7 Thibaut Brandscheid 2017-03-25 12:08:18 UTC
> 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.
Comment 8 Heiko Tietze 2017-03-26 20:57:52 UTC
Caolán McNamara replied at the mailing list:

On Fri, 2017-03-24 at 22:15 +0100, Heiko Tietze wrote:
> In tdf#106756 [1] 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.
Comment 9 Jan Holesovsky 2017-03-30 11:21:11 UTC
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?
Comment 10 Thibaut Brandscheid 2017-03-30 15:44:03 UTC
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.