Announcement

Collapse
No announcement yet.

Why Wayland & Weston Were Forked

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Minimise as a result of window stacking

    If the "desktop" (e.g. background picture) was a full-screen surface, then minimise could just mean stacking minimised windows behind it. Then you would only need to deal with windows being normal, maximised and full-screen. Restoring the window would mean stacking it in front of the desktop, probably as the top window.

    With minimised windows stacked behind the desktop, then doing previews should not be a problem.

    Comment


    • #22
      Originally posted by soreau View Post
      One technical concern I forgot to mention was one that I just noticed when a user notified me about a problem when using the window list (taskbar) found in northfield/norwood. The problem is, that there is supposed to be a protocol versioning system in place so that you can make additions to the protocol and increment the relevant interface version number. In theory, this is supposed to work in a way that clients would only use the highest interface version it supports locally, to avoid problems with potential crashes when related events/requests are processed. It is yet another technical problem involving the protocol interface versioning system. See the very bottom of http://lists.freedesktop.org/archive...ch/008084.html

      My questions there have yet to answered. I tried to work out a solution to this problem with them but they seem like they don't want this new stuff to happen in the first place for some reason. I followed protocol but the version control system is broken by design apparently.
      1) No, you can't mix and match versions, since the scanner generates opcodes sequentially. So, if you insert a request in the middle, it changes the opcode of everything after it and your extension is broken.
      2) Simple: when the client binds to an interface, it sends the highest version it supports to the compositor. The compositor's then responsible for not sending events to a client it won't be able to understand since it doesn't support a high enough version of the interface.
      3) If you're talking about the wl_surface implicit attach semantics, they were stuck in a halfway house, so got changed to be one definite state. It was unpleasant but had to be changed one way or another.

      I didn't reply to explain this at the time because every conversation with you usually ended in either a torrent of abuse (much like the recent ones where you were repeatedly threatening to try to get me fired in private, whilst acting all nice and reasonable on the forums ...) or you flat-out ignoring what I said, so my desire to go out of my way to help you by explaining how the core Wayland protocol works is roughly zero.

      Comment


      • #23
        Originally posted by GreatEmerald View Post
        I mean, I don't suppose Wayland developers are happy with fast changes to the protocol at this point
        Specifically, we didn't want our core interfaces to include protocol with design flaws which were pointed out in review and left unfixed. http://lists.freedesktop.org/archive...ch/008116.html is where Scott's minimisation patches ended up, as far as Wayland goes: in review, with issues pointed out, and Scott refusing to engage with the process, just sitting out and demanding that his code be merged into core protocols (not extensions), with known issues that he'd neither fixed nor managed to explain away. The rate of change in itself was never an issue.

        Comment


        • #24
          Originally posted by GreatEmerald View Post

          But speaking about the technical side, I see both sides now, and both have a point. Wayland developers are trying to settle down at this point, so that something bad doesn't happen, now that it's past 1.0. All changes need a lot of thinking and testing now. And Northfield developers
          you seem to have a spare s there.

          Dave.

          Comment


          • #25
            Originally posted by daniels View Post
            1) No, you can't mix and match versions, since the scanner generates opcodes sequentially. So, if you insert a request in the middle, it changes the opcode of everything after it and your extension is broken.
            2) Simple: when the client binds to an interface, it sends the highest version it supports to the compositor. The compositor's then responsible for not sending events to a client it won't be able to understand since it doesn't support a high enough version of the interface.
            3) If you're talking about the wl_surface implicit attach semantics, they were stuck in a halfway house, so got changed to be one definite state. It was unpleasant but had to be changed one way or another.

            I didn't reply to explain this at the time because every conversation with you usually ended in either a torrent of abuse (much like the recent ones where you were repeatedly threatening to try to get me fired in private, whilst acting all nice and reasonable on the forums ...) or you flat-out ignoring what I said, so my desire to go out of my way to help you by explaining how the core Wayland protocol works is roughly zero.
            Right, but the problem is 2). This is the broken part. The clients do not currently do as you describe here. When you bump the version, no client changes are needed as in the very first protocol bump in wayland protocol by Ander Conselvan de Oliveira here http://cgit.freedesktop.org/wayland/...5306f27c699fff I did not notice any evidence of client changes surrounding this commit that I could tell specifically regarding the version interface client code.
            Last edited by soreau; 29 March 2013, 05:04 PM.

            Comment


            • #26
              Originally posted by airlied View Post
              you seem to have a spare s there.

              Dave.
              In correct. I will refer you to the northfield and norwood repository commit lists:

              GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 420 million projects.

              GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 420 million projects.


              You can see commits from many other contributers than myself not found in upstream wayland/weston repositories. Read up before posting, I encourage it. Thanks.

              Comment


              • #27
                Originally posted by soreau View Post
                Right, but the problem is 2). This is the broken part. The clients do not currently do as you describe here. When you bump the version, no client changes are needed as in the very first protocol bump in wayland protocol by Ander Conselvan de Oliveira here http://cgit.freedesktop.org/wayland/...5306f27c699fff I did not notice any evidence of client changes surrounding this commit that I could tell.
                There weren't any client changes because there were no new events. There's nothing from v2 the compositor could send to a v1-only client which would confuse it, and a v1-only client can't exactly send v2 requests to the compositor. If you look at clients/window.c, all the binds explicitly specify which version of each interface they support. So I'm not sure what exactly you want to change ... ?

                Comment


                • #28
                  Originally posted by daniels View Post
                  There weren't any client changes because there were no new events. There's nothing from v2 the compositor could send to a v1-only client which would confuse it, and a v1-only client can't exactly send v2 requests to the compositor. If you look at clients/window.c, all the binds explicitly specify which version of each interface they support. So I'm not sure what exactly you want to change ... ?
                  I will show you what I mean through code, in due time. Thanks for your concern.

                  Comment


                  • #29
                    Originally posted by soreau View Post
                    I will show you what I mean through code, in due time. Thanks for your concern.
                    If clients start using set_buffer_transform, then yes, they should declare that they support v2 in their bind. I think one of the key parts you're missing is that the protocol is strictly append-only, and requests do not - ever - get reordered, which was the answer to your question 1.

                    And this is _exactly_ why everyone is happy for you to fork Weston, but doesn't want you to fork libwayland and the core protocols. You don't understand how the versioning system works, so I can only assume you're on course to break it, and thus break compatibility between clients built against your library, and Wayland clients. That's the absolute disaster scenario we've all been trying to avoid, and this conversation has given me as little confidence of avoiding that, as when you refused to create your own extension protocol in the first place, and insisted on forking literally the entire Wayland protocol into your own project.

                    Comment


                    • #30
                      Originally posted by daniels View Post
                      If clients start using set_buffer_transform, then yes, they should declare that they support v2 in their bind. I think one of the key parts you're missing is that the protocol is strictly append-only, and requests do not - ever - get reordered, which was the answer to your question 1.

                      And this is _exactly_ why everyone is happy for you to fork Weston, but doesn't want you to fork libwayland and the core protocols. You don't understand how the versioning system works, so I can only assume you're on course to break it, and thus break compatibility between clients built against your library, and Wayland clients. That's the absolute disaster scenario we've all been trying to avoid, and this conversation has given me as little confidence of avoiding that, as when you refused to create your own extension protocol in the first place, and insisted on forking literally the entire Wayland protocol into your own project.
                      And the key point you're failing to understand is that I tried to ask how the core devs wanted me to do it on the mailing list. This is after querying several times on IRC in efforts to get an answer. But now I realize, the best answer is the one that I come up with, using my own common sense.

                      Comment

                      Working...
                      X