Hi! Me, Heiko, Rafael and M.Weghorn have been working on "LibreOffice Themes" GSoC project for the last few months. This project introduces UI color customization to the application; which means that the user will be able to change the 'application theme' independent of their desktop environment. Our plans are to merge only the non-UI parts of the project for now, and discuss with the community what direction should the UI changes take. We, in a design meeting, decided that it would be better if we remove the `menus > tools > options > application colors` tab from the dialog as it's very crowded with color entries (some colors are not even relevant to the 'application colors' label, like the SQL syntax highlighting colors). This requires replacement for commonly used controls like - Light/Dark toggle - Scheme: [ Automatic ] combobox - Buttons like Save/Delete And some way for the user to change colors like the "Document Background", "Text Boundaries" etc. which doesn't clutter the UI. Rafael and Heiko suggested that we can have all these controls in a dialog which can be added via an extension. (If you find some point (mis/under)represented then please add that as a correction below; I am writing this from memory)
Created attachment 197469 [details] Mockup 1) Personalization (which could be renamed to "Theme") supersedes Application Colors and Appearance from View (see #3) 2) Selection of a theme starts from a list of presets shared via extensions; it includes a "Default", which is not removable and just offers automatic colors 3) The appearance formerly located under View is picks the light or the dark color from the preset, or follows light/dark as triggered by the OS 4a) Items can be fine-tuned with different colors or, if applicable, an image that either is stretched or tiled on the canvas 4b) if the item has no image capability, eg. in case of simple lines, we hide the controls; some items can be toggled on/off here but I'd rather move those all to other places The XML could list <name> <light> <dark> <image> <option> and take colors from the OS, if a value is omitted. Meaning Default would be more or less empty. Since changing the theme needs to be possible it must not be readonly, but we offer a "Reset to Default" for all items (as context menu, see #2) or individually next to color, #4a.
(In reply to Heiko Tietze from comment #1) > Created attachment 197469 [details] > Mockup > ... OK, I like it! +1 Folding the 'Application Colors' panel into a new drop list driven widget on a UI theme panel would work well--agree the current panel is just too cumbersome with the entire set of colors showing in a scrollable lb with swatch pickers. Majority of which, users will never touch. And once UI color theming/personalization is available, best to get rid of the old Firefox Persona style bitmap area fill "personalization". But what to preload the area fills with? Small patterned bitmaps, grids, gradients... In addition to TDF build defaults, the new implementation would support both user configured UI and community build theming as well as framework for full UI theme by extension. "Packaging" that has long been needed. But we do want to be certain we keep the document "Theme" (MS Office "schemeClr") handling (bug 151507) completely isolated from the consolidation of the Application colors and Personalization panels of Tools -> Options. Any WYSIWYG "Document theme" should not cross bounds with "UI theme". So naming the replacement Tools -> Options panel "UI Personalization" or "LibreOffice Personalization" or even "LibreOffice UI Theme" seems appropriate, keeping Document theming well separated .
(In reply to V Stuart Foote from comment #2) > And once UI color theming/personalization is available, best to get rid of > the old Firefox Persona style bitmap area fill "personalization". But what > to preload the area fills with? Small patterned bitmaps, grids, gradients... (In reply to Heiko Tietze from comment #1) > 1) Personalization (which could be renamed to "Theme") supersedes > Application Colors and Appearance from View (see #3) We default to "Default". If other types of area fill options are added those go into the extension and need some way to tweak the item similar to bitmap ("image" in the mockup). > Any WYSIWYG "Document theme" should not cross bounds with "UI theme". To my understanding, the document theme affects the document internal content more similar to templates than a UI theme.
We discussed the topic in the design meeting. Proposal was appreciated in general. We should call the tab Appearance rather than Personalization, and Remove next to Add is not needed and could be better Modify (ie. changes wont become effective/stored immediately).