Styleable icons (icon widget)

[phisch]

The Problem

Currently the icons displayed in rofi list elements behave like html-inline elements, which are separated by one space. Also the icon-size is depending on the element-font-size used.

Even though the flexible *.rasi theme format was introduced, the icons are one of the few parts which are out of control or scope of this format.

Why?

Letting the user define how the icons are rendered in a theme, gives the user more creative freedom.

How?

To follow the approach of how theming works in rofi, an icon should be a child widget of the #element widget. Besides this -let's call it- #icon widget, a #title widget, representing the corresponding text could be introduced. This is refering to rofi-theme#name

Order

Since rofi widgets allow defining their children, this approach allows the user to re-order the widgets inside the #element widget. Therefore configurations with the icon behind the text, or without icons at all are possible.

Spacing

Since rofis widgets allow for styling of paddings, margins and borders, those attributes can be used to define specific rules to space the icons from the text.

Orientation

Rofi widgets allow defining a flow direction (orientation) for their child-widgets. Since this would separate #icon and #text, interesting configurations which render the icon above the text would be possible.

Sizing

If the #icon widget does not receive a specific width and height, the current approach of taking the font-size of the text (in this case #text widget) can be used.

If both width and height are defined, the smaller length could be chosen to find the next bigger icon available and scale it down. Obviously the best looking icons can be achieved by defining sizes in which the icons are available, like 8x8, 16x16, 32x32, 64x64, 128x128 and so on. Optionally, a separate style-attribute size could be introduced to not rely on both height and width.

Highlighting

The #icon widget would still be able to receive style-attributes like background-color, border-radius and border-color, which makes visually separating icons from text possible.

Hiding icons

Because a theme doesn't know if an #element has an icon or not, the #icon widget could receive a class #icon.missing indicating a missing icon. A separate style-attribute display could allow removing the icon from being rendered in the "DOM" in the first place. This would allow the user to either use the space otherwise used by icons to get more space for the #text widget, or keep the #text widgets vertically-aligned in a traditional list-view (like they are aligned in the current build).

Challenges

From my point of view this seems like it logically fits into how rofi treats theming. But it might look different from a code point of view. @DaveDavenport since you probably have the most knowlege/experience with this code, do you see any hudles, blockers or challenges an implementation like this would face?

Further

I'd like to get some input on this, since i think this would fit really well into rofi, would make theming a bit more versatile, and also make some themes more attractive to new users. Maybe this is a bad idea, and i just don't see why. Let's discuss!

[DaveDavenport]

I think most of this is doable and I am all for it.

I do wonder how often it will be used. I see very little themes actually use theme features (like border radius and the like).

[phisch]

I would most certainly use it, and i think the people using rofi are all for customization. Most themes are probably buried somewhere in dotfile repositories, and not pushes into the user-themes directory here.

[diamondburned]

I would definitely use most of it. Padding, icon size, border-radius, etc could be used to make various things from a miniature launcher to a full-screen HUD without making everything look cramped. As my philosophy always goes, padding is everything.

[DaveDavenport]

Given there is already an icon widget, so I did a quick an dirty implementation attempt:

• It will break existing themes.
• The listview sizing logic needs to be rewritten (as it is now optimized for fixed height based on text). It is likely not going to get any faster.
• The highlighting/alternating logic needs to be updated (for the better I think).

[JonnyHaystack]

I just found this issue by searching because I was looking for a way to increase padding between the icon and the text. I'd definitely be interested to see this implemented. Is there a way to adjust padding between the text and description in drun? If not, that would be a very nice thing to have as well.

[phisch]

@JonnyHaystack no there is no way right now, there will be if this gets implemented.

I am stoked that you are working on this, dave!

[DaveDavenport]

I just found this issue by searching because I was looking for a way to increase padding between the icon and the text. I'd definitely be interested to see this implemented. Is there a way to adjust padding between the text and description in drun? If not, that would be a very nice thing to have as well.

@JonnyHaystack no there is no way right now, there will be if this gets implemented.

This is all one text, so if you want extra margin update the formatting string.

[JonnyHaystack]

This is all one text, so if you want extra margin update the formatting string.

I can't find seem to find anything in the documentation on this.

[DaveDavenport]

might be new option

`-drun-display-format`                                                              

The format string for the drun dialog:                                              

* **name**: the application's name                                                  
* **generic**: the application's generic name                                       
* **exec**: the application's  executable                                           
* **categories**: the application's categories                                      
* **comment**: the application comment                                              

Pango markup can be used to formatting the output.                                  

    Default: {name} [<span weight='light' size='small'><i>({generic})</i></span>]   

Note: Only fields enabled in `-drun-match-fields` can be used in the format string. 

[DaveDavenport]

[DaveDavenport]

[DaveDavenport]

[DaveDavenport]

[DaveDavenport]

fixed icon sharpness a bit.

[DaveDavenport]

There is a branch issue949 old 'element' is now an: element box, with two child widgets: element-text: textbox widget element-icon: icon widget

to make old theme work, you need to add something like:

element-text,element-icon {
   text-color: inherit;
}

[ntcarlson]

Thanks @DaveDavenport! This is a feature I've been looking for for a while. The orientation and icon size works great, but I could not get the text to center like in your last 2 examples. Could you share the configuration files you used in your examples?

[DaveDavenport]

There is a horizontal-align option on textbox.

[ghost]

@DaveDavenport How you increased the size of the icons and is it possible to add margin or padding to the icon ? Can you show me the code.

[DaveDavenport]

Lets limit the discussion in this issue to the actual issue. (margin/padding for icon is identical to every other widget. size property sets size.)

[DaveDavenport]

TODO on this issue:

• [x] Check the dmenu multi-select.
• [x] Find a way to keep backwards compatibility with themes.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.