Remove Fluent-Dark and Fluent-Light themes, add Fluent theme

[fredcw]

Remove Fluent-Dark and Fluent-Light themes and replace with Fluent theme which is configurable.

[rcalixte]

This is extremely tough on my browser to review but I'm almost through. Is there an easier way to present the options to users? I understand the flexibility that the scripts offer but for the average user, they expect a theme to be usable after downloading it via the built-in module. Adding an extra step to that process will leave more people thinking that the theme doesn't work rather than looking for a README. It's a departure from the standard convention. I see how having the option scripts mean there won't need to be a virtual infinite number of themes in the repository/site but the tradeoff seems steep right now.

[fredcw]

Yeah, it froze chrome for me as well. Maybe I should have done separate PRs?

they expect a theme to be usable after downloading it via the built-in module

The theme is usable straight away. It is the standard version of the theme by default. The options.py program modifies theme "in place". Actually, I guess I should mention the options.py in the description in info.json, I forgot about that. I'll do that in another PR. But in any case, the theme works as is without using the options program.

[fredcw]

I can't think of an easier way to present the options to the user. If you have any ideas, I'd love to hear them. The only way I can think of involves changes to the themes module in cinnamon settings. In fact, that's kinda the plan. The themes module could search in the current theme for the file: /config/config_gui.py and if present, could display an "options" button that would run the program.

[rcalixte]

I can't think of an easier way to present the options to the user. If you have any ideas, I'd love to hear them. The only way I can think of involves changes to the themes module in cinnamon settings. In fact, that's kinda the plan. The themes module could search in the current theme for the file: /config/config_gui.py and if present, could display an "options" button that would run the program.

Something like this is what I'm thinking too. I think a JSON settings file might be easier here, just like applets, desklets, and extensions but we'll also need some common interface too, just like applet.js, desklet.js, and extension.js. It's a bit more work and we probably need to brainstorm around an implementation but having a structure in place that themes can make use of would be pretty awesome. Something like the recently added styles.

One thing to think about is how to handle the changes in place. In X, a Cinnamon restart will work but should that be left to the user to execute? Again, there's precedent here of things being applied immediately which isn't immediately possible if the theme files are modified. Then there's the question of how this would work on the current Wayland implementation that doesn't support restarting Cinnamon (yet?).

It feels like we're in agreement about wanting some form of this feature. 😅

I don't know what should be done about this PR (I want to see feedback from the team and others first) but I think that implementing something proper in the Themes module is the best user experience in the end and hopefully it can be done in a simple way for developers to implement in themes too. (I'm thinking of the Actions module that was just rolled out recently.)

If we can agree on how it should look, we can try to implement it sooner than later. I'm not speaking for the team here, but if we can at least get the changes on master in a reasonable enough time-frame, hopefully you can work your magic on a few themes to start with and we can have something for the next release. Maybe I'm being too ambitious but I think it's a good enough idea to invest some time into.

[fredcw]

Yes, there is one major hurdle to overcome, how to reload the window manager theme (window decorations) after a theme has been modified. Reloading the gtk and cinnamon themes is easy enough though. The solution I came up with in this PR is to rename the theme after each modification so as to force the WM to reload it. But I don't think this is a practical solution if it's going to be integrated into cinnamon settings. I also don't think that automatically restarting Cinnamon after each options change is practical either. The only other alternative is to notify the user that they'll need to restart cinnamon to see all changes take effect - also not ideal.

As for a standard JSON file, I've already included this in this PR: /config/options_config.json This idea is that this file will contain a description of all the options available in the theme and which DE's these options apply to. These options would then be presented to the user and then on an "apply" button being pressed, the options would be passed as parameters to the install script which would modify the theme. I think that it should also be a requirement that this install script should have no dependencies other than what would be expected on any GTK based distro. Btw, if some standard is to be written, please consider the current json file a first draft as I think perhaps some of the fields could be better named.

The choice in cinnamon is either to create its own GUI to this json file or to import as a module and run /config/config_gui.py which basically does the same.

I also separated out the code that reloads the theme in the OS into /options.py (which in turn imports /config/config_gui.py) because I wanted to ensure some future compatibility with older configurable themes should an OS change the method in which it reloads the theme in the future, i.e. the OS would implement it's own version of options.py and import config_gui.py from the theme.

btw, in options.py, I've included code to reload the theme if run in other DE's like GNOME, xfce, MATE, etc. I think that if theme designers are to see this as worth implementing, it would have to be usable on all GTK based DEs rather than just Cinnamon.

[rcalixte]

Right, I was referencing some of what is already here. What I mean is a standard/schema that would be consistent. For settings, we would probably want to use the existing settings-schema.json structure, etc. etc. I think we should also implement something like a tagging feature so that developers could identify which aspects a theme provides among the Applications and Desktop categories.

btw, in options.py, I've included code to reload the theme if run in other DE's like GNOME, xfce, MATE, etc. I think that if theme designers are to see this as worth implementing, it would have to be usable on all GTK based DEs rather than just Cinnamon.

I think it depends on how we implement it. Ideally, it would be something close to plug-and-play but the structure might also only matter for inclusion into this repository. Removing the barrier to this functionality and implementing it natively within Cinnamon would mean those themes could be added to the repository via a series of pull requests, just like what you're doing here.

[fredcw]

Another idea I had was that if we can find a way to reload the WM window decorations theme then this could also be implemented for the Mint-Y and Mint-X themes so that that instead of having all the color variations listed in the themes settings, we could have just one Mint-Y theme and an options button available when it's selected.

[fredcw]

we would probably want to use the existing settings-schema.json structure, etc. etc

I don't think that this is something we should make cinnamon specific because I don't think that theme designers would see it as something worthwhile in this case. It's not just a matter of uploading it to cinnamon spices, it's a matter creating a self modifying theme and all the work that that involves. Unless this is going to be adopted by gtk theme designers generally then I don't think it's worth bothering with just for a few (probably unpopular) cinnamon specific themes uploaded to the repository As for people modifying existing themes to make them self modifying only for cinnamon, sure that's possible but it's a lot of work that would only benefit cinnamon and I certainly won't be able to find time to start modifying and uploading lots of themes. I think we have to rely on theme designers implementing this and that means making it DE agnostic.

tagging feature so that developers could identify which aspects a theme provides among the Applications and Desktop categories.

Yes, this is something that can be added to options_config.json. Currently, I've just considered them as together under "Cinnamon"

those themes could be added to the repository via a series of pull requests

I think to be worthwhile, we can't rely only on themes being uploaded to the repository. This would have to be something where people could also download such "self- modifying" themes from the internet and put them in ~/.themes themselves. We shouldn't be thinking only about what benefits cinnamon. I think we need to think more about what benefits the linux ecosystem and interoperability between DEs/distros and avoiding separation/fragmentation between DEs.

[fredcw]

Also, I don't see any reason why this PR can't be merged as is. It's just a theme with an optional config script added to it. There are already such themes with config scripts in the repository such as Adapta-Nokto and the Cinnamox themes.

[rcalixte]

Also, I don't see any reason why this PR can't be merged as is. It's just a theme with an optional config script added to it. There are already such themes with config scripts in the repository such as Adapta-Nokto and the Cinnamox themes.

I wasn't aware. I'll go ahead and merge this then. We can revisit this another time.