Add opacity control for colour-picker

[dajare]

Flameshot offers a useful selection of colours for the tools provided. This would be much enhanced if an opacity level could be added to those colours.

Sometimes when you add an arrow or other annotation to a screenshot, something gets obscured. Being able to set opacity would ensure that this does not happen.

Thanks for the great app! I hope this suggestion helps make it even better.

[dajare]

I see that the 0.6.0 Roadmap plans already include an update to the Qt-Color-Widgets component (now hosted on GitLab). I see its ColorDialog panel includes a transparency slider already...

... so perhaps this enhancement request will be taken care of "automatically".

[brianjmurrell]

Or being able to use the Rectangle paint tool and set the opacity of what it paints, so as to emulate like colouring an area with a highlighter.

[PrSunflower]

I agree with a global opacity slider.

I had suggested to change the opacity of the Marker tool in issue #1085 because the current setting is bad for highlighting text, but being able to change the opacity of all drawing tools would be a great feature.

[borgmanJeremy]

Seems like there is a lot of interest in this feature. I'll get an RFC going so we can discuss the implementation .

[PrSunflower]

Hello! Hope you are all well.

Do you have any updates on the Request For Comments?

[mmahmoudian]

Interestingly enough, all issues tagged with Need RFC are color-picker related. @PrSunflower would you like to write the RFC? For now we don't have a template (or at least I don't remember if we have), so I suggest using this template: https://cwiki.apache.org/confluence/display/GEODE/RFC+Template

[PrSunflower]

Thanks for replying. Oh wow it would be an honour!

I am not familiar with RFCs, where can I redact it? Is there a place in GitHub repos for RFCs?

[mmahmoudian]

I discussed it with devs on Slack (btw you are welcome to join) and @borgmanJeremy mentioned:

This is the process currently documented and there is an RC template: https://github.com/flameshot-org/flameshot/blob/master/docs/RFC.md my personal opinion is this was too much complexity for our project, so maybe we can make it more simple?

Therefore you can use that documentation as a guide, but let's keep it simple and light as this color issue is not such a massive change. This can also be a learning process for all of us regarding this project 😃 . About what is the process, it is very simple: https://github.com/flameshot-org/flameshot/blob/master/docs/RFC.md#what-the-process-is

[PrSunflower]

Hi everyone,

I have redacted a draft of the RFC 🙂. This was my very first time creating a Pull-request, I hope I did it correctly 😄

As written in the description of the Pull-request and in the RFC itself, I would be grateful if @mmahmoudian and @borgmanJeremy could check, correct and add missing info to the RFC 🙂

I did learn many things while redacting it and I hope the Flameshot community can improve as well. 😄 Cheers! 😁

[4n0nct]

Yes opacity selection would be a great improvement. Thx by advance if you can implement that in one of your future updates

[mmahmoudian]

I believe this is not implemented, but it just occurred to me that by changing the color of the rectangle tool and make it transparent, one can achieve what you are looking for.

In the figure below, I just added transparency manually to the color in line 4:

[wencakisa]

Hey, guys! This will be a great addition to the tool once implemented 🤓

I've just found a workaround that works for all Flameshot versions that support writing the hex value for the color. You can "abuse" the HEX color format by appending an opacity color code in the color selector:

In this recording ☝🏼 , I use the 80 opacity value for the color, which sets the color opacity to 50%.

[mmahmoudian]

Perhaps something like the following can be added to GUI and also consider the RFC written by @PrSunflower

[SamuraiNinjaGuy]

So I made a pull request that implemented this for the marker, before this issue/discussion was brought to my attention by @mmahmoudian. @mmahmoudian and @veracioux have brought up some good points and I would like to take this change on, but I want to make sure I don't get ahead of myself again.

I am a huge proponent of not changing the default UIX. Especially with Flameshot, as I only recently learned of some of the customization options, and I have been using it for years without knowing any beyond the quick right-click color change/scroll mouse, make some tools bigger or smaller. This is very praise-worthy in my opinion.

The custom opacity for marker creates a bit of an issue if we use a single global color opacity setting. We either have to have marker use 35% of the global opacity setting (preserve UIX), or we change it so marker is 100% opacity by default (changing the UIX). At 100% the marker makes links on white hard to read when using the blue (#0000FF) preselect as seen in the below image.

Other colors likely would pose similar issues for other text. I suspect that is related to the change to 35% (from 50%) that I found from an earlier commit. There was no documentation that I could find on why it was done.

So, to maintain the default UIX, and add the ability to modify the opacity for any tool, I propose an opacity slider (similar to @mmahmoudain's suggestion), with a checkbox to allow custom/global opacity to be set for any tool. (I think we should also need to add the opacity to the hex value, for those that need to lookup the values, or have exact matches for whatever reason, but that is not present in this mock-up). NOTES: I don't like the placeholder label as it is unclear, and it needs tooltips when moused over that would explain what it is. I feel like we should probably specify what tool is currently selected, maybe added to the tooltip to prevent clutter?

This is just a mock up, and I see a couple of ways to do this and maintain the current UIX...

Implement it like the example (use global opacity, T/F). Default is checked for everything but marker. The box would be checked and grayed out if no tool is selected, and would be unchecked and grayed out when changing an existing element.

Implement it in reverse (use custom opacity, T/F). Default is unchecked for everything but marker. Grayed out and unchecked if no tool selected, grayed out and checked if modifying an existing element.

Last idea, and you cannot change it on the fly, but checkboxes in the configuration menu. This could do the same as above but list them out, or specify that a tool should use opacity at all (making the color opacity slider hidden like the text tool's options in the sidepanelwidget). Either method could be setup to allow defaults that mostly maintain the existing UI, but unfortunately it also makes them harder to find and annoying to change. I am only thinking of this for keeping the sidepanelwidget from getting cluttered, but I really don't care for it.

@veracioux also suggested a keyboard shortcut to change opacity on the fly [Alt] + [+] and [Alt] + [-]. I rather like that idea, though also adding [Alt] + [mouse scroll] and maybe [Alt] + [Right click] for a quick preselect so you can see multiple transparency settings on the current document. Not sure how great that would work with global vs custom opacity though.

I have other questions with actual implementation (future proofing), but I'd rather not go down that rabbit hole until this part is locked down more.