Enabling persistence of custom colors in answer color

[trevordevore]

The dialog displayed to the user when calling `answer color` allows the user to define custom colors (at least on OS X and Windows, don't know about Linux). On OS X the OS stores/restores the colors across sessions of an application by means of the app preference file. On Windows this is not the case and the colors only persist across calls to `answer color` in the same session.

The engine needs a way for the developer to store/restore the custom colors on Windows. Currently the code defines a state variable in w32ans.cpp on line 874:

Code: Select all

static variable static COLORREF custclr[16]; //save custom colors

I think the simplest approach would be to add a property that allowed you to set a CR delimited list of colors.

Code: Select all

set the colorDialogCustomColors to theListOfColors

The property would be updated to reflect the list of custom colors in the color dialog after the user closes it. This would allow the developer to store the value in preferences and have it persist across sessions.

Perhaps an ideal implementation would allow the developer to specify the custom colors for each call to `answer color`. Should `answer color` be extended to accept a list of colors to use as the custom ones? I imagine OS X allows you to configure the default colors as well.

Code: Select all

put "182,153,123" into theDefaultColor
put "245,245,245" & cr & "125,125,125" into theCustomColors
answer color with theDefaultColor with custom colors theCustomColors

If the developer doesn't provide a list of custom colors then `colorDialogCustomColors` would be used. If `colorDialogCustomColors` is empty then the OS defaults are used.

Thoughts?

[monte]

Is it possible to implement this cross platform? As in can we override the preferences on OS X ... do we want to do that... perhaps people want to use colors created in a different app??? Another thing is are we sure the engine isn't meant to read the user's colors from the registry or something???

I think `customColors` seems nicer than `colorDialogCustomColors` and I guess they could be used as a place to store colors even if the system dialog isn't being used or if both the system dialog and a separate UI for quicker switching of pre-chosen colors was used.

Anyway, good pick for a contribution mate ... I'm starting with edge cases to support pet hobbies not anything particularly useful to most users

[LCMark]

I think the Cocoa version of the Mac color panel allows specifying custom color lists... Although the engine uses NPickColor at the moment which doesn't seem to. We might actually have some code to replace the Carbon one with the Cocoa one - I recall having to do so for the webplugin.

It would be good to get this as cross-platform as possible

I wonder if we need the 'custom' though. How about 'answer color ... with colors ...' and a global property 'the colorDialogColors'.

Looking to the future where we will have more flexible syntax, the dialogs could become pseudo global objects. So you could do something like:

Code: Select all

set the colors of the color dialog to ...

[trevordevore]

Monte - Windows doesn't store the values for you automatically as the system doesn't manage preference files like OS X does.

Mark - I think you are right about the Cocoa dialog. attachColorList will add colors to an NSColorPanel.

For starters I'm going to implement 'the colorDialogColors' and see how that goes.

[monte]

On platforms that support it will the colorDialogColors be populated on startup with the user's colors? That would be nice.

Is answer with colors redundant if there's a colorDialogColors

Also something doesn't seem right with colorDialogColors to me... probably color is in there twice seems redundant. dialogColors doesn't work... answerColors either... I wonder if something like userColors is nicer?

[LCMark]

On Mac, I believe you can save color-lists that the dialog picks up itself (i.e. into your user session) and you can have 'document-level' colors, which the application calling it manages. On WIndows, I believe its just 'document-level' colors... i.e. On either of these platforms there's nothing to initialize the global to.

The issue with 'userColors' as a property name is that it doesn't really suggest its domain - colorDialogColors may seem a little verbose / strange but it very well describes what it is for.

Of course, this still doesn't answer the question of whether need both 'answer color ... with colors ...' *and* a global property. If not, the answer command might be better...

There's still Linux to investigate too...

[trevordevore]

If we just went with 'answer color ... with colors ...' then how would the developer get the list of colors after the color dialog is dismissed? That is why I thought the global property might be the way to go.

[trevordevore]

Regarding Linux - I don't have Linux running on this computer so I don't know what the color dialog looks like. But the GTK API has the following two functions which look promising:

gtk_color_selection_palette_from_string ()
gtk_color_selection_palette_to_string ()

https://developer.gnome.org/gtk3/stable ... rom-string

[monte]

If we just went with 'answer color ... with colors ...' then how would the developer get the list of colors after the color dialog is dismissed? That is why I thought the global property might be the way to go.

Are you assuming they are creating multiple colors and only picking one? If you just record the colors each time they pick one and keep them in an ordered list from most recent to oldest then that should do the trick.

[trevordevore]

If you just record the colors each time they pick one and keep them in an ordered list from most recent to oldest then that should do the trick.

That isn't how it works. The user could open the color picker, add 10 colors to the custom list, and then select a completely different color. The list exists independently of colors chosen.

[LCMark]

I forgot about the need to access the selected color list

So, it sounds like global property + optional extension to answer color is the way to go.

[monte]

Hi

@trevordevore asked me to look into this one.

I'm a little confused about what to do cross platform because of the differences between the way the color dialog works on Windows and OS X... haven't looked at Linux yet. On Windows we want the color dialog to manage the colorDialogColors during the session and we save at the end and set at the start. On OS X the system already retains the color lists the user creates so we don't need to set the colorDialogColors at the start of the session or save at the end. We would only do so if we had a custom color list we wanted to provide the user and if we had that we would want to set the color list name.

So what I'm thinking is something like this:
answer color [with startingColor] [with colors colorList] [named listName]

Where listName only applies on OS X and defaults to something like [[NSRunningApplication currentApplication] localizedName].

However it's a bit quirky syntax if the developer skips the [with colors colorList] part in favor of using the colorDialogColors global. I wonder if we could get away without the colorDialogColors global by putting the altered color list into dialogData on Windows and possibly Linux if it supports that workflow.

Cheers

Monte

[monte]

FYI I've done some experimentation with this and implemented (Windows only):

Code: Select all

answer color with <color> with colors <custom colors>
put the dialogData into theCustomColors

I hadn't really played with the custom colors in the windows color picker before and I notice now that it keeps the custom colors for the session so perhaps the global is better because you can set and forget until shutdown. Should we worry about implementing this cross platform or just resolve the issue where it's a problem (Windows).

If we go for a global is there any need for answer color with colors?

Cheers

Monte

[monte]

If we are looking to implement this cross platform we are going to hit a quirk with the fact that NSColorList needs keys for each color while on windows we just need a 16 element array of colors. Combined with the fact that while the feature is quite important for getting a Windows app that uses the color picker to behave right it's not an important feature for OS X (because the system really does what we are wanting to do) I'm inclined to implement this as Windows only and not do the with colors thing in answer colors (because of the way the dialog behaves I think the global is better). Any thoughts on that?

[trevordevore]

Personally, I would be fine with only adding the global in order to get Windows working properly.