• 0 posts
  • 5 comments
Joined 3 years ago
Cake day: September 7th, 2023
  • This is like arguing with someone on the phoronix forums and I’m genuinely disappointed. This isn’t basic functionality, it’s a complicated design choice and just going: “do it the same way everyone else does lmao it’s not that hard” while ignoring all the problems this has caused over the years is incredibly disingenuous. I get it, you just want Windows, or MacOS or whatever traditional, windows inspired never-changing desktop UI you’re used to. You don’t care about things like different screen shapes, scrollable compositors or enabling new window management strategies. Ironically, most people can already have that with current Wayland compositors. It works fine for the vast majority of users. What’s so “ivory tower” and “not real world usage” about that? I’m using it. I have been since before it was made default in Fedora, because it solved my screen tearing issues immediately. I’m using it at work and at home. It’s fine. Yes there are missing features. No, it’s not “basic functionality” or complete deal breakers for everyone but a tiny subset of users. That obviously doesn’t stop some people from blowing it out of proportion apparently.

    Fine, pivot to complaining about the pace of development instead. I’m sure everyone who has been successfully using Wayland for years is going to see your vague hints of what’s wrong with it and the Wayland devs will go back to working on X.

    I should know better than to engage with someone willing to throw around meaningless buzzwords like ivory tower design.

  • Yes, window management systems that are as old as X have that escape hatch of allowing positioning by global coordinates. It’s pretty much impossible to take that ability away from applications when it inevitably becomes an issue.

    “You don’t want that - I know you don’t”

    You can try to frame this as pandering, condescending, mean or the devs having a personal vendetta against your workflow all you want, there are tradeoffs with such fundamental design decisions which have been deliberated over a lot. You either make global window position the sole responsibility of the compositor or you expose control to applications and get an unmanageable mess, which you can’t fix.

    Afaik, there are plans to implement additional client hints which applications can use to indicate desired window positioning or even manage relative position of multiple windows, but they don’t involve direct access to the global coordinates. This is mainly a concern for complex multi-window legacy applications which are currently stuck on xwayland. See this for example: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264

    Do you have an issue that actually requires this or do you just have an issue with how a certain compositor handles window placement?

  • No. The people who thanklessly maintained X for years have made their choice. If you want to take up that slack, go ahead. The codebase sucks and X has many missing features, some of which Wayland supports or at least can feasibly implement at some point before the heat death of the universe. Every single person that says: “if we put all that effort into X instead we would be better off” has no idea what they are talking about and has clearly never spoken to a developer who actually worked on X.

    can’t reproduce the functionality we had in the '90s

    Good. Fuck the ancient shit that has been collected over the years. There are still missing features that Wayland compositors need at some point and there are things that used to be easier with X, but if you can’t actually name anything then I’ll just assume you’re being contrarian.