Right click in color palette doesn't set Inactive color [Was: Right click in color picker doesn't set secondary color]

[frio]

Right clicking in the color palette does the same as left click whether you have the selector tick on primary or secondary color, but I could swear in the past right click would set the secondary color (a bit inconsistently).

 

I tried searching for the issue and all I found was this post from a year ago that suggests right clicking should be setting the secondary when the color picker window was getting reworks:

Since that was several versions ago, I figured I'd mention it in case it fell through the cracks. I'm trying to condition myself to do C-left click-C to swap to secondary briefly, instead of right clicking, but having a hard time making the habit stick.

[Red ochre]

Yes - right click works to set Secondary color on the color-wheel but not on the palette (as expected).

[Tactilis]

On 10/18/2024 at 3:48 PM, Red ochre said:

Right click works to set Secondary color on the color-wheel but not on the palette (as expected)

I don't agree that it is "as expected".

Like @frio, I would expect a right click on the palette to set the other color slot, in the same way that a right click on the color wheel does.

The Documentation is written assuming that it does do this (although it mangles the terminology - see my suggested corrections further below).

Currently at https://www.getpaint.net/doc/latest/ColorsWindow.html#12 it says:

 

Quote

5. Palette

 

This control is used to quickly select one of the colors in the current palette. Left click on a color shade to load it into the Primary color slot.  Right clicking will load the color shade into the Secondary color slot.

 

But, as @frio says, right clicking doesn't work (at present).

 

IMO, this is a bug in paint.net.  If you agree @Rick Brewster, would it be feasible to fix this for 5.1?

 

-----------------------------------------------------------------------------------------------

@Ego Eram Reputo here are my suggested updates to the Colors Window documentation. They are intended to tidy up some inconsistencies in the way terminology is used regarding Primary/Secondary vs. Active/Inactive color slots.

Let me know if the reason for a proposed change is unclear.

 

strikethrough  = text to be deleted

red = text to be inserted

 

1. At https://www.getpaint.net/doc/latest/ColorsWindow.html#1  (Colors Window)

 

This:

"The active color is indicated by a notch in the Current Color Selector (top left in the image above)."

 

should say:

"The active color slot is indicated by a notch in the Current Color Selector (top left in the image above)."

 

2. At https://www.getpaint.net/doc/latest/ColorsWindow.html#9  (Current Color Selection)

 

This:

"The active color is indicated by a notch in the colored square. Click on the other square to swap the active/inactive status of the slots (the 'active' notch will move to the clicked color slot)."

 

should say:

"The active slot is indicated by a notch in the colored square. Click on the other square to swap the active/inactive status of the slots (the 'active' notch will move to the clicked color slot)."

 

 

3. At https://www.getpaint.net/doc/latest/ColorsWindow.html#9  (Current Color Selection)

 

This:

"The overlapping squares in the upper left of the Colors Window show the currently selected Primary (foreground square) and Secondary (background square) color slots."

 

should say:

"The overlapping squares in the upper left of the Colors Window show the currently selected Primary (foreground square) and Secondary (background square) colors."

 

 

4. At https://www.getpaint.net/doc/latest/ColorsWindow.html#9  (Current Color Selection)

 

This:

"Tip
 Use the shortcut key C to quickly switch between Primary and Secondary colors."

 

should say:

"Tip
 Use the shortcut key C to quickly switch the 'active' notch between Primary and Secondary colors."
 

 

5. At https://www.getpaint.net/doc/latest/ColorsWindow.html#9  (Current Color Selection)

 

After:

"The double headed arrow icon situated at the upper right of the Current Color Selection icon swaps the colors in the Primary and Secondary color slots."

 

add a Tip box to say:

"Tip
 Use the shortcut key X to quickly swap the colors in the Primary and Secondary color slots."

 

 

6. At https://www.getpaint.net/doc/latest/ColorsWindow.html#12  (Palette)

 

This:

"This control is used to quickly select one of the colors in the current palette. Left click on a color shade to load it into the Primary color slot.  Right clicking will load the color shade into the Secondary color slot."

 

should say:

"This control is used to quickly select one of the colors in the current palette. Left click on a color shade to load it into the Active color slot.  Right clicking will load the color shade into the Inactive color slot."

NB:
     - The right clicking description above depends on whether the bug gets fixed or not.  EDIT: The bug is being fixed for 5.1 (see the end of this thread)

     - The description for the Color Wheel at https://www.getpaint.net/doc/latest/ColorsWindow.html#10 does use the correct Active/Inactive color slot terminology.

 

 

7. At  https://www.getpaint.net/doc/latest/ColorsWindow.html#12  (Palette)

 

This:

"When the Colors window is at it's smaller size, only 32 colors of the current palette are show.

 

should say:

"When the Colors window is at its smaller size, only 32 colors of the current palette are shown."

 

 

 

Edited Saturday at 10:22 PM by Tactilis
Clarify that the bug is being fixed for 5.1

[Red ochre]

3 hours ago, Tactilis said:

I don't agree that it is "as expected".

Language - and we both speak English! 😄

To be clear I would expect a right click on the palette to set the Secondary color.

3 hours ago, Tactilis said:

Like @frio, I would expect a right click on the palette to set the other color slot, in the same way that a right click on the color wheel does.

That is what I meant, though it could be read the other way (my fault)... worse than A.I. hands!🤪

'Other' color is ambiguous though. A consistent right click always sets Secondary color would be my preferred behaviour.

