Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wayland Protocol Finally Ready for Fractional Scaling

phoronix.com

Post reply on HN
Print view View original

91–100 of 102 posts

Re: Wayland Protocol Finally Ready for Fractional Scaling

#91

Post by QEIAo7BCrzKtYQ »

Sakos wrote: post #65
jpetso wrote: post #60

Earlier quoted context omitted.

> Is that why they're so unresponsive to user needs? It's because Wayland is a set of protocols, rather than a single dominant implementation. In order to do it right, cross-compositor and flexible, you have to get different actors with different interests and bandwidth agree on a standard. This takes time. In order to get it working fast, developers need to make a compositor-specific implementation first and then pu…

Sounds like a terribly managed project that will never reach an acceptable state. Again, I don't know why people are so tolerant of it. If the Linux kernel had worked the same way, we'd never have gotten Linux.

>If the Linux kernel had worked the same way, we'd never have gotten Linux.

Yes we would. In fact it's exactly how Linux works and has worked for decades. New features get added in drivers and then get rolled up into driver subsystems when enough hardware supports them.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#92

Post by hackyhacky »

Ptchd wrote: post #84
hackyhacky wrote: post #37

Earlier quoted context omitted.

People are responding to this comment by saying "Screenshots work," and yes, they do, somewhat. However, you're limited to using the screenshot tool built in to your Wayland compositor, rather than any third-party tool. For example, my favorite screenshot tool supports automatic timed screenshots, of particular windows or the whole screen or of a specified region, of one desktop or several, and various customizations…

> However, you're limited to using the screenshot tool built in to your Wayland compositor That not true anymore... I use Flameshot

It offers a degraded experience depending on your compositor.

https://flameshot.org/docs/guide/wayland-help/

Re: Wayland Protocol Finally Ready for Fractional Scaling

#93

Post by chlorion »

mort96 wrote: post #53
ybc37 wrote: post #31

Earlier quoted context omitted.

> xclip, read from and write to the clipboard in the command line There's wl-clipboard with the commands wl-copy and wl-paste: https://github.com/bugaevc/wl-clipboard Works flawless in my experience.

Doesn't that have to create a window to interact with the clipboard? That makes it quite disruptive in some contexts.

No it doesn't do anything like that. I am not sure where this idea came from but it's totally incorrect.

I have also been using the wl-clipboard program with no issues like the parent commenter. I use it for my password store, which decrypts a file containing the password with GPG and pipes it into the clipboard!

Re: Wayland Protocol Finally Ready for Fractional Scaling

#94

Post by kaba0 »

Sakos wrote: post #48
WhyNotHugo wrote: post #41

Earlier quoted context omitted.

> For example, my favorite screenshot tool supports automatic timed screenshots, of particular windows or the whole screen or of a specified region, of one desktop or several, and various customizations. Those features aren't supported by my compositor, and I don't have a choice. So Wayland limits my options. Xorg doesn't support his either. Your screenshotting tool runs the timer and takes the screenshot when the ti…

> Xorg doesn't support his either. Your screenshotting tool runs the timer and takes the screenshot when the timer expires. You complaint is like saying "the Linux kernel won't render markdown for me". No, it won't, you're looking at the wrong part of the stack. Xorg also doesn't prevent you from using an application that does have these functions. Wayland does prevent you. > but it's perfectly possible to write with…

> Xorg also doesn't prevent you from using an application that does have these functions. Wayland does prevent you.

Surely, as much as seatbelts prevent my movement. And literally every wayland compositor has this functionality, that there is not a universally supported standard here sucks, but that’s just the way of life of the bazaar. There is no one company exerting a cathedral approach over the whole thing, and I believe that is what most of the linux users prefer. It just so happens to have some tradeoffs as well.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#95

Post by kaba0 »

FloatArtifact wrote: post #51
WhyNotHugo wrote: post #42

Earlier quoted context omitted.

Most of these things work fine (though with wayland-specific tools, rather than X-specific tools), except: > (4) global indicator of where my cursor is (xeyes) AFAIK, no tool allows you to do this. The issue is: clients generally can't snoop on input when they're not in foreground (e.g.: to make key-loggers less trivial). A privileged client could do this using something like layer-shell. It's a hack, but it should w…

Pretty much any accessibility or automation software suffers here without having to be a root. Wayland makes accessibility impossible is developer with its fragmentation. Want to make tools that work across now Wayland ecosystem good luck with that.

It’s almost like there are layers to security. You don’t have to be root, but nor should any random npm install script be able to steal keystrokes and send them away. While we are it, linux desktop security just sucks all around.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#96

Post by [deleted] »

saurik wrote: post #49
hackyhacky wrote: post #37

Earlier quoted context omitted.

People are responding to this comment by saying "Screenshots work," and yes, they do, somewhat. However, you're limited to using the screenshot tool built in to your Wayland compositor, rather than any third-party tool. For example, my favorite screenshot tool supports automatic timed screenshots, of particular windows or the whole screen or of a specified region, of one desktop or several, and various customizations…

