Copy paste... a hard problem ?

chomwitt · 2024-01-05 16:21:52

I came across on the web of discussions (1) on how difficult is the implementation
of copy paste and drag and drop on Wayland.

I wonder .. is copy paste a hard problem ? Or is it possible when you lay down the
architecture of a display server targeting perfect frames your construction becomes
hostile to copy paste ?

What information do you loose when 'you' as a Display server you let every app
draw whatever they want how ever they want on their private frame buffers?

So 'you' don't have the faintest clue
of what the apps graphically do.
To the graphical memory you guard
bits and pixels play their card.

------ refs
(1) discussion ref1 (2010)
discussion ref2 (2021)
wayland-clipboard-drag-and-drop/
Synchronizing the X11 and Wayland clipboard
copy-paste-from-firefox-88-0-1-not-working-properly-on-ubuntu-21-04

(2) Discussion on X's copy paste (2010)

Last edited by chomwitt (2024-01-11 13:53:50)

trinidad · 2024-01-05 16:35:51

Link to this discussion please.

TC

quickfur · 2024-01-05 18:07:56

Copy-n-paste has always required a cooperative implementation.

In X11, it requires that the application in question support selections in a way that conforms to the window manager conventions, which requires handling X11 atoms in a conformant way so that the selected text can be transferred to the target application (i.e. where the paste happens). All of this requires a significant amount of code not just in the target application, but in the source application, and would not be possible if the authors decided to be lazy and simply not implement it. (It's not part of the core X11 protocol, btw, it's part of the window manager conventions which strictly speaking is optional, though not implementing it is regarded as highly antisocial.)

I'm no fan of wayland either, but blaming the failure of cut-n-paste on wayland is not really fair because it requires all 3 parties to be involved: the display manager/compositor/whatever, the source application, and the target application. A failure on the part of any one party means that cut-n-paste won't work. So the blame could equally go to the authors of either application too.

chomwitt · 2024-01-06 11:40:02

I'm not blaming. I just say that although you have a difficult issue you prioritize the perfect frame .

Isnt it essential, to productive desktop workflows, to have desktop apps exchange data ?

In my devuan+sway installation indeed i dont see graphically speaking anything buggy but i cant copy paste simple text between some apps breaking my workflow.

And isnt it the essence of a DS protocol to laydown some rules for the clients . And the clients should coooperate in order to use the DS's services and resources ?

So my question is could a protocol BOTH apply rules to committing pixel perfect frames AND enforcing data exchange protocols ?

An tty-analog example could be Unix. To have pipes in Unix a unix pipe-friendly program must follow some conventions. Use stdout by default , use ascii. If a program decides to write to the console not in ascii but in a finer-grained private encoding then doesnt that brake the pipe ?

Also isnf a legitimate display server functionality to enforce certain type-constraints on data written to it's graphical memory so that sharing could be easily exposed to it's client as a service? (generally type constraints have also a security bonus).

Shouldn't also the integration of the window manager in the display-server compositor made the matter easier for wayland (if there isnt not any protocol inherited constraints) ?

In X11 you have 4 parties involved: X11,windows manager, target app, source app

Last edited by chomwitt (2024-01-06 12:30:19)

quickfur · 2024-01-07 04:33:24

I'm not disagreeing with you. I'm just saying that even if wayland specifies a protocol for copy-n-pasting, it would still be up to the relevant applications to implement it in a sane way before it would work. If one of the authors is lazy and decides to just ignore it, or implement it minimally (i.e., copy always returns an empty string) then you'd still get nowhere.

chomwitt · 2024-01-07 12:41:02

quickfur doesn't your argument applies to every aspect of a display protocol ?

if wayland specifies a protocol for committing pixel perfect frames, it would still be up to the relevant applications to implement it in a sane way before it would work. If one of the authors is lazy and decides to just ignore it, or implement it minimally then you'd get various screen artifacts

A protocol is a contract . To be of any use the programmers must study it and use it. A lazy programmer would use could use it wrongly.
So i think we could make a DS protocol with perfect copy paste. And it would be a perfect copy paste desktop for those apps that conform to the protocol rules.

Now we are in a situation that i hear horror stories of a user that must know what apps run on xwayland and what not in order to predict if copy paste or drag and drop would work.

So we have a pixel perfect desktop BUT it seems that 'we' miss something essential . And that essential could be a problem not amenable to hackers skills but out of their reach. That's an idea that i explored for days in my post How X started.. .

I mean the speed by which X was used and prospered is in great contrast with what is happening with Wayland. Wayland is not X. Shouldnt be seen as a display server protocol DSP replacing X but either as a pixel perfect extension or as another type of display protocol aiming perfecting a certain aspect of the a display protocol.

I personaly think wayland is not a DSP. Wayland is a DSP's perfect frame component.

All those companies and institutions that are in the remote desktop 'business' i think would agree. They all implement various free or proprietary protocol to share desktop rendered data across various networks. (the initial X use case) . So those are protocol controlling display data sharing. There we are.
Display Server Protocols chassing a differerent rabit hole!..
A DSP must encompass more. For me a generic DSP needs a RenderingProtocol (RP) But the RP cant be the DSP .

So i think 'we' the IBM-PC clone era architecture users are getting dangerously close to the 80's !!.
Back then we did have again x86 PCs. And we used various 'display servers' . But 1) they were proprietary 2). they were aligned closely to a pc desktop not-networked view of computing .

ps: I just realized that another issue i have with firefox in sway could be also related to copy-paste problem. I cant drag and drop links inside bookmark menus . Something that i was doing the last years . On top of that i cant copy paste text to the 'foot' wayland terminal from many of my favorite apps.

Last edited by chomwitt (2024-01-07 14:55:16)

The officially official Devuan Forum!

#1 2024-01-05 16:21:52

Copy paste... a hard problem ?

#2 2024-01-05 16:35:51

Re: Copy paste... a hard problem ?

#3 2024-01-05 18:07:56

Re: Copy paste... a hard problem ?

#4 2024-01-06 11:40:02

Re: Copy paste... a hard problem ?

#5 2024-01-07 04:33:24

Re: Copy paste... a hard problem ?

#6 2024-01-07 12:41:02

Re: Copy paste... a hard problem ?

Board footer