davatorium / rofi

Rofi: A window switcher, application launcher and dmenu replacement
https://davatorium.github.io/rofi/
Other
13.31k stars 614 forks source link

[REQUEST] Theme unicode icons (two proposed solutions) #2026

Open Onred opened 2 months ago

Onred commented 2 months ago

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:

* {
    text-color:       var(fg0);
    fg0:              rgba ( 230, 230, 230, 100 % );
element-text {
    text-color:       inherit;
}

would instead output this:

* {
    text-color:       rgba ( 230, 230, 230, 100 % );
    fg0:              rgba ( 230, 230, 230, 100 % );
element-text {
    text-color:       rgba ( 230, 230, 230, 100 % );
}

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

DaveDavenport commented 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.

Onred commented 2 months ago

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.

DaveDavenport commented 2 months ago

I don't have time to work on/look at this at the moment. (We need a release first). Hence the 'patch is welcome'.