6 ms·

Universal keybinding and screen capture of any kind. Kind of show stoppers for people who actually use their window manager for managing windows.

by hyperion2010 7y ago

whatshisface 7y ago
I use screen capture and remote operation every day. Are those features planned?
- hyperion2010 7y ago
  As far as I know not into the wayland protocol itself. The devs have been pretty adamant that wayland is 'just the compositor' and left the rest as an exercise for the community, or the toolkit developers. So for instance there is https://github.com/foss-project/green-recorder https://github.com/foss-project/green-recorder but as far as I can tell on wayland it only works for gnome, and requires dbus to work (wat?!).
  - Spivak 7y ago
    * Screen recording is a privileged operation in Wayland which is left to compositors to implement as they see fit. * Screen recording apps are therefore largely just nice frontends on whatever primitives the compositor exposes to do screen recording. * GNOME speaks dbus and exposes those primitives as dbus services. * So you need to speak dbus. You can't really avoid dbus without going really far out of your way these days. Unless something better comes along it's going to be the Linux messaging passing system.
  - majewsky 7y ago
    The wlroots developers have proposed protocols for screen grabbing etc. which are already supported by some window managers (e.g. Sway) and by some applications. https://github.com/swaywm/wlr-protocols https://github.com/swaywm/wlr-protocols
