How to hide "interface locked" text?

z0al commented 1 year ago

I want to auto-start zellij on every terminal session in locked mode by default but I'm bothered by the -- INTERFACE LOCKED -- text. Is there any way to hide it without quitting Zellij?

Ideally, I'd want Zellij to stay out of the way when I'm not using it.

I'm aiming for a minimalistic look and I want to use the presence of the tip as an indication that I'm not in a locked mode.

template:
  direction: Horizontal
  parts:
    - direction: Vertical
      body: true
    - direction: Vertical
      borderless: true
      pane_frames: false
      split_size:
        Fixed: 1
      run:
        plugin:
          location: "zellij:status-bar"

Love Zellij btw, keep up the great work.

har7an commented 1 year ago

Hey @z0al,

at this point I'm afraid there is no way to hide the "LOCKED" mode indication. We're generally working towards a full rework of the whole plugin system, and we can try to incorporate this as a feature there, if you wish. However, we don't have any fixed date until which this will be implemented - it will likely take a while to get there.

In the meantime, you can build the status-bar plugin yourself and customize it entirely to your liking. After all, zellij allows for loading custom plugins. Would that be an option for you? I can guide you through the process, too, if you want.

z0al commented 1 year ago

Hey @har7an , thank you so much for your helpful response.

In the meantime, you can build the status-bar plugin yourself and customize it entirely to your liking. After all, zellij allows for loading custom plugins

I guess building a plugin makes sense. I can give it a try. Could be a nice way to learn a bit of Rust :)

Any links to docs or pieces of code to get started would be great.

I will start by looking into reusing the existing status bar plugin code and make a few adjustments. Any tips are welcome.

Regardless, I think the argument for a custom plugin is fair enough, the issue can be closed.

har7an commented 1 year ago

Hi @z0al,

I guess building a plugin makes sense. I can give it a try. Could be a nice way to learn a bit of Rust :)

It certainly is! Just keep in mind: You'll be responsible for keeping the plugin up-to-date when updating zellij in case errors/incompatibilities arise. So if you make an update and things break, maybe rebuild the plugin.

Any links to docs or pieces of code to get started would be great.

Sure thing:

If you only want to get rid of this particular text, just replace this string here
If you also want to change the text for locked mode + floating panes, look here and here

Regardless, I think the argument for a custom plugin is fair enough, the issue can be closed.

Glad to hear this may work for you! I'll keep the issue open until you've reported you got it working. Keep in mind that you'll also have to include your custom plugin in a layout file, like so:

    - direction: Vertical
      borderless: true
      split_size:
        Fixed: 2
      run:
        plugin:
          location: "file:/home/you/somewhere/status-bar.wasm"

