Re: Clipboard work

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
> 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  
>, 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, mozilla, Qt.
>    See:
>    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.
>    (
Murray Cumming
murrayc murrayc com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]