Move to fs.FS and embed package from standard library

[Ju-B]

Hi,

Is there work in progress to move toward pakage embed from the standard library?
Is there a technical reason why or pitfall that should be avoided for someone to start make this move?

Kr,

Julien

[andydotxyz]

We are not working on that because Fyne still supports back to Go 1.14.
This is because compiler 1.15 removed support for 32bit iOS devices, which we still support.
Additionally we won't move to greater than 1.15 until the latest version of all popular desktop OS have newer Go versions available by default. This won't happen until Debian releases bookwork, their current testing release.

[andydotxyz]

Is there work in progress to move toward pakage embed from the standard library?

Additionally I would ask, what is the benefit of that package?
The current Fyne bundling creates static resources automatically, so we'd have to do some wrapping to make the embed system as helpful.

[Ju-B]

Benefit for me is consistency and fallback capability.

My requierement is that i'd like a single file to distribute.

Current fyne implementation do not allow me to use/share/hook into the fyne ressources loading.
(also i rely on 'you' to run the ressources embeding)
This blocks me when i triy to use the theme.json with embeded ressources.

I wrote a small implementation of interface fs.FS using embed.FS and os.DirFS as fallback to provide defaults for my application.
So i'm now able to use a the theme.json equivalent

Thanks for the replies(i wasn't aware of the will for the 'long time support'), that was the kind of answers i hopped to receive before coding/submiting a pull request.

[andydotxyz]

My requierement is that i'd like a single file to distribute.

Yes, we do that by design - that is why "fyne bundle" existed before the embedding in Go https://developer.fyne.io/extend/bundle.

Current fyne implementation do not allow me to use/share/hook into the fyne ressources loading.

That's not the case - you can load any resource you want. You can even override the theme icons with a custom theme if you desire.

This blocks me when i triy to use the theme.json with embeded ressources.

Right, there may be an issue with JSON based theme definition as I don't think we found a way to reference a program variable instead of a URI for external file. I would be very happy to see that added - perhaps a repository that provides resource lookup, so something like "resource://myIconResource" could be interpreted through reflection to use a variable in memory perhaps?