Clipboard Improvements Idea

[David Bensimon]

Kevin McKinney wrote:
> While researching the clipboard issue, I noticed this in the documentation
> here http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt:
> 
> 
> 
> “*A remaining somewhat odd thing about X selections is that exiting the*
> 
> *app you did a cut/copy from removes the cut/copied data from the*
> 
> *clipboard, since the selection protocol is asynchronous and requires*
> 
> *the source app to provide the data at paste time. The solution here*
> 
> *would be a standardized protocol for a "clipboard daemon" so that apps*
> 
> *could hand off their data to a daemon when they exit. Or*
> 
> *alternatively, you can run an application such as xclipboard which*
> 
> *constantly "harvests" clipboard selections.*”
> 
> 
> 
> It seems reasonable to create a daemon or some sort of program to store the
> clipboard data in such a way so it is available after the original
> application has exited.  However, by architecting this functionality in this
> manner, existing applications may some degree of change (as previously noted
> by other developers).  Further, when an application is closed, the
> daemon/program would have to capture the clipboard data.  There are several
> posts about this enhancement, and I would be willing to provide assistance
> in conjunction with other developers.
> 
> 
> 
> Regards,
> 
> Kevin McKinney
> 
> On Sat, Mar 27, 2010 at 12:29 AM, Sarah Strong <sarah.e.strong at gmail.com>wrote:
> 
>> Hey, James,
>>
>> I believe the class of apps that break are ones that don't conform to the
>> freedesktop.org ClipboardManager specifications
>> http://www.freedesktop.org/wiki/ClipboardManager and modify them. You can
>> find details on the clipboard problem at the bug David Bensimmon lists at
>> https://bugs.launchpad.net/ubuntu/+bug/11334
>>
>> It lists some popular apps along with their status. In some case it links
>> to resolved bug reports with diffs that can be used for reference code in
>> tracking down and fixing the problem in other applications. The apps it
>> lists as non-conforming would be a great starting point, and you could find
>> other affected applications either by searching for complaints online or by
>> spending one terribly boring afternoon testing popular applications.
>>
>> I definitely think it's a worthwhile problem to tackle, and I love the idea
>> with tinkering with a small bug on a whole bunch of different projects, each
>> with their own language and style dialect. It looks like a potentially easy
>> fix in most of them, though, so I'm not convinced it's a full summer's work.
>> I won't be able to try tackling one until after my classes end on April 1st,
>> but I'll post a trip report and ultra-rough time/difficulty estimation from
>> an undergraduate's POV here that weekend. We might also try asking someone
>> who resolved one of the bugs linked on the master copy/paste page for an
>> idea of how long it took, too.
>>
>> -Sarah
>>
>>
>>
>>> Message: 7
>>> Date: Fri, 26 Mar 2010 15:48:46 -0400
>>> From: James Westby <jw+debian at jameswestby.net<jw%2Bdebian at jameswestby.net>
>>> Subject: Re: Clipboard Improvements Idea
>>> To: Sarah Strong <sarah.e.strong at gmail.com>,
>>>
>>>        ubuntu-soc at lists.ubuntu.com
>>> Message-ID: <874ok2n9sx.fsf at jameswestby.net>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>>
>>> On Wed, 24 Mar 2010 18:53:06 -0400, Sarah Strong <
>>> sarah.e.strong at gmail.com> wrote:
>>>> Hey, all,
>>>>
>>>> I'm a third year computer science student poking around on GSOC ideas. I
>>>> asked about the state of clipboard support in the xorg project, and got
>>> a
>>>> very useful overview of how X handles it: http://pastebin.com/1n4mRck8.
>>> It
>>>> sounds like it wouldn't be appropriate to make any change to X in fixing
>>>> clipboard management issues. The xorg devs seem to think it'd be
>>> appropriate
>>>> to eliminate the pointer to xorg in the description
>>>> https://wiki.ubuntu.com/GoogleSoC2010/Ideas, too.
>>> Hi Sarah,
>>>
>>> Nice job on investigating this.
>>>
>>>> Combining that with James' comment, it looks like the most obvious way
>>> to
>>>> tackle this task would be per-application. If that isn't a big enough
>>> job,
>>>> perhaps David Bensimon could combine it with another grab bag idea he's
>>>> mentoring such as the nautilus improvements one, or with other one
>>> hundred
>>>> paper cuts style usability issues
>>>> https://bugs.launchpad.net/hundredpapercuts
>>>>
>>>> Does that sound like a reasonable modification to the idea?
>>> I think so. It depends on how many apps need fixing I guess. Is it
>>> individual apps that break, or classes such as running Qt apps under
>>> GNOME?
>>>
>>> It might be a difficult project to do if we have no idea which apps
>>> don't work :-)
>>>
>>> Thanks,
>>>
>>> James
>>>
>> --
>> ubuntu-soc mailing list
>> ubuntu-soc at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-soc
>>
>>
> 

I think Kevin has it right...

"create a daemon or some sort of program to store the
clipboard data in such a way so it is available after the original
application has exited."

:-)

I feel it is a better idea that changing bits of every different project
to conform to how GNOME's clipboard manager works. I am open to anyone
who may have another opinion on this matter.

Kevin, just to clarify and make sure we are on the same page - this
proposal does not touch on X selection paste buffer, only on the
clipboard experience in GNOME (i.e. Edit > Copy/Cut/Past and Ctrl-C/X/V)
as explained in Bug #11334 (and its duplicates).

Cheers,

David