Re: Clipboard improvements, II

[Wesley Leggette <wleggette sbcglobal net>]

On Thu, 2004-05-20 at 08:21, Matthias Clasen wrote:
> 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. 

Does this mean that the clipboard will be able to sometimes just have
the sender automatically render the data on exit without prompting the
user? This would be beneficial when the data is something that is small
and easily fits in memory, like a small bit of text, right?


> 
> > 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
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list