[History] Some effect icons don't look as good on dark mode

[pedropaulosuzuki]

Description
While many icons work great for both light and dark themes, some don't translate that well. Many would benefit heavily from a symbolic variant (maybe with some colors to help differentiate between them, as suggested on #555). Here are some examples of problematic icons on dark mode:

Additional context
Light mode: icons look good

Dark mode: some icons lose clarity or some elements get hard to see

[pedropaulosuzuki]

@yioannides, maybe some of those could be a starting point from what we talked about in #555. These icons have a lot of character, and only using a single color would probably take that away. But we could also somewhat keep the current design and only create a dark-theme variant of those. I'd also like to see @cameronwhite's view on this.

[cameronwhite]

Yeah a bunch of the old png icons were never changed over to symbolic SVG icons. I think these were lower priority since they only appear in the history panel now ( previously they also appeared next to menu items, before GTK removed that feature )

If we are changing them, my vote would be to make them consistent with the rest of the symbolic icons we're using throughout the UI now. They could be good to experiment with for the coloured symbolic icons that were being discussed, but again these would maybe lower priority since they're not visible super often

[pedropaulosuzuki]

Yeah a bunch of the old png icons were never changed over to symbolic SVG icons. I think these were lower priority since they only appear in the history panel now ( previously they also appeared next to menu items, before GTK removed that feature )

If we are changing them, my vote would be to make them consistent with the rest of the symbolic icons we're using throughout the UI now. They could be good to experiment with for the coloured symbolic icons that were being discussed, but again these would maybe lower priority since they're not visible super often

