5 ms·
Those things are mostly compositor specific and not specifically a Wayland issue. For example with Sway: * Programmatic output configuration swaymsg -t get
by iod 8y ago
Those things are mostly compositor specific and not specifically a Wayland issue. For example with Sway:
* Programmatic output configuration
swaymsg -t get_outputs # get displays
swaymsg output DP-1 pos 0 0 res 1920x1080 # set displays
* CLI clipboard access
swaymsg -t get_clipboard
* Third party app launcher/window switcher
I use gnome-panel with Xwayland, but better than nothing
* Third party screen shot/capture/share
https://github.com/foss-project/green-recorder https://github.com/foss-project/green-recorder
* Color picker (gpick, gcolor3, kcolorchooser)
Sorry, no options here yet, but it can be done
* xdotool
swaymsg [title="Top Panel"] floating enable, resize set width 2560 px height 32 px, move position 0 -38
- gpm 8y agoNo, it's fundamentally a wayland issue. Window managers can implement their own extra protocols of course, but instead of X11 where everything was standardized and window managers didn't even have to think about it, there is no standard and window managers have to rewrite all the code for it themselves.
- AsyncAwait 8y ago> No, it's fundamentally a wayland issue. It's not an "issue". It's a design decision. As another example, Linux doesn't have just one desktop environment, like Windows or MacOS, would you say that's an "issue", even if it's a deliberate decision?
- pmoriarty 8y agoAs OP in the thread I linked to above says: "GNOME and KDE have dbus APIs for some (but not all) of these things, and sway has its own IPC, and other compositors probably have similar solutions. However, they all use different mechanisms, which means that if you are writing say, screenshot application you either have to write a different backend for every compositor, or choose just one or two to support. "Something all of these types of applications have in common is they need to be able to inspect and/or modify state from other applications or the compositor itself. Which wayland's security model normally prevents. I think a major gap in wayland, is having a way for an application to run with escalated permissions so it can have access to other applications. Unfortunately, I don't have any great ideas on what that would look like." and then, later in the thread: "for simple things using the compositor's screen shot tool is fine. But what if I don't like the screenshot tool for my compositor of choice? My experience with the GNOME screenshot tool (granted this was pre-wayland) was that it wasn't as good as, say, shutter, which has a lot of options, let's you easily crop and edit the screenshot from inside the screenshot tool etc. And then swaygrab doesn't even (currently) have an option to capture a rectangular region." The entire thread linked to above is worth reading. My own takeaway is that Wayland is just way too immature to compete with X for my power-user use cases. It might be ok for users with simple needs.