Clipboard Improvements Idea

[James Westby]

On Mon, 5 Apr 2010 13:36:39 -0400, Sarah Strong <sarah.e.strong at gmail.com> wrote:
> Hey,
> 
> So I did some investigation of the clipboard problem yesterday. Here's what
> I found:
> 
> 
>    1. Most GUI applications I tested fail the copy-exit-paste test. A list
>    of applications tested is at the bottom of this message
>    2. Gnome-terminal handles copy-paste for applications that live in the
>    terminal, and it succeeds on copy-close-paste
>    3. Fixing the issue in GTK apps is fairly straightforward. You need to
>    set gtk_clipboard_store on exit if you own the clipboard
>    4. Most apps don't do that, likely some because they didn't test the
>    issue on a machine without glipper/klipper/parcellite/clipman
>    5. Other apps (Chrome, for one) intentionally do not use
>    gtk_clipboard_store because it has a performance hit
> 
> I think it would easily be a summer's work to chase down and fix the bug in
> many affected apps.

It sounds like it.

> There are 12 weeks in GSOC. In that time, I believe I can fix at a rate of
> one application a week, starting with smaller, easier to fix applications
> and moving towards larger, more popular, more difficult to fix ones. Eight
> fixes might be a good projected number of fixes to allow for unforeseen
> difficulties and extra non-fix work.

Right, and that doesn't seem to be too many given the number of broken
apps that you found.

> Other deliverables:
> 
>    1. Web page that details how to fix this bug in other programs

Great idea. I think investing time in this at the start would be
worthwhile. I imagine that some apps don't work as their developers just
never tested, and so if the problem is explained to them they will fix
it without you having to get involved.

Also, I think it would be great to document the things you have learnt
about what the problems are as well. For all the comments on the Ubuntu
bug, and all the different ways people have tried to deal with the
issue, it seems that hardly anyone understands all of the issue.

For instance, there have been insinuations that the daemons that record
everything in the clipboard are poor for performance, and chromium say
that gtk's method is also strangely slow on close. It would be great to
write down the arguments for this, then investigate whether they are
true, and if so, look at why that is.

If you agree then I would happily support a proposal that didn't have
the 12 weeks set aside for coding, but started with investigation and
documentation. It would be invaluable if we want to approach GNOME to
change the way that they do things.

>    2. Convince GTK+ to set gtk_clipboard_set_can_store by default. There's
>    likely a very good reason this isn't the case, but it might be a good thing
>    to check out since it could potentially fix the bug in many apps at once.

This falls in to that too. It seems to have been a deliberate decision
and so finding the reasons for that would be important.

> I'm a bit concerned that the overwhelming ubiquity of this bug means maybe
> we should be tackling it by adding glipper/klipper/parcellite/clipman to
> Ubuntu by default, instead. What do you guys think?

I agree that looking for solutions that fix many apps at once are a good
idea.

I do have some concerns about whether glipper etc. are a good idea:

  * They may have a performance hit.
  * They currently rely on a panel applet, which isn't suitable to have
    on panels by default. The applet should become optional if we want
    them installed by default.
  * We already have something like them by default in
    gnome-settings-daemon, so looking at improving that, possibly by
    merging code from one of the others would be my first instinct.


It seems this problem is not as straightforward as I assumed at first
:-) I really like the way you are digging in to the issue and looking
for the best solution.

Thanks,

James