I'm currently doing some work to port some things to Gtk.Dropdown, though I'm having a hard time with some details. I think we can bring those icons back to the menu, like this (from my unfinished patch for #1977):

[cameronwhite]

Just to clarify I was referring to icons in regular GTK menus (like the screenshot below), which is separate from the combobox / dropdown widgets. Those changes to the widget look great so far though!

[pedropaulosuzuki]

Just to clarify I was referring to icons in regular GTK menus (like the screenshot below), which is separate from the combobox / dropdown widgets. Those changes to the widget look great so far though!

Yes, I know! I meant we could probably do something similar, as the check icon was something custom I added, not something that comes with Gtk.Dropdown when you add custom ListItemFactory. (And it's bugged at the moment, as hovering a ListItem triggers the 'selected' state for some reason, also the events fire even on setup, not just on click. I'll really need some help with those things).

[cameronwhite]

cool! If you want to upload a draft PR at some point I could try having a look at those issues

[pedropaulosuzuki]

cool! If you want to upload a draft PR at some point I could try having a look at those issues

@cameronwhite I believe I solved everything by now, but if you would like to take a look, it's MR #2092!

[yioannides]

maybe some of those could be a starting point from what we talked about in #555

I think these need to be vectorized first (I'll redo all of these eventually), but regarding colorization, since a lot of these icons contain colors beyond what's discussed in #555 (as in, colors that are not defined by the system or user), we have three options:

1. we draw colors straight from the libadwaita color palette itself and automate this process with whatever colors come from upstream (for both light and dark mode) with color variable tags for each color (eg. icons like Red Eye Removal get --red-1 for accent, icons with a green Plus in the bottom-right get --green-1 etc)
2. we let the user choose their own accent color, as well as red, green, blue (for people with color vision deficiencies, like @pedropaulosuzuki suggested, but it might add future technical debt / feature bloat)
3. we stick to the original plan and only use the one color defined by either the system or user and work around it

[pedropaulosuzuki]

maybe some of those could be a starting point from what we talked about in #555

I think these need to be vectorized first (I'll redo all of these eventually), but regarding colorization, since a lot of these icons contain colors beyond what's discussed in #555 (as in, colors that are not defined by the system or user), we have three options:

1. we draw colors straight from the [libadwaita color palette](https://gitlab.gnome.org/GNOME/libadwaita/-/blob/main/src/stylesheet/_palette.scss) itself and automate this process with whatever colors come from upstream (for both light and dark mode) with color variable tags for each color (eg. icons like `Red Eye Removal` get `--red-1` for accent, icons with a green Plus in the bottom-right get `--green-1` etc)

2. we let the user choose their own accent color, as well as red, green, blue (for people with color vision deficiencies, like [@pedropaulosuzuki](https://github.com/pedropaulosuzuki) suggested, but it might add future technical debt / feature bloat)

3. we stick to the original plan and only use the one color defined by either the system or user and work around it

I'd say we go with 1. We could use the accent color when some icon is color-agnostic, such as a somewhat transparent filled circle or bézier handles, but better to use fixed colors when there's more than one color involved or if the context requires certain specific colors, such as in the red eyes example you brought up.

[yioannides]

I'd say we go with 1

I agree. The GNOME palette is very accommodating, as is. When the time comes, would you mind compiling a list of all the scalable icons we need to vectorize, so we can keep better track?

[pedropaulosuzuki]

I'd say we go with 1

I agree. The GNOME palette is very accommodating, as is. When the time comes, would you mind compiling a list of all the scalable icons we need to vectorize, so we can keep better track?

I'd say we can start with these 7 icons, which are the worst offenders, and then we can see about the rest later.

Either way, here is the full list of 16x16 icons in Pinta.Resources/icons/hicolor/16x16/actions (this includes even icons that are not effects/adjustments, some of which I don't know if are even used anywhere, such as help-bug.png.

addins-manage.png
adjustments-autolevel.png
adjustments-blackandwhite.png
adjustments-curves.png
adjustments-huesaturation.png
adjustments-invertcolors.png
adjustments-levels.png
adjustments-posterize.png
adjustments-sepia.png
edit-selection-erase.png
edit-selection-fill.png
edit-selection-invert.png
edit-selection-offset.png
effects-artistic-inksketch.png
effects-artistic-oilpainting.png
effects-artistic-pencilsketch.png
effects-blurs-fragment.png
effects-blurs-gaussianblur.png
effects-blurs-motionblur.png
effects-blurs-radialblur.png
effects-blurs-unfocus.png
effects-blurs-zoomblur.png
effects-color-dithering.png
effects-distort-bulge.png
effects-distort-dents.png
effects-distort-frostedglass.png
effects-distort-pixelate.png
effects-distort-polarinversion.png
effects-distort-tile.png
effects-distort-twist.png
effects-noise-addnoise.png
effects-noise-median.png
effects-noise-reducenoise.png
effects-photo-glow.png
effects-photo-redeyeremove.png
effects-photo-sharpen.png
effects-photo-softenportrait.png
effects-photo-vignette.png
effects-render-cells.png
effects-render-clouds.png
effects-render-juliafractal.png
effects-render-mandelbrotfractal.png
effects-render-voronoidiagram.png
effects-stylize-edgedetect.png
effects-stylize-emboss.png
effects-stylize-outline.png
effects-stylize-relief.png
help-bug.png
help-translate.png
image-flatten.png
image-resize-canvas.png
image-resize.png
layer-import.png
view-grid.png
view-rulers.png
view-zoom-100.png
view-zoom-selection.png
view-zoom-window.png

[yioannides]

Alright, if I'm home tomorrow, I might start working on these.

I will color these manually for now, but as I previously mentioned in #555 (comment), I'm not sure how we'll be able to separate colored icons from non-colored ones for the icon colorization backend, but it might be better to eventually move all plain symbolic icons onto a new symbolic folder regardless and maybe have the scalable folder for the multi-colored symbolic icons, as well as the left toolbar icons that will pick up on either the system or user accent color. If you have any other ideas in the meantime, please let me know.

[pedropaulosuzuki]

Alright, if I'm home tomorrow, I might start working on these.

Awesome!

I will color these manually for now, but as I previously mentioned in #555 (comment), I'm not sure how we'll be able to separate colored icons from non-colored ones for the icon colorization backend, but it might be better to eventually move all plain symbolic icons onto a new symbolic folder regardless and maybe have the scalable folder for the multi-colored symbolic icons, as well as the left toolbar icons that will pick up on either the system or user accent color. If you have any other ideas in the meantime, please let me know.

Seems like a good folder structure to me!