Able to choose which monitor to display on

[ErikReider]

• Choose monitor as config option
• Notification window logic
• Control center logic
• Test if disconnecting monitor breaks this
• Open on focused monitor if the chosen display isn't found

[nwg-piotr]

You may have a better idea. My solution only supports symbolic output names (like eDP-1). I list them by the sway IPC, then list Gdk.Monitor instances. By comparing x and y coordinates, I map output names to Gdk.Monitors. Then I only need layershell.SetMonitor. See this.

[ErikReider]

You may have a better idea. My solution only supports symbolic output names (like eDP-1). I list them by the sway IPC, then list Gdk.Monitor instances. By comparing x and y coordinates, I map output names to Gdk.Monitors. Then I only need layershell.SetMonitor. See this.

I'll take a look at this after work :)

[ErikReider]

But it doesn't work on other wlroots based WMs though right? The most optimal solution would be to not use sway ipc. Does your stuff work in dwl and river?

[nwg-piotr]

To list outputs on other compositors, you'd need to talk to wlroots, or just parse wlr-randr output.

[nightly-brew]

Although it's easier said than done, It would be better to avoid binding to another specific program like wlr-randr, and instead make use of wayland protocols directly I think.

[nwg-piotr]

Of course. I didn't care about it much, as the shell is primarily aimed at sway. Finally I won't avoid doing the same.

[nwg-piotr]

While working on the Swaync panel module, I realized, that the output selection is not really essential to me, since the client will be opened on icon click. In most cases (apart from gtk-layer-shell oddities) the appropriate output will be already focused. The only use of this feature would be to determine which screen to display notifications themselves on.

[nightly-brew]

While working on the Swaync panel module, I realized, that the output selection is not really essential to me, since the client will be opened on icon click. In most cases (apart from gtk-layer-shell oddities) the appropriate output will be already focused. The only use of this feature would be to determine which screen to display notifications themselves on.

Makes sense to me!

Reading around I think the compositor should provide a wl_output for each output without any need to register an output manager, though at least registering a listener for output events might be useful to change output if the configured one is disconnected/unregistered, for instance.

[ErikReider]

While working on the Swaync panel module, I realized, that the output selection is not really essential to me, since the client will be opened on icon click. In most cases (apart from gtk-layer-shell oddities) the appropriate output will be already focused. The only use of this feature would be to determine which screen to display notifications themselves on.

Makes sense to me!

Reading around I think the compositor should provide a wl_output for each output without any need to register an output manager, though at least registering a listener for output events might be useful to change output if the configured one is disconnected/unregistered, for instance.

Yeah. I'll need to build some vala bindnings

[nwg-piotr]

No hurry, if it comes to integration with the shell. It's absolutely usable as is, and looks great.

[ErikReider]

@nwg-piotr Found out that there's a way of getting display connector names in GDK but it was deprecated. In GDK 4 they have gdk_monitor_get_connector which also exists in GDK 3 but is private. https://gitlab.gnome.org/GNOME/gtk/-/issues/4982

[nwg-piotr]

For my use case I just attached swaync-client -t to a panel icon, so the window opens where I want it to. No major problem.

[MathisP75]

Has this feature been abandoned?

[ErikReider]

Has this feature been abandoned?

I've moved it into #262

The only issue is a segfault on monitor disconnect. Otherwise it's ready