[frio]

32 minutes ago, Red ochre said:

A consistent right click always sets Secondary color would be my preferred behaviour.

I'd like this too, though my preferred option would probably be left click: sets the color your selector is on, right click: sets the other color. So if you've got secondary color selected, right click sets the primary instead.

[Tactilis]

1 hour ago, Red ochre said:

Language - and we both speak English! 😄

Yes, but we do live four counties apart  😉

 

1 hour ago, Red ochre said:

To be clear I would expect a right click on the palette to set the Secondary color.

But that isn't how the color slots work.

The way it works is:

• A left click on the color wheel sets the Active color slot.  (The Active slot is the one with the notch)
• A right click on the color wheel sets the Inactive color slot.  (The Inactive slot is the one without the notch)
   
• A left click on the palette sets the Active color slot.
• A right click on the palette sets the Active color slot.  (This, IMO is the bug; it should set the Inactive slot)
   

1 hour ago, Red ochre said:

 

4 hours ago, Tactilis said:

Like @frio, I would expect a right click on the palette to set the other color slot, in the same way that a right click on the color wheel does.

 

'Other' color is ambiguous though.

I used the word 'other' deliberately here, because at that point in my reply I hadn't got to the suggested Documentation updates which correct the inconsistencies in the use of Primary/Secondary vs. Active/Inactive color slot terminology. The inconsistencies are there because the Color Window documentation was rewritten (but not 100% correctly) when Primary/Secondary dropdown control was removed in 5.0.8 in favour of the Active slot notch.

 

[Tactilis]

5 minutes ago, frio said:

my preferred option would probably be left click: sets the color your selector is on, right click: sets the other color

Yes, exactly! That's how it's supposed to work.

By "the color your selector is on" you mean the Active color slot, i.e the one displaying the notch.

It's the Documentation that is inconsistent in its use of terminology plus there is currently a bug in that a right click on the palette sets the Active color slot instead of the 'other' one (i.e the Inactive slot).

 

[Tactilis]

@frio  I've taken the liberty of updating your topic title.
You wrote 'Color Picker' (i.e the tool) when you meant the 'color palette' (in the Colors Window).

I've also changed 'secondary color' to 'Inactive color' because that is the correct terminology.

[Red ochre]

Aargh semantics!, 'active' and 'inactive' are still confusing names as many effects use both values... so they are both active?
Additionally they are still referred to as Primary and Secondary in code.
eg.

ManagedColor primaryColorM = Environment.PrimaryColor; 

Primary and Secondary could also refer to Primary (Red, Blue and Green) and Secondary (Magenta,Cyan and yellow)... for mixing light.
Since the default values are black and white (not actually colours) and pigment mixing also uses the same terminology it could be better to just call them 'Color1' and 'Color2'?
It would mean less typing when creating colour choices for effect U.I.s too!

...Despite sounding pedantic, I'd be happy if left and right click just affected different colours... whatever their names.😉

[Ego Eram Reputo]

11 hours ago, Tactilis said:

@Ego Eram Reputo here are my suggested updates to the Colors Window documentation. They are intended to tidy up some inconsistencies in the way terminology is used regarding Primary/Secondary vs. Active/Inactive color slots.

 

Thanks for taking the time to post these suggestions. I'm always happy to receive updates to the docs I'll work these into the next update.

[Tactilis]

8 hours ago, Red ochre said:

Aargh semantics!, 'active' and 'inactive' are still confusing names as many effects use both values... so they are both active?

No, only one is the active slot. See the definition in the Documentation at https://www.getpaint.net/doc/latest/ColorsWindow.html#9

 

 

8 hours ago, Red ochre said:

Despite sounding pedantic, I'd be happy if left and right click just affected different colours... whatever their names.

To be accurate, that should be: "just affected different colour slots"

[Rick Brewster]

On 10/18/2024 at 9:33 AM, Tactilis said:

IMO, this is a bug in paint.net.

 

Seeing as how the code is literally supposed to behave this way -- but it isn't -- I think I agree with you 🤔

 

[Rick Brewster]

Also, 5.0.13 does behave as you'd expect here. So this is a new bug in 5.1.

 

The upgrade to a Direct2D "advanced" rendering control, which also involves upgrading from "mouse" to "pointer" input, is probably the culprit.

 

("advanced" rendering = support for wide color gamut and HDR, "pointer" = modernized input handling that supports pen/stylus in a non-emulated manner. I bundle them together for simplicity, if you can believe it)

[Rick Brewster]

Okay this is a straightforward bug. The event handler over in the Colors form is almost doing the right thing, but the code sending it the event is not.

 

The older mouse input handling code only had to deal with "which button was pressed/released" (which button changed)

 

The newer pointer input handling code gets more information. "Which buttons are currently pressed" as well as "which button changed". The code is using the first value, and because this is in the OnPointerReleased event handler, the value for this is "none." So it just needs to look at the other button-related value.

[Rick Brewster]

This is fixed for the next 5.1 build/update.

[Rick Brewster]

7 minutes ago, Rick Brewster said:

So this is a new bug in 5.1.

 

@frio btw next time please be sure to mention that you're using the beta  It helps to save time

[frio]

10 minutes ago, Rick Brewster said:

please be sure to mention that you're using the beta

Oh sorry, momentary lapse of mind, I think I usually remember to add the version number of what I'm reporting against.

Edited Saturday at 08:06 PM by frio