Improving the clipboard handling

[Lauri Kasanen]

Hi,

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.

I opened STR 3229 to track this. What do you guys think?

- Lauri

http://www.fltk.org/str.php?L3229

[Albrecht Schlosser]

I think that this is generally a good idea. Certainly something we
should do in FLTK 1.4 - not in 1.3.4 though, to avoid (even more) confusion.

I can't tell if there is really such an inconsistency, for instance in
Fl_Input, as you mentioned. Maybe this is due to the different behavior
of selection vs. clipboard, since X11 is designed to differentiate
exactly that. But for a cross-platform toolkit we should consider to do
it more consistent across platforms.

I discovered recently that xterm has an option to "Select to Clipboard"
[1] which does something similar to what you proposed, i.e. copy the
selection (also) to the clipboard. This enables the user (me) to select
text in an xterm window (e.g. in a VM) and paste it from the clipboard
into a Windows application on the host (Windows) system.

[1] run xterm, press ctrl and click (and hold) the middle mouse button.
Then it is about the 13th menu entry in my xterm version.

[MacArthur, Ian (Selex ES, UK)]

Hi Lauri,

> 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.
>
> I opened STR 3229 to track this. What do you guys think?

That induced some nasty flashbacks for me...

Years ago I tried (with no success) to devise improved clipboard handling under X11. It was not a success.

The two things I really wanted to do were to support more types than just ASCII text (some of which has been added fairly recently) and to somehow unify the X11 clipboard and paste buffer handling.

So, to me, this sounds like a Good Plan.
Particularly if someone other than me does it.
And especially so if someone who actually understand the disparate X11 clip mechanisms can sort it out!

That's a yes from me, then.

ABI compatible for 1.3, or we do it as a breaking change in 1.4? (which of course will be "Real Soon Now".)

--
Ian




Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[Lauri Kasanen]

On Wed, 13 May 2015 10:51:10 +0000
"MacArthur, Ian (Selex ES, UK)" <ian.ma...@selex-es.com> wrote:

> So, to me, this sounds like a Good Plan.
> Particularly if someone other than me does it.
> And especially so if someone who actually understand the disparate X11 clip mechanisms can sort it out!

I'm not too familiar with it, I just want my application to "just
work" ;)

> That's a yes from me, then.
>
> ABI compatible for 1.3, or we do it as a breaking change in 1.4? (which of course will be "Real Soon Now".)

There's multiple widgets that call Fl::copy, so I would suggest
ABI-breaking method(s) to Fl_Widget, rather than each of them having
their own.

Listing them:
Fl_Help_View
Fl_Input
Fl_Text_Display
Fl_Text_Editor

The support for "2" could be added right away though, leaving the
defaults and the above change for 1.4.

- Lauri