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).
Created attachment 197905 [details] Altered mockup with annotations Hi all... I know I'm a bit late for the discussion, but I'd like to share some thoughts on this. One thing that feels confusing about the proposed mockup (as well as in the current implementation in the WIP patch by Sahil) is the "Options" section where the user can choose: System, Light and Dark. This is similar to what we have in the current UI, which I also find confusing. These options don't seem to play nicely with the "LibreOffice Themes" section, because it feels like the user can select a theme and at the same time select the "System" option. This seems to be the root-cause of some confusion about the UI implementation. I have made a simple change to the mockup (see attached screenshot) by adding a new section: Application Colors (*) Use system colors ( ) Use theme colors This new section (above) indicates whether the theming will come from the system theme or from a manually selected theme. If "system colors" is selected, the "Select theme" list is disabled. If "theme colors" is selected, then "Select theme" is enabled. Then we have another section: Variant (*) System ( ) Light ( ) Dark The section above tells which color variant to use. If "System" is selected, then the system preference for light/dark is applied. If the user selects light or dark, then the the light/dark variant of the theme is loaded. Themes installed by extension may have a light and dark variants that are loaded based on this option.
We currently have system color, app color, item color and introduce theme color. This is confusing in its combination. The proposal was to only have one option: follow the System (use dark colors if system is dark) and overwrite system with Light or Dark. Each color has two representations, eg. window background is 42,46,50 or 239,240,241 [1] and the document background is #FFFFFF or #1C1C1C [2]. The new theme contains all of these colors, and switching from dark to light changes the entire setup. In order to get a white document background on the dark system default we need to install the theme "White Document", which leaves the OS colors empty aka uses the default but lists the same light values as hard-coded. I think we don't need to other way, ie. light system background and manual dark app colors. The advantage of this approach over the current is just one selection of dark/light, and the theming of all colors. [1] https://github.com/KDE/breeze/tree/master/colors [2] svtools/source/config/colorcfg.cxx
Created attachment 197932 [details] Mockup #2 The mockup was missing the customization of light vs. dark color pairs. We may need to reconsider the design when this background image or gradient will be possible.
Sahil Gautam committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c4962247e40b5e6750c522d43359d9436dcfec68 tdf#163620 [API CHANGE] remove persona/appearance-toggle related code It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Sahil Gautam committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ddeeca35d9630f2d3d3afb83a2ec8f21458f6e19 tdf#163620 [API CHANGE] Add UI for libreoffice themes It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Sahil Gautam committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/06640b94586c454ffc1fe1605e8f4c5356d73171 tdf#163620 [API CHANGE] remove persona/appearance-toggle related code It will be available in 25.2.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Sahil Gautam committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/eaa5a4de85c7b7a8b606614a1dca6cee6badfb4a tdf#163620 [API CHANGE] Add UI for libreoffice themes It will be available in 25.2.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
@Sahil, Heiko,* With such a late push into 25.2.0 please get a release notes entry made and standby for any blow-back or substantive regressions. Would have preferred to see/test first for a bit in master against 25.8.0, but if you want to just "pull the band-aid off", I'm OK there as well--just need to promote testing and be ready for any issues.
(In reply to V Stuart Foote from comment #12) > @Sahil, Heiko,* > > With such a late push into 25.2.0 please get a release notes entry made and > standby for any blow-back or substantive regressions. > > Would have preferred to see/test first for a bit in master against 25.8.0, > but if you want to just "pull the band-aid off", I'm OK there as well--just > need to promote testing and be ready for any issues. https://wiki.documentfoundation.org/ReleaseNotes/25.2#Application_Theming added to the release notes. I don't know if we can align those last 2 images symmetrically in the center, that would look way better.
(In reply to Sahil Gautam from comment #13) > https://wiki.documentfoundation.org/ReleaseNotes/25.2#Application_Theming > added to the release notes. I don't know if we can align those last 2 images > symmetrically in the center, that would look way better. Couldn't align them, but tweaked a bit using a Wiki gallery row with width and height for the images. You might post up a third example image to balance out the row.
Sahil Gautam committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e87b50fb4936c221bdfb0fe6e8efd15251f6f38f tdf#163620 Allow users to modify "Appearance" for Automatic scheme It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Sahil Gautam committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/f1130f7f8aef49c86c39b9fbd377eab6d0346d21 tdf#163620 Allow users to modify "Appearance" for Automatic scheme It will be available in 25.2.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
@Sahil, * Finally got a test drive with the 20241220 tb73 build of 25.2.0b1+ [1] OK so far. The old 'Demo Theme' color theme extension offered is not behaving if installed (does not show in the Appearance panel), and can't then be removed from install via the Extension dialog (have to delete profile to clear its install.) Might need to be removed from the server, or at least a note on it to not install on >= 25.2 builds. =-ref-= [1] https://dev-builds.libreoffice.org/daily/libreoffice-25-2/
OK, going to have an issue! Not clear why, but with no Color Theme installed, using the 'System'|'Light'|'Dark' radio buttons to select color theme is not restoring the os/DE provided colors when returning to the 'System' radio buttons (rb). Now no restart, and the 'Items' listbox in 'Customizations' goes inactive. Choosing either 'Light' or 'Dark' Appearance rb, then setting rb to 'System' and Themes still on "Automatic" setting: The 'Document background' is now "Black" not "Automatic" but also apparently the 'Font color' also "Black" rather than "Automatic". Seems like we have a state where we don't restore colors back to os/DE provided colors for the "Automatic" theme and 'System' DE. Colors are set, but should roll back to "Automatic". Noticed also, that any change to the Theme would require a restart, but no similar restart without a color theme and just "Automatic". Issue may be a simple as forcing the restart, without a color theme set, when just the change is made between the 'System'|'Light'|'Dark' radio buttons? =-testing-= Version: 25.2.0.1.0+ (X86_64) / LibreOffice Community Build ID: 468d47bdf44a772e989a0adbeb5bb097e3cb4f31 CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to V Stuart Foote from comment #18) > Not clear why, but with no Color Theme installed, using the > 'System'|'Light'|'Dark' radio buttons to select color theme is not restoring > the os/DE provided colors when returning to the 'System' radio buttons (rb). Please read https://design.blog.documentfoundation.org/2024/12/20/libreoffice-themes-will-replace-the-color-customization/ @Sahil: please resolve as fixed. Follow-up tickets are welcome, of course.
(In reply to V Stuart Foote from comment #18) > > Seems like we have a state where we don't restore colors back to os/DE > provided colors for the "Automatic" theme and 'System' DE. Colors are set, > but should roll back to "Automatic". > OK, even with a color theme (Lime Theme) installed, changing the theme back to the Automatic lb entry--the Appearance options and Customization items don't restore the color values from os/DE. The Items lb remains inactive but the showing "Document bacground" shows Dark with a 'Black' color swatch. Can't see the 'Font color' item--but either automatic or black we get black or black on the document.
Marking as resolved fixed. Further improvements will follow (as tickets come up).
Verified as fixed in own master build: Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2305fe302e12c4256e452589e2533772d4213e59 CPU threads: 8; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded Thanks Sahil!
Sorry, I only speak Chinese. If my comments should not appear here, please help delete them. And I can't use pictures to illustrate my words here, I can't express my meaning accurately. Text: First of all, I thank and support everyone for making new improvements to the theme and appearance of the software interface. I agree with the idea of integration here. Secondly, I can't accept the setting schemes in the 5th line "customizations" and the 6th line "items". Click one, modify one, and change to the latter, and the brain has forgotten what color it changed to before. (Although this may be used 2 to 3 times a year, it is easy to make people very unhappy if it changes from easy to use to difficult to use.) I hope to change back to the previous mode in this item, so that all menus that can specify colors can be seen at the same time. Finally, the logical relationship between themes, appearance options, and application colors customizations is a bit difficult to understand, as if they are three things, but also seem to be one thing. (I suggest treating them as three sub-projects and integrating them under menu > tools > options > libreoffice) I am a user from Ooo to LO all the time, thank you for all your work.
On downloading 25.2.1 (from 24.8.4) I was shocked to find the appearance of documents and spreadsheets suddenly changed completely with NO warning. When I found the Appearance option which was set to System I tried to set a Light theme, but I found that the menu bar (File, Edit, etc.) was white on white. I am now told that I must remove 25.2.1 if I wish to downgrade back to 24.8.5, but I am fearful that I will lose a bunch of settings in the process. This has been a truly shocking experience. The change should NOT have been hidden away as inconsequential with no proper explanation somewhere down the bottom of the release notes.
I should add that there ought to be a guide (and a default) to set the appearance to how it was in the user's previous installation: change should not be forces unwittingly.
(In reply to Libomark from comment #25) > I should add that there ought to be a guide (and a default) to set the > appearance to how it was in the user's previous installation: change should > not be forces unwittingly. Please open new BZ issues for specific issues regards the new Appearance theme framework. This BZ issue is closed.
(In reply to Libomark from comment #24) > I am now told that I must remove 25.2.1 if I wish to downgrade... We ship a theme "Light Application Color" that does exactly what you want. Here is a blog post about the new appearance configuration [1], and the release notes [2] refer to it. Would probably miss such an announcement myself, but looking from the other side there is no perfect time or procedure for disruptive changes. Hope you enjoy the new theming anyway. [1] https://design.blog.documentfoundation.org/2024/12/20/libreoffice-themes-will-replace-the-color-customization/ [2] https://wiki.documentfoundation.org/ReleaseNotes/25.2#Application_Theming
The correct procedure is not to make disruptive changes, but to make them evolutionary and optional. Most changes are minor upgrades with added functionality, and if they don't quite work they can be ignored. Making your work and the menus unreadable and suddenly expecting printers to deliver black pages is an attempt to sabotage the whole suite.
(In reply to Libomark from comment #28) > The correct procedure is not to make disruptive changes, but to make them > evolutionary and optional. Most changes are minor upgrades with added > functionality, and if they don't quite work they can be ignored. Making > your work and the menus unreadable and suddenly expecting printers to > deliver black pages is an attempt to sabotage the whole suite. Opinion. Not reality... The new Appearance framework is a reasonable and oft requested feature, brought in during GSOC. Exactly as intended, it is a nice piece of work and moves LibreOffice functionality and desktop integration along. Anyone interested has seen its ongoing development in Nightly builds of master against next major release cycle. And now as released at 25.2, functional incremental patches as needed are being pushed backward onto that base. With refinement in works for 25.8. You've had opportunity to test the developmental build, it *is* expected of contributors. If you now find yourself affected, that is on you--not the project. If you remain unhappy, stay with the 24.8 release. Alternatively roll up your sleeves and contribute, issues don't get fixed unless they are fully described. Simply "pissing and moaning" about changes does not help, and is not much appreciated.