Does Fl::paste() wait until FL_PASTE occurs before returning?

[Brian Larsen]

Using Ubuntu with X11.

My interpretation of the documentation for Fl::paste() is I call it 

from my code, it returns and then I need to wait for the data to 

be ready, i.e. FL_PASTE event occurs.      

However, in my tests when I added a timeout loop after the call to 

Fl::paste(), it appears that Fl::paste() doesn't return until the 

FL_PASTE event occurs. The loop only iterates once even if it takes 

more than 1 second when pasting a *huge* amount of data.

I just want to confirm if Fl::paste() is supposed to wait until FL_PASTE 

happens before returning. If so, I can move my timeout code to 

handle(), if I decide I really want it.

[Manolo]

An FLTK application calls Fl::paste() when it wants to receive the clipboard content.

That's usually done in a callback function. The first argument of the Fl::paste() call

identifies the receiving widget.

Then, control returns to the event loop.

At some later point, the receiving widget's handle() function will be called

with an FL_PASTE event. That function can use Fl::event_text() to get the pasted text

and Fl::event_length() to get that text's byte length. If an image is being pasted,

the value of Fl::event_clipboard() can be cast to type Fl_RGB_Image*.

The FLTK library internally does all the work of receiving a potentially large

piece of text or image. When that work is completed, FLTK generates the 

FL_PASTE event and sends it to the receiving widget's handle method which

has immediate access to the entire pasted text or image.

[Manolo]

The documentation of function Fl::paste() contains this sentence:

  The receiver should be prepared to be called directly by this, or for it to happen later, or possibly not at all.

It means that, depending on the platform or where is the source of the pasted data,

the Fl::paste() function can return before the FL_PASTE event gets sent to the receiving widget. In that case

control goes to the FLTK event loop. But function Fl::paste() itself can also send itself the FL_PASTE event to

the receiving widget and then return.

[Bill Spitzak]

The way it works was to get around how X11 clipboard works. The program has to request a paste, which then causes the X11 server to send the data in a different call. Emulating a single call that returns the pasted data would require it to implement it's own event loop internally so that it could wait for that data to arrive in the events. Also if the source of the data crashed or exited then the data would never arrive, requiring a timeout. The API fltk uses is much simpler and foolproof to implement.

I think all other systems implement a single call that just returns the data to paste. For these, calling Fl::paste() just gets the data and does the FL_PASTE event immediately before returning.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/4c393ab7-e09a-40ff-ad31-5038e259fd36n%40googlegroups.com.

[Brian Larsen]

Thanks spitzak and Manolo,
I didn't realize that FL_PASTE could occur before FL::paste() returned.
I was trying to move some of the work out of handle(), but I reverted
to my previous method; when CTRL+V is seen it doesn't get added to the
app's key queue until FL_PASTE is seen. If FL_PASTE doesn't occur in
200ms (arbitrary) the CTRL+V is ignored. This is all done in handle().

Presumably the ignore will only occur if there is some error, e.g. X11
never provides the data. At least now if this did occur my app won't be stuck
waiting forever.

For fun I tested copying and pasting over 4GB without any issues, except that
it takes about 5 seconds :)