MobaXterm manage_rules as Default for All Users

[stevej-algoteer]

Many people use MobaXterm as a terminal emulator on Windows. (It's the only one that supports mosh: https://mosh.org.) Unfortunately, MobaXterm doesn't play well with Komorebi by default. It floats on all workspaces and needs to be explicitly tiled by Komorebi using manage_rules. It also opens a second window that doesn't contain, or do, anything for the user; it just annoyingly occupies a container and needs to be ignored by Komorebi.

Putting all of this together, I believe that the following section should be added to komorebi.json so that MobaXterm will work properly by default for all Komorebi users:

  "manage_rules": [
      [
      {
          "kind": "Exe",
          "id": "MobaXterm.exe",
          "matching_strategy": "Equals"
      },
      {
          "kind": "Class",
          "id": "TMobaXtermForm",
          "matching_strategy": "Equals"
      }
      ]
],

I've done some preliminary testing with this and believe that it works correctly.

Thanks,

Steve

[alex-ds13]

@stevej-algoteer Is that TApplication class window supposed to be opened in floating mode? Because if it is than I would recommend setting the manage rules to the MobaXterm executable and then set that specific window using floating_windows because this way that window will still be managed by komorebi as floating, meaning it stays on the same workspace.

The way you are using it right now that floating window will probably be shown on all workspaces because it is being ignored by komorebi. Isn't this happening to you?

Basically the settings would be these:

"manage_rules": [
      {
          "kind": "Exe",
          "id": "MobaXterm.exe",
          "matching_strategy": "Equals"
      }
],
"floating_windows": [
      [
              {
              "kind": "Exe",
              "id": "MobaXterm.exe",
              "matching_strategy": "Equals"
          },
              {
              "kind": "Class",
              "id": "TApplication",
              "matching_strategy": "Equals"
          }
          ]
],

Can you check it out?

[stevej-algoteer]

Hi, @alex-ds13,

When I launch MobaXterm, it launches:

• cygtermd.exe
• MobaXterm.exe
• MoTTYnew.exe (one or more instances)
• XWin_MobaX.exe (zero or one instance)

Initially, instances of the binaries don't seem to be managed at all. (I don't know why.) This causes the GUI to float across all workspaces, which we want to prevent.

If we manage only MobaXterm.exe, something strange happens. Both the GUI and a window without content, but the title "MobaXterm," get managed by Komorebi. Then, it's not possible to close the window without content, which the user doesn't interact with and isn't even supposed to see, as far as I can tell. Perhaps this window, which seems to be invisible when not controlled by Komorebi, is somehow used by the X11 server. I really don't know.

komorebic visible-windows shows us:

{ "title": "MobaXterm" "exe": "MobaXterm.exe" "class": "TApplication" }, { "title": "MobaXterm Professional" "exe": "MobaXterm.exe" "class": "TMobaXtermForm" }

I believe that the one that we want Komorebi to manage is the one identified by the class, TMobaXtermForm. I think we want Komorebi to ignore the other window.

It's possible that further testing might surface a problem pertaining to X11, but I suspect that most MobaXterm users only use it as a text terminal, usually to telnet/ssh/mosh. @LGUG2Z suggested that I try what I submitted here originally, and that seems to work. I don't see anything that floats across workspaces. Everything seems to work properly.

At the moment, I don't have a way of running something such as xeyes using MobaXterm's X11 server (in the X world, "server" and "client" mean the opposite of the modern usage). But I'll try to set it up as soon as I have the time, and will comment again if I find any anomalous behavior.

I'm fairly confident that the improvement from the code snippet, above, will enable most, or all, MobaXterm users to use the application out of the box with Komorebi, without any problems.

Your suggestion sounds right if that second window is used by MobaXterm's X11 server, but I've struggled so much to get things (seemingly) working that I'm almost scared to mess with it again. :)

Let's keep an eye on things and see what happens.

[alex-ds13]

Ok. If that is some invisible window, then it is best to ignore it. Although I don't see why would it become visible after being handled by komorebi since komorebi doesn't change windows' visibility. But if this isn't showing any floating (ignored) window on the other workspaces then it is fine just like this!

[stevej-algoteer]

I really don't know, Alex. MobaXterm is one of those weird applications, with regard to how it makes use of windowing. Part of it has to do with X11, but I don't know how they designed the application, so I can only guess based on observable behavior.

Can you give it a try on your end, and see if you can replicate what I've observed? Perhaps you'll have some insight that I overlooked.

Thanks!

Steve