Announcement

Collapse
No announcement yet.

The Ongoing Work For Native Wine Wayland Support

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

  • #21
    Originally posted by treba View Post

    They haven't enabled Lacros by default yet, but they already use Wayland in order to run Linux apps.
    Yes, but my comments were about native ChromeOS, not the Linux container. So my point still stands.

    Comment


    • #22
      Originally posted by Vistaus View Post

      Yes, but my comments were about native ChromeOS, not the Linux container. So my point still stands.
      Exo, the Wayland compositor, is a part of ChromeOS. So the phrase "ChromeOS doesn't use Wayland." is factually wrong. It's just not used for core apps *by default* yet.

      Comment


      • #23
        Originally posted by avis View Post
        How are they going to tackle absolute window positioning which is required by many applications including Adobe Suite and which is AFAIK not part of the Wayland protocol because reasons?
        I also think that absolute positioning is not a good idea.

        To allow an application to "remember it's position", the application should be allowed to suggest a window position when it creates a new window (that functionality should be added to Wayland, if missing), and the compositor should probably (but not always) accept the suggestion.

        For a few applications that actually require absolute positioning, it is probably the best to emulate it, by WinE creating a fullscreen window, and then Wine can position anything on it in any required way).

        Comment


        • #24
          Originally posted by drastic View Post
          If I'm not mistaken, Wayland has that (IMO terrible) design idea where it does not handle the input events (mouse, keyboard; therefore an application must gather those input events from some other source. Or something alike that. Which is completely unlike X11.

          So WinE must now gather input events from libinput, or something similar, to be able to use Wayland?
          No, you're mistaken.

          Edit: at 5:35:17 "Wayland is somewhat special in that events are not events on surfaces but rather events on a dedicated input object"

          Does that mean that Wayland provides input events, but it does not specify to which window events belong to (an application might open many windows)? That would be nuts.
          Indeed it would be, if it was the case. Good thing it's not.

          Comment


          • #25
            Originally posted by drastic View Post
            To allow an application to "remember it's position", the application should be allowed to suggest a window position when it creates a new window (that functionality should be added to Wayland, if missing), and the compositor should probably (but not always) accept the suggestion.
            Nobody cares if the compositor rejects it or not. The fact is it's not even possible to tell it. If it ends up rejecting it, then the blame will go to the compositor, instead of the Wayland protocol.

            Originally posted by drastic View Post
            For a few applications that actually require absolute positioning, it is probably the best to emulate it, by WinE creating a fullscreen window, and then Wine can position anything on it in any required way).
            Basically Wine's Virtual Desktop mode, but that won't work for your own scripts that you want to control other apps with, unless you run all of those apps in the Virtual Desktop, including the script.

            Comment


            • #26
              Originally posted by Weasel View Post
              Nobody cares if the compositor rejects it or not. The fact is it's not even possible to tell it. If it ends up rejecting it, then the blame will go to the compositor, instead of the Wayland protocol.
              Of course it is possible to suggest initial window position to the compositor. It is a feature that has to be added to a new (next) version of the Wayland protocol. Problem solved.

              Originally posted by Weasel View Post
              Basically Wine's Virtual Desktop mode, but that won't work for your own scripts that you want to control other apps with, unless you run all of those apps in the Virtual Desktop, including the script.
              Then you run all those scripted apps in Virtual Desktop. Problem solved.

              Comment


              • #27
                Originally posted by oiaohm View Post
                You find the following in the PDF and the presentation and the experimental branch.

                then note about


                This is the thing Wayland wine support has been finding that majority of windows applications don't need absolute window positioning to work. Logical space is good enough for majority of windows applications.

                Avis the thing to remember from the wine prototype of Wayland support less than 1 in 10 Windows applications in fact use absolute window positioning in any complex way.

                Not all applications in the Adobe Suite in fact require absolute window positioning used in any complex way that was found in the early wine wayland prototype.

                Remember multi window gimp the windows version does in fact work in the prototype of wine for Wayland.

                One of the reasons why absolute position is not part of the Wayland protocol is failure to find examples where it really required. Example after Example have turned out not to require absolute position even after a person put it forwards as real world example that required it.

                Avis get the problem yet. Wayland developers don't add stuff to protocol without functional use case. For absolute position no one has found one that passes full inspection. The presumed need of absolute position may be a limitation myth we have been using for decades.

                Wayland Window could be floating in a 4D space falling into a black hole for all the application knows about it. Of course since this is the case Wayland applications can kind of write its own rules of it own relative space(also called logical space).

                Avis lot of ways X11/windows compared to Wayland is like newtons physics vs General Relativity. Yes Wayland being the general relativity.

                Wayland is a good chance to re-look at some of these long term beliefs and check out if they are valid or not.
                This is a bit depressing to read.
                Wayland developers also fought for many years to prevent screen sharing from happening (making fools of themselves explaining why no one should ever need screen sharing - I guess that also less than 1 in 10 apps need to implement screen sharing, right ?).

                In the industry, when a client needs something you try to find an elegant way to implement it instead of dismissing it because you don't see the need for yourself.

                In the ticket there actually is a long list of valid examples using absolute positioning.

                Examples that are dismissed with vague, ideological reasons or using irrelevant implementation details.

                It looks like the real reason is some devs are using a tiling window manager and have strong opinions about the matter despite many people explaining why they need that feature.
                Last edited by wagaf; 26 October 2023, 11:30 AM.

                Comment


                • #28
                  Originally posted by wagaf View Post
                  This is a bit depressing to read.
                  Wayland developers also fought for many years to prevent screen sharing from happening (making fools of themselves explaining why no one should ever need screen sharing).

                  In the industry, when a client needs something you try to find an elegant way to implement it instead of dismissing it because you don't see the need for yourself.

                  In the ticket there actually is a long list of valid examples using absolute positioning.

                  Examples that are dismissed with vague, ideological reasons or using irrelevant implementation details.

                  It looks like the real reason is some devs are using a tiling window manager and having strong opinions about the matter despite many people expressing the need for that.
                  Note: I don't like or hate Wayland, I'm ambigous on that topic.

                  - Your mention of an example where Wayland developers got things wrong might be irrelevant, because such things do happen in big projects. It is only important that design errors are eventually corrected.

                  - If you want an example from the ticket discussed, then quote it here. I don't want to read an endless list of examples.

                  - You have to distinguish "ideology" from "design". If every unnecessary requested feature is added to a design, you won't have a good design anymore.

                  - I use a compositing window manager.

                  Comment


                  • #29
                    Originally posted by wagaf View Post
                    This is a bit depressing to read.
                    Wayland developers also fought for many years to prevent screen sharing from happening (making fools of themselves explaining why no one should ever need screen sharing - I guess that also less than 1 in 10 apps need to implement screen sharing, right ?).
                    xdg-desktop-portal reference implementation for screensharing does not depend on Wayland compositor support at all.

                    Its not exactly elegant to go around reinventing wheel without need.​

                    The catch here with screen-sharing is that the screen was always shareable without using the Wayland protocol. Now sharing individual windows that requires compositor cooperation.

                    Originally posted by wagaf View Post
                    In the industry, when a client needs something you try to find an elegant way to implement it instead of dismissing it because you don't see the need for yourself.

                    Yes key word "elegant way".

                    Originally posted by wagaf View Post
                    In the ticket there actually is a long list of valid examples using absolute positioning.
                    But they are not demonstrating need for it. There are particular advantages to relative positioning.

                    Comment


                    • #30
                      Originally posted by Weasel View Post
                      Nobody cares if the compositor rejects it or not. The fact is it's not even possible to tell it. If it ends up rejecting it, then the blame will go to the compositor, instead of the Wayland protocol.
                      Its not that straight forwards. Why does Wayland protocol use relative positions. Turns out you need to perform less maths to get absolute position on monitor that way instead of using X11/Windows like absolute position.

                      So there are a lot of cases where applications use absolute positions under Windows and X11 that just are waste of CPU time. Remember each monitor out is it own buffer with its own X and Y with its own origin point.

                      Get the problem yet. The Absolute position virtual image people are use to is virtual construct with no relevance to modern day hardware. Heck it does not even have relevance on the early multi monitor hardware.

                      Comment

                      Working...
                      X