Sticky monitor workspaces

[dalyIsaac]

The sticky monitor workspaces plugin (name TBD) should:

• Contain a list of workspaces assigned to a monitor
• Expose commands focus_next_workspace_on_current_monitor + *_previous_*, to activate the next/previous workspace in that monitor's list
• The existing focus_workspace commands would continue to do the same as they do now, but would move workspaces across monitors
  • The plugin would update the monitor object that keeps track of which workspace is on which monitor whenever a workspace is moved ( workspaces can only be assigned to a single monitor at a time)
• Config option that lets users configure which workspaces are assigned to which monitor on startup

Follow-on tickets

• Provide a variant of the WorkspaceWidget for the bar that only lists the currently active workspaces on each monitor.

---

TODOs

Core

• Create a mechanism to map monitors to their index
  • If a monitor doesn't exist, release all workspaces
• Add to MapSector
• Add last activated monitor (index?) to Workspace
• Update workspace creation
• Workspace activation
  • 1. Try activate on the current monitor
  • 2. Try activate on the last monitor
  • 3. Activate on the first available monitor
• Automatically create workspaces if none are available for a monitor
• Save state
• Docs
• Tests

Commands

• focus_next_workspace_on_current_monitor + *_previous_*, to activate the next/previous workspace in that monitor's list
• move_window_to_[next|previous]_workspace_on_monitor
• TODOs
• Docs
• Tests

YAML

• Update schema.json
• Parse monitors and pass to workspace creation
• Docs
• TODOs
• Tests

Bar

• Update existing widget to only show workspaces which can run on a given monitor
• TODOs
• Tests

[urob]

Having move_window_to_[next|previous]_workspace_on_monitor commands would also work great with this (i.e, the sticky-monitor variant of #659).

[RawPerfect]

Imo this is a necessary feature, and the only reason (besides lack of documentation on certain things) someone would want to use any other tiling manager over Whim.

Having to press a hotkey to swap to the correct monitor before pulling up a workspace means you have to track state (where your focus is, what monitor you're on) vs. instantly doing what you want.

Changing the focus command to 'reassign' the monitor its associated with also sounds great and convenient.

[dalyIsaac]

This is my initial idea for sticky workspaces. Suggestions and feedback are welcome.

This will likely be part of the core and not a plugin as I initially thought.

Overview

• Workspaces will be able to be restricted to specific monitors
  • This means that workspaces can be restricted to a subset of monitors
• Workspaces with no restrictions will be available on any monitor
• Since monitors must have at least one workspace, if no workspaces are available then one will be created at runtime
• If a monitor is disconnected, workspaces restricted to non-existent monitors can be activated on any monitor
• Activating a workspace will:
  1. Try to activate the workspace on the current monitor
  2. If the workspace isn't available on the current monitor, try to activate it on the first available monitor
• For the C# API, workspaces will define a list of monitors they are available on.

Example 1

workspaces:
  - name: Browser
  - name: Slack
  - name: Code
  - name: YouTube

monitors:
  - workspaces:
      - Browser
      - Slack
  - workspaces:
      - Code
      - Slack

• The Slack workspace is available on both monitors
• Browser is only available on the first monitor
• Code is only available on the second monitor
• YouTube is available on any monitor

Example 2

workspaces:
  - name: Browser
  - name: Slack
  - name: Code

monitors:
  - workspaces:
      - Browser
      - Slack
  - workspaces:
      - Code
  - workspaces: []

• The third monitor will create a new workspace, since there are no workspaces available.
• The third monitor cannot lose the new workspace, since it is the only workspace available, until a new workspace is created

Example 3

workspaces:
  - name: Browser
  - name: Slack
  - name: Code
  - name: YouTube

monitors:
  - workspaces:
      - Browser
      - Slack
  - workspaces:
      - Code
      - Slack
  - workspaces: []

Alternate design

This approach is how the C# API will be designed. However, my initial thought was that separating out the monitors and workspaces would better fit the current separation of concerns in the YAML config.

workspaces:
  browser:
    name: "Browser"
    monitors: [1] # Explicit monitor assignments
  slack:
    name: "Slack"
    monitors: [1, 2] # Available on multiple monitors
  code:
    name: "Code"
    monitors: [2]
  youtube:
    name: "YouTube"
    monitors: [] # Empty array means available everywhere

[urob]

Could the two yaml approaches be reconciled by making workspaces in the alternate approach a list & by making monitors an optional argument that defaults to all?

workspaces:
  - name: Browser # available everywhere if monitors is not specified
  - name: Slack
  - name Code     # only available on monitor 1
    monitors: [1] 
  - name: YouTube # available on monitor 1 and 2
    monitors: [1, 2] 

[dalyIsaac]

I like that approach - I'll give it a shot and see how it goes

[dalyIsaac]

Functionality added in:

• Add sticky monitor workspaces to the core #1071
• Update WorkspaceWidget to support sticky workspaces #1072
• Sticky workspace YAML config #1073
• Add commands for sticky workspaces #1074