need the ability to control the background color of (at least) Entry, Label

[scottmayo]

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

Without this feature I can't sanely port python/tkinter applications that do this freely and with good reason. I know the arguments for Styles and tight control of look and feel - they don't matter in all cases. Sometimes the background simply has to be light green or light red for selected widgets.

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

Probably custom widgets can do this, but it's a great deal of work for something that should be extremely easy in core widget code.

Describe the solution you'd like to see:

SetBackGroundColor(RGBcode) should, on next refresh, redraw the widget as specified. It should trump attempts by Fyne itself to play with backgrounds.

[andydotxyz]

Sorry but the standard widgets don't offer customisation like this - they adhere strictly to the theme. To build a status widget (assuming that's what you are describing) you could use images, coloured circles or a custom widget that replicates what you have done before. Whatever you do ensure that it is readable on the dark and light themes as the theme can be changed by the user.

[scottmayo]

The goal is an Entry field that reports the state of the text being entered. In this app the background is pale yellow if the text has been accepted by the server, pale green if it's different than what the server has but is still legal, pink if it's different and illegal, and so on. Labels get similar treatment; the server can specify a color on the red-yellow-green spectrum depending if the computed value in the label is good news or bad news.

My issue is that supporting the ability to force a background color is likely 2 lines of code per widget for you (is a color forced, ok, use it), but writing a custom widget that formats text and does all the things Entry does is going to be difficult.

You gain nothing by demanding the widgets conform to someone's conception of a Theme. If people want their app that conforms to a Theme, great, they wouldn't call SetBackgroundColor() and they get whatever appearance you deem is correct. But if they have compelling reason to control color, it ought to be available. You must already have a function that computes the appropriate background color; this would amount to adding if w.backGroundColorForced != -1 {return w.backGroundColorForced} as the first line. It seems like a trivial addition with important benefits.

And yes it leads to requests for SetFontColor(), SetCursorColor(), SetShadowColor() and all manner of small related enhancements, but so what? They should all be cheap to implement.

[andydotxyz]

The widget API is purely semantic to assist in enforcing a standard UX experience - if your use-case could be described through a common requirement independent of the rendering specifics it could be considered (like the "primary" button which displays a style variant defined by the theme).

You could extend your entry widget further such that the renderer is tweaked using the following code:

type pinkEntryRenderer struct {
    fyne.WidgetRenderer
}

func (p *pinkEntryRenderer) BackgroundColor() color.Color {
    return color.RGBA{255, 20, 147, 255}
}

func (m *myEntry) CreateRenderer() fyne.WidgetRenderer {
    r := m.Entry.CreateRenderer()
    return &pinkEntryRenderer{r}
}

It may be 10 lines of code, but enables what you want to do without altering the design of our Widget API.

[stephanwesten]

FWIIW; it is pretty frustrating you cannot easily change the background color of a single container for debugging, experimental purposes.

All UI frameworks I know do support this and it is nice when you are learning a new framework to see how the containers are organised.

If you have no plans to support this, I suggest to close this issue.

[Jacalz]

This issue is already closed. I think the case for better debugging is better solved by implementing https://github.com/fyne-io/fyne/issues/3314 and generally better tooling around it.

[andydotxyz]

For debug purposes you can surround a widget with a rectangle, or draw over it by putting some other content over the current with them both in a Max.

This way we don't have to add graphical customisations to a behaviour based API to support debugging.

Of course @Jacalz is right, we have better plans for this in coming releases.

[stephanwesten]

A browser like inspector would be pretty cool.

Perhaps you can make it so that debug mode is default and disabled when creating a production dist. (Still learning, so perhaps this concept is already applied)

[andydotxyz]

Graphical debugging can be costly and so will always be disabled by default. We are considering a "remote" inspector (via IPC or HTTP) which could be on by default. Follow the conversation on the linked ticket.

[lordofscripts]

Although late in the conversation, I must agree with @scottmayo and @stephanwesten on that this is a basic feature on all GUI frameworks out there, something as useful and as simple requires a lot of work and waste of time to accomplish. Sometimes the FG/BG colors are dictated by Functional Requirements. It is no surprise that Fyne hasn't quite been that popular. When I began "going" (I learned GO & Fyne earlier this year), I hadn't paid attention when all this came to life and I was thinking that it was so limited because it hadn't matured yet. Then I learned it had been around for quite some time, so I am surprised that things that are so easy to n other GUI frameworks (I come from .NET but done plenty of others) are just forgotten in Fyne as if development had gone stale. On a personal note, I learned Python a month before GO. It was fun but I hate interpreted languages, that's why I immediately became a fan of GO. Then I had to port my Python+TkInter GUI code because Python's GUI is based on Tcl/Tk which is as old as the Pangea supercontinent, and sadly Tk hadn't evolved a bit and remained ugly and old looking. I chose Fyne because it was closer to GO and hoped it wouldn't go stale, and looks of Fyne are WAY MUCH BETTER than TkInter from Tcl/Tk & Python. But yes, I too, like the OP, constantly run on this basic missing functionality. En fin, just wanted to put my word out on the subject. BTW even the Fyne documentation is so sparse that one must Google around everytime.

[andydotxyz]

Please don't comment on old resolved issues. As demonstrated above status can be indicated with icons etc which are much more context safe and don't have issues of colour blindness or theme change. Our widgets use the standard theme for consistency and a good user experience. Not allowing developers to break them is not a feature missing in the framework, it is our design choice.

[Jacalz]

Just because something doesn't work in Fyne doesn't mean that development is stale or something is forgotten. Please, and please again, remember that this is an open source project almost entirely run by volunteers like myself and many other kind soles who contribute changes. We are a limited team and we can't work on every feature that users want. We have to prioritise between what to work on and it usually, at least for me, lands somewhere in between what I deem most important and what I feel the most motivated to work on. If you are interested in something consider sponsoring work or opening pull requests.

For what it's worth, this will kind of be resolved once https://github.com/fyne-io/fyne/pull/4313lands for the next release.

BTW even the Fyne documentation is so sparse that one must Google around everytime.

I don't think this quite fits in with the discussion here but I really do want to hear you elaborate on this. What is missing? All of our APIs are documented over at https://pkg.go.dev/fyne.io/fyne/v2 and we have a bug development documentation website over at https://developer.fyne.io/.

Like with open source mentioned above. All our websites are open source under the fyne-io organisation as well. Anyone that wants to is more than welcome to contribute to the documentation as well ;)