Dropper (color picker) fetches values - instead of swatches

[mray]

Inkscape 0.91+devel r Ubuntu 14.10 64bit

I expect the Dropper tool to pick and assign swatches.
Instead it always reads the color _values_ and assigns a non-swatch color.

[su_v (suv-lp)]

Questions to clarify the requested feature (pick colors from objects, instead of color values of the rendered objects):
Assume this situation:
- a rectangle with a custom solid swatch color as fill (100% opaque)
- on top of the rectangle, a circle with a gradient fill from blue to transparent.
What color is the dropper supposed to pick from any point inside the area of the two blended object fills?

Assume another situation:
- a rectangle with custom swatch color A as fill
- adjacent (to the right) another rectangle with custom swatch color B
What color is the dropper supposed to pick when used in drag mode (currently: average color over a circular region)?

etc.

[mray (mrayyyy)]

I see how my problem is more complex than I expected.
It is a general problem though, since picking the fill property (gradients, patterns, swatches,...) rather than values remains relevant request. Especially since we finally have those awesome swatches!

From what I gather there are three scenarios:
1. you want to pick the color value (or avarage of an area)
2. you want to pick the color value, but only from the topmost object
3. you want to pick the fill property
4. ...did I miss anything?..

Maybe it is an option to switch between them via shortcuts;
D; default color picking
Shift-D: toggles the destination fill -> stroke.
Ctrl-D: toggles value -> color property

The circular dreag region would need to be deactivated during the Ctrl-press.

[su_v (suv-lp)]

<opinion>
I'd caution that this quickly made feature request would introduce (possibly numerous) inconsistencies in the use of the dropper tool because the tool does not act on (pick from) a current selection (note that 'Edit > Copy, Edit > Paste style' does exist, to transfer actual object style attributes to other objects).

See trivial example in attached file: with the proposed new mode to pick the "object style" of the top-most (?) object - how would a user be able to use the tool in this new mode predictably without indication what actually is the relevant object the style attribute is picked from?
</opinion>

--
replaces (hidden) comment #3 to fix incorrect summary of 'Paste style'

[mray (mrayyyy)]

You're right about the inconsistency problem. The dropper currently does not pick gradients or patterns either.
(But why shouldn't it? I see how this is a separate feature request...)

@example: on one hand you're right you can't predict the outcome, on the other hand swatches worsen that problem: how would a user ever notice picking a value from a swatch vs. a "regular" color?

I see a problematic inconsistency in handling colors – but not understanding the benefit of named colors.
I expect Inkscape to understand that once I deliberately choose to make use of named colors I probably may want to keep it that way. Picking swatches needs not to override the default behavior - but it seems reasonable to provide a toggle for that purpose.

[mray (mrayyyy)]

Gathering more experience with named colors I want to note that it appears to be impossible to exclusively use named colors ina a project. Totally refraining from the eyedropper or manual color assignement isn't realistic and sooner or later a non-named color slips in here and there.
That's really bad if you need all the colors to stick to named colors.

Imho this *is* a Dropper Tool bug.

[su_v (suv-lp)]

On 2015-09-10 20:03 (+0200), mray wrote:
> Imho this *is* a Dropper Tool bug.

<opinion>In my opinion it is definitely not a dropper tool bug, and adding a (by itself necessarily selection-based) "picking" of a literal style property (a 'named color' paint of the fill or stroke style) to a tool which picks the computed color from rendered canvas pixel(s) beneath the cursor and uses a selection to _assign_ the picked color (and optionally opacity) won't "fix" anything but badly break a tool which currently does well what it is designed for.

Use 'Edit > Copy', 'Edit > Paste style' to transfer style properties from a selected object to another one. IIRC we have reports requesting to enhance that feature (e.g. to allow more selective pasting i.e. only certain style properties).
</opinion>

[su_v (suv-lp)]

I should add though that 0.91 has a new 'pick once' instance of the dropper tool added in 'Fill&Stroke' which doesn't work well with custom swatches (named colors) in a very specific use case: editing the color of an existing swatch in Fill&Stroke; as reported earlier here:

* Bug #1049481 “Allow dropper tool to edit current custom swatch fill”
  https://bugs.launchpad.net/inkscape/+bug/1049481

[mray (mrayyyy)]

Your remark makes sense from a developers side.

From my perspective as a user the Dropper "sucks in" the color on the canvas to "squirt" it out elsewhere. I see how named colors could qualify as style here, but to me the important thing is they certainly qualify as color. And I see the resulting corner case where the Dropper works by gathering the merged results of the pixels below and can't possibly take into consideration what values came from which objects and their eventually assigned named colors.

Yet there is the common (maybe TOP!) use-case for the Dropper Tool that suddenly falls apart: making one thing have the identical color as another.
So it might have been a lucky side-effect that property and value have been almost always identical for a long time, but to me this side effect is the MAIN purpose of the tool and I have a need for it either way.

So probably this is a feature request after all: A new Dropper Tool via "new modifier+D" that sucks in the topmost *named* color, gradient or pattern.

[mray (mrayyyy)]

The more I work with Inkscape the more this is an issue for me.
Is there any other way to pick swatches from one object to another?

I end up not using swatches just because it is just too cumbersome, even though I love them.