You should also install cargo-make and then run cargo make wasm-opt-plugins from the zellij root directory to build the plugins with optimizations. It will require a binary called wasm-opt, which you can grab from a release of binaryen. The finished plugins reside in assets/plugins/*.wasm.

Feel free to ask in case things don't work as you expect. And happy hacking!

z0al commented 1 year ago

Ok, I tried to cheat a bit but got stuck :)

I'm experimenting with NixOS at the moment so I thought it would be easier just to patch the zellij package to overwrite the -- INTERFACE LOCKED -- text. I created a simple Overlay (nix way of overriding packages):

{
  nixpkgs.overlays = [
    (final: prev: {
      zellij = prev.zellij.overrideAttrs (o: {
        patches = (o.patches or [ ]) ++ [
          ./patches/locked-text.patch
        ];
      });
    })
  ];
}

Where the locked-text.patch contains:

diff --git a/default-plugins/status-bar/src/second_line.rs b/default-plugins/status-bar/src/second_line.rs
index 9b654033..86fc62f3 100644
--- a/default-plugins/status-bar/src/second_line.rs
+++ b/default-plugins/status-bar/src/second_line.rs
@@ -95,7 +95,7 @@ fn first_word_shortcut(
 }

 fn locked_interface_indication(palette: Palette) -> LinePart {
-    let locked_text = " -- INTERFACE LOCKED -- ";
+    let locked_text = " 🔒 ";
     let locked_text_len = locked_text.chars().count();
     let text_color = palette_match!(match palette.theme_hue {
         ThemeHue::Dark => palette.white,
@@ -512,7 +512,7 @@ pub fn locked_fullscreen_panes_to_hide(palette: &Palette, panes_to_hide: usize)
     });
     let green_color = palette_match!(palette.green);
     let orange_color = palette_match!(palette.orange);
-    let locked_text = " -- INTERFACE LOCKED -- ";
+    let locked_text = " 🔒 ";
     let shortcut_left_separator = Style::new().fg(text_color).bold().paint(" (");
     let shortcut_right_separator = Style::new().fg(text_color).bold().paint("): ");
     let fullscreen = "FULLSCREEN";
@@ -551,7 +551,7 @@ pub fn locked_floating_panes_are_visible(palette: &Palette) -> LinePart {
     };
     let shortcut_left_separator = Style::new().fg(white_color).bold().paint(" (");
     let shortcut_right_separator = Style::new().fg(white_color).bold().paint(")");
-    let locked_text = " -- INTERFACE LOCKED -- ";
+    let locked_text = " 🔒 ";
     let floating_panes = "FLOATING PANES VISIBLE";

     let len = locked_text.chars().count() + floating_panes.chars().count();

But somehow the final binary isn't picking up these changes at all even though it works fine if I try to patch text under src like this line for example. I asked around on Reddit and nobody seem to have a clue.

I even tried to do things manually, like clone the project, change the string and compile:

When I do cargo make run my changes are picked up as it seems to explicitly build the status-bar dir
But if I clean the target folder and do only cargo run it will still show -- INTERFACE LOCKED --

I'm confused at the moment. Do you happen to be familiar with the matter?

har7an commented 1 year ago

I'm not familiar with nix at all, so I can't help you on the building/tooling with that. However, my suspicion is that your zellij doesn't pick up the new plugins. Can you try running zellij --data-dir /tmp/foo and see if it works then?

z0al commented 1 year ago

However, my suspicion is that your zellij doesn't pick up the new plugins.

Probably, but what I don't understand is how? the status-bar plugin, if I understand correctly, isn't a crate that gets pulled from somewhere else but rather a local cargo package. Since I manually updated its source code before compiling how is it that zellij is still reporting the old message 😅

Can you try running zellij --data-dir /tmp/foo and see if it works then?

That didn't help.

The steps to reproduce my situation are the following:

$ git clone https://github.com/zellij-org/zellij.git
$ cd zellij && git checkout v0.31.4 # master is causing error when running the output binary

Manually modify the code at default-plugins/status-bar/src/second_line.rs and then:

# using "cargo make build/run" would work but I think the Nix package runs this instead so I'm sticking with it until I figure out what is going on
$ cargo build 
$ ./target/debug/zellij --config-dir /tmp/foo --data-dir /tmp/bar

har7an commented 1 year ago

Probably, but what I don't understand is how?

Each of the plugins is a standalone binary. What we do when releasing zellij (and what cargo make install does, which is the command you should be using when building) is to build all the plugins in release mode, stuff them into an assets folder in the project, and then build zellij and include the plugin blobs into the application binary.

Now when you execute zellij it will check its own version, read the version from $DATA_DIR/VERSION and compare them. It will then replace the plugins in $DATA_DIR/plugins as necessary. And then it will load said plugins from that data dir.

The part where zellij includes the plugins in the binary is exactly why you need cargo make install. A regular cargo build or cargo make will not (this is very important) build the optimized plugins or even include them into the binary.

So I suggest you try this:

Apply your patch, however you prefer to do that
Run cargo make install target/zellij
Wait a few minutes...
Run ./target/zellij --data-dir /tmp/somedir

This should work, provided that /tmp/somedir wasn't already populated. Then, if that does work, I recommend you purge your data directory (the default is ~/.local/share/zellij) and use the freshly compiled zellij binary from here on. That should do the trick.

And a heads-up for you: There's a new release imminent, likely on Tuesday. So be prepared to do all that again on Tuesday or sometime after that. ;)

z0al commented 1 year ago

Thanks for the quick response and explanation. It sounds like I also need to modify the nix package to correctly build zellij by using cargo make ... I will give that a shot and hopefully, that will be enough :)

So be prepared to do all that again on Tuesday

Thanks for the heads up. Once I get the patching to work automatically via nix then it should be much easier especially since I usually use a stable channel (e.g. 22.05 ) rather than automatically getting all the latest packages :)

zellij-org / zellij

How to hide "interface locked" text? #1742