[REQUEST] modi script mode - event based system

[fogine]

Recently I've been playing around with rofi-blocks, it's C modi plugin that provides similar functionality to rofi's script mode.

What I like about it is that it spawns the user child script which it keeps connection with and sends events to the stdin. However since its in form of modi plugin, it doesnt really play that well with -combi-modi. I think having integrated solution in rofi is better idea.

After reading rofi-script doc I think it could be improved such that it would send usage data to the user script in form of events. Like when textbox input data changes, when selection changes, shortcut is triggered etc... Having event based system would make it scalable as rofi feature set grows. Currently as far as I know, it sends only selected entry to the user script which limits its use cases.

• Rofi version:
  • rofi -v 1.5.4

[DaveDavenport]

We have been discussing this recently on #rofi. The biggest question is how the API should look.

To clear one things up, rofi-blocks (being a c plugin) can have identical functionality as an integrated solution. There is no difference (from both rofi and the plugin side). It will behave identical with combi modi too (as it all goes via the same API).

Combining 'live updating' modi and combi mode is an odd use-case to me. What is it you are trying (describe your use-case) to do, and what does not work well?

[fogine]

combi mode

Sorry, I mixed up -combi-modi with multiple -modi plugins... even though I could think of use case of combining several applets together that share similar base functionality of showing results based on user's input - search engines. Example: combining applet that searches through buku bookmarks and applet that searches on google/ddg... You could have combined app that would prioritize search results from your bookmarks and otherwise went for search for results to the web.

modi mode

But originally I was thinking about different issue. Lets say people start using rofi-blocks and the end users will want to combine and traverse between different applets, like you can currently do with rofi custom script mode:

rofi -modi "window,blocks" -show blocks -blows-wrap script.py

Currently, you can't really define multiple apps built with rofi-blocks. I realize that it could be solved similar to the following:

rofi -modi "window,blocks" -show blocks -blows-wrap "script.py,script2.py"

but which plugin to show now?
Since you can already combine plugins like this:

rofi -modi "window,name:script.py" -show name

Anything else just over-complicates things and makes it confusing to new users.

rofi script mode event API

I don't think the actual data format is that important if that's, quote, "the biggest question"?
What I think is important, is to design data structure for events such that rofi can easily adhere to it in the future.

In my opinion, for data format, I'd choose something rather readable than something that is simple to generate in shell script specifically. For example json.
My argument is that you wouldn't want to use shell scripting for more advanced use cases (outside of scope of dmenu) that are starting to emerge. Majority of languages that could be used for scripting handle json really well (python, javascript, lua, ...). Even in shell script you can use jq

Example of JSON API data format:

Something similar but more scalable to what rofi-blocks already has would be sufficient:

rofi would send one or more events at time to addon's stdin:

{
    "version": "1",
    "events": [
        {"name": "input_change", "data":"input text box value"},
        {"name": "active_entry", "data":""},
        {"name": "key_press", "data":"1"},
        {"name": "...", "data":"..."}
    ]
}

In the similar manner, the addon would send json data object to stdout..

Maybe try to describe the thought process behind the current problem that exists regarding the API?

[DaveDavenport]

I don't think the actual data format is that important if that's, quote, "the biggest question"?

I don't understand this.. The API between the scripts and rofi is something we need to get right to be usable and easy for the user. How can this not be important? The rest is (reasonably trivial) implementation work that is for the largest part already there (in rofi and rofi-blocks).

The problem with multiple blocks can be easily solved, I think it would be possible to expose the same interface as used for script to the blocks.

[DaveDavenport]

@OmarCastro do you have any input on this?

[DaveDavenport]

I think the best way to tackle this issue is not to make another version of rofi-blocks (integrated in rofi). Lets see if we can fix the issue with the rofi and rofi-blocks combination.

[fogine]

I don't understand this.. The API between the scripts and rofi is something we need to get right to be usable and easy for to the user. How can this not be important?

Yes of course it does matter. I believe I expanded on this when expressing my opinion on shell scripting in this case.

I guess it comes down to whether you want to have prioritized support for shell scripting in regards to making rofi plugins, in that case having having more flat defined format would be helpful I guess. But again, it would make it more difficult to parse everywhere else (py,js,lua etc..)...

I do not see a problem with json format, its readable and you can store multidimensional data which isn't the case for the current custom script format proposals..

[fogine]

I think the best way to tackle this issue is not to make another version of rofi-blocks (integrated in rofi).

Well, I wouldn't bother discussing this if, as you said, rofi wouldn't have very similar but somewhat limited functionality already built in.

What's the purpose on custom script mode then, if we are gonna have superior implementation in a plugin?

