ICCCM-compliant support for mouse selection and paste from/to primary, both X11 and Wayland

[viklequick]

Added ICCCM-compliant support for mouse selection and paste from primary buffer

with options

[unxed]

Can you please make it write to both clipboard and primary as browsers do if no clipboard options are specified? So I could remove conflicting logic from #3215

[viklequick]

Can you please make it write to both clipboard and primary as browsers do if no clipboard options are specified? So I could remove conflicting logic from #3215

Sorry, but it is wrong behavior: change both clipboards at once. The main idea of two clipboards in X11 that it are living completely independently.

And surely, browsers do not corrupt clipboards; both clipboards works independently and I'm using this feature every day.

It seems you have certain clipboard management application active that "synchronizes" both primary and clipboard.

[unxed]

No. I definitely have no special clipboard managers. I have a problem: text copied in wx backend can not be pasted to tty backend, because they use different clipboard types. If your approach fixes that in any other way, I will just remove that part from my PR

[viklequick]

No. I definitely have no special clipboard managers. I have a problem: text copied in wx backend can not be pasted to tty backend, because they use different clipboard types. If your approach fixes that in any other way, I will just remove that part from my PR

Could you explain a case how to reproduce it?

By default, terminal emulators use the primary for all mouse-related activities, and the clipboard itself is bounded to Shift+Ctrl+{C,X,V}.

But what is being used by bracketed paste etc -- it seems it is terminal emulator specific. So, if you make me a hint how to reproduce, what's wrong and how it should be, I'll try to find less heavy solution rather than premature synchronization of clipboards.

Thank you.

[unxed]

#3214

1. Copy multi-line text to the clipboard in the graphical far2l.
2. Go to the tty far2l in GNOME Terminal (running in Xi mode).
3. Try pasting with Shift+Ins.
4. Something completely different is pasted.

And this was the case even before #3212.

I'm testing on this text.

[viklequick]

#3214
2. Go to the tty far2l in GNOME Terminal (running in Xi mode).

As we're discovered, the Shift+Insert is the hardcoded keybinding to gnome terminal and it is processed by VTE internally, we even does not receive the keys. So, we need to solve the GNOME terminal issue outside of far2l by making PR to VTE.

It means, the aggressive hack that synchronizes both lkeyboards will not help if the clipboard owner will be not the far2l-wx.

[viklequick]

I've fixed code a bit to not make so aggressive attempts to open/close clipboard when we have nothing selected. Hope this will work better.

[viklequick]

By the way, the code change is very simple and belongs to editor.cpp and config (with two options and its' processing respectively). Just dozen of lines of code.

Unfortunately, the glue is huge: it needs several files to be touched, as it need a new function in clipboards API: way to choose primary or clipboard buffer. I've copied the same way as for other functions by registering ChooseClipboard and added stubs everywhere for all clipboard implementations.

The implementation for wx Clipboard Backend is trivial: use wx API to choose clipboard (one function, one line).

I've added workaround for Wayland as well: due to strange limitations, wxGTK cuts access to primary buffer, despite the gtk itself provides full support to it for the Wayland. So, I've added a workaround for this case: if we have wayland and no X11, we're using gtk directly just to operate with primary buffer. Hope in future wxWidgets will remove this strange limitation and we'll able to remove this workaround.

Just an example how 20 lines-code patch needs 20 extra files to be modified ;-)