Comment on I don't like the Linux clipboard situation

• PhilipTheBucket@ponder.cat ⁨4⁩ ⁨days⁩ ago

  The people writing the tools don’t have to do this, it ‘just works’ as it’s functionality the UI framework provides.

  Read it as “if you’re going to teach all your UI frameworks to do this,” then. My point is, the people who write the software that handles clipboards are having to deal with multiple clipboard. If that’s invisible to the app author because it’s in a toolkit, then great. The people that wrote the toolkit still had to worry about it. To me it would have been preferable if what they’re supporting was a different and more sensible paradigm.

  source

  • notabot@lemm.ee ⁨4⁩ ⁨days⁩ ago

    The thing is, in X11 that clipboard behaviour was written once, and that made it work everywhere. Obviously there’ll have been work done on it over time, and non-native frameworks (java UIs and such) would have had to do it themselves, but for the vast majority of programs the author, and indeed the author of the toolkit probably didn’t have to think about it at all. It’s one of the nice things about the X11 architecture that I think we lose with the wayland approach, everything that should work the same everywhere is written once. I suspect that over time we’ll see only a few wayland compositors really lasting and being maintained, and we’ll start to get back to that common architecture.

    I can definitely understand your frustration with the clipboard situation, but it’s a decades old paradigm, and I’m used to it, so it seems reasonable to me. That said, I do use clipman to automatically store the text I’ve copied to the clipboard, and let me switch to previous values, so maybe that sort of thing would at least help you a bit?

    source

    • PhilipTheBucket@ponder.cat ⁨3⁩ ⁨days⁩ ago

      Oh, also, update: I found a thing with the new setup that still doesn’t work. Highlighting stuff in Colab doesn’t put it into PRIMARY, and I can’t even really seem to copy into CLIPBOARD since Colab overrides the right-click to offer me a menu that doesn’t give me “Copy” as one of the options.

      I mean Colab is shit, that’s not surprising. I just wanted to add one more data point that making a strange paradigm is going to cause issues down the road, whereas simple paradigms have power and can survive.

      source
    • PhilipTheBucket@ponder.cat ⁨3⁩ ⁨days⁩ ago

      The thing is, in X11 that clipboard behaviour was written once, and that made it work everywhere.

      Dude it just doesn’t work this way. People write apps and they choose keyboard shortcuts, people port applications and frameworks from one place to another. I randomly fired up the first non native program that came to mind, hit ctrl-shift-c, and it didn’t copy stuff to CLIPBOARD. I get what you’re saying but the keyboard shortcuts simply aren’t going to be defined unilaterally by the one and only author of the only allowed windowing toolkit and then everyone’s going to use that for all time. It just doesn’t work that way. Software is a social contract. Actually, I would hold up the MacOS “Ctrl-C versus Cmd-C” paradigm as a golden example of how it should be: The paradigm is clear and easily defined, and obviously makes sense, so of course everyone who’s dealing with some kind of software on Mac is going to adhere to it. It’s easy and sensible, and then the fact that there’s a standard toolkit that provides it out-of-the-box becomes icing on the cake instead of being the only thing holding back dysfunction.

      Look at my list of fixes for finally making my clipboard work sort-of the way I wanted it to. Only one of them had anything even vaguely to do with the windowing toolkit. It’s an issue of the fundamental paradigms at work. My complaint was a little bit more focused on X11 introducing a new (and, I would argue, largely pointless) paradigm that now everyone needs to be aware of and adhere to. The people implementing clipboard-provider = “termcode” in Helix aren’t going to benefit from any X11 toolkit regardless of what software is on the desktop that runs the ssh session connecting to the headless computer where Helix is running. But do they have to think about whether the stuff that gets copied from a remote session is going to go to PRIMARY or CLIPBOARD? Do the people who write the protocol that sends clipboard stuff over xterm terminals? I mean, I would hope they do, otherwise we’re back at the issue of randomly choosing one clipboard or another, which was a big part of what I was saying people would (and did) do in practice and why I levied criticism at the original paradigm for introducing that stupid choice to their programming.

      I can definitely understand your frustration with the clipboard situation, but it’s a decades old paradigm, and I’m used to it, so it seems reasonable to me.

      I mean people said the same thing about slavery. Now that I got it out of my system by whining about it on Lemmy and then took some time to set things up how I want them, I’m pretty much fine with the behavior on my system now. The frustration basically came from (a) things don’t work for me and (b) the reasons why seem stupid, and then coupled up also with © I’m having trouble making it work in a way I am happy with. Now that (a) and © are taken care of by running wl-paste (which I guess is doing what the xfce person was saying their system does, just on the side instead of out-of-the-box), I’m not embittered about it anymore. But it just still seems silly.

      source