[REQUEST] Apply styling depending on the modi

[dannycolin]

❗
First read the guidelines!
This is not optional for any report/question. People must be able to understand the full context of the report when reading it, at any time.
If you feel like you “just have a simple question”, please consider you’re wrong and still fill the full report.
Any report missing these informations will be labeled as “Incomplete Report - Please follow the guidelines” and may not be answered in a timely fashion.
❗

Before creating a feature request

• I checked the next branch to see if the feature has already been
  implemented

• I searched existing reports to see if it is already requested.

What is the user problem or growth opportunity you want to see solved?

I use a theme that emulate the look of Gnome Shell which shows the desktop files as a grid. However, I'd like to only apply that grid style when I'm in drun.

How do you know that this problem exists today? Why is this important?

I made a theme using a grid and in run modi the text is truncated too early and so the line is unreadable. Same for ssh modi. So I wanted to use a list instead of a grid but I couldn't do it.

Here's an example of how it could looks like in a rasi file:

listview {
  ...
}
@media (mode: drun) {
  listview {
      columns: 6;
      lines: 3;
  }
}

Who will benefit from it?

Users who wants a theme that display drun in a grid but still want a list for window, run, ssh and so on without having a different keybind to call rofi with a different theme. In other word, they can launch rofi, cycle through the different modi and the style will adapt accordingly.

Version

Output of rofi -v: Version: 1.6.1

Configuration

Output of rofi -help (in a gist, please paste the full output): https://gist.github.com/dannycolin/a0397d1e8da22c1ff3211766cc712a60

Additional details:

• Include a link to your private config
• Include screenshots/casts of your issue

Please do not submit reports related to wayland, see
here for more
information.

Requesting a feature is no guarantee it will be added.

[DaveDavenport]

rofi is not designed to dynamically change it theme. I am not sure this can be implemented (without being a gigantic hack or with very limited options) without a major rewrite.

[dannycolin]

I guess that's a good candidate for the "Crazy/Future" label then 😄

[renanwp2]

Have you seen what this user have done? I can switch themes and modes depending on the way I launch rofi. More generally, Its possible to cycle between themes in any order you want to configure for a fixed mode. Is it what you want?

[DaveDavenport]

Yes, I know that repository, I don't think what he has done matches with what @dannycolin wants. (switching themes without closing and re-opening rofi. atleast that was my intrepetation.)

Your last sentence I don't think I understand.

[renanwp2]

Yes, I know that repository, I don't think what he has done matches with what @dannycolin wants. (switching themes without closing and re-opening rofi. at least that was my interpretation.)

Your last sentence I don't think I understand.

Without closing Rofi I think it's not possible as well.

About my last sentence, I have said that It's possible to cycle between themes (and modi) running Rofi a different number of times (using bash script for example like the repository I have posted). Since this technique does not depend on keyboard input, it's possible to do it with the same keyboard input. However, changing the theme without closing Rofi, like I said, I am not sure if it's possible. I have never seen even a GTK/Qt applications doing that. It would be interesting. =)

[DaveDavenport]

A bit offtopic, but most toolkits can change theming on the fly, I am pretty sure GTK 2 and 3 can do this back in the time I wrote gmpc.

[dannycolin]

Yes, I know that repository, I don't think what he has done matches with what @dannycolin wants. (switching themes without closing and re-opening rofi. atleast that was my intrepetation.)

That's exactly what I want.

A bit offtopic, but most toolkits can change theming on the fly, I am pretty sure GTK 2 and 3 can do this back in the time I wrote gmpc.

Yes. I don't remember if it was possible in Gtk2 (or if it was a per app hack) but it's definitely possible with Gtk3+

[windowsrefund]

