Komorebi and the relationship between Monitors (physical devices), display, workspaces, and desktops

[MMitsialis]

Hi,

I understand :

• Komrebi works with Workspaces that have containers.
• Each contianer can holds a Windows application window.
• Workspaces follow a pattern to create new containers.

What I don't understand and can't figure out is:

• Relationship between a Komorebi Workspace and a Physical Monitor
• Relationship between a Komorebi Workspace and a Windows Desktop ( of which there can be multiple virtual desktops per monitor).

My current setup is:

• Two monitors

• 5 Windows Virtual Desktops.

• When I start Komorebi the windows on the active monitor and desktop are organised and can be manipulated. ( moved between the monitors, shuffled, monocled, etc).

• If a change to a different Windows Virtual desktop, komerebi seems to be inactive.

  • however any new windows on the desktop or moveing windows around creates empty container on the virtual desktop that was actvie when Komerbi started.

Is Komoeribi only usable with the single Windows Virtual Desktop or is there a way to use both.

[CtByte]

There is an explanation on why Virtual Desktops are not supported

I think that using workspaces can replace Virtual Desktops. One big difference I think is that a workspace belongs to a monitor, while a virtual desktop belongs to all monitors.

[LGUG2Z]

Is Komoeribi only usable with the single Windows Virtual Desktop

Yes

is there a way to use both

No

Some history and code archeology:

komorebi/komorebi/src/lib.rs

Lines 244 to 285 in d9bffa0

	pub fn current_virtual_desktop() -> Option<Vec<u8>> {
	let hkcu = RegKey::predef(HKEY_CURRENT_USER);
	// This is the path on Windows 10
	let mut current = hkcu
	.open_subkey(format!(
	r#"SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\SessionInfo\{}\VirtualDesktops"#,
	SESSION_ID.load(Ordering::SeqCst)
	))
	.ok()
	.and_then(
	|desktops| match desktops.get_raw_value("CurrentVirtualDesktop") {
	Ok(current) => Option::from(current.bytes),
	Err(_) => None,
	},
	);
	// This is the path on Windows 11
	if current.is_none() {
	current = hkcu
	.open_subkey(r"SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VirtualDesktops")
	.ok()
	.and_then(
	|desktops| match desktops.get_raw_value("CurrentVirtualDesktop") {
	Ok(current) => Option::from(current.bytes),
	Err(_) => None,
	},
	);
	}
	// For Win10 users that do not use virtual desktops, the CurrentVirtualDesktop value will not
	// exist until one has been created in the task view
	// The registry value will also not exist on user login if virtual desktops have been created
	// but the task view has not been initiated
	// In both of these cases, we return None, and the virtual desktop validation will never run. In
	// the latter case, if the user desires this validation after initiating the task view, komorebi
	// should be restarted, and then when this // fn runs again for the first time, it will pick up
	// the value of CurrentVirtualDesktop and validate against it accordingly
	current
	}

On Windows 10, which is where development for this project started, Virtual Desktops were aggressively off-by-default, and this persisted across reboots.

Fast forward to Windows 11, and now by default a single Virtual Desktop is always initialized, which is problematic because VDs are a poorly supported feature which are not exposed for programmatic manipulation by Microsoft in the Win32 API.

As a result, on Windows 11, komorebi will record the ID of the Virtual Desktop it is launched on, and for the lifetime of the process will only operate on events which take place on that VD ID:

komorebi/komorebi/src/process_event.rs

Lines 108 to 118 in d9bffa0

	if let Some(virtual_desktop_id) = &self.virtual_desktop_id {
	if let Some(id) = current_virtual_desktop() {
	if id != *virtual_desktop_id {
	tracing::info!(
	"ignoring events and commands while not on virtual desktop {:?}",
	virtual_desktop_id
	);
	return Ok(());
	}
	}
	}

[MMitsialis]

Thannk you @LGUG2Z , and @CtByte the combination of your two posting has clared up the confusion.

In summary using Komorebi on Windows

• I must disable as much Windows Virtual Desktop functions as possible.
• Allow Komrebi to mange placements of Windows as far as possible.
• The Komorebi Workspaces provide the functionlity of Virtual Desktops
• I use the "Komorebi Placement Rules" function to position app windows in specified workspaces and monitor/displays
  • This is one of the key goals I want to achieve: specfic applcation windows may only operate on specifc workspaces.
• I am still trying to wrap my head around the the monitor and displays
• I would like to get a confiogiurration defined that works in my home office and when I am in my company office.
• I have a different monitor connection and layout in the two locations and I would like to build a single configuration that works in both locations.