Re: Clipboard improvements, II

[Matthias Clasen <mclasen redhat com>]

On Thu, 2004-05-20 at 08:34, Hans Breuer wrote:
> At 21:37 17.05.04, Matthias Clasen wrote:
> >Here is another piece of clipboard api that will be needed to make
> >the clipboard experience less painful. It is the cleanup call outlined
> >earlier by Owen.
> >
> >Tor, Hans, I'm posting this mainly as a quick check that the proposed
> >API is implementable for the Windows clipboard as well.
> 
> Does this mean any further questions will be ignored ? I hope, not ;-)
> 
> First to your question : if I understand correctly the proposed API is to 
> let GTK work after a model called "delayed rendering" in the windoze world. 
> That is not simply create the whole clipboard content on ctrl-C but just 
> advertize the ability to create the content (in some formats) on request.

That is basically how the clipboard has always worked in gtk: When you
press ctrl-C in app A, it takes ownership of the CLIPBOARD selection,
but doesn't "render" any content. When you press ctrl-V in app B, it
asks app A to convert the CLIPBOARD selection to the target of its
choice. At that point, app A "renders" the content.

> 
> When the application ends and there still is some data 'advertised' in the 
> clipboard the users gets asked if it should be rendered now or dropped. If 
> it should be rendered it is triggered by a call to 
> gtk_clipboard_wait_for_exit_cleanup()

Basically, thats the idea behind wait_for_exit_cleanup(), but the
general feeling on xdg-list was that it is better to have the clipboard
manager deal with the "user interaction" aspects, so apps should just
always call wait_for_exit_cleanup(), and the clipboard manager will
decide whether to ask the user before saving the contents. 

> If my understanding is right, it certainly should be implementable on 
> win32, although the current code in gdk/win32 does not make use of delayed 
> rendering -  following the comment cause of implementation problems - maybe 
> related to the differences in clipboard owner models (already tried to get 
> some comment from X experts in my previous mail on the subject, but 
> apparently failed ;)

Did my comments above help ?
> 
> Now for my questions : all this dealing with GTK Clipboard improveents is 
> still restricted to plain text, right ?
> Wouldn't it be feasible to extend the API while on it to at least have 
> something like QClipboard::setImage(), i.e. gtk_clipboard_set_image() and 
> gtk_clipboard_get_image(). Or is what QT does so far away from a standard, 
> that it shouldn't be considered for GTK ?

Apps are free to advertise whatever targets they want on the clipboard. 
What we may be missing is convenience api on par with 
gtk_clipboard_set_text(), gtk_clipboard_request_text() for nontextual
targets.

> Oh, and while on the subject of IMO real clipboard improments, could 
> something  be done to also support vector data ? Maybe stuff in SVG from 
> the cross platform application [GIMP and Dia spring to my mind, but there 
> are obviously more] and silently convert it to WMF/EMF on demand within the 
> gdk/win32 backend - and do what ever is appropriate for X11 ?

In the X clipboard model, conversion is generally done on the sender
side, ie the clipboard owner advertises the content in all targets that
it knows how to convert it to.

Matthias