Glad to have found this thread as I'm in the same boat having written a thing to drive base16 theme changes via flavours. Basically, I can change themes across i3, tmux, alacritty, gtk2, gtk3, and rofi using the script menu but only rofi doesn't take on the new look as it is obviously not reloading its config during runtime. So I'm fairly confident when I say the traditional way this is usually handled is through the use of SIGUSR1 or SIGUSR2. Of course that would mean rofi itself would need to support the signal and do the thing (reload config in this case) when it receives it.

[RickMakesThings]

Hi,

First of all; I have only recently started playing with customising Linux so I am currently trying to figure a lot of things out at once. Rofi and Github being two of them, please let me know if I say anything stupid! Apologies in advance.

Currently, I am trying to create some menus for a custom DE project using Rofi. As somebody with more sense of design than coding, I really wanted to use different colour schemes per Rofi mode to better indicate what mode I am in, without even having to look at any buttons/icons/text.
For instance; Just by looking at the list view itself, I would be able to tell that I'm browsing files if the selected element is blue, and windowcd when it is yellow.

rofi is not designed to dynamically change it theme. I am not sure this can be implemented (without being a gigantic hack or with very limited options) without a major rewrite.

This got me thinking. What if it doesn't have to swap themes?
As far as I understand how Rofi works; each element gets assigned a "class" at some point, right? Since we can call these from rofitheme.rasi as window {}, input {}, listview {}, button {}, etc.

Would it potentially be an option to add a second class to each element? With an SCSS-like syntax such as
[element]:[mode], where [element] is just the original element name, and [mode] is the name of the currently active mode.

This way current configs will remain compatible without rewrites, while it should also not require major code changes from the developer. At the same time, it would open up a lot of options. For instance, I could achieve my ideas by rewriting my config as such:

// Set selected element background-color
element {border-radius: 20px; padding: 5px;}
element:drun selected {background-color: @red;}
element:windowcd selected {background-color: @green;}
element:customscript selected {background-color: @blue;}

// Set entry placeholder per mode
entry {placeholder-color: @foreground;}
entry:drun {placeholder:"Apps";}
entry:windowcd {placeholder:"Windows";}
entry:customscript {placeholder:"Power menu";}

// Set scrollbars per mode
listview:drun, listview:windowcd {scrollbar:true;}
listview:customscript {scrollbar:false;}

Whereas the OP of this issue could use:

listview {columns:1;layout:vertical;}
listview:drun {columns:6;lines:3;}

Please let me know if there is any merit to this at all, or if there is anything that I can do to help make this a reality, because I genuinely believe this feature would make Rofi much, much more customiseable and easier to use.

[DaveDavenport]

The problems is not in 'coloring', the difficulty lies in the dynamic build up of the UI.

window {
   children: [ entry, listview];
}
window:drun {
   children:  [ vertbox, listview]; 
}
vertbox:drun {
children: [prompt, entry];
}

Or more complex restructuring.

Hence the:

rofi is not designed to dynamically change it theme. I am not sure this can be implemented (without being a gigantic hack or with very limited options) without a major rewrite.

If we just limit to colors/margins/padding, yes it would work without to many changes, but is that what people expect?
I put a little 'taste' of this in script mode, and the fact the passable options are limited already resulted into confusion (see option theme here).

[dannycolin]

If we just limit to colors/margins/padding, yes it would work without to many changes, but is that what people expect?

Definitely not what I would expect from something "dynamic". IMO, I agree with Dave here. It's better to not implement it than implementing a half-baked solution.

[DaveDavenport]

I am interested into seeing if I can rewrite parts to make this possible. But I have very little time/energy to work on rofi (still did not manage to make a 1.7.6 release).

I don't expect this anytime soon, unless somebody else steps up.

[RickMakesThings]

Dave, Danny, thank you both very much for replying so quickly!

Firstly: I fully agree that no implementation is better than a half-baked, confusing one.

The problems is not in 'coloring', the difficulty lies in the dynamic build up of the UI.
[code]
Or more complex restructuring.

