[ Return to Bugs & Features | Roadmap 1.3 ]

STR #3229

Trouble Report Files:

No files

Trouble Report Comments:

	Name/Time/Date	Text
	#1  cand 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.
	#2  greg.ercolano 22:31 May 18, 2015	Reference to developers: see discussion on fltk.coredev, Subject: "Improving the clipboard handling" 05/13/15.
	#3  AlbrechtS 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?
	#4  cand 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.
	#5  AlbrechtS 13:54 Jan 26, 2022	FTR: the mentioned commit (svn r10731) was: commit 03f69c0dd5244c50e430b430ee3a2e952b5a00fe 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.
	#6  AlbrechtS 20:07 Jan 05, 2023	Please see GitHub PR #636 for a proposal to fix this issue. https://github.com/fltk/fltk/pull/636 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   Fl::selection_to_clipboard(1); I don't think that we can and/or should do more in FLTK 1.4.0. Lauri, is this OK?
	#7  cand 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)
	#8  AlbrechtS 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: https://groups.google.com/g/fltkcoredev/c/jmoUUEdxUko/m/X_LQ_8idAVcJ

[ Return to Bugs & Features ]