Read clipboard data directly into a string?

[Brian Larsen]

I'm using FLTK from git/master and I'm using Ubuntu, which means X11.

For the clipboard, FLTK has a nice copy() function that takes a pointer to 

a string as the data to put into the clipboard. Perfect.

Is there a related function that takes a pointer to a string for the destination

to put the clipboard data into? It seems paste() doesn't offer that option, 

unless I misunderstand the docs. Is there a simple way to get the current 

clipboard data into a string?

If not, it's no problem, I'm currently using a hack that uses popen() to 

read/write the clipboard via xclip. That's fine for my current needs, but it's 

not OS independent. 

[Greg Ercolano]

On 5/28/24 23:30, Brian Larsen wrote:

I'm using FLTK from git/master and I'm using Ubuntu, which means X11.

For the clipboard, FLTK has a nice copy() function that takes a pointer to 

a string as the data to put into the clipboard. Perfect.

Is there a related function that takes a pointer to a string for the destination

to put the clipboard data into? It seems paste() doesn't offer that option, 

unless I misunderstand the docs. Is there a simple way to get the current 

clipboard data into a string?

    I believe the technique is you have your widget's `handle()` method
    watch for an FL_PASTE event, and when that arrives, you can use
    `Fl::event_text()` and `Fl::event_length()` to read the pasted text.

    This should work on all platforms.

[Brian Larsen]

Thanks for that information. Because of the way I've chosen to do things that might not work

for me. The problem is I'm porting a working app that was text only and using ncurses. So it's

been (mostly) convenient to do all the key processing myself since that was already setup.

Thankfully, FLTK allows using  Fl::wait() inside a while(1) loop instead of having to use

Fl::run(). In my case when Ctrl+V is seen, I call a paste routine and was hoping to just pull

the text from the clipboard. Anyway, I have a work-around, but I'll take a look at my handle() 

routine to see if FL_PASTE is useful.

[Greg Ercolano]

On 5/29/24 01:04, Brian Larsen wrote:

Thanks for that information. Because of the way I've chosen to do things that might not work

for me. The problem is I'm porting a working app that was text only and using ncurses. So it's

been (mostly) convenient to do all the key processing myself since that was already setup.

Thankfully, FLTK allows using  Fl::wait() inside a while(1) loop instead of having to use

Fl::run(). In my case when Ctrl+V is seen, I call a paste routine and was hoping to just pull

the text from the clipboard.

    Fl_Text_Editor.cxx does this too; in response to a Ctrl+V hotkey, it calls  Fl::paste(<widget>, 1);
   which sends an FL_PASTE event to <widget>,  and that widget's handle() method checks for
    FL_PASTE and gets the actual text via Fl::event_text() / Fl::event_length().

    The 2nd numeric argument to Fl::paste() indicates which source to paste from:
    0 being the "selection buffer", or more commonly 1 being the "clipboard" (as shown above).

    It shouldn't matter how you're handling the event loop, either with Fl::run() or while/Fl::wait(),
    but I think you need to have your widget watch for the FL_PASTE event before you can use
    Fl::event_text() / Fl::event_length(), so FLTK can set those up properly.

[Brian Larsen]

Thanks, that makes things more clear to me. My main window has a handler that is checking for key and

mouse events, so it should be pretty easy to add the FL_PASTE event to its handling.

I have to say I'm impressed with the level of this community. All the responses to my newb questions

have been both friendly and helpful. 

[Brian Larsen]

Thanks again for that info. I did get Fl::paste() to work in my main window
handle(). One thing I wasn't sure about, but it seems to work, is I'm
calling Fl::paste() from handle(), which will see the FL_PASTE event on
on a subsequent invocation of handle(). The high level flow is

In handle()
- Detect a new CTRL+V
- Don't add CTRL+V to the key queue, but save it for later...
- Fl::paste()

In a later handle()
- FL_PASTE occurs
- Copy the clipboard data locally
- Finally add the pending CTRL+V to the key queue

In the Editor's processing
- Detect the CTRL+V
- Paste the local clipboard data

One thing I need to think about is what if the original CTRL+V
is pending for a very long time because the clipboard screwed up. Anyway,

it's a lot better than making an external call to xclip.