How to open a workspace on a specific monitor?

[RawPerfect]

I can only figure out how to set hotkey for opening a workspace on the currently focused monitor. Imo this is pretty annoying since to open it on a different monitor you have to manually move your focus to that monitor (using a separate hotkey) and only then use the correct workspace hotkey. It seems like there's a ton of stuff you can do with Whim, but it's hard to figure out since the documentation isn't very extensive (nothing at all about monitors, for example).

Related - how to set up a router so opening a window automatically sets it to the correct workspace and opens it on the correct monitor? I can't get ANY routers or filters to work right now ((context.RouterManager.AddProcessFileNameRoute("TickTick.exe", "7") doesn't work for me, nor when I try to use title), but even if I could, I don't see how to accomplish this.

[urob]

I can only figure out how to set hotkey for opening a workspace on the currently focused monitor. Imo this is pretty annoying since to open it on a different monitor you have to manually move your focus to that monitor (using a separate hotkey) and only then use the correct workspace hotkey.

Activate takes an optional monitor argument. So you could create bindings for each monitor, or write a short command to switch workspaces on the next/previous monitor.

Related - how to set up a router so opening a window automatically sets it to the correct workspace and opens it on the correct monitor?

Since workspaces aren't bound to monitors, this isn't currently supported by the router property. There is a plugin idea for having separated workspaces for each monitor, which would solve this.

[dalyIsaac]

Hopefully the new Monitors page in the docs helps.

[RawPerfect]

I cannot make heads or tails of how to setup and keybind an Activate command which specifies the workspace and monitor. The documentation really really really needs more examples.

I eventually got it almost to work, but now it's saying context.Butler.Activate(workspaces[Index-1] ,context.Store.Pick(Pickers.PickMonitorByIndex(1)).Value); is invalid because PickMonitorByIndex does not exist. Even though that's the exact monitor argument in the example given in the store manager.

I have to say, needing to follow the breadcrumb trail around to all these different managers, in order to do something essentially simple, is very annoying.

Edit: It could be because I'm on an older version. Will try later with newest.

[dalyIsaac]

That's totally fair - I was squeamish about the whole idea of adding in the Butler. Hopefully it's simpler now, with the "pickers" getting data from a single store and the "transforms" performing actions.

The one downside is that the error handling approach is somewhat obtuse. I've documented how it works in the Store page, but I'm open to suggestions on how to make it more approachable.

Edit: It could be because I'm on an older version. Will try later with newest.

Yeah, it's a recent addition.

[RawPerfect]

That's totally fair - I was squeamish about the whole idea of adding in the Butler. Hopefully it's simpler now, with the "pickers" getting data from a single store and the "transforms" performing actions.

The one downside is that the error handling approach is somewhat obtuse. I've documented how it works in the Store page, but I'm open to suggestions on how to make it more approachable.

Edit: It could be because I'm on an older version. Will try later with newest.

Yeah, it's a recent addition.

Yes I updated and the PickMonitorByIndex works now. Good thing too, it's the only one that makes intuitive sense to me (especially with the handy graphic on the monitors page). So now things work well for me (I can use hotkey to open a workspace on a certain monitor) but it still doesn't focus that monitor. Maybe that's where Transforms come in? Or maybe Dispatch..? To be honest I'm still not clear on any of it - there's a lot of abstraction going on (context.store.pick(pickers.pickmethod).value is hilariously abstruse to anyone who isn't already a programmer, for example) and it's quite hard to parse.

I really think what Whim needs most is more approachability, more 'good defaults', more user friendliness, since Whim is already very well featured and (so far in this new version for me) bug free. The docs, for example, are not incredibly useful if you aren't at least somewhat familiar with object oriented programming (very linux-like in that regard). At the end of the day, this is mostly for power-users, but still, I definitely had an easier, much smoother time with i3 than Whim, even though Whim is probably at this point of similar power/flexibility to i3. And that was even with i3 being my first tiled window manager.

My suggestions for ways to improve approachability would be to (1) have more different 'default' configurations (for example, one that emulates the most common i3 setup, komorebi setup, or whatever other common setups people might want). Some of the current default options are pretty obnoxious as well (unless it has changed), for example the super thick highlight around the active window and large margins. (2) Have some plug and play config snippets for the most common use cases (so people don't have to learn a bunch of details about how the program works, for most things). In my case, a plug and play for activating and switching to workspaces on specific monitors would have been nice, or another one, how to do the floating small window scratchpad thing you can do in i3. Or whatever things have come up frequently in the discussion boards. And (3) put up a notice or request under 'documentation' on the github page to see if anyone wants to work on and improve the documentation generally (for example, more examples). In no one wants to, no harm.

Don't get me wrong though, Whim is pretty amazing (once you get the hang of it).

[dalyIsaac]

To be honest I'm still not clear on any of it - there's a lot of abstraction going on (context.store.pick(pickers.pickmethod).value is hilariously abstruse to anyone who isn't already a programmer, for example) and it's quite hard to parse.

I've never quite reached a level where I think the config is approachable to non-programmers. Accordingly, the documentation do mainly cater to power-user programmers.

I've decided to make the next major piece of work to be a JSON config, closely followed by sticky workspaces - I have created a proposal for JSON config written up at #993.

I think this will address the majority of the suggestions in terms of making Whim more approachable. I've also turned your suggestions into tracked issues, and made the contribution areas clearer in the README and docs.

Thanks a lot for the feedback, it's really helpful. I'm glad you're enjoying Whim!