> ...without any of the modularity and flexibility that Linux is (allegedly) proud of. Linux seems to have been infiltrated by people who simply don't believe in this anymore, and so we keep getting "modern" "batteries included" integrated monoliths that suck at everything but supposedly make things easier because this new crop of people don't want to have to know about or compare multiple options :(. And like, becau…

[deleted]

Re: Wayland Protocol Finally Ready for Fractional Scaling

#97

Post by unconed »

sho_hn wrote: post #73
ChuckNorris89 wrote: post #54

Earlier quoted context omitted.

>I'm not a fan of some standardization of protocols that is going on in Linux desktops Standardization and Linux desktops are sometimes mutual conflicting terms. There's doesn't seem to be much standardization on this front but tribes of people saying "new things should be this way" and other tribes saying "n'ah mate, that sucks, we'll keep using our own better way". Linux desktops don't have the Apple/Microsoft dict…

> Linux desktops don't have the Apple/Microsoft dictatorship powers to actually enforce any kind of GUI standards so we get this constant hassle and even more fragmentation. Do Apple and Microsoft actually have them? The GUI experience on Windows is relatively disjointed, and Apple famously did it to itself with e.g. randomly chosen brushed metal windows and other app-specific background textures. It appears far more…

>brushed metal windows and other app-specific background textures.

You're about a decade late with this complaint... and wrong. The brushed metal look was for application windows that resembled "appliances", which would remain open as you loaded/saved different projects. This was to distinguish them from the normal white document windows, which are tied 1-to-1 to a file.

I'm not saying they always followed this rule exactly... but there definitely was a rule. And the Apple of the era would publish detailed Human Interface Guidelines detailing all the thinking and intended practices. Third party mac software of that era was famously extremely consistent too, because of this shared base.

I only have one request from Linux desktops: mac style shortcuts with meta instead of ctrl. I also know it will never happen because everyone took their cues from messy Microsoft instead of the superior Apple practices.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#98

Post by hackyhacky »

QEIAo7BCrzKtYQ wrote: post #89
hackyhacky wrote: post #43

Earlier quoted context omitted.

You're missing my point. The Wayland architecture does not give me a choice in my screenshot, video recording, and remote desktop tool: you have to use the functionality built in to the compositor. Many compositors (notably GNOME and KDE) don't support the Wayland semi-standard interface for these things. You mentioned shotman, but that isn't even a real screnshotting tool: it's just a screenshot GUI that depends on…

>The Wayland architecture does not give me a choice in my screenshot, video recording, and remote desktop tool Yes it does. Use the screenshot, screencast and remote desktop XDG portals for that. It's understandable you're confused because the X11 way was to try to jam everything into X extensions whether it made sense or not. The overall trend lately is to move APIs into other components (XDG portals, pipewire, DBus…

The portal only allows an external application to request the service from the compositor. He portal does not allow an external application to provide additional functionality beyond what is already provided by the compositor.

In my use case, I want to screen share a specific window, not the whole screen; this is functionality previously provided by a third-party X11-based tool, which cannot be provided from an XDG portal (even on those compositors that support portal at all).

Re: Wayland Protocol Finally Ready for Fractional Scaling

#99

Post by WhyNotHugo »

hackyhacky wrote: post #43
WhyNotHugo wrote: post #41

Earlier quoted context omitted.

> For example, my favorite screenshot tool supports automatic timed screenshots, of particular windows or the whole screen or of a specified region, of one desktop or several, and various customizations. Those features aren't supported by my compositor, and I don't have a choice. So Wayland limits my options. Xorg doesn't support his either. Your screenshotting tool runs the timer and takes the screenshot when the ti…

You're missing my point. The Wayland architecture does not give me a choice in my screenshot, video recording, and remote desktop tool: you have to use the functionality built in to the compositor. Many compositors (notably GNOME and KDE) don't support the Wayland semi-standard interface for these things. You mentioned shotman, but that isn't even a real screnshotting tool: it's just a screenshot GUI that depends on…

There's discussions in progress about adding the ability to capture a single toplevel window to the screencopy protocol. Nobody's decided that it's a bad idea, it merely hasn't been implemented yet.

Regarding the fact that GNOME doesn't implement a lot of functionality: I don't think it's fair to criticise the protocol and architecture because one implementation decides not to implement a given feature. This is like saying "C sucks because some specific compiler doesn't support the feature I need". It's the compiler you've chosen that sucks in that case, not the language.

I'm sure there's some X server implementation out there that's also lacking features you want -- but you wouldn't blame the protocol itself for that implementation's shortcomings.

Re: Wayland Protocol Finally Ready for Fractional Scaling

#100

Post by WhyNotHugo »

QEIAo7BCrzKtYQ wrote: post #89
hackyhacky wrote: post #43

Earlier quoted context omitted.

You're missing my point. The Wayland architecture does not give me a choice in my screenshot, video recording, and remote desktop tool: you have to use the functionality built in to the compositor. Many compositors (notably GNOME and KDE) don't support the Wayland semi-standard interface for these things. You mentioned shotman, but that isn't even a real screnshotting tool: it's just a screenshot GUI that depends on…

>The Wayland architecture does not give me a choice in my screenshot, video recording, and remote desktop tool Yes it does. Use the screenshot, screencast and remote desktop XDG portals for that. It's understandable you're confused because the X11 way was to try to jam everything into X extensions whether it made sense or not. The overall trend lately is to move APIs into other components (XDG portals, pipewire, DBus…

Portals are a really weird thing. They're mostly pushed via the Flatpak/GNOME crowd, and are intended to be cross platform by using an external messaging bus: d-bus (e.g.: they don't use the X protocol and Wayland). The same interface can be used in both Xorg and Wayland, and that's the only upside of portals.

However, their implementation is not meant for native applications and are pretty inefficient. For example, the screenshot portal will save the image into disk and return its path -- so if you wanted to render the image on screen, you now need to read and decode a file. The screenshot is encoded, serialised to disk, serialised FROM disk and then decoded again just to get pixels from the compositor back into the compositor.

Portal really don't make sense if you're writing native wayland clients, since portals just really end up using the wayland protocol under the hood, with two or three services in the middle handing messages over just to expose a "standard" API.

Post reply on HN