Recent

Author Topic: Feature request: Toggle between last used color schemes  (Read 551 times)

Pascal

  • Hero Member
  • *****
  • Posts: 832
Feature request: Toggle between last used color schemes
« on: April 16, 2019, 01:26:35 pm »
I'd like to switch between two color schemes (SolarizedDay and SolarizedNight) by hotkey.
So i issued a feature request on bugtracker.

I also did a first try by attached patch. Comments are welcome!
laz trunk - fpc trunk 32bit - Windows 10 Pro x64 (1803)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5631
    • wiki
Re: Feature request: Toggle between last used color schemes
« Reply #1 on: April 16, 2019, 03:37:30 pm »
I'll go through it in a bit.

The main decision is if it should be part of the main IDE, or an installable package (via OPM).

Pascal

  • Hero Member
  • *****
  • Posts: 832
Re: Feature request: Toggle between last used color schemes
« Reply #2 on: April 16, 2019, 04:41:46 pm »
I don't thinkt that it will be posiible inside an installable package atm.

I had to construct TOptionsDialog to get to the functionality i need. But maybe there is an easier way of doing it.
laz trunk - fpc trunk 32bit - Windows 10 Pro x64 (1803)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5631
    • wiki
Re: Feature request: Toggle between last used color schemes
« Reply #3 on: April 18, 2019, 11:21:43 pm »
Ok, I had a quick look. Sorry I got carried away a bit. Don't wont to hijack your idea to push for more... Anyway my ideas below. Please comment, we can then assess. Nothing put into stone yet.


TEditorColorOptionsFrame should not be used at all. That is meant to be used if the options dialog is actually open.
To set/get the current scheme calls should be made to
TEditorOptions.WriteColorScheme
TEditorOptions.ReadColorScheme
and trigger the editors to re-read.

There is EditorOpts.HighlighterList, which should allow to get the name of the colorscheme for each highlighter. So that can be used to read/write complete configs.
As schemes are identified by name, it needs to be defined what happens if a user-added scheme is removed.


Pre assigning a key is problematic. It is probably going to be a feature used by fewer people, and the keymap is very crowded. I already used your key in a combo of my own.



Well now the rest depends....

1) External package vs build into main IDE.
I am a fan of modularisation. (But I see it may have its limits)
Also the current feature to me (but I may be mistaken) seems to target a possible smaller group (nothing wrong with that). It has potential to develop into more.
Who knows what other options may get some form of quick access.... And if so, I would like to avoid a loose collection of differently developed, yet related features.
Thus my thought it may be easier to start collecting inside a package. Then if incompatibility arises, people can keep the old, or use the new.
On the other hand there is the question how much overhead a package may cause....

From a first glance:
- we need to expose an event, if the user changes the config (IdeIntf) / may not be needed....
- we need read/write access to the current selected colorschemes (per filetype) (sourceEditorIntf?)

Lets call "names of selected colorschemes (per filetype)" => colorscheme-set

Storing the info can be done in its own option file.


2a) About the design of the feature.
Would it be better to allow saving a colorscheme-set to a key?
Then you can assign as many of them to as many keys as you want.

In that case, all you need is access to read/write the current colorscheme-set.
If src-editor intf provides that, the rest can easily go into a package.
That is if the package only allows to save the current colorscheme-set, and then when you changed it for the first time via options, the package can save the new current to another key....

Minimum changes in the main IDE, but not the greatest integration for setting up your initial set of colorscheme-sets.


2b)
No package / In the IDE.
The alternative would be to design that into the Tools>Options dialog. You would need a button there, that allows you to choose the key, to which to save the current colorscheme-set.
That needs more thought on the design though.
While the functionality today can be kept to just colorscheme-set, the button should be placed in such way, that it could one day act, like build-modes to today.


2a+b)
In either case I would suggest to store the resulting config in a new xml-node (if stored in the IDE env opts / but also if stored outside)
...
  <quick-options>
    <color-sets count="">  // count may no longer be needed some day => already new code exists for some settings
      <color-set1  key="Shift-Ctrl-[>
        <highlighter name="pas" scheme="darknight"/>


-----------
Now I know this is a hell of a lot more than you would have expected.

Maybe we can find a suitable subset, that you would be interested to do?


----------
We can always identify the events needed to allow acces from a package.
Then you have the freedom to do it anyway you want.

Packages already can register menus, toolbars, key shortcuts...
EditorMacro even shows how to dynamically add key shortcuts.



Pascal

  • Hero Member
  • *****
  • Posts: 832
Re: Feature request: Toggle between last used color schemes
« Reply #4 on: April 24, 2019, 08:06:37 am »
Thanks, Martin, i'll have a look at your comments in detail when i have more time.
laz trunk - fpc trunk 32bit - Windows 10 Pro x64 (1803)