Re: gtk_clipboard_wait_for_text_timeout

[Gaal Yahas <gaal forum2 org>]

On Wed, Mar 03, 2004 at 12:06:34PM -0500, Owen Taylor wrote:
> > In applications it is often useful to have a way to wait on the clipboard,
> > but only tolerate short waits. A delay of 50ms, for example, is not
> > noticeable by the user and is *usually* enough to get text from the
> > clipboard. In case the time window is not enough to get the text, the
> > application can act as if the request failed.
> > 
> > I'd like to suggest the following be included in gtk/gtkclipboard.c:
> > (This is a simple function, but it can't simply be put in user code
> > because it uses some private gtk symbols)
> 
> API proposals generally belong in bugzilla, but here I'm pretty sure
> we shouldn't add such a function. Adding a timeout like this makes
> the clipboard unreliable for the user for no apparent reason, and
> unreliable differently between apps.
> 
> If the concern is applications not responding at all, then we 
> possibly should consider reducing the time for GTK+ to timeout
> selection retrieval (I think it's currently 5 minutes, which is
> almost certainly too long.)

The application I have in mind is populating a field in a newly created
dialog according to a hint from the clipboard. The dialog will work fine
without the initial data, but for the user it's a nice shortcut if it
automagically appears there when the dialog is shown.

(Sometimes it's even possible to skip the dialog completely based on
information in the clipboard, if it looks right. For example, suppose
we're adding a "create link" tool in an editor. If the clipboard contains
a URL, and some text is selected in the editor GtkTextView, the link can
be inserted in-place immediately. This tolerates occasional failures:
the user would get the dialog and paste the information explicitly.)

-- 
Gaal Yahas <gaal forum2 org>
http://gaal.livejournal.com/