Open Onred opened 2 months ago
Just add text-color as valid property to element-icon widget.
This to me is the only real solution out of the two. Patch is welcome.
This to me is the only real solution out of the two. Patch is welcome.
Hey Dave,
Thanks for the reply. My C is novice level which is why I opened a feature request instead of an MR. I could still try to take a look and see if I can come up with a patch for at least a starting point for this… any info you could give me on where to check would be extremely helpful.
For example what in the code is responsible for: 1) parsing the theme text color, 2) applying that color to the text widget (to see an implementation example), and 3) drawing the icon widget that has already been detected as being Unicode.
I tried looking at the source and following some symbols but C is utterly confusing to me.
I realize your cycles are limited too so if this doesn’t end up becoming a feature because you need to focus on other things, I understand.
I don't have time to work on/look at this at the moment. (We need a release first). Hence the 'patch is welcome'.
Before opening a feature request
What is the user problem or growth opportunity you want to see solved?
The Problem: If you set a unicode icon in a custom rofi-script, you have to use \ tags for them. As mentioned when that functionality was merged, they do not inherit color from the element-text > text-color or from anywhere else in the theme. This is an issue, because I would really like to use icons in my script without needing to hard-code a text-color in the \ tags.
Proposed Solution 1 (simple): Just add text-color as valid property to element-icon widget. This should have no effect on normal picture-based icons, but apply to the \ tag in the widget if one exists.
Proposed Solution 2 (roundabout): Make a new command line option similar to -dump-theme that would resolve variables (and inherits) before dumping the theme. This would provide a consistent way to parse values across themes that may use different variable names to assign properties. Example
-dump-theme-resolved
:Where as a normal -dump-theme looks like this:
would instead output this:
Then I could simply run this new -dump option, parse the element-text's text-color property, and insert that value directly into the \ of my icon.
How do you know that this problem exists today? Why is this important?
I've tried many ways to add values from the theme directly in the \ tag of the icon, but neither using existing variables nor trying to create a reference works. It's important because it would be nice to have consistent theming, and it doesn't seem like a fix that would be too difficult to implement.
Who will benefit from it?
Anyone who makes rofi scripts with configurable icons. If you want properly colored icons, you would no longer have to put the icons in the element-text widget (which looks wrong if you use -combi with modes that have real icons.)
It's probably possible to write a script that parses the current -dump-theme command line option, recursively going through all the variables and inherits to ultimately land on the correct value... but that would introduce a lot of overhead to what should otherwise be simple rofi scripts, just to do simple theming.
Rofi version (rofi -v)
Version: 1.7.5+wayland3
Configuration
Unimportant
Additional information
No response