The new Appearance LO Theme panel does not enable user to review the full list box of 'Customization' Item entries when no theme has been set active and the Theme lb shows Automatic. Should not have to create a new LO Theme just to be able to review the color assignments ("Automatic" or specific color swatch/tag from os/DE system theme).
By design. Changing the automatic colors is pointless. OTOH, since we can now revert any color to Automatic it could make sense to rename the theme to Default, or the like, and allow changes. Would be nice to have the Revert All function first.
Concern is not that value can't be changed, rather that you can not examine the elements in the listbox! And currently the Automatic (or reasonable rename to Defaults) is *not* restoring the element values on the listbox--but as they can't be seen you can't tell. Logic for setting an elements color back to "default" as theme is removed, or toggle between system|dark|light radio button without a theme needs adjustment (see also bug 164392) to correctly reset appropriate "automatic" colors drawn from os/DE.
We disabled customizations for Automatic theme for the following reason. - Let's say that the customization section is enabled, and the user changes a lot of colors (including the UI colors). Now to see those colors in effect, the user has to restart the application (no alternative to restart found yet). - Now after restart, the user found that the UI is messed up (because he changed the colors). Now he wants to reset the colors back to the default values. The only way to do this is to go through the dropdown and individually change the values for the colors to automatic. - One might say that the reset button should do that. The reset button is used for throwing away changes which have not been committed yet, so that cannot be used to set all values to Automatic. - And if we add another button anywhere else in the UI, it would look super ugly. That's why I (and Heiko) agreed on disabling cusotmizations for Automatic theme. - One Potential solution I can think of is to not show the UI color entries in the customizations dropdown. That way the user wouldn't be able to shoot himeself in the foot. Then for any other scheme, we add those entries. (Opinions on this?)
I'm happy with the Theme model. But *not* having the Customization listbox for the UI elements active just unpleasantly sidesteps the case that no Theme has been applied, right? So absent an active Theme, my expectation would be that if we use the 'System' radio button (os/DE in Dark or Light color mode) the full slate of os/DE colors should be restored (and/or shifted to appropriate 'Automatic' contrast) at least for the System rb. Simply not allowing review of the listing UI elements is not a comfortable state--if not restoring it to function, then a warning message to user of need to define and apply a Theme might be sufficient. But really think restoring the listing of UI elements even to adjust just a single element, after restoration from os/DE values, would be more comfortable work flow than forcing each user to define their own theme. Especially as we need to get better guidance/help into user hands about complexity of what they now need to define in their Appearance themes (e.g. assigning a full slate of element values for both a Light and a Dark color mode, etc.).
(In reply to V Stuart Foote from comment #4) > I'm happy with the Theme model. But *not* having the Customization listbox > for the UI elements active just unpleasantly sidesteps the case that no > Theme has been applied, right? Even worst the UI doesn't give any hints about what's going on, as said below very bad UX. > So absent an active Theme, my expectation would be that if we use the > 'System' radio button (os/DE in Dark or Light color mode) the full slate of > os/DE colors should be restored (and/or shifted to appropriate 'Automatic' > contrast) at least for the System rb. The system radio button is for following the system's "appearance mode", and it happens many times that the system uses light theme during the day and dark theme during the night. Let's say we use system to restore the system colors, then what if the user is not using Automatic theme? Would we still restore system colors then? If so then the theme would be overwritten with system colors. I don't think system rb can be used for that purpose. > Simply not allowing review of the listing UI elements is not a comfortable > state I agree on that. That makes it more complex and we have to use a lot of ifs and buts to explain the feature. It's bad UX for sure as the user has to go out to the blog/help/internet to figure out the whole deal. We need a slight UI redesign, please wait a moment, I will share a new UI
Created attachment 198219 [details] new layout for cusotmizations section How about this? The reset button label here would be "Restore Defaults" and that would throw away all the customizations and get colors from the system. We would show the "Restore Defaults" button only for the automatic theme.
(In reply to Sahil Gautam from comment #6) > Created attachment 198219 [details] > new layout for cusotmizations section > > How about this? The reset button label here would be "Restore Defaults" and > that would throw away all the customizations and get colors from the system. > We would show the "Restore Defaults" button only for the automatic theme. Yes something like that, but if it was going to reset all UI elements, and not just the "Document background" element, then reset button placement might be more clear if positioned above the still inside the Customizations label, but above the Items: for the listbox? Also, with quick turn-around needed here at 25.2 I'm including the entire UX-advise list members.
(In reply to V Stuart Foote from comment #7) > Yes something like that, but if it was going to reset all UI elements, and > not just the "Document background" element, then reset button placement > might be more clear if positioned above the still inside the Customizations > label, but above the Items: for the listbox? oops, finger flub... s/if positioned above the/if/ so make that read "more clear if still inside the Customizations label,"
Created attachment 198222 [details] "Restore Defaults" button above items Then the UI would look something like this.
(In reply to Sahil Gautam from comment #9) > Created attachment 198222 [details] > "Restore Defaults" button above items > > Then the UI would look something like this. Right, that UI. But then do you have what you'd need under the hood to reread from os/DE and "regenerate" the full slate of automatic colors to perform the reset?
(In reply to V Stuart Foote from comment #10) > Right, that UI. But then do you have what you'd need under the hood to > reread from os/DE and "regenerate" the full slate of automatic colors to > perform the reset? Yes, We do. If you use lime theme, and then (after restart) set the color for window to automatic using the automatic button on the color palette/dropdown, then (after restart) you would see that the window color has changed to the desktop environment's window color.
Patch: https://gerrit.libreoffice.org/c/core/+/179322
(In reply to Sahil Gautam from comment #12) > Patch: https://gerrit.libreoffice.org/c/core/+/179322 Oh! Wow, that "patch" got pretty far down in the weeds. I read through the source and think it is the right approach to move appearance theming forward. Provides more of a framework now. But even to my non-dev eyes its touching a lot of dusty corners. This late, I doubt it would make it through review for a backport to 25.2 without direct attention and assistance of a few of the senior devs, and then support at ESC. And Mike K's already commented on current scope being too extensive for a single commit. So if it is unlikely to be committed en masse to 25.2.0 (just to facilitate a revert from 25.2 if needed) then probably better to split it apart and tweak things against master. We can explain a lot of the new Appearance color theming, extension and profile handling thus far in 25.2.0 with help/documentation. What is there *is* already functional if not ideal UX. Possibly patch portions in 25.2.x (another reason to split it up) but reliably finish themes and extension manager integration at 25.8
(In reply to V Stuart Foote from comment #13) > (In reply to Sahil Gautam from comment #12) > > Patch: https://gerrit.libreoffice.org/c/core/+/179322 > This late, I doubt it would make it through review for a backport to 25.2 > without direct attention and assistance of a few of the senior devs, and > then support at ESC. And Mike K's already commented on current scope being > too extensive for a single commit. Merry Christmas, and being the youngest here, I want a Christmas present. I want this feature to not eat dust in the master for another 6 months. Split the patch into smaller patches each doing one unit of work. The work is done (except for 1-2 minor issues for which I will push the patches by tomorrow latest). Once all the patches are merged in 25-2, only a help page would be left.
Sahil Gautam committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/aa93f7366236c5c291a8984900eb863b98d4da07 tdf#164393 nicely format gtk-css-declarations for custom themeing 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.
Resolve as fixed, Sahil?
(In reply to Heiko Tietze from comment #16) > Resolve as fixed, Sahil? Yes, but the patches have still not been reviewed and merged. There are a lot of them (https://gerrit.libreoffice.org/c/core/+/179404 in the relation chain). I hope they make it to 25-2, depends on when I get +1 for the code.
Sahil Gautam committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7970a121a83653474e696550f91c5e7b963674e8 tdf#164393 Format the code to make clang-format happy 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/c398498fe155790a8e6510353427ffa5224343ac tdf#164393 ThemeColors refactor part 1 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/6929168584be46583ae033c3b82574f743490c4c tdf#164393 ThemeColors refactor part 2 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/242b8a9540f8e019dbe82c11d989d20d3a0f0ea7 tdf#164393 [API CHANGE] ThemeColors refactor part 3 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/c007449ec38f49e18ed7d6b8f9ef74c5bd5c015a tdf#164393 Change themes UI as per UX feedback 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/924c7de80afa47a93705e5d073c35f2d81f4ed5a tdf#164393 [API CHANGE] Make the "Automatic" theme Customizable 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.