STR #3229

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Roadmap 1.3 ]

STR #3229

Application:FLTK Library
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
Created By:cand
Assigned To:AlbrechtS
Fix Version:1.4.0
Fix Commit:8dd3ff8e12a7cabce9a1931831b311bf898aaaaf
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

No files

Trouble Report Comments:

Name/Time/Date Text top right image
#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.

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?
#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:
bottom left image   bottom right image

Return to Bugs & Features ]


Comments are owned by the poster. All other content is copyright 1998-2023 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.