Internal support for custom colored fyne.Resource theming. about fyne HOT 10 OPEN

I do not want to change the theme. Or I should say, there might be cases in which it is not desired.
For example, the user selects a color from a color picker which changes the color of an svg resource to the picked color.

But yes, it can definitely make it ugly when the theme changes, but in this regard it doesn't matter.

from fyne.

You can already do this by going through the Theme system.
The ThemedResource accepts a ColorName which is looked up in your theme.

If you manually specify the custom colour directly then any theme change will potentially make it unreadable or ugly, which is why the theme system makes consistent use of standard colours.

from fyne.

I guess this opens up the question of whether this is related to the theme, the toolkit, or your app?

Use-case is important here so we know what API is expected or where to place it.
If this is not related to theme (as you seem to indicate) then it doesn't belong in the theme package - right?

from fyne.

Yes you are right, it is not necessarily related to theme package.

Maybe something like this can be added to the resource.go file:

// Maybe a ColoredStaticResource struct should be returned which also stores the color
func NewColoredStaticResource(res Resource, color color.Color) *StaticResource {
	arr := svg.Colorize(res.Content(), color)
	ret := NewStaticResource(res.Name(), arr)
	return ret
}

The reason I am addressing this is mainly because the svg package is an internal fyne package so I cannot simply create this function (let's say as a utility function) without copying the code of the svg package into my application.

from fyne.

This is one thing that would be solved by having the builtin theme be able to accept HTML-style #RRGGBB[AA] strings as color names in addition to the standard named theme colors that we briefly discussed in the last contributor call @andydotxyz

from fyne.

It could be solved that way, but I don't see a problem exposing access to our Colorise functionality in the meantime. I'm not sure if it belongs at top level, in the canvas package or elsewhere though.
If it is to be top level then the API and/or doc should be specific about this being for SVG files etc.

from fyne.

I don't think it would go in the top-level package. Maybe canvas - canvas.ColorizeSVG?

from fyne.

I agree with exposing the svg package which includes the Colorize functionality. Maybe I would just place the svg package outside of internal so everything stays the same (except the fact it is exposed), but it's up to you to decide based on the fyne development philosophy.
(Maybe it would worth reiterating some other packages, because I can see that there are some useful generic/utility/helper packages which might come handy for other developers, but this is off topic for this Issue.)

The second thing to decide is to create (or not) new initialization functions in:

• fyne/resource.go -> NewColorizedStaticResource(name string, content []byte, color color.Color)
• fyne/widget/icon.go -> NewColorizedIcon(res fyne.Resource, color color.Color)

Which would help users to easily create colored icons/resources.

I would definitely do the svg package exposure, because it does not complicate project maintenance.
Although the second idea introduces new code and functionality, this might be a neat addition as well.

from fyne.

There has to be a really good reason to introduce a new public package name, and I don't think the svg.Colorize is a big enough candidate to do so. I think we'll need to find a sensible place in one of the existing packages.

The second thing you mention would be superseded by having the builtin theme support color hex strings color names, which I think is a quite important thing anyway to unlock full functionality of the RichText widget (right now having arbitrary colored text that supports wrapping, and all the other RichText niceties is impossible). So we'll hold off on that one perhaps.

from fyne.

I don't think it would go in the top-level package. Maybe canvas - canvas.ColorizeSVG?

Sounds good

I agree with exposing the svg package which includes the Colorize functionality

As @dweymouth says that is a huge change for a single function - there are already more than enough packages - every one added makes it harder to learn the toolkit.

fyne/widget/icon.go -> NewColorizedIcon(res fyne.Resource, color color.Color)

No to this one, the widgets follow the theme and so you should not create a widget with a static colour. It will not update if user changes theme and could become unreadable by mistake.
I'm similarly tempted to say no to the other as well - if you want to pass it in as a static coloration then you can colorise it and then pass it to NewStaticResource. Implying the resource will be colourised could suggest changes over time which is not included when you are outside the theme/widget context.

from fyne.