Add data binding support to Select

[Bluebugs]

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

Currently widget.Select doesn't have support for data binding. Would be nice to have.

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

No API available for this.

Describe the solution you'd like to see:

I can see the following:

func NewSelectWithData(options []string, data binding.String) *Select
func NewSelectWithDataOption(options binding.StringList, data binding.String) *Select

func (s *Select) Bind(data binding.String)
func (s *Select) Unbind()
func (s *Select) BindOptions(options binding.StringList)
func (s *Select) UnbindOptions()

[andydotxyz]

Yes, adding the String bind for the main data matches our current APIs. Binding the options, however, is a step beyond what we have done elsewhere.

[Bluebugs]

Binding options would be a very useful/expected use case when connecting to databases. It would be good to figure out the right pattern for it.

[andydotxyz]

As mentioned in another issue it's outside the current scope of the binding implementation. If it is something to enable database features we probably need to work through the use-case and confirm that it (and the wider "bind everything" discussion) is worth including in core. Probably worth considering that, as it can be done in user-space, it could be done in fyne-x to keep the main APIs lean.

[mbnoimi]

As mentioned in another issue it's outside the current scope of the binding implementation. it could be done in fyne-x to keep the main APIs lean.

Why this is out of the scope?! binding.StringList already exists

what's making it -unlean- by implementing widget.NewSelectWithData ?!

[andydotxyz]

Because the data of a Select is it's selected String. Therefore to match our usage for entry etc the NewSelectWithData would bind to binding.String not the options item as binding.StringList.

[jimorc]

I have attempted to create a BoundSelect widget (in fyne-x) which binds both the Selected and Options fields by basing it on the Select widget (copying and modifying functionality). There are a number of properties and functions used in the SelectRenderer Refresh function that are internal to fyne and therefore unavailable to any widget in fyne-x. These are:

• BaseWidget.propertyLock, defined in widget.go
• BaseWidget.super() also defined in widget.go
• alignment property for PopUpMenu, defined in the Menu struct in menu.go

To continue on this development, it appears that the most direct way would be to externalize each of these (i.e. make them part of the external API). A lot of work, but could possibly make it a lot easier to develop future widgets in fyne-x.

Is this the right approach, or am I completely off base?

[andydotxyz]

The propertyLock is something we are working on. We are not going to expose it because there is a better solution coming in 2.6. You should not need to access super() as that is used only in core widgets for internal purposes - do you know why you need it?

For alignment - why would a bind select have a different alignment to a select?

I suspect that what you are reporting is due to extracting core code and modifying it instead of extending an existing widget in the way that the API is designed for?

[jimorc]

As I mentioned, I did a lot of copying of Select widget code, which appears to be entirely the wrong approach. I will try a different method. I tried this because go does not directly support inheritance, so I thought it would be necessary to duplicate the Select widget code.

[andydotxyz]

Go's embedding of structs is essentially inheritance - just not with all of the OOP implications.

https://docs.fyne.io/extend/extending-widgets