feat: Embedded graphics assets

[Arcitec]

Hi, I heard about your project from Gradience's goodbye-post, and figured that this was the best time to mention the biggest Gradience limitation:

There was no way to port or create themes that used custom UI artwork in Gradience.

For that reason, talented theme designers were unable to move their themes to the Gradience platform even if they wanted to do it.

Since this project is in the early beginnings, it would be worth considering a simple solution for that:

• Have an "Artwork" tab for the theme designer, where the author can attach files. They are then base64 encoded into the theme JSON file.
• When applying a theme, extract all those graphics files into ~/.config/gtk-4.0/artwork/<filename>. (Or maybe call it /assets/.)
• Allow the author to refer to the custom graphics via the usual way in the CSS: background-image: url("assets/titlebutton-maximize-hover.png");

This would allow authors to port almost any theme to Chameleon! The only exception would be the "fully dynamic" themes with install-scripts that dynamically generate the artwork, but those are rare.

Anyway, I just wanted to let you know early, to avoid the same architecture mistake as Gradience, before you get too far into the design, if this project is something you want to continue growing and evolving. :)

[Arcitec]

For reference, here's what a typical theme looks like when it uses custom graphics. By the talented designer lassekongo:

https://github.com/lassekongo83/adw-colors/blob/main/themes/wandows-ngrmadly/gtk.css

[pixlxip]

I think we can make this work. It is easier to allow room for features this early, yes. How should we do the UI? Maybe in the chooser for the colour, which already will I think have a tab for a gradient, we can have a tab for a background image? Then from that tab in the overlay, you can import an image. I'll mess around with the design to see what will fit. Having separate tabs for basic colours and for images would also work, but I'm not sure about how we could covey that it has to be either a colour or an image. I will consult the other people in the Matrix room, too. (if you'd like to be invited to the Matrix room, just tell me your username on Matrix)

[Arcitec]

Great to hear that it's worth considering this feature.

Well, for the UI, I think it would be best to have a dedicated tab for attaching and managing the files. This is because several different UI elements can be reusing the same artwork file, so it doesn't make sense to do it per-element.

Furthermore, many themes will require the Custom CSS tab to properly apply the artwork to "unusual" places anyway, and they also often use special selectors like :hover to change the background image dynamically, so it makes sense that all artwork is in a single Artwork tab, to make it very easy to see them all and refer to them from the Custom CSS editor.

Your idea about having a "background picker" is good too. It could pop up a window with all the existing attached artwork files for instant selection, and an extra option to either directly "upload" another file, or a button to go to the Artwork tab to add more files, whichever is easier to implement.

One more thing that would simplify theme porting: Being able to drag and drop multiple files from Nautilus into the Artwork tab to attach multiple images would be a godsend for authors porting themes. For example, we can see lassekongo's theme where there's 8 different image files. It would be best to reduce friction for theme authors by letting them drop multiple files at once:

https://github.com/lassekongo83/adw-colors/tree/main/themes/wandows-ngrmadly/assets

I'd be happy to join your Matrix. I'm @arcitec:matrix.org.

[pixlxip]

Sounds good. I have invited you to the Matrix room. The headerbar already has elements, including a text field for changing the theme name, but we could put this tab bar on the bottom of the window, instead. Another worry of mine is that there is a possibility of low contrast. I already plan on adding a warning if contrast between elements is low, and this seems like something that would require a warning, too. This could break things, and that should be communicated clearly to the user.

[Arcitec]

Adding notes from our Matrix discussion:

• Having a basic custom CSS editor. Doesn't have to be fancy. A normal textbox is enough. But if Rust has some nice cargo crate with an auto-completing/auto-indenting editor, that dependency can be considered later.
• And a button above the CSS editor to "insert asset", which adds a background-image: url("assets/<filename>"); CSS command automatically, to make it very easy to insert the custom images where they belong when writing dynamic themes. (You can see examples of that in lassekongo's themes where lots of effects depend on custom CSS).