Custom theme variants in widgets

[AndrusGerman]

Is your feature request related to a problem? Please describe:

I find it too verbose to work on the color customization of some widgets. And having a simple way to send values of a theme variant in a widget makes the job more comfortable.

Is it possible to construct a solution with the existing API?

No need to modify current api, the possibility of passing a variant can be added in the 'theme' package. If the widget contains the parameter 'variant' it will send it and if it has a value it will be used, if it has no value or it is not sent it will continue to work as usual

package theme // fyne-io/fyne/theme


// Example of a function to get the color
func InputBackgroundColor(variant ...uint) color.Color {
	return current().Color(ColorNameInputBackground, getVariant(variant...))
}

// Get a custom variant or the default
func getVariant(variant ...uint) fyne.ThemeVariant {
	if len(variant) != 0 && variant[0] != 0 {
		return fyne.ThemeVariant(variant[0])
	}
	return currentVariant()
}

Describe the solution you'd like to see:

I propose to implement optional variables to widgets to receive custom themes

'Variant' is a variable type 'uint', in this way from the themes the customization could be extended by the user choosing how to handle its multiple variants. And since they are optional values the custom theme api can be preserved and will continue as usual

Sorry if I don't express myself correctly (English is not my main language), I am willing to answer any questions. The screenshots are from a fork I'm working on

I'm working on this, maybe it exists and I didn't realize it. If it is something that is desired in the project I can send a push request, I am willing to read all the details to do this

[andydotxyz]

The variant in a theme is user-customisation related (light / dark for now, high contrast etc to be added in the future.

The whole API is based on semantic meaning, you can see how Primary has been implemented already to show a button that is the main action of a form/dialog etc.

What is not clear to me is what the user will understand as a "tertiary" button... In a recent change the Success and Warning colours were added alongside Primary and Error, so these are in the theme now.

Bear in mind that all standard widgets are transparent, so you can draw whatever colour under the button that you want.

[andydotxyz]

This is probably a duplicate of #255

[AndrusGerman]

@andydotxyz

I had no idea widgets were transparent, this helps in customization of simple widgets <3

As far as implementing a 'tertiary' color is not really what I'd like to see

The main idea is not to get locked into just 2 or 3 main colors in a theme. Widgets have some way to force a theme variant or even receive a totally different theme

what I wrote as 'Primary, secondary, tertiary', is what here would be a 'theme light, theme dark, my custom other theme' for one unique widget.

My proposal to extend the customization: is to add a function to the widgets to force a theme independent of the application (and this will be applied to its children)

	list1 := widget.NewSelect(
		data,
		func(s string) {

		})
	list1.CustomTheme(Dark)

	list2 := widget.NewSelect(
		data,
		func(s string) {})

	list2.CustomTheme(Light)


	list3 := widget.NewSelect(
		data,
		func(s string) {

		})
	list3.CustomTheme(VeryRed)

This will allow us to independently customize any external widget without the need to modify the main theme.

I could perfectly change the primary and secondary color of a widget.Select without altering the others of my application Oh even import a widget from some community user and with this new api, I could change its colors without writing so much code (creating a new theme for that widget which could be reused in other parts of the app)

[andydotxyz]

I see what you mean, however the standard widgets are designed for consistency and to respect the theme that is loaded. Consistency in UX is what we have aimed for. So if there is some use-case that the current API misses we should add it, but so far our concern is that by applying themes for individual widgets the user graphical hint that make a clear experience could be quickly confused.

[AndrusGerman]

@andydotxyz I understand that consistency is an important thing, this doesn't seem like a short term goal. But it seems like a desirable feature in the future, Could it be something that is implemented in version 3? with a little clearer idea of this, it's something I wouldn't mind working on in the future or in a branch

[andydotxyz]

I guess it would be worth looking back for previous requests for this feature (in GitHub) you can see the arguments for or against. If you think it should be worked on then I would recommend you consider a proposal for discussion to see what others feel about any proposed approach, that would get more specific feedback than the general concept https://github.com/fyne-io/fyne/wiki/Contributing:-Proposals

[AndrusGerman]

Now I understand that I have to upload it to the proposals repo, should I close this when I receive a negative response or at the end of a possible integration, or just close it since it is a proposal?

[andydotxyz]

You can keep this open to track - the important thing is to link the proposal PR to this issue so we can connect the progression.