[DaveDavenport]

What's the purpose on custom script mode then, if we are gonna have superior implementation in a plugin?

1. backward compatibility. I cannot completely overhaul the API as it would break all existing scripts. This is one of the reasons why we where discussing API (see if we can fit it in with the current API of script mode) and why it is so important (imho).
2. Somebody needs to maintain it. Rofi is already grown well beyond it initial goals. I have very little time to work on it, and there is very little contribution coming in. Adding yet another mode (because 1 it will be an addition) is not something I want to do. I would not be able to put enough effort into it.

[fogine]

1. and 2. that's I wanted to hear, I wasn't sure whether its being used much (I use rofi extensively and really didn't know about the feature). I also understand and agree that having two modes doesn't make much sense.

To be honest, the reason I created this issue was that I thought having the feature as part of rofi or davatorium would make it more maintainable. I created few patches for rofi-blocks but it waits on the owner to make time to review and merge it. Having it here and possibly having more people in the organization would help.

[DaveDavenport]

1. and 2. that's I wanted to hear

Then why did you not ask this? Would have gotten us to this point quicker.

[fogine]

I've read wiki which contains proposals and looked on next branch diff and saw rofi-script documentation being added... so I assumed things... It looked like there isn't stable implementation in place yet and there is time to tweak direction... Certainly I could communicate things clearer, my bad.

[DaveDavenport]

Yeah, this all boils down to time. Very little time to spend on rofi, wiki and documentation suffered by it.

Still hoping somebody will step up.

[vredesbyyrd]

But originally I was thinking about different issue. Lets say people start using rofi-blocks and the end users will want to combine and traverse between different applets, like you can currently do with rofi custom script mode:

That's where I sit. I am using @fogine rofi-search script which depends on rofi-blocks. I converted a browser-tab dmenu script to a mode script and intend to do the same for my buku script.

I have not dug into rofi blocks much yet, but from the documentation I can assume it was not designed to be used this way... that said, this command almost succeeds:

rofi -modi blocks,brotab:tab-modi.lua -blocks-wrap rofi-search -show brotab

The one covet is -show name will not work, -blocks-wrap name takes precedence. Other than that switching between modes works fine and the scripts appear to work as intended.

I just want to say as a user I would love this functionality, though I do not posses the programming knowledge to give any constructive input on how to best implement it : /

[fogine]

I've been basically waiting when and if @OmarCastro gets active again to coordinate next steps taken with him also. But looking at his profile it doesn't seem he is active much.

So I'm thinking I would maintain rofi-blocks in my fork instead and switch arch package I made to point to it.

Another option, which I'm more inclined to, is for the project to be forked to davatorium organization so people can discover it easily. I could either make pull requests to it as usual or @DaveDavenport could give me push access to the repository specifically and maybe, if I get good hold of it, I could also start contributing to rofi in the future.

The thing is I have currently minimal experience with C language. But I've always wanted project like this to learn more of it. So this might be good opportunity for me.

What do you think @DaveDavenport ?

[DaveDavenport]

I don't mind moving it into the davatorium organization, but not going to do it without @OmarCastro blessing.

[OmarCastro]

Hello, first of all, sorry for my inactivity, I am now going to give some input on this

[OmarCastro]

I am a proponent of "Do one thing and do it well", so I believe keeping rofi and rofi-blocks separated, or in a more accurate way, not integrated, simplifies maintainability of the core of rofi. It would not surprise me separating custom script into a plugin would improve maintainability.

The original purpose of rofi-blocks was to be a prototype to extend the scripting capability of rofi, since I found the original script lacking in functionality, namely those in the Background section of rofi-blocks README which is indicated on the next list, since I am also creating scripts to customize rofi.

• Changing the message and list content on the fly

• Allow update of content on intervals, without the need of interaction (e.g. top)

• Allow changing the input prompt on the fly, or be defined on the script instead of rofi command line

• Allow custom overlay message

A good direction would be to make plugins isolated, I remember having hard time integrating rofi-blocks with another modi, or even making multiple instances of rofi-block on the same window, it seemed that rofi-blocks was trying to overwrite the content of another modi. Was looking into it before being inactive here.

I do not mind rofi-blocks being moved into the davatorium organization either, but I think some work of isolating rofi-blocks will be needed before integrating it.

[DaveDavenport]

for the 1.7 release, lets dive into this. I have some (unrelated) work waiting for that release, that would make the creation of Modes more dynamic, (e.g. a mode_create) function.

modes are pretty isolated already if you only respond on request, the async behavior is (as in rofi-blocks) is a bit more tricky, but very doable.