1. 21
  1.  

  2. 4

    Systray (minus right-click menu positioning)

    Is there any proposal for the positioning protocol yet? Or is the official line still that apps shouldn’t do it?

    1. 8

      Or is the official line still that apps shouldn’t do it?

      The cycle of new things: stage one is saying the old thing is bloated and useless so it needs to be thrown out. You make a “beautiful” replacement that works for you. Stage two is people asking for features but you defensively say nobody should ever do it anyway and refusing. Stage three is relenting and badly reinventing the same “bloated, useless” thing as some extensions.

      Then stage four is acknowledging maybe the designers of the past weren’t all incompetent fools and actually maybe learning from them. But by then, the new kids on the block are reaching stage one with regard to you.

      1. 4

        Or, as it actually happens with wayland, someone writes a protocol proposal and it gets implemented and everyone walks away happy, with no contempt for users or developers.

        1. 3

          The circle of….bloat. I mean features.

          1. 1

            This… is a complete misunderstanding of everything to do with X11. Nobody claims that the problem with X11 are that it lets applications provide too rich of a user experience; discrepancies between what an X11 application can do and what a Wayland application can do are usually regarded as bugs (within reason, of course) and eventually fixed. The issues people are referring to regarding X11 is actual problems with the user experience provided by X11-based systems, the fact that X11 makes sandboxing impossible, the fact that X11 makes screen tearing unavoidable, the fact that the protocol is absolutely chock-full of race conditions which causes a janky UX, the fact that there’s no concept of DPI scaling, etc etc. The bloat people refer to is the fact that X11 contains a complete GUI toolkit which literally nobody uses anymore because it’s stuck in the 80s, looks and feels like garbage, and can’t be changed because backwards compatibility.

            You should really learn something about the topic before confidently spouting bullshit. You’re free to dislike and disagree with the Wayland transition, but there are actual, good reasons for why everyone involved in actually building the graphical/GUI stack on Linux wants to get away from X11.

            1. 1

              This… is a complete misunderstanding of everything to do with X11

              the fact that X11 makes sandboxing impossible

              False.

              the fact that X11 makes screen tearing unavoidable

              False.

              the fact that the protocol is absolutely chock-full of race conditions which causes a janky UX

              Partially true, but there’s facilities to manage it.

              there’s no concept of DPI scaling

              False.

              he bloat people refer to is the fact that X11 contains a complete GUI toolkit which literally nobody uses anymore because it’s stuck in the 80s, looks and feels like garbage, and can’t be changed because backwards compatibility.

              False.

              You should really learn something about the topic before confidently spouting bullshit. You’re free to like and even agree with the Wayland transition, but you don’t have to lie about X11 and the people involved in the process.

              1. 3

                Notice how I elaborated on my point and made actual arguments. I can’t argue against “false”. If you want to be taken seriously, you should try to provide arguments. I’m up for having a nuanced conversation, but you don’t seem too interested in that.

                Being snarky isn’t an argument. Merry christmas.

                1. 3

                  Notice how I elaborated on my point and made actual arguments.

                  You know the post is right there for anyone to read and see that you did no such thing.

                  But OK, let’s talk about it. WHAT about X11 makes screen tearing unavoidable? (Answer: nothing because it is a solved problem. DRI applications work almost identically to Wayland (in fact, Wayland uses many of the same facilities), you can also use traditional techniques like double buffering and the opt-in sync extension.) WHAT about it makes sandboxing impossible? (Answer: nothing because it is a partially solved problem. The hooks are all in the server code and the extension even works in some cases, though a lot of the containerization things run a nested server instead for various reasons… but nested servers also work perfectly fine.) How do you explain DPI scaling not being a concept when there’s tons of applications that successfully implement it?

                  And none of this is material to my original point either, which is more about linked blog post. Wayland started off by throwing out over twenty years of work and breaking everything. This is an act of youthful arrogance, with no relation to technical merit. As they’ve matured, some of them have realized they were wrong and thus we see the proliferation of Wayland extension protocols. Others though, just keep lying. One of the notable points they refused to implement was any kind of global positioning, saying that’s the compositor’s job, and the applications shouldn’t know anything about the world outside their own surfaces. But the problem is that it is actually pretty useful, and as much as you want to break away from the world, there’s still applications people actually use that need this (e.g. Wine).

                  See, I know this, because I’ve actually been there. I’ve written an X toolkit. This gives me experience both in the second-system effect - I started off refusing to implement various functions (including positioning!) saying they weren’t actually useful and relented on many over the years as user-demanded use-cases forced some extensions - and in the details of working with X. Many of the things Wayland propagandists say are impossible are things I implemented in a few dozen lines of code…. maybe GTK makes it hard, maybe your buggy compositor doesn’t do it right, but X doesn’t actually block you.

                  (And this is why nobody really cares about Xaw. It costs nothing to leave there and it doesn’t prevent people from writing gtk or qt or my minigui or anything else.)

                  Similarly, claims about how “everyone involved in actually building” is just an obvious falsehood if you yourself are involved in actually building the stack. One of the authors of a lot of X extensions, a name you get to know (and kinda hate, because so much of his documentation is kinda obtuse, but he’s done a very significant amount of work on Linux graphics and X itself) is Keith Packard. He’s still working on X in between his day job and has several concrete proposals to shore up some deficiencies. You can read about it on his website: https://keithp.com looks like last update almost a year ago, but December 2020 isn’t that long ago.

                  But anyway, back to the bigger point, this is another example of hypocrisy: Wayland propagandists point to X’s 27 extensions and the freedesktop.org interop standards as proof that it is trash and balk at he idea of adding a 28th extension like Packard sometimes talks about or another inter-client specification to add whatever they want to add. Yet Wayland is now up to 58 extension protocols listed on the wayland.app website with more being talked about, including the positioning one right here! And several of those extensions (including more not specified there) are specific to particular compositors. Where in history have we seen this desire for some kind of, oh how should I say it, inter-compositor communications conventions manual before?

                  Speaking of freedesktop.org, one of the things the blog in the OP talks about is drag and drop. It talks about how it seems impossible to do full interop there. Wonderful, more breakage. But the Xdnd spec is a microcosm of this same thing too. Just look at the version history: https://freedesktop.org/wiki/Specifications/XDND/#changesfrompreviousversions

                  And it helps if you’re familiar with how it works on Windows. Or html5, which is just a tweak of the Windows way so you can see the compare and contrast in that spec. You can imagine xdnd wanted to keep things simple up front and cut a lot of the features Windows 95 had. But what happened in version 2 through 5? They started adding those things back. And one of the listed reasons is compatibility with Java. MAYBE, maybe, if you were alone in the world, you could pull off some of those changes. But in the real world, in the late 90’s, people used Java applications, so they HAD to make them work somehow. And today, people use Wine, so you HAVE to make it work somehow. Your walled garden rarely survives contact with a broad userbase.

          2. 2

            I would assume that the official stance is to let the compositor figure it out.