Created attachment 189154 [details] Video showing how the Color Scheme switcher works Modern IDEs offer the possibility of quickly switching the color scheme of the code editor. I believe we should have this in the Basic IDE as well. Currently we can configure Basic colors in Tools - Options - Application Colors, which is OK and offers some flexibility to the user. However, this has the disadvantage of changing color settings for the entire application. Also, if the user wants to quickly switch the color scheme in the Basic IDE, it is currently not possible. And modifying the existing Application Colors scheme via the Options dialog is tedious. Therefore a quick color scheme switcher would come in handy. I have a WIP patch with a proposal. I've attached a video of how it works. Here's a description of how it works: 1) If the user chooses "Use Application Colors", the IDE will use the colors defined by the currently selected scheme in the Tools - Options dialog 2) If the user chooses "Choose Color Scheme", then they'll be able to choose among the available color schemes, which are instantly applied to the editor When a color scheme is selected, it overrides the settings in Tools - Options (these options are not overwritten). So if the user simply wants to revert to the default colors, they simply need to choose the option "Use Application Colors".
Created attachment 189155 [details] Colors used by the proposed color schemes Here you'll find the colors used by the themes I added to this feature. If anyone would like to propose changes or new themes, it is very easy to add/modify them. The schemes I used were adapted from the ones available in Kate. I'd like to point out that the color schemes are hard-coded and I don't plan to implement a UI to allow the user to customize the color schemes. The idea here is to provide a quick color scheme switcher.
(In reply to Rafael Lima from comment #1) > I'd like to point out that the color schemes are hard-coded and I don't plan > to implement a UI to allow the user to customize the color schemes. The idea > here is to provide a quick color scheme switcher. How does that fit to the "Basic Syntax Highlighting" settings in Tools > Options > Application Colors?
(In reply to Regina Henschel from comment #2) > How does that fit to the "Basic Syntax Highlighting" settings in Tools > > Options > Application Colors? When the user selects the option "Use Application Colors", then the colors defined in Tools > Options > Application Colors are used. When the user selects another color scheme (first they click "Choose Color Scheme" and then choose one of the available schemes), then these colors are used instead of the Application Colors. The colors from the color scheme override the ones defined in Tools > Options > Application Colors. It is important to note that the colors in the Options dialog are not replaced. This way, if the user decides to go back to "default" application colors, they only need to select "Use Application Colors". BTW proposed patch is here: https://gerrit.libreoffice.org/c/core/+/155928 It's WIP yet but it works... there are just a few things that I need to polish before submitting for review.
Appreciate the idea but would rather make this part of the application colors switch, which is possible yet not comfortable. My idea is to add color schemes via extension and allow users to switch from Automatic (Dark/Light) to Breeze, Nord, Oblivion... If some colors are not defined it should take the default - and thereby you get BasicIDE only color schemes.
(In reply to Heiko Tietze from comment #4) > Appreciate the idea but would rather make this part of the application > colors switch, which is possible yet not comfortable. My idea is to add > color schemes via extension and allow users to switch from Automatic > (Dark/Light) to Breeze, Nord, Oblivion... If some colors are not defined it > should take the default - and thereby you get BasicIDE only color schemes. The idea I'm proposing is to provide users with a list of color scheme presets, which are available for everyone without the need to install extensions. They're available to any user with no additional effort, even on a clean LO install. The problem with adding color schemes via extensions is that it's very cumbersome (TBH I don't really know it's possible at the moment). Also, some users wouldn't even know it's possible to install color schemes via extension. As a Basic IDE user myself, I would find it very annoying to have to install multiple color schemes via extensions and then have to go to the Tools - Options dialog just to change the color scheme of the Basic IDE. I would be very happy to have a handful of color schemes readily available for use. This is why I'm proposing this approach of providing presets that can be quickly accessed and applied.
Couldn't they be put in the share folder of the installation and read from there instead of hard coding?
(In reply to Regina Henschel from comment #6) > Couldn't they be put in the share folder of the installation and read from > there instead of hard coding? I recognize hard-coding styles is not a very elegant approach. One thing I considered was creating a BasicColorScheme.xcs schema definition and then adding the color schemes to the corresponding .xcu file. Then when initializing the ColorSchemeMap I would read all available Basic color schemes from this file. However, I still haven't completely understood how to accomplish that. And I'm not really sure of what benefits this extra effort would bring. But in the future, I would be open to moving these hard-coded styles to a separate xcu file. The only thing that wouldn't be nice is duplicating whole Application Color schemes just to have different Basic IDE color schemes.
(In reply to Rafael Lima from comment #5) > The idea I'm proposing is to provide users with a list of color scheme... Effectively you keep Application Colors as some kind of storage and provide another route to modify it with the hard-coded extra colors. This might end up in confusion if users change something in one of the two places and it does not produce the expected result. Nothing to say against separating the basic colors into an extra scheme. The opportunity to customize everything is a key feature of LibreOffice. Your Breeze variant is maybe not 100% the same as my colors and I'd like to change just one value. (In reply to Rafael Lima from comment #5) > Also, some users wouldn't even know it's possible to install color > schemes via extension. We made this very easy to understand with the tight integration.
(In reply to Heiko Tietze from comment #8) > Your Breeze variant is maybe not 100% the same as my colors and I'd like to > change just one value. Feel free to edit the patch and change the color.
(In reply to Rafael Lima from comment #9) > Feel free to edit the patch and change the color. "Me" is "one user", "a value" an example to illustrate why hard-coded constants are odd.
(In reply to Heiko Tietze from comment #10) > "Me" is "one user", "a value" an example to illustrate why hard-coded > constants are odd. Sorry, I really hadn't understood. The main problem of creating all the machinery to allow the user to edit/create color schemes is that the complexity of the patch will increase 4x for something that very few people will use. I myself have never edited a color scheme... I only choose the one that fits better among the available ones. This is why I chose to prioritize having some presets. If the user really wants to edit the colors one by one, they can go to Toos - Options - Application Colors and edit them (and set Basic to "Use Application Colors" in the new dialog)
Set to ASSIGNED by https://gerrit.libreoffice.org/c/core/+/155928
(In reply to Rafael Lima from comment #11) > The main problem of creating all the machinery to allow the user to > edit/create color schemes is that the complexity of the patch will increase > 4x for something that very few people will use. Not necessarily. You could add color schemes where only the Basic IDE colors vary and remotely switch the option from "Automatic" to "Basic Foo". You could change the default values with the hard-coded values and maybe also hide the Basic IDE colors in the options. Point is that you introduce another route to customization and this adds up to the spaghettiness code-wise and challenging usability (how to explain users that you either modify in a) or b) but only in case of...). Ultimately the doer decides. And if you consider to remove the patch later once we have a better approach I'm not against this.
(In reply to Heiko Tietze from comment #13) > ...and challenging usability (how to explain users that you either > modify in a) or b) but only in case of...). I'll create the dialog Help page to document how this feature works and how it interacts with Application Colors. > Ultimately the doer decides. And if you consider to remove the patch later > once we have a better approach I'm not against this. I don't see any problem to change this approach if something better comes along in the future.
Created attachment 191449 [details] Sample Extension with Additional Color Schemes Recently I changed the approach to handle colors in the proposed color scheme selector. The color schemes are no longer hardcoded. Instead they're stored in the registry, which makes it possible to extend them via extensions (see attached sample extension with two additional color schemes). Here's the updated patch: https://gerrit.libreoffice.org/c/core/+/155928 Everything is working fine (as far as all my testing goes). If anyone could please review the patch, I'd appreciate it. The current patch includes: - The code to manage color schemes in the registry - Apply the color scheme to the Basic IDE I'll leave for a subsequent patch the inclusion of functionalities to edit color schemes in the dialog.
Works like a charm. The extension misses some info, however. In particular the package description and a license statement. Some hints at https://wiki.documentfoundation.org/Development/Extension_Development https://wiki.documentfoundation.org/Development/Create_a_Hello_World_LibreOffice_extension
(In reply to Heiko Tietze from comment #16) > Works like a charm. The extension misses some info, however. In particular > the package description and a license statement. Oh yes... after the patch gets merged I'll work on a proper extension.
Rafael Lima committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/076e21f4e3c47f8be5218ab683f972eef1de3e18 tdf#156925 Add Color Scheme selector to the Basic IDE It will be available in 24.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.
Rafael Lima committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/b85bb4516175e71903a9c5db583724231fa60471 tdf#156925 Document the Color Scheme dialog
Verified in: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d0dcd87788910e3c9f67a2b68534019c05b77bad CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded In release notes: https://wiki.documentfoundation.org/index.php?title=ReleaseNotes%2F24.8&type=revision&diff=730190&oldid=724409 Thanks for the great feature, Rafael! :) @Michael: wondering if you have input regarding making sure that we ship at least one scheme that is suitable for low-vision? And maybe a dead-simple "high contrast" scheme?
(In reply to Stéphane Guillou (stragu) from comment #20) > Thanks for the great feature, Rafael! :) Thanks for adding it to the 24.8 release notes. BTW, soon I'll be publishing an extension with extra color schemes for Basic. Maybe with 15-20 more options. > @Michael: wondering if you have input regarding making sure that we ship at > least one scheme that is suitable for low-vision? And maybe a dead-simple > "high contrast" scheme? If you can point me to some existing schemes that are suitable for low-vision / or that are high-contrast, I can add them to the set of built-in schemes.
(In reply to Rafael Lima from comment #21) > BTW, soon I'll be publishing an extension with extra color schemes for > Basic. Maybe with 15-20 more options. We can introduce a special category on the extension site that could be accessible via tight extension (if the website would be working). A prototype could be https://gerrit.libreoffice.org/c/core/+/104248
(In reply to Stéphane Guillou (stragu) from comment #20) > Thanks for the great feature, Rafael! :) Yes, that indeed looks great in a quick test! > @Michael: wondering if you have input regarding making sure that we ship at > least one scheme that is suitable for low-vision? And maybe a dead-simple > "high contrast" scheme? I don't have anything readily available for specific colors to point to. The WCAG criterion regarding contrast is at [1] and there's some related discussion with further links in tdf#156182. Looking e.g. in Qt Creator, there's no color scheme explicitly labelled "high contrast". The KDE wiki mentions a "Breeze High Contrast" style [2], but if I remember correctly, that was dropped at some point because it was said that the default Breeze styles (or at least one of them) was just as good. @V Stuart: Any ideas/thoughts? [1] https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html [2] https://develop.kde.org/hig/style/color/high/
(In reply to Michael Weghorn from comment #23) > > @V Stuart: Any ideas/thoughts? > The COLORSCHEME_LIBREOFFICE_DARK and COLORSCHEME_LIBREOFFICE_LIGHT applied from corresponding entry on the newly implemented View -> 'Color Scheme...' dialog for the Basic IDE have reasonable HC response. Could just append an "(HC)" to the listbox entry. Though ideal would be to actually read the os/DE provided color theme and extract colors from there, but that's Rafael's call as implementer.