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:

The current right way of implementing the fix is to make apps conform to the ClipboardManager spec. I'd like to investigate alternative ways to solve it, though, because the issue exists in more Ubuntu apps than not, and that fix would require one patch per application. The plan, developed with the help of other devs on the ubuntu-soc mailing list and #ubuntu-gsoc, is to spend a month investigating and documenting the problem. Then I'd either pursue the original plan to fix a variety of popular apps or pursue the new fix we determined during the month of investigation.

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?

• Nope!

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

• Not a one.

Why did you apply for the Google Summer of Code?

• I'd love to get further involved in open source development, and Ubuntu in particular, but it's always difficult to know where to start. With Summer of Code, I'd have a concrete task that needs completion and a mentor to help me work through the problem.

Why did you choose Ubuntu as a mentoring organisation?

• I use Ubuntu as my primary OS and I'd love to fix the copy/paste problem because it affects me. It also seems to be the distro most often suggested for those trying an alternative to Mac/Windows, so I think the 100 paper cuts style usability issues like these are important not just for Ubuntu's success, but also for FOSS's reputation in the public at large.

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

• I've worked hard to investigate the problem and develop a plan for the best fix possible with participaton of the community. Check the Clipboard Improvement Idea thread in the ubuntu-soc mailing list for how I developed my plan of attack. I also spoke with james_w and antileet on #ubuntu-gsoc about the project.

• I have excellent communication skills, as illustrated in my work as an English teacher and professional writer.
• I just started contributing to an open source app, and I submitted a patch that was incorporated into the upcoming pylint 0.21.
• I co-created tracsnap, an open source plugin to the Trac project manament system
• I've worked in Python, Ruby, Java, C, Scheme, Standard ML, Haskell, and Prolog. I don't pretend to be proficient in all of these languages, but the flexibility it's given me as a programmer will be valuable when I work on patching a wide variety of applications.