Possiblity to disable element groups

[sebastian2357]

Hi there, This is the most feature rich and also best looking color picker I could found. Thank you for sharing your work :)

Would you consider to add Properties to disable/enable the visibility of the various element groups?

Because in many cases you don't need all the provided features - just a few..

If you like I could also provide a PullRequest...

[arklumpus]

Thanks for the suggestion! I just released version 1.2.0 which has a few properties to do this (see here for more details). Some elements can't be hidden, because I don't think it makes much sense to have a colour picker where you can't pick the colour 😅

Let me know if this works for you, or if you any other suggestions!

[sebastian2357]

Thanks for your quick reply.

I could just test it. Now it is possible to hide/show element 👍 :-) Do you see a possibility to make the layout more compact? Maybe even to split the whole control in many small ones?

[arklumpus]

That is an interesting point; it will require some reworking of the control, but it should be possible. The question is how to expose this: in any case, there would be a number of controls (e.g. HSBControls, RGBControls, ColorPreview, etc.), which you would arrange using XAML code. Then, there needs to be some sort of AbstractColorPicker that connects them. I see a few options here:

1. AbstractColorPicker inherits from ContentControl (or something similar); then, you need to use it in your XAML as the parent object of all the elements. E.g.:

   <AbstractColorPicker>
       <StackPanel>
           <HSBControls/>
           <RGBControls/>
           <ColorPreview/>
           <!-- ... -->
       </StackPanel>
   </AbstractColorPicker>

   The AbstractColorPicker then scans all its descendants and connects them.

2. The AbstractColorPicker is an "invisible" control, that scans all of the descendants of its parent (or of the window?) and connects them. For example:

   <StackPanel>
       <HSBControls/>
       <RGBControls/>
       <ColorPreview/>
       <!-- ... -->
       <AbstractColorPicker/>
   </StackPanel>

3. The AbstractColorPicker is not a control at all. You cannot create it using XAML, and you must create it in the C# code, where its constructor requires the sub-controls as parameters.

Which possibility makes more sense to you?

I was also wondering, why do you want to hide some of the controls? I don't see much value in allowing users to only select the colour using RGB values, but I'm happy to change my mind 😅

[sebastian2357]

Hey, Sorry for my late reply.

In advance is there a special reason, that you do not want to use Binding? For example:

    <HSBControls Color="{Binding Color}" />
    <RGBControls Color="{Binding Color}" />
    <ColorPreview Color="{Binding Color}" />

Otherwise I would prefer the third option to bind the elements by code :-)

Regarding to your question: it depends on your use-case how comlex a color picker should be. In my case the user mainly need a dialog to just set a color, but not "research" a color. This will be already done in an another professional illustration tool.

[arklumpus]

Hi, sorry for the delay! I have finally come around to implement this in version 1.3.1 of the package.

Unfortunately, it's not as easy as just using bindings, because there a number of "inconsistent" states that can happen, and of which the control(s) must be aware; this is because (due to rounding errors in integer math) there is not a 1:1 correspondence between RGB, HSB and CIELAB values.

For example, in some cases, slightly changing the colour in HSB or CIELAB coordinates might not have any effect on the RGB values of the colour; in this case, the colour picker needs to know which component you were changing, otherwise it might accidentally "undo" your change. This would make it impossible to change the colour with successive increments of one component from the color picker interface.

I have created a Wiki for the repository, explaining how to customise the colour picker window (and other things); you may be interested in this page in particular. As an example, I used the kind of interface that (I think) you were trying to create.

In practice, you can use either approach 2 or 3 from above, i.e. have all controls in the XAML code within a parent CustomColorPicker, or create a CustomColorPicker from code passing the child controls as parameters to the constructor.

[arklumpus]

Closing because this should be fixed.