Re: Clipboard work

[Murray Cumming <murrayc murrayc com>]

Owen, it's wonderful that you are thinking about this. I'd love to help
though I'm not sure that I can be useful.

On Thu, 2004-04-08 at 21:55, Owen Taylor wrote:
> Thought I'd sit down and try to write down what needs doing on the
> clipboard situation, with an emphasis on GTK+. Additions appreciated.
> 
> Regards,
> 						Owen
> 
> ===
>  * Notification on clipboard changes for sensitizing menu and
>    clipboard items.
> 
>    This blocks largely on X changes; the necessary bits are in the 
>    FIXES extension that should be making its way out in a
>    freedesktop.org release in the near future. Looking
>    at the facilities on other platforms, figuring out the
>    GTK+ API doesn't need to block on the X features being
>    widely available.
> 
>  * Saving contents on clipboard exit
> 
>    Someone needs to come up with a protocol; propose it  
>    freedesktop.org, figure out the needed GTK+ API, and 
>    implement it. This is going to involve some sort of
>    gtk_wait_for_exit_cleanup() call. The architecture will also likely
>    involve a daemon, which will have to be implemented for GNOME.
> 
>    (I don't want to do straightforward contents-stealing, since
>    this works very badly for clients that provide large amounts
>    of data, or provide data in many formats)
> 
>  * Consistent UI behavior for middle-button-paste
> 
>    The GTK+ interpretation of middle button paste as pasting
>    the current selection is consistent with traditional 
>    X behavior, but inconsistent with other desktop components
>    such as openoffice.org, mozilla, Qt.
> 
>    See:
>  
>    http://mail.gnome.org/archives/usability/2002-November/msg00160.html
> 
>    for an alternate proposal
> 
>  * Consistent UI behavior for removing selection; in GTK+, 
>    unselection isn't on focus out, but rather when the
>    primary selection is grabbed away elsewhere. If we change
>    the interpretation of the primary selection, we may
>    want to reconsider this.
> 
>    There's some discussion of this in the thread linked above.
> 
>  * Performance
> 
>    GTK+ currently sends selections via the INCR protocol in (iirc) 4k
>    chunks; it should be possible to use much bigger chunks ... 256k  
>    or so by looking at the maximum request size for the server.
> 
>  * Better definition of some target types. In particular the text/plain
>    target type is poorly defined.
> 
>    (http://bugzilla.gnome.org/show_bug.cgi?id=55117)
-- 
Murray Cumming
www.murrayc.com
murrayc murrayc com