- maxharris 7y ago
  I don't use remote operation (as imagined by X11) at all. But I do use non-X11 screen-sharing systems all the time. Ask yourself, "why do all of the major GUI systems - in daily use by billions of people, evolved over the past 40 years - opt to offer remote operation only as an optional add-on?" Maintainers, beware of the tail wagging the dog!
  - petschge 7y ago
    And I use remote operations all day every day. As does the entire department with hundreds of people. Don't dismiss other peoples works flows without understanding them.
    - maxharris 7y ago
      (I ran Linux + X11 as my sole desktop from 1996-2000. And then on and off again for years in VMs.) I'm not dismissing the need. I'm just saying that the other systems work pretty well, and this is not something that needs to be baked into the core of the display system. I used and loved Screenhero on the Mac for years before Slack swallowed them up. (Now there's tuple.app, made by some of the same people.) Prior to that, I used Windows RDP for years. That worked pretty well, too!
      - petschge 7y ago
        Sorry if I misread your comment and thanks for editing it to make it clearer. But why are you so opposed to having this featured backed into the display system? After all you point out yourself that all display systems and up with solutions for this work flow. Why not do it right and build it into the display system instead of adding it after that fact (and usually in an inferior qay)?
        maxharris 7y ago
        I'm against baking it in precisely because it's not the right thing. Network transparency in X11 led to a design that didn't scale to meet the needs of the vast majority of users: "The X11 protocol was never meant to handle graphically (in terms of bitmaps/textures) intensive operations. Back in the day when X11 was first designed computer graphics were a lot simpler than they are today. Basically X11 doesn't send the screen to your computer, but it sends the display-instructions so the X-server on your local computer can re-create the screen on your local system. And this needs to be done on each change/refresh of the display. So your computer receives a stream of instructions like "draw line in this color from coordinates x,y to (xx,yy), draw rectangle W pixels wide, H pixels high with upper-left corner at (x,y), etc." The local client isn't really aware what needs to be updated and the remote system has very little information on what the client actually needs, so basically the server must send a lot of redundant information that the client may or may not need. This is very efficient if the display to be rendered consists of a limited number of simple graphical shapes and only a low refresh frequency (no animations and such) is needed. Which was the case back in the days when X11 was first developed. But modern GUI's have a lot of eye-candy and much of that needs to be send from the remote system to your client in the form of bitmaps/textures/fonts which take quite a lot of bandwidth. And all sorts of eye-candy includes animated effects requiring frequent updates. And the displays keep getting bigger too, twice as wide/high is 4x the number of pixels. Of course, over time, enhancements to the X11 protocol were made to optimize this as much as possible, but the basic underlying design is, in essence, simply not well suited to the demands of the kind of GUI's people nowadays expect. Other protocols (like RDP and VNC) are more designed to let the remote system do all the hard work and let that system decide which updates to send to the client (as compressed bitmaps) as efficiently as possible. Often that turns out to be more efficient for modern GUI's. Neither method is perfect and can deal with every situation equally well. There is no such thing as a single display-protocol that can do well under every conceivable use-case. So in most cases you just try all protocols that are supported between your local client and the remote server and use the one that gives the best results. And in some cases there is no choice and you just have to make do with whatever is available. Most protocols do allow some performance tuning, but many of these settings are server-side only and not available to the average user. (And configuring them properly is a bit of an arcane art. A lot of sys-admins won't be willing to mess with that.) In most cases the easiest way to improve performance (sometimes quite dramatically) is by switching to a more simple desktop environment with less eye-candy and forego the use of background images." https://superuser.com/a/1217295 https://superuser.com/a/1217295
- snazz 7y ago
  Screenshots and recordings work fine with Sway and GNOME. I don’t know about other compositors. See https://github.com/swaywm/sway/wiki#taking-screenshots https://github.com/swaywm/sway/wiki#taking-screenshots
- sq_ 7y ago
  swaywm supports screenshots and screen capture for sure [0]. I haven't personally done anything with screen capture on sway, but I can definitely confirm that grim works for screenshots. [0] https://github.com/swaywm/sway/wiki#taking-screenshots https://github.com/swaywm/sway/wiki#taking-screenshots

Universal keybinding and screen capture of any kind. Kind of show stoppers for people who actually use their window manager for managing windows.

whatshisface 7y ago

I use screen capture and remote operation every day. Are those features planned?

hyperion2010 7y ago
As far as I know not into the wayland protocol itself. The devs have been pretty adamant that wayland is 'just the compositor' and left the rest as an exercise for the community, or the toolkit developers. So for instance there is https://github.com/foss-project/green-recorder https://github.com/foss-project/green-recorder but as far as I can tell on wayland it only works for gnome, and requires dbus to work (wat?!).
- Spivak 7y ago
  * Screen recording is a privileged operation in Wayland which is left to compositors to implement as they see fit. * Screen recording apps are therefore largely just nice frontends on whatever primitives the compositor exposes to do screen recording. * GNOME speaks dbus and exposes those primitives as dbus services. * So you need to speak dbus. You can't really avoid dbus without going really far out of your way these days. Unless something better comes along it's going to be the Linux messaging passing system.
- majewsky 7y ago
  The wlroots developers have proposed protocols for screen grabbing etc. which are already supported by some window managers (e.g. Sway) and by some applications. https://github.com/swaywm/wlr-protocols https://github.com/swaywm/wlr-protocols
maxharris 7y ago
I don't use remote operation (as imagined by X11) at all. But I do use non-X11 screen-sharing systems all the time. Ask yourself, "why do all of the major GUI systems - in daily use by billions of people, evolved over the past 40 years - opt to offer remote operation only as an optional add-on?" Maintainers, beware of the tail wagging the dog!
- petschge 7y ago
  And I use remote operations all day every day. As does the entire department with hundreds of people. Don't dismiss other peoples works flows without understanding them.
  - maxharris 7y ago
    (I ran Linux + X11 as my sole desktop from 1996-2000. And then on and off again for years in VMs.) I'm not dismissing the need. I'm just saying that the other systems work pretty well, and this is not something that needs to be baked into the core of the display system. I used and loved Screenhero on the Mac for years before Slack swallowed them up. (Now there's tuple.app, made by some of the same people.) Prior to that, I used Windows RDP for years. That worked pretty well, too!
    - petschge 7y ago
      Sorry if I misread your comment and thanks for editing it to make it clearer. But why are you so opposed to having this featured backed into the display system? After all you point out yourself that all display systems and up with solutions for this work flow. Why not do it right and build it into the display system instead of adding it after that fact (and usually in an inferior qay)?
      - maxharris 7y ago
        I'm against baking it in precisely because it's not the right thing. Network transparency in X11 led to a design that didn't scale to meet the needs of the vast majority of users: "The X11 protocol was never meant to handle graphically (in terms of bitmaps/textures) intensive operations. Back in the day when X11 was first designed computer graphics were a lot simpler than they are today. Basically X11 doesn't send the screen to your computer, but it sends the display-instructions so the X-server on your local computer can re-create the screen on your local system. And this needs to be done on each change/refresh of the display. So your computer receives a stream of instructions like "draw line in this color from coordinates x,y to (xx,yy), draw rectangle W pixels wide, H pixels high with upper-left corner at (x,y), etc." The local client isn't really aware what needs to be updated and the remote system has very little information on what the client actually needs, so basically the server must send a lot of redundant information that the client may or may not need. This is very efficient if the display to be rendered consists of a limited number of simple graphical shapes and only a low refresh frequency (no animations and such) is needed. Which was the case back in the days when X11 was first developed. But modern GUI's have a lot of eye-candy and much of that needs to be send from the remote system to your client in the form of bitmaps/textures/fonts which take quite a lot of bandwidth. And all sorts of eye-candy includes animated effects requiring frequent updates. And the displays keep getting bigger too, twice as wide/high is 4x the number of pixels. Of course, over time, enhancements to the X11 protocol were made to optimize this as much as possible, but the basic underlying design is, in essence, simply not well suited to the demands of the kind of GUI's people nowadays expect. Other protocols (like RDP and VNC) are more designed to let the remote system do all the hard work and let that system decide which updates to send to the client (as compressed bitmaps) as efficiently as possible. Often that turns out to be more efficient for modern GUI's. Neither method is perfect and can deal with every situation equally well. There is no such thing as a single display-protocol that can do well under every conceivable use-case. So in most cases you just try all protocols that are supported between your local client and the remote server and use the one that gives the best results. And in some cases there is no choice and you just have to make do with whatever is available. Most protocols do allow some performance tuning, but many of these settings are server-side only and not available to the average user. (And configuring them properly is a bit of an arcane art. A lot of sys-admins won't be willing to mess with that.) In most cases the easiest way to improve performance (sometimes quite dramatically) is by switching to a more simple desktop environment with less eye-candy and forego the use of background images." https://superuser.com/a/1217295 https://superuser.com/a/1217295
snazz 7y ago
Screenshots and recordings work fine with Sway and GNOME. I don’t know about other compositors. See https://github.com/swaywm/sway/wiki#taking-screenshots https://github.com/swaywm/sway/wiki#taking-screenshots
sq_ 7y ago
swaywm supports screenshots and screen capture for sure [0]. I haven't personally done anything with screen capture on sway, but I can definitely confirm that grim works for screenshots. [0] https://github.com/swaywm/sway/wiki#taking-screenshots https://github.com/swaywm/sway/wiki#taking-screenshots