Each output should be independent and sending window to pre/next output should be available.

[minsoehan]

I have been using labwc for a month or so. It is very simple and great. But I had noticed one thing that is inconvenient for me. I always work with multiple outputs (two monitors) at office like writing on one monitor while looking up information from another monitor. When I shift workspace on the current output, the workspace on the unfocused output where I was looking up information from. I know it is how labwc is implemented. I do respect the concept to be simplest. But if I can do request a function, I would want to request that function. Each outputs should be independent like shifting workspace on one monitor/output has no effect on another monitor/output. And it would be also nice if I can sent current window to another output by keybinding.

[johanmalm]

Hi and thanks for writing.
I agree that it would be nice to be able to set the workspace independently of outputs.
We have looked at this before and the main reasons it's not implemented are:
a. It's not a high priority of current core devs in terms of personal requirements (so effort goes elsewhere).
b. It would be quite a deep, systemic change touching many areas of the code base.

I've not discussed it with the other devs for a while, but I'm happy to support if someone is willing to roll up their sleeves and write it. It's probably not a good first issue though because I'm pretty sure it'll take a while to grind out and stabilize.

Regarding a SendToOutput action, I think that would be quite easy to implement. Fancy having a go?
Ref:

labwc/src/action.c

Lines 906 to 911 in 7c59351

	case ACTION_TYPE_FOCUS_OUTPUT:
	{
	const char *output_name = action_get_str(action, "output", NULL);
	desktop_focus_output(output_from_name(server, output_name));
	}
	break;

[jp7677]

I tried the following snipped, but this only works for snapped or maximized windows, do you have a hint what is actually needed?

case ACTION_TYPE_MOVETO_OUTPUT:
	{
		const char *output_name = action_get_str(action, "output", NULL);
		struct output *output = output_from_name(server, output_name);
		if (output && view && view->output != output) {
			view_set_output(view, output);
			view_adjust_for_layout_change(view);
		}
	}
	break;

[ahesford]

Changing the output of a floating window doesn't help because following windows are dynamically assigned to whatever output contains their centroids. Calling view_adjust_for_layout_change will also have unintended side effects (and will probably fail altogether) now that this function attempts to cache the last user-specified positions and restore windows to those positions if an output can contain them. The right behavior is probably to view_move the window (making sure to invalidate the last-layout position) to a point expressly on the new output. Afterwards, applying the placement policy (automatic if configured, center otherwise) is probably desirable. There won't be a lot of value in trying to preserve the original relative position of a floating window cast to a new output, because outputs may be sized differently and will almost certainly have other contents that will interfere with the window.

Moving to outputs by name is probably not all that useful an action. Directional moves to the next output in some cardinal direction are probably far more useful, intuitive and adaptable to changing layouts. The MoveToEdge action shows how to find the "next" output.

[jp7677]

Thanks a lot for the detailed info.

Yes, i fully agree that sending to output by name is not optimal and from a user perspective a SendToOutput should behave the same as SendToDesktop with the same options but for outputs instead. I think a snapped or maximized window should remain the same snapped/maximized position on the new output. If it is floating, applying placement policy sounds indeed fine.

I got enthusiast by johanmalm's response and thought everything is in place and just a few lines are needed to wire things together. Well, reading your reply and also playing a bit I already figured it is not that easy, at least not for my limited knowledge in this area. To be honest I'm happy to help testing when somebody else comes up with something, but I don't think i can create a PR that covers all cases and is still fun to review.

[ahesford]

Actually, I think most of the pieces are in place. For floating windows, this is pretty much already done in MoveToEdge. A MoveToOutput can re-use most of that, effectively setting snapWindows="false" and skipping the "opposite edge" behavior in favor of just jumping to the first edge on the next display.

[droc12345]

Hi and thanks for writing. I agree that it would be nice to be able to set the workspace independently of outputs. We have looked at this before and the main reasons it's not implemented are: a. It's not a high priority of current core devs in terms of personal requirements (so effort goes elsewhere). b. It would be quite a deep, systemic change touching many areas of the code base.

What's a rough idea of what would be needed?
I'm thinking that views need to know about workspace and output
workspace needs to know about output,
output needs to know about current workspace

Do we keep all views in one heap or do we separate out views per output?

[minsoehan]

Hi, thanks for discussing. Yeah, even if setting independent workspace of outputs is not a good issue for scope of code base to touch, I hope SendToOutput action would be available in a future release soon.

[jp7677]

See #1457

[stefonarch]

Recently we are testing pcmanfm-qt's desktop for multiple monitors (and we ironed out also the bugs in lxqt-runner and notificationd for multiple monitor setups). I didn't use multiple monitor setups before so all this is quite new to me.

Using workspaces and rules for placing the windows on their dedicated workspace for years I immediately noticed that dual monitor could be similar to that, but only if monitors are treated independently as proposed here. If I'd use on a stable basis dual monitor setup I would probably replace some workspace rules with monitor rules.