Making Writing Good Fyne Code More Accessible

[xypwn]

Checklist

• I have searched the issue tracker for open issues that relate to the same feature, before opening a new one.
• This issue only relates to a single feature. I will open new issues for any other features.

Is your feature request related to a problem?

Fyne makes it very easy to get started with UI programming, and the open community allows for everyone to share their code to everyone else's benefit. Fyne-x is just one place where a curated collection of community content is gathered.

However, I've noticed that many of the community widgets are poorly implemented, or lack certain standard features. One particular feature that often goes overlooked is extensibility, which even many fyne-x widgets don't fully support. I don't think this is out of lazyness, but simply due to the inaccessibility of proper guidelines and/or lack of any systems to check if the code conforms to fyne standards. Personally, I had to look at the source code to get an idea of how to implement extensible widgets properly. There should at a minimum be documentation!

I think the community aspect and ease of use is one of fyne's biggest strengths, but to get the maximum out of these qualities, there should be a simple way to ensure at least some level of quality and modularity.

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

No response

Describe the solution you'd like to see.

There must be clearly written standards with examples describing how widgets or other fyne extensions should be implemented.

Humans always make mistakes, and Go is a perfect language for building a simple static analyzer (https://pkg.go.dev/golang.org/x/tools/go/analysis). This analyzer could check, among other things, that all of the general initialization logic is done in ExtendBaseWidget, so extensibility is guaranteed.

---

Keep in mind that this proposal is not yet fully thought out, and we will have much to discuss. Feel free to drop in any constructive criticism of the suggestions.

[andydotxyz]

It sounds like this is specific to fyne-x and not the main toolkit, should the issue be in that repo?

[xypwn]

It sounds like this is specific to fyne-x and not the main toolkit, should the issue be in that repo?

The discussed problem and proposed solutions are on a level relating to the whole fyne project. It may be required to branch this issue out to some of the other subprojects, but the main fyne project seemed like a good starting point to me.

Additionally, I mentioned that fyne-x was just one of many projects that are affected by this issue.

[andydotxyz]

This seems like a documentation issue, so moving