Bug 130970 - Implement a "gradient-picker" / gradient-eyedropper
Summary: Implement a "gradient-picker" / gradient-eyedropper
Status: RESOLVED DUPLICATE of bug 93813
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
3.3.0 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-02-26 21:52 UTC by Eyal Rozenberg
Modified: 2020-03-18 08:48 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Mockup gradient picker (43.27 KB, image/png)
2020-03-17 14:29 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2020-02-26 21:52:43 UTC
Many LO entities support a gradient fill rather than merely filling by a uniform color. Now, just like we can choose to mimic an existing gradient with a new one, we can also do the same for gradients. And just like we could use a color-picker/eyedropper for single colors (see bug 130967) - we could also use an eyedropper for gradients.

It could look at an encompassing LO object or an image, and either retrieve its gradient fill or compute it (by projection of the image onto one or several of the spaces of possible gradients supported in LO).
Comment 1 Heiko Tietze 2020-03-17 14:29:14 UTC
Created attachment 158753 [details]
Mockup gradient picker

I fully agree. We should not expose all properties to the sidebar as kind of replacement to the ordinary dialogs but provide quick access to settings. This is an excellent example.

The devil lies in the detail. While we may list the presets, the list may grow indefinitely. So either we implement some reload mechanism as known from news feeds, meaning when you scroll below item #20 or so the next 20 are loaded. Or we show a link "More gradients" and on click you open the dialog. Or we just limit the number to 20 with the hope that users don't create so many own presets (and show the user-defined first).
Comment 2 Eyal Rozenberg 2020-03-17 14:55:46 UTC
(In reply to Heiko Tietze from comment #1)

I don't think we are talking about the same thing. What I'm suggesting is not a modification of the dialog for setting a gradient. Rather, I'm talking about a tool which, once engaged, does the following:

1. Changes the mouse pointer (e.g. to look like an eyedropper, or a target crosshair etc.)
2. Shows you the document (i.e. not some dialog), to let you pick something within it.
2. "Captures" the next mouse click
3. Determines what gradient is used in the object (within the document) that the mouse has clicked.
4. Sets the "current gradient" (determined by the context in which we invoked the gradient picker) to the same gradient as that object.

Here:
https://www.youtube.com/watch?v=_Np5Hr34Mj4

is a demonstration of a what a uniform color picker/eyedropper tool looks like in action. In that video, the narrator uses an eyedropper to set the foreground color, then the background color.


What you were talking about and the mockup you posted is an interesting idea but should be a different issue :-)
Comment 3 Heiko Tietze 2020-03-18 07:56:29 UTC
We use the term picker for the floating widgets eg. the colors, where you don't pick a color from the document but the palette.

So your request is about a color reader (GIMP calls it eyedropper) and this has been asked for in bug 93813.

*** This bug has been marked as a duplicate of bug 93813 ***
Comment 4 Heiko Tietze 2020-03-18 08:48:40 UTC
(In reply to Heiko Tietze from comment #3)
> *** This bug has been marked as a duplicate of bug 93813 ***

For clarification: I also make bug 130967 a duplicate of 93813. This one is about gradients, so two or more colors, but I strongly believe and wait-for-next-click or press-button-foo interaction to pick more than one color from the document is not easy to use and we should focus on the per-color picker.