Hacker News new | past | comments | ask | show | jobs | submit login

I've been very patient with Wayland, trying it out every once in a while for the past few years, wasting many hours following the endless discussions, and simplifying my setup to avoid X11-specific tools etc. These days I just don't care anymore, and will stay on Xorg as long as I can.

Besides screensharing, which from what I hear is still a clusterfuck (i.e. it can work just fine, but any given app might or might not work), I've whittled it down to two, seemingly very basic and essential-to-me features, that for some reason still aren't supported:

Window positioning:

As in, the ability for an app to request a specific position for a window. Like when I minimize my music player to the tray, and when I open it again I want it to appear in the same location. Or when productivity apps remember the positions of their tool windows, or I want to script apps to start in specific positions using the near-universal "--geometry" flag of old. Wayland doesn't want to expose global coordinates, supposedly for security reasons (which I call bullshit on), and in order not to discriminate against non-finite/non-square displays (which I guess could just ignore the position requests, but apparently that's not good enough).

One of the proposed solutions for this is the "xdg-session-management" protocol, where it would be the compositor's job to remember window positions for client apps. But to me that only sounded like a partial solution that probably won't ever work consistently, and anyway there hasn't been much progress on the MR for this which was started a full 4 years ago. There's been a lot of activity recently with the "ext-placement" protocol, which from what I understand introduces an application-local "zone" system which will allow window positioning in a very roundabout way that will hopefully please everyone. I appreciate everyone's work on this, but at this rate it will probably take a couple more years until compositors support this new protocol, and client apps have made the necessary changes.

Refresh rate changes:

I have a HTPC connected to a TV. No refresh rate changes means I get constant micro-stutters when watching 24fps content. And yes, I do notice them, and no, turning on motion smoothing doesn't make them go away (and looks even crappier anyway). There are protocols to request refresh rate changes (last time I looked, at least four of them), but client apps like Kodi are not allowed to use them (only system management tools), and proper support for apps to signal a desired refresh rate is tangled up in discussions about achieving the perfect design to support VRR. So I'll give this at least a couple more years too.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: