Sarah Strong

Contact information

Your Name:

• Sarah Strong

=== Email Address: ===

• sarah.e.strong@gmail.com

=== IRC nickname: ===

• aganice

=== Launchpad ID: ===

• sarahstrong

=== Skype username: ===

• sarah-strong

=== Webpage/blog: ===

• www.sarahstrong.110mb.com

=== College-University: ===

• University of Toronto

=== Major: ===

• Computer Science, Software Engineering Specialist

Project

=== Project Name: ===

• The Great Clipboard Fixing Galore Project

=== Project Description: ===

Many popular Ubuntu apps have the problem that Copy/Paste doesn't work if the source is closed before the paste. It's a problem that's been reported and discussed at length, and there are several possible solutions

#1 Install a clipboard manager such as glipper, parcellite, or klipper by default

• Some people don't like this solution.

• It's going to be a hard sell to install a panel app with a robust history function to fix a problem with single selection copy/paste.

#2 Change the specification and xorg to correspond, so that applications are not required to explicitly request storage of their clipboard contents on quit.

• The way to implement this might be a hook on X quit that copies the selection from the quitting application into a special buffer - so sort of what klipper/glipper/do, but integrated into X and only done on application quit.

• Xorg developers don't like this idea

• It might create a performance problem
• Tt's been suggested many times without being changed, and this appears to be because there is a very good reason for leaving X's implementation as it is.

#3 Bring affected apps up to spec, so that they export their clipboard contents on exit as required by gnome-settings-daemon.

• The major objection to this solution is that it would be a big undertaking
• There would be no way to guarantee this problem didn't crop up in new apps
• Fixing the same problem in many different places sounds like poor design

• On the other hand, this fix is exactly what the ClipboardManager spec expects from apps.

=== If you would be willing and able to do other projects instead, which ones? ===

I would certainly be willing to work on an alternate project, but I haven't put in the time to research any others thoroughly. I'm quite interested in the Berkman Centre's Open Net Initiative tester, for one.

=== Why did you like this idea? ===

It's a problem that affects every Ubuntu user and one that can cause loss of user data, which puts it at a pretty high severity rating in my opinion. At a technical level, I'd enjoy the challenge of implementing a fix in a wide variety of applications, each with their differing languages and architectures.

=== Please describe a tentative project architecture or an approach to it: ===

=== Give us details about the milestones for this project ===

Weeks 1-4

• Fix the bug in one or more applications, documenting the steps taken
• Create website explaining the bug and how to fix it in other applications
  • Include a minimal GTK+ application in which the bug exists, probably just a text field
  • Step by step instruction on fixing it the bug in this minimal app
  • And the finished product.
  • Also include a discussion of issues around clipboard management - the performance hit, clipboard managers. Assume the page will be found by devs trying to fix the issue, but also users googling the behaviour.
• Test applications and compile a list of all affected popular open source Ubuntu apps
• Contact developers on affected apps and link them to the website in case they're interested in fixing it
• Research the best way to fix this bug. Possibilities include getting the GTK team to agree to store clipboard contents on app quit by default and incorporating a more robust clipboard management application in Ubuntu by default, a task that would involve modifying existing applications.
• If we identify a better way to fix the bug, create an application to the mentor for the rest of the term's work.

Weeks 5-12

• If a better way to fix the bug was identified in the first month of work and the mentor approved the work plan, follow that.
• Otherwise, complete approximately one fix a week to apps identified in the first month, following these steps:
  • Find an affected app. Focus on ones that are easy to fix first, then popular ones where users are likely to use the clipboard heavily. Copy, close, paste. Make sure the issue exists on the standard release version
  • Track down a ticket. If none exists, create one. If it's listed as in progress, check if the issue is fixed in the nightly and contact the community. List the bug as in progress and contact the dev community
  • May need to discuss the fix with the dev community if it's been rejected as a wont-fix
  • Check out the dev branch, build, make sure the issue still exists there - copy, close, paste.
  • Locate clipboard management code, compare to existing fixed clipboard management code
  • Debug to understand how clipboard management is currently handled
  • Debug to understand how application exit is currently handled
  • Fix it, test if the fix works
  • Run all regression tests
  • Add documentation of the change where appropriate
  • If they have a testing framework that allows automated testing of this change, add tests.
  • Submit patch to the community, make any changes requested, resubmit

=== Why will your proposal benefit Ubuntu? ===

It's a long-standing bug that we could fix for many major applications over the course of the summer. It has 2426 votes in Ubuntu Brainstorm and 85 "issue affects me too" and 80 comments in Launchpad.

Open Source

=== Previous Open Source development experience: ===

• Co-creator of the open source project TracSNAP, a social network analysis tool for developers using the Trac project management system. Currently contributing to pylint, a code analysis tool for python.

=== Why are you interested in Open Source? ===

I'm an avid user of open source software, and I believe that a robust open source community is essential to the development of young programmers like me. We need to have popular and fun to use applications that we can pop the top off of and tinker with.

Availability

=== How long will the project take? When can you begin? ===

• I expect to begin mid-May.

=== How much time do you expect to dedicate to this project? (weekly) ===

• Approximately 40 hours/week, including not just writing and testing code but also communication with my sponsor and related communities.

=== Where will you based during the summer? ===

• Toronto , ON and Montreal, QC

=== Do you have any commitments for the summer? (holidays/work/summer courses) ===

• I plan to take one distance course, an introduction to economic philosophy taught using a book I've already read. I don't expect it to take much time.

=== Please designate a back up student (in case you need to withdraw your application): ===

• Sorry, I don't know any other students applying to GSOC.

Other

=== Have you ever participated in a previous GSoC? ===

• No

=== Have you applied for any other 2010 Summer of Code projects? If yes, which ones? ===

• Nope

=== Why did you apply for the Google Summer of Code? ===

• Interest (...)

=== Why did you choose Ubuntu as a mentoring organisation? ===

• Ongoing user, it seems to be a distro most often complained about by those trying an alternative to Mac/Windows (...)

=== Why do you want to participate and why should Ubuntu choose you? ===

• Add resume fluff here, plus breakdown usability improvement goals.

*/