Wine Wayland Merge Request Opened For Clipboard Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • Weasel
    Senior Member
    • Feb 2017
    • 4510

    #11
    Originally posted by anda_skoa View Post
    That it is unfair to claim that Wine loves to piss against the wind just because they have chosen a path that seems somewhat hackish, like in this case having a pseudo window for intercepting the clipboard.

    At the time that probably was good enough and only now falls apart.

    With the new implementation they have discarded that hack and are now using the actual target window.
    The change request also indicates that there might be further improvements.

    Improvements that will also help Wine on X11.
    Because clipboard needs to be shared across processes, that's like the whole fucking point of it.

    It's already a pain in the ass that when you shutdown a wineprefix which had something copied into the clipboard, the clipboard content is gone. This happens to me quite often since I run my browsers in a completely different prefix because it's ran under different users etc (restricted obviously).

    Sometimes I copy something from the browser to paste into my text editor, but I close the browser. Guess what happens a few seconds later when the wineprefix shuts down?

    With target window it will be even worse. Fuck Wayland.

    Comment

    • jonkoops
      Phoronix Member
      • Dec 2019
      • 99

      #12
      Don't engage the troll, just ignore these fucking idiots.

      Comment

      • anda_skoa
        Senior Member
        • Nov 2013
        • 1205

        #13
        Originally posted by Weasel View Post
        Because clipboard needs to be shared across processes, that's like the whole fucking point of it.
        Nothing changes in this regard.

        Wine just switched to using the handle of the window in which the user initiated the paste instead of some hidden window that is not involved at all.

        I agree with you that the old implementation was a bit hackish but really not necessary to say Wine love to piss against the wind just because of that.

        Originally posted by Weasel View Post
        It's already a pain in the ass that when you shutdown a wineprefix which had something copied into the clipboard, the clipboard content is gone.
        That is true regardless of display protocol.
        Copy&paste is very similar to drag&drop on the protocol level just triggered differently (keyboard/menu vs mouse).

        I am not aware of any DE that does not have a clipboard manager to preserve content of an exiting client.


        Comment

        • oiaohm
          Senior Member
          • Mar 2017
          • 8469

          #14
          Originally posted by Weasel View Post
          Because clipboard needs to be shared across processes, that's like the whole fucking point of it.
          Wayland protocol in fact defined a single clipboard protocol. Not X11 mess of many protocols.

          Originally posted by Weasel View Post
          It's already a pain in the ass that when you shutdown a wineprefix which had something copied into the clipboard, the clipboard content is gone. This happens to me quite often since I run my browsers in a completely different prefix because it's ran under different users etc (restricted obviously).
          So you never started intentional clipboard manager outside wine did you.

          Originally posted by Weasel View Post
          Sometimes I copy something from the browser to paste into my text editor, but I close the browser. Guess what happens a few seconds later when the wineprefix shuts down?.
          Yes wineserver shutdown so taking down wine own clipboard manager when application is no longer running.

          Wine you end up with double stacked clipboard managers and a double set of clipboard protocols.

          X11 server with xace enabled has the same restrictions as Wayland where only active windows and designated clipboard managers can see the clipboard also the with xace the clipboard manager cannot see what is the top window directly. Yes the application receiving is informed by the X11 server that there is something on the clipboard and it pulls the request while it the top window.

          Wine build in clipboard manager has be duplicating what the X11 server and Wayland compositor in fact does for clipboard delivery just wine has not been coded to receive the X11 or Wayland clipboard message to the active window.

          Yes the issue with shutdown wineprefix and clipboard contents disappear that a direct result of not running a independent clipboard manager. The auto shutdown of wineserver so shutdown the wine prefix makes wine built in clipboard manager go away is user annoying because it can make copy paste functionality seam random to the user because if the clipboard manager is work or not depend if you have applications running in the wine-prefix..

          Weasel you want a clipboard manager that you can control when it shutdown independent to shutdown applications right and if you had this you would not have the wineprefix shutdown issue right?. No matter how you look at it wine current clipboard manager design is bad.

          From my point of view wine should use the X11/Wayland provided clipboard manager and if they want a clipboard manager do a standalone clipboard manager application that the user controls when it starts and stops. Yes if you have a DE providing it own clipboard manager why does wine go and duplicate this functionality in a unstable way??????

          This is the thing about Wayland. Wayland breaks a lot of things that are already broken that should have been fixed. Wine clipboard manager design is broken somewhat works because most distributions x.org X11 servers run in permissive mode yes a X11 server not permissive mode wine clipboard manager breaks as well. Remember xace was added to x11 protocols in the year 2000.

          Yes weasel the complete time wine clipboard manager has existed it been shutdown on users when they don't want it shutdown so the problem you are suffering from is a day 1 bug of that part one wine..

          Comment

          • Weasel
            Senior Member
            • Feb 2017
            • 4510

            #15
            Originally posted by oiaohm View Post
            Wayland protocol in fact defined a single clipboard protocol. Not X11 mess of many protocols.
            Sometimes I wonder if you even grasp the basics of what you're responding to. WTF has protocol to do with sharing clipboard across application processes?

            Originally posted by oiaohm View Post
            So you never started intentional clipboard manager outside wine did you.
            No, because apart from the wine issue, it has never been a problem. Ever. X11 just works.

            Comment

            • Weasel
              Senior Member
              • Feb 2017
              • 4510

              #16
              Originally posted by anda_skoa View Post
              Nothing changes in this regard.

              Wine just switched to using the handle of the window in which the user initiated the paste instead of some hidden window that is not involved at all.

              I agree with you that the old implementation was a bit hackish but really not necessary to say Wine love to piss against the wind just because of that.
              What if the window gets destroyed and it's a copy instead of a paste?

              Originally posted by anda_skoa View Post
              That is true regardless of display protocol.
              Copy&paste is very similar to drag&drop on the protocol level just triggered differently (keyboard/menu vs mouse).

              I am not aware of any DE that does not have a clipboard manager to preserve content of an exiting client.
              What clipboard manager? (genuine question)

              Wouldn't it fix my issue if it were available?

              Comment

              • oiaohm
                Senior Member
                • Mar 2017
                • 8469

                #17
                Originally posted by Weasel View Post
                Sometimes I wonder if you even grasp the basics of what you're responding to. WTF has protocol to do with sharing clipboard across application processes?
                Because the protocol defines how that done and what are the rules.

                Originally posted by Weasel View Post
                No, because apart from the wine issue, it has never been a problem. Ever. X11 just works.
                But when wine is deleting the contents off the clipboard that is exactly what X11 and Wayland protocol says should happen if not are running a clipboard manager. The fact that you closed application and copy did not instantly disappear with no clipboard manager equals wine not behaving as X11 protocol defined it should.

                Originally posted by Weasel View Post
                What if the window gets destroyed and it's a copy instead of a paste?
                Following X11 or Wayland protocol without a clipboard manager that copy/cut is to be nuked out of existence as soon as the application that did the copy/cut is no longer running.

                People have been coding clipboard managers almost forever for X11 so that when you close an application that cut/copy from application remain after application has closed. First version of the xserver ever made came with clipboard manager. It was something that xfree86 and x.org X11 server never included was a clipboard manager.

                Originally posted by Weasel View Post
                What clipboard manager? (genuine question)

                Wouldn't it fix my issue if it were available?

                KDE one.


                XFCE one .

                Save yourself time and frustration with a clipboard manager and never lose track of your copy-pasting.


                Yes there are generic clipboard managers as well all with different feature sets.

                Yes the problem you are talking about with wine where application closes and your cut/copy goes away that is fixed by having a clipboard manager. Remember following X11 and wayland that meant to be instant the application closes that the cut/copy from application goes away not hanging around until wineserver gets auto shutdown.

                Wine has not been behaving how X11 or Wayland says it should with cut and copy.

                Comment

                • anda_skoa
                  Senior Member
                  • Nov 2013
                  • 1205

                  #18
                  Originally posted by Weasel View Post
                  What if the window gets destroyed and it's a copy instead of a paste?
                  The clipboard operation is a data exchange between a sender and a receiver.
                  The sender offers its data, potentially in various formats, until someone asks for it (and selects a format the data should be transferred in).

                  The data will be incomplete if either sender or receiver exit before the transfer has been completed.

                  Like a phone call where either side hangs up prematurely.

                  It doesn't make any difference which of the two parties that is, i.e. whether it is the one doing the copy or the one doing the paste.

                  Hence the addition of clipboard managers to acquire the data in one or more formats when new content is advertised.
                  They can then serve as a new sender if the original one exits before any receiver has asked for the data or even provide data of previous senders.

                  Originally posted by Weasel View Post
                  What clipboard manager? (genuine question)
                  I guess that depends on your setup.
                  On KDE Plasma that is klipper.

                  Originally posted by Weasel View Post
                  Wouldn't it fix my issue if it were available?
                  Yes, it should.
                  Unless the sender exited before even handing over content to the clipboard manager, e.g. crashing in clipboard code.

                  In any case the change in Wine is only which window ID the code passes to the clipboard API, it doesn't change anything in behavior

                  Comment

                  • Weasel
                    Senior Member
                    • Feb 2017
                    • 4510

                    #19
                    Originally posted by anda_skoa View Post
                    The clipboard operation is a data exchange between a sender and a receiver.
                    The sender offers its data, potentially in various formats, until someone asks for it (and selects a format the data should be transferred in).

                    The data will be incomplete if either sender or receiver exit before the transfer has been completed.

                    Like a phone call where either side hangs up prematurely.

                    It doesn't make any difference which of the two parties that is, i.e. whether it is the one doing the copy or the one doing the paste.

                    Hence the addition of clipboard managers to acquire the data in one or more formats when new content is advertised.
                    They can then serve as a new sender if the original one exits before any receiver has asked for the data or even provide data of previous senders.
                    This is not what clipboard is. Maybe in the dumb Wayland design (as I see one of the wine devs even complained about it), but not on a proper design like Windows.

                    The point of the clipboard is to upload data which is then downloaded/pasted many times over any process that asks for it. Not from the original process, but from the "manager". The manager should be implicit. It's the whole fucking point of the clipboard.

                    A single process doesn't need the clipboard by itself, it could just implement its own copy-pasting among itself, so that's obviously NOT the point of a clipboard.

                    Comment

                    • anda_skoa
                      Senior Member
                      • Nov 2013
                      • 1205

                      #20
                      Originally posted by Weasel View Post
                      This is not what clipboard is. Maybe in the dumb Wayland design
                      This isn't Wayland specific, X11 has the same design.

                      Core idea is that the same data can be presented in various formats and only the one that is actually wanted needs to be transferred and only when it is needed.
                      Especially important for large data or remote clients.

                      For example if one were to copy a section if an image in a painting application, the data could be shared as format native to the application (for pasting into a second instance of the same application or a compatible program), as uncompressed pixel data, as lossless compressed image format (e.g. PNG) or a lossy compressed one (e.g. JPG).

                      If the transfer happens on paste, the destination can pick the format it can handle best and potentially the most accurate (the painting program could have layers which it can represent in its own format but likely not as pixel data).

                      If the transfer would happen on copy, the source application would either need to transfer multiple copies to some intermediary storage or decide either for the most accurate (best case for a compatible destination) or the least advanced one (best case for widest possible support).

                      Each of those choices is worse than the handshake that copy on paste can do.

                      Originally posted by Weasel View Post
                      The manager should be implicit.
                      Yes, that is what they do.

                      The detect that new content is available and "save" it in the most common format.
                      Since the source application is still the primary content provider, the pasting application can still get better data directly.

                      The "saved" data held by the manager is only needed if the original source can no longer provide the data.

                      Originally posted by Weasel View Post
                      A single process doesn't need the clipboard by itself
                      Yes, obviously.
                      Any reasonable implementation of a clipboard API will have a short path for this scenario and/or functions to check if this is the situation at hand.

                      The former makes it transparent to the application code and data will just not be transferred (but still likely serialized/deserialized).
                      The latter allows an application to detect that it can just use some internal code path to get the data.

                      The two most common clipboard APIs on Linux, Gdk.Clipboard and QClipboard, can do both.

                      Comment

                      Working...
                      X