Add Nameable and Linkable object interfaces with map of contained objects

[mmaFR]

Description:

That allows:

• to reach a parent object from a given object as long as the objects honor the fyne.LinkableObject interface.
• to set an ID on a given object as long as the object honors the fyne.NameableObject interface.
• lookup for an object embedded in a container by its ID.

For example, this allows 2 button objects to interact together without having to reference them directly in the button functions. Now you can call the parent object map to get access to an object in the same container. If your target is in another container, you can navigate to it (with the Parent() and LinkedObject() methods).
This could be useful when you add objects to your UI dynamically, especially when these objects should interact together.

Checklist:

• Tests included.
• Lint and formatter run with no errors.
• Tests all pass.

[andydotxyz]

I can see why you might want this functionality but it basically breaks the encapsulation of widgets in the system. They should work in complete isolation with only your app bringing their behaviour together.
Also looking up an object by string id returns an any which basically removes all type safety we have tried to bake in.

If you want two different widgets to interact in some cohesive unit perhaps what you need/want is a custom widget that wraps the two with a clean public API around that?

[mmaFR]

I don't get the purpose of the "complete isolation" of the widgets. I mean it could be useful to be able to access a given widgets from another one. However if it would be against the lib design, so be it.
I don't see how a custom widget could help me here. I recently discover your lib, I very likely missing some point.
I guess that the most simple option to me at the moment would be to build the object tree externally.
Thanks for your great library.

[andydotxyz]

I don't see how a custom widget could help me here.

Well, reading between the lines from your original message it sounds like some sort of toggle buttons:

For example, this allows 2 button objects to interact together without having to reference them directly in the button functions.

In which case a widget called ToggleButton where the public state API is about switching states instead of about tapping two different buttons.

I don't get the purpose of the "complete isolation" of the widgets.

A widget should work in complete isolation to the application running. That is required for unit testing and for the re-usability of components. If the two widgets you want to interact with each other are part of the same data manipulation then it should be a custom widget, if they relate to each other through the application only then they should be managed at that level.

[mmaFR]

Thanks Andy for your answers and suggestions.
Your answer about isolation definitely pushes me to handle this externally.
I actually remembered when I was writing a GUI with a tool where each part of the GUI was more or less linked to the others. And I was trying to get more or less the same thing here.
Now I realize that your library is based on a very different design, so I'll try to use it as is instead of trying to tweak it to get what I want.

[andydotxyz]

Now I realize that your library is based on a very different design, so I'll try to use it as is instead of trying to tweak it to get what I want.

Cool. Be sure to ask questions of check out the tutorials if you're not sure how - remember we are all over Slack, Discord and Matrix too ;)