Extract backgrounds and modules to other repos for reusability

[andydotxyz]

I am considering (and looking for feedback on) creating two new repos extracted from fynedesk.

• backgrounds - our standard backgrounds, with a little Go code to help manage them - and in future to discover others installed
• modules - things like battery, brightness etc that could be used in other apps (fin would like to show a subset of the fynedesk widget panel)

This would allow more consistency and code sharing between apps doing desktop-y things.
The backgrounds could bundle lots, or with tags provide a minimal setup - this would allow apps built for FyneDesk (or other well configured platforms) to bundle less in the UI if we know what is on the filesystem instead.

[taigrr]

This would really help out one of the major issues I had before -- large 'codebases' which are actually just images in text format. My ide would sometimes choke on the large variables when using autocomplete. I still think the end solution should be using go embed, but debian hasn't shipped that version of go yet, so this is a great mitigating step!

Would you expose the backgrounds directly as exported []byte variables or as io.Reader interfaces? And would you use a subpackage per 'set' of assets to allow tree-shaking/smaller imports (only compile in the byte arrays actually in use)?

[andydotxyz]

I had not thought about how the data would be exposed yet. The byte[] or Resource would have been the obvious choice initially - but to support external files that doesn't make sense any more. The Reader is an idea, but when you want a byte[] from one in memory then Reader is an indirection we could avoid.
Perhaps returning *canvas.Image would be interesting, but then we cannot simply set it on an existing image.
Hmm

Funnily enough, I was actually going to propose a separate repo to throw in all my backgrounds in -- when I dropped the at least 8 more 'sets' of lite/dark variants on the way. lol

The background question is a surprisingly tough one, because at least with my intentions (which I probably need to layout in a formal-issue at some point) -- think we should shoot for default backgrounds to approximate what I've been calling "adaptive wallpapers". So like the active Fynedesk theme sets a primary color, and basically it shifts a wallpaper's various hues based on it. This is def a feature that'd only work well with simple / abstract / "material" styled wallpapers, still I think it's a lot of value added.

Recently I've been moving all said wallpapers from a massive shared 4k .xcf (Gimp file) to a bunch of svgs & at this point think they'll just "eventually" end up as a bunch of canvas code https://github.com/tdewolff/canvas -- which would open some interesting possibilities (like off the top of my head, simple animations, randomly generated patterns, etc, etc).

But yeah, TLDR: I guess what I'm saying is I'm fully for chunking these out; But I'm also not imagining 'backgrounds' in the same way as other desktops do them and maybe ultimately if this idea I have becomes more formalized it'd be worth separating them again from any traditional wallpapers Fynedesk might pick up in the interim.

[andydotxyz]

Backgrounds repo created with some very basic code and the existing backgrounds added https://github.com/FyshOS/backgrounds/.

I went with CanvasObject as being the thing returned rather than []byte or Reader as that is what we want ;). Might need to consider coding in some "Thumbnail" code for efficiency in the future.