I looked at this for a while to figure out what the problem is but I'm afraid I either misunderstood or rambled too much and didn't make it clear what I meant.
By adding vertbox:drun to the vertbox item as a second, or alternative class, it would mean that the vertbox in drun mode has both: vertbox and vertbox:drun classes. This would mean that the structure

window:drun {
   children:  [ vertbox, listview]; 
}
vertbox {
children: [prompt, entry];
}

should still work. It's just that the properties in vertbox {} would apply to all vertboxes across all modes (like... the way it currently works?), where vertbox:drun {}'s properties would only apply to the vertbox in drun mode.

Much in the same way that in (S)CSS

item {padding: 10px; background-color: @background;}
item:hover {background-color: @background;}

would result in the item still having its padding on hover, because it gets its properties from both classes.
Adding padding: 0; to the second class would override the first, like it is doing with the background-color property.

Thinking about it, I think Rofi already works in this way with the selected tag?

My current config contains:

button {
    font:             "RobotoMono Nerd Font Mono 18";
    padding:          5px 0px;
    border-radius:    40px;
    background-color: @grey;
}
button selected {
    background-color: @accent;
}

The selected button gets the accent colour according to button selected {}, but also still keeps its properties from button {}. Could this method maybe be re-used where instead of "selected", each element gains a tag with the name of the currently running mode?

Or does the difficulty lie in applying this tag? Specifically to non-stock Rofi items that users might add in their configs?
I'm trying to understand and would love to help out, but to save everybody here some time I will fully admit my knowledge of how this program actually functions under the hood is very, very limited.
At the same time I understand Dave's time is limited and want to make it clear that I'm not trying to pressure you into doing anything.

[DaveDavenport]

You keep going to the syntax, but the syntax is not the issue.

The issue is, on startup the interface layout is build up once, how items are packed cannot easily be changed once build up in the current implementation. (See the manpage for more on this).
At the moment the only viable solution would be to tear down the interface and rebuild it.
On the theme parser side, once loaded it resolves links and prunes the tree internally (for inherited and conditional parts) . This would not be valid anymore if people load in another layout, this then has to be re-resolved again.. The information for this might not even be present anymore.
Again, in the current design this is not as trivial, this is independent of how it looks in the syntax.

[RickMakesThings]

Dave, thank you for this explanation, this makes it much clearer and I understand what you meant in your earlier comment now.

It now also makes sense why actually using echo -en "\0theme\x1fentry {placeholder: \"Test\";}\n" or echo -en "\0theme\x1fwindow {children: [ entry, listview ];}\n" in a script results in these settings being applied to all modes, rather than just the one for the script. Gonna be honest; spent a while trying to "fix" that as I was sure I was doing something wrong.

I guess you ran into the exact same issue here, with no way to refresh the contents without essentially re-spawning the entire window?

[DaveDavenport]

I did not run into it myself, given I hardly use 1/10 of the options I implemented on request.
But users where confused by it in the past, the manpage now sais:

The theme property cannot change the interface while running, it is only usable for small changes in, for example background color, of widgets that get updated during display like the row color of the listview.

[RickMakesThings]

Ha that's fair. I appreciate you taking the time mate!

Wanna hear something funny though? That line is exactly what tripped me up. After reading that I was convinced I would be able to use this to change the button selected and element selected background colours (seeing as both can change while Rofi is running), and because you add this code to a specific script, I figured it would apply only to the mode of that script, rather than the whole window and all modes.

Maybe that has to do with me being frankly, a noob at Rofi. Or maybe it's because I was specifically looking to make such changes. Now that you've explained how it works under the hood it makes complete sense, but before I had this information, everything after the first sentence just made it seem like those were exceptions to the rule.

All that said; For me personally, I'd still LOVE to simply be able to change foreground/background colours, placeholders, maybe the icon pack and scroll bars per mode, however, sadly (for me) I still agree that if you are planning to do a full implementation of this at some point, including rebuilding the interface and allowing re-structuring, you should probably not waste your time on this right now.