[ Return to Bugs & Features | Roadmap 1.3 ]
|Status:||1 - Closed w/Resolution|
|Priority:||1 - Request for Enhancement, e.g. asking for a feature|
|Scope:||2 - Specific to an operating system|
|Summary:||X11 dual clipboard control|
Trouble Report Files:
Trouble Report Comments:
07:17 May 11, 2015
|X's dual clipboards still create confusion in 2015. Some of FLTK widgets' inner methods copy to one and some to other. |
I would like to see two changes:
1) Which clipboard a widget targets internally should be user-changeable. See for example Fl_Input which targets both in different actions.
2) There should be a new value, 2, accepted by Fl::copy, meaning "copy to all clipboards". Then it wouldn't matter which one the other application wants.
Finally, the default of widgets could be changed from the previous 0/1 to 2 everywhere, targeting cross-app compatibility by default.
22:31 May 18, 2015
|Reference to developers: see discussion on fltk.coredev, |
Subject: "Improving the clipboard handling" 05/13/15.
05:19 May 22, 2015
|There was a commit in svn r10731. Looks pretty straightforward and probably complete. |
Lauri, is this finished? Any reason to keep this STR open?
12:49 May 22, 2015
|This STR should be kept open until 1.4 is branched, and all the functionality is in. The commit adding support for "2" was just the ABI-safe part - Fl_Widget change plus clipboard default change can only be done then. ||
13:54 Jan 26, 2022
|FTR: the mentioned commit (svn r10731) was: |
Author: Lauri Kasanen <...>
Date: Mon May 18 09:10:06 2015 +0000
Add support for Fl::copy(..clipboard = 2..)
--- end of commit message ---
This commit is included in FLTK 1.4.0 but, as Lauri said, this does not resolve the complete request.
20:07 Jan 05, 2023
|Please see GitHub PR #636 for a proposal to fix this issue. |
Note that the PR implements a new method Fl::selection_to_clipboard()
that enables (if set) to always copy the selection buffer to the
clipboard, similar to what can be enabled in `xterm`.
IMHO this is a good compromise and this STR can be closed when the
PR is merged.
Lauri, you wrote: "Finally, the default of widgets could be changed from the previous 0/1 to 2 everywhere, targeting cross-app compatibility by default."
This is now implemented, not as the new default but as an option (opt-in), i.e. if an application calls
I don't think that we can and/or should do more in FLTK 1.4.0.
Lauri, is this OK?
22:45 Jan 05, 2023
|Everything looks good, the only remaining change would be changing the widgets that default to 1 to default to 0. (not sure if any remain, but the original post mentions one) ||
08:04 Jan 06, 2023
|Fixed in Git repository. |
Thank you for the quick confirmation. I merged PR #636 in commit 8dd3ff8e12a7cabce9a1931831b311bf898aaaaf and I'm closing this issue now as completed.
I checked all usages of Fl::copy() I could find in widget code and I'm pretty sure everything is correct as required by X11 conventions:
- Fl::copy(0) goes to the selection buffer
- Fl::copy(1) goes to the clipboard.
I'm not going to change this the default behavior unless I missed a bug somewhere.
Users have now two choices to override this X11 specific behavior:
- Fl::copy(2) in their own code copies to both as requested and implemented earlier
- Fl::selection_to_clipboard(1) to duplicate the selection buffer to the clipboard as documented.
The latter is not the default for previously mentioned reasons (X11 conventions).
Side note: Wayland does not use the selection buffer at all, in this regard it works already like Windows and macOS.
If you find another reason to pursue your request (this STR), please discuss this in fltk.coredev (which widgets should be changed, and why exactly) before eventually opening an issue (or a PR) on GitHub. Thank you.
PS: the old discussion in fltk.coredev can be found here:
[ Return to Bugs & Features ]