Simulating hyperlinks in TextView, looks like 20 minutes problem, in and out.
So two days later, after combing through docs, sources, and yes, getting enlightenment from discourse I now know that “there is no color”, and some theme out there could color row of LinkButtons like rainbow.
Practically though no one would unironically use such theme day to day. And I expect any adequate theme to reasonably define link color.
But overall current styling-theming approach looks like this:
if your app doesn’t mention any concrete color anywhere, it’s theme author’s job to make sure your app looks good in it
the moment you set your first color value it’s your job to make sure your app looks good in every theme
My initial question now transformed into one about GTK theming design:
Is this the best GTK can offer? Wouldn’t it be better to have some basic contract with theme at least in terms of colors (primary/secondary fg/bg, like ones in Default/_colors-public.scss), so custom widgets can at least attempt to match current theme?
Note
There is nifty hack by the name of gtk_widget_get_color(), which can be used to solve this one problem with link color miming (create widget, get color, destroy widget), but looks like prime candidate for deprecation down the line, being so much out of line with more general API
Yes. There’s no solution that maintains both the ability of themes to change fundamental aspects of the UI and preserves the ability of application developers to deal with an internally consistent UI. If there were such a solution it would have been implemented already.
The other problem with themes is one of responsibility; you have multiple stakeholders:
toolkit developers
OS/distribution developers
application developers
users who like to tinker with their UI
and none wants to take responsibility for things breaking or for people not being able to do what they want. Tinkerers always want to have the last words, except when things break in which case they want somebody else to blame; application developers want to be able to write their application’s UI without having to care about a long tail of tinkerers; OS developers want to ship an OS with their own brand differentiation; toolkit developers don’t want to be burdened by everybody’s conflicting requirements manifested in an unmaintainable mess of API and overrides.
Who is going to enforce that “contract”? What happens when a theme breaks it? What happens when a distribution wants to break it? What happens when an application developer wants to break it?
Social problems generally don’t have technical solutions, but if there’s no way to at least deal with conflict then you’re essentially on your own, in which case: it’s already what’s happening. After all, libadwaita does document its named colors.