Multi-screen support about waypaper HOT 13 CLOSED

Yes, free input field might also be a good idea. Now that I finished with other features, I'll try to work on this.

from waypaper.

Hi, so I implemented a beta version of multimonitor support, so far only on swww. If you are using AUR version, you can test it!

With swaybg it proved to be more difficult, because it sort of requires different instances of swaybg to run for each monitor, but then those processes are never killed and accumulate in the memory. I'll think about a better way to deal with that. I'll also need to implement saving different wallpapers for different monitors, now --restore restore the last wallpaper on all monitors.

from waypaper.

Absolutely. At the moment, I'm trying to see which backends support this feature (only swaybg I suppose) and plan how to show this function on some backend and hide on other backends. The problem is that I don't actually have second screen to test :) Otherwise it should be easy to implement in swaybg.

from waypaper.

swww also support with --output, maybe we need add the function for swww and swaybg first, then waiting other dev to add more

from waypaper.

One important question is what would be a universal way to check what displays are available in the system that would work in different window managers on both Wayland and Xorg? Preferably without using other tools (python libs are okay).

from waypaper.

I had check swww and Smithay's Client Toolkit, then I find a lib seems useful PyWayland

from waypaper.

I think it's a bit overkill, I hope that simple check of environmental variable should be enough, like:
echo $WAYLAND_DISPLAY or echo $DISPLAY, but I didn't test on different systems and multiple monitors.

However, in Azote there is a pretty huge function check_displays() to just check displays in all different cases, so probably it's not so simple...

Another strategy would be to use backend themselves to inquire information about monitors. For example, swww query works well, once swww demon is running.

from waypaper.

Yeah swww can do that, but we cannot force dependent swww.
Bye the way, environmental variable is not include the infos.
I had 2 screen, maybe I will try to dev it or test it.
And the simplest way is add a list to let user add screen name by theirself.

from waypaper.

Personally, I don't see the problem if the multiscreen feature is only available on swww backend. Like, when swww is selected as backend, a new option becomes available: a drop-down menu with list of displays from swww query. For other backends, it won't appear. This can be implemented in just several lines. By contrast, looking at the example with Azote's function to determine monitors, only that check_displays() function is almost as large as the entire code of waypaper. I mean, the goal of this application is mainly to be a nice GUI frontend for the functionality provided by the backends.

from waypaper.

I like your idea, but I think if we cannot auto get screen info by right and simple way, maybe the best way is add a list which user can input there screen name at here.
Because you also do not have many screen, so you can not test it, I don't want this to be your nightmare of maintenance.
That can avoid adding a lot of logical judgments and we don’t need to modify a lot of code every time, if other backends add multi-screen support later.

from waypaper.

Good job, I had test it by pipx, it's working fine in multi-screen. (version 1.8.2)

Thank you

from waypaper.

By the way, saving multimonitor configuration is implemented as well in version 1.9, so it restores the same wallpapers to the same monitors upon --restore.

from waypaper.

By the way, saving multimonitor configuration is implemented as well in version 1.9, so it restores the same wallpapers to the same monitors upon --restore.

Yeah, but I had used the function when it was 1.8.2! (idk why it work when you not implement), LOL

from waypaper.