Utils: add force_elementary_style ()

[cassidyjames]

Turns elementary/calculator#177 into a one-liner.

[danirabbit]

I suppose maybe this should be "force" instead of just "use"?

[cassidyjames]

@danrabbit yeah that's probably fair. I was kind of mixed since force sounds a bit more harsh (and users can always override GTK_THEME because GTK), but I don't feel strongly.

[cassidyjames]

I'm also unsure if I should handle the variant thing here or ignore if for now; I figured it might be nice to consider forcing a specific variant, but if that's too much scope creep, I'm fine dropping it.

[Marukesu]

Maybe we want to manage the notify signal here? with elementary/calculator#177 if i start the program with the elementary stylesheet and change to other theme they will fallback to Adwaita. If i start with Adwaita, the theme is frozen on io.elementary.blueberry ever if i set the theme to any stylesheet theme.

[cassidyjames]

Maybe we want to manage the notify signal here? with elementary/calculator#177 if i start the program with the elementary stylesheet and change to other theme they will fallback to Adwaita. If i start with Adwaita, the theme is frozen on io.elementary.blueberry ever if i set the theme to any stylesheet theme.

I thought about that but honestly supporting changing to/from/between non-elementary stylesheets on the fly is much less of a concern since that's already pretty janky in Flatpak apps to begin with; I mainly want to support the case where you are on elementary OS or at least using the elementary stylesheet (so we don't change anything and just use the stylesheet as-is) or are not on elementary stylesheet so we just force a specific one.

I think this PR does the least amount of work to get that working satisfactorily.

[cassidyjames]

I do wonder if it makes sense to check this against a list of valid variants instead of just allowing any arbitrary string; maybe we accept a Granite.Settings.AccentColor instead of a string? Again, I'm also happy to split that off into its own branch if it is creeping too much scope here. Maybe we just start without any params.

[Marukesu]

I do wonder if it makes sense to check this against a list of valid variants instead of just allowing any arbitrary string; maybe we accept a Granite.Settings.AccentColor instead of a string? Again, I'm also happy to split that off into its own branch if it is creeping too much scope here. Maybe we just start without any params.

I don't think setting a variant here is necessary now, apps that use fixed accent are already doing it with Gtk.StyleContext and a custom css file.

[cassidyjames]

@Marukesu yep that was my conclusion as well; I've removed that from this branch.

[alice-mkh]

If it's "force", I'd expect it to also track changes and not be a one-time thing. :)

[cassidyjames]

@Exalm I mean, see the previous comments in that vein. I was going to prefer use but realized that on elementary OS, that's already the assumption, so force or something does make sense. I'm open to suggestions or improvements to track changes here but honestly I don't want to turn this into a bikeshed. Further improvements can follow in future PRs.

[alice-mkh]

Not bikeshed at all, what I mean is it can track changes as well instead of being a one-time thing. :)

[danirabbit]

Code looks good and works as intended afaict. Nice job :)