WIP: Migrate Wiki content over to src/docs

docs/google_summer_of_code2010.md

Index: docs/google_summer_of_code2010.md
diff --git a/docs/google_summer_of_code2010.md b/docs/google_summer_of_code2010.md
new file mode 100644
index 0000000000000000000000000000000000000000..fa83090f2c612a4f863b75aa45191ef500a025f3
--- /dev/null
+++ b/docs/google_summer_of_code2010.md
@@ -0,0 +1,131 @@
+# Key note
+
+Thanks for your interest in the GSoC 2010 for Chromium. Before applying, make sure you have checked out, built chromium and run the unit\_tests. Visit http://dev.chromium.org/ for the guidelines. Once you've done that (and not before), feel free to contact your potential mentor on the chromium irc channel.

[Bons, 2015/08/20 20:16:50]

propose deletion due to this doc being 5 years old

+
+We'd like to see you take an idea and flesh it out as much as possible, demonstrating how you'd accomplish it within the context of the Chromium codebase and how long it would take you. Please do not just copy and paste the project idea and submit that as your proposal, as that does not demonstrate any knowledge of Chromium and gives us very little to go on. The more detail and specifics you provide, the better chance you have at being accepted. If providing this level of detail proves too difficult, it might be a good indication you would have significant trouble during the Summer.
+Projects
+
+# Chromium Projects
+Email: chromium-dev@chromium.org
+IRC: irc.freenode.net #chromium
+
+## Improve BiDi support in WebKit and Chromium
+
+**Contact/Mentor**: Jeremy Moskovich (jeremy@chromium.org)<br>
+<b>Difficulty</b>: varied<br>
+<br>
+There remain a number of issues with BiDi language support in WebKit & Chromium.  The tasks involved cover a variety of of areas of the code, a list of open BiDi issues can be found in WebKit & Chromium bug trackers.<br>
+<br>
+Some sample tasks:<br>
+<ul><li>Add support for auto-directionality to Chromium textboxes - easy<br>
+</li><li>Layout tests for WebKit BiDi issues - easy<br>
+</li><li>Support split/directional caret when editing bidi text - hard<br>
+</li><li>Better BiDi support in Chromium omnibox - medium</li></ul>
+
+<h2>Port C/C++ Libraries and Applications to Native Client</h2>
+
+<b>Contact/Mentor</b>: Brad Chen (bradchen@google.com)<br>
+<b>Difficulty</b>: varied<br>
+<br>
+Native Client adds native code execution capabilities to Chromium and other browsers. For this project, we would like to port interesting native applications and libraries to Native Client. Examples of libraries that have already been ported include Cairo, QT, Mesa and ImageMagick. We've also ported a couple languages (Ruby, Lua, Awk) and are working on porting the game Nexuiz.<br>
+<br>
+<h2>Frontend for build status</h2>
+
+<b>Contact/Mentor</b>: Marc-Antoine Ruel (maruel@chromium.org)<br>
+<b>Difficulty</b>: easy<br>
+<b>Areas</b>: python, HTML, canvas, AJAX, doesn't require C++ experience.<br>
+<br>
+The Chromium team uses a <a href='http://src.chromium.org/viewvc/chrome/trunk/tools/buildbot'>forked</a> 0.7.12 <a href='http://github.com/nsylvain/buildbot/'>version</a> of <a href='http://buildbot.net'>buildbot</a>. Buildbot is used by <a href='http://build.webkit.org'>webkit</a> among <a href='http://buildbot.net/trac/wiki/SuccessStories'>others</a> and mozilla is actively contributing to it towards 0.8.0.<br>
+<br>
+We are writing a buildbot <a href='http://src.chromium.org/viewvc/chrome/trunk/tools/aebuild'>frontend</a> on <a href='http://code.google.com/appengine/docs/python/gettingstarted/'>AppEngine</a> in<br>
+python to separate status serving from the actual builds control. It uses <a href='http://www.djangoproject.com'>django</a>.<br>
+<br>
+We have an open ended position for a frontend project. We'd like to have someone to write new awesome presentations interfaces using newer HTML technologies instead of prerendering them server-side. The tasks are:<br>
+<ul><li>an AJAX-y Canvas-based <a href='http://build.chromium.org/buildbot/waterfall/waterfall'>waterfall</a> to replace the <a href='http://github.com/djmitche/buildbot/blob/master/buildbot/status/web/waterfall.py'>current</a> table based one.<br>
+</li><li>Figure out a new original way to present information from the try server useful for both the <a href='http://tryconsole.appspot.com'>users</a> (<a href='http://codereview.chromium.org/517046'>sources</a>) and the try server <a href='http://build.chromium.org/buildbot/try-server/waterfall'>maintainer</a> and is efficient server-side. We assume it'd require 2 differents layouts but better ideas are welcome.<br>
+</li><li>(optional) Make the <a href='http://build.chromium.org/buildbot/waterfall/console'>console</a> view work with git.</li></ul>
+
+As specified above, most of the work will be happening <a href='http://src.chromium.org/viewvc/chrome/trunk/tools/aebuild'>http://src.chromium.org/viewvc/chrome/trunk/tools/aebuild</a>.<br>
+<br>
+<i>Bonus points if the new presentation layers are usable on a cell phone.</i>
+
+<h2>(Mac) AppleScript support</h2>
+
+<b>Contact/Mentor</b>: Mike Pinkerton (pinkerton@chromium.org)<br>
+<b>Difficulty</b>: medium<br>
+<b>Areas</b>: C++, Objective-C, Cocoa, AppleScript<br>
+<br>
+Many third-party applications utilize AppleScript to automate user tasks and collect information from running applications, however Chromium is mostly left out as there is very little AppleScript support beyond the basic "open url" event. For starters, we would like to add a full suite for tab and window actions, followed by whatever else seems appropriate.<br>
+<br>
+Chromium has a concept of an "automation proxy" which is used primarily from automated UI tests to drive the browser from an external process (C++ or python). This AutomationProxy object is a good starting point.<br>
+<br>
+<h2>(Mac) Improve Drag and Drop Experience</h2>
+
+<b>Contact/Mentor</b>: Mike Pinkerton (pinkerton@chromium.org)<br>
+<b>Difficulty</b>: medium<br>
+<b>Areas</b>: C++, Objective-C, Cocoa<br>
+<br>
+The drag and drop experience in Mac Chromium is substandard in various areas:<br>
+<br>
+<ul><li>Dragging text and links from the web contents doesn't show a transparent thumbnail like in other apps<br>
+</li><li>HTML5 drag-n-drop has no preview images either<br>
+</li><li>Dragging bookmarks around on the bookmark bar should move others out of the way, like the tab strip.</li></ul>
+
+<h2>(Mac) Fixing ColorSync issues, fully enable pixel tests on 10.5 and 10.6</h2>
+
+<b>Contact/Mentor</b>: Mike Pinkerton (pinkerton@chromium.org)<br>
+<b>Difficulty</b>: medium<br>
+<b>Areas</b>: C++, Objective-C, Cocoa, WebKit, ColorSync<br>
+<br>
+Pixel tests for WebKit layout tests are currently enabled for Mac OS X but due to color differences caused by both our own color space bugs and factors beyond our control (HITheme vs. Cocoa scrollbar drawing differences), many are disabled. The following needs doing:<br>
+<br>
+<ul><li>Solving the remaining color space issues on 10.5 and 10.6 that cause real bugs in incorrectly rendering images and colors<br>
+</li><li>Weed out which tests fail due to real bugs and which fail due to theme drawing issues.<br>
+</li><li>Rebaselining tests that were baselined assuming the buggy behavior<br>
+</li><li>Propagate fixes into our Skia->NSImage conversion so favicons and other images have the correct colors on all OS versions.</li></ul>
+
+While this may not sound like a glamourous job, rendering correctness and fidelity is the cornerstone of the Chromium project. Contributions here improve the entire project and directly impact all users.<br>
+<br>
+<h2>(Mac) Access Web Content Via Accessibility Framework</h2>
+
+<b>Contact/Mentor</b>: Mike Pinkerton (pinkerton@chromium.org)<br>
+<b>Difficulty</b>: hard<br>
+<b>Areas</b>: C++, Objective-C, Cocoa, WebKit<br>
+<br>
+While the Chromium UI can easily be connected to Apple's Accessibility Framework, making web content accessible is much more difficult. Chromium's multi-process architecture means that the web content and the browser exist in separate processes, thus IPC must be used to fetch the web content. The bigger problem is that IPC from the browser process cannot be synchronous as any delays in responding by the renderer would block the browser's user interface. As a result, the browser can not simply ask for the content when the A11y Framework desires the content. We need a different solution.<br>
+<br>
+Some work along these lines has been started, but not much is actively in progress. This work involves plumbing between the browser and WebCore and would probably benefit all platforms, not just Mac OS X.<br>
+<br>
+<h2>Extension for Creating Custom Stylesheets</h2>
+<b>Contact:</b> Rachel Shearer (rshearer@google.com) <br>
+<b>Difficulty:</b> medium <br>
+<b>Areas:</b> WebKit, AJAX, Chromium Extensions <br>
+
+A Chromium extension that helps users create their own CSS style-sheets. The extension should allow users to identify a piece of content on the page, hit a key to bring up a simple widget that tweaks the look of that content -- font, bgcolor, fgcolor, font-style -- apply the update to the page, and if the user likes it, generate a CSS  rule that would create that effect. This would be a nice way to interactively and incrementally build up a CSS  stylesheet that matches the user's needs. Relates to <a href='http://src.chromium.org/viewvc/chrome?view=rev&revision=40882'>http://src.chromium.org/viewvc/chrome?view=rev&amp;revision=40882</a>
+
+<h2>Settings for font and color customization</h2>
+<b>Contact</b>: Jonas Klink (klink@chromium.org)<br>
+<b>Difficulty</b>: medium<br>
+<b>Areas</b>: C++, WebKit<br>
+
+Users need a way to customize the appearance of Chromium, including setting default and minimum font size, font face, as well as override foreground/background color and link/visited link color. If possible, we'd also like to provide a mode to respect system colors/fonts, such as High Contrast mode.<br>
+<br>
+For related issues, see <a href='http://crbug.com/92'>issue92</a> and <a href='http://crbug.com/7417'>issue7417</a>.<br>
+<br>
+<h2>(Linux) Improve KDE support</h2>
+<b>Contact</b>: Evan Martin (evan@chromium.org)<br>
+<b>Areas</b>: C++, KDE, Qt<br>
+
+Though we've made an attempt to work ok with KDE, most of the team uses GNOME so we still have a variety of <a href='http://code.google.com/p/chromium/issues/list?q=label:KDE'>issues on KDE systems</a>.  I'd like to mentor someone who is experienced with KDE through polishing the Chrome experience for KDE users.  Aside from that bug list, I'd like to hear other ideas of ways to improve our KDE integration.  (Note: rewriting the UI entirely in Qt is way too large for a SoC project.)<br>
+<br>
+<h2>(Linux) Better support for tiling/tabbed window managers</h2>
+<b>Contact</b>: Evan Martin (evan@chromium.org)<br>
+<b>Areas</b>: C++, X11<br>
+
+Chrome's tab strip ends up looking redundant when your window manager itself provides a tab strip.  But Chrome knows more than a normal app about the way its tabs ought to behave: depending on how you interact with a page, new tabs should be opened "next to" the current tab or "on the right".  I'd like to see a proposal for a way to better integrate Chrome into such a system (perhaps allowing X clients to expose additional metadata about where their new windows belong?) as well as an implementation in at least two different window managers (if you only implement it in one, bugs in the implementation become hard coded into the spec).<br>
+<br>
+<h1>Chromium OS Projects</h1>
+Email: chromium-os-dev@chromium.org<br>
+IRC: irc.freenode.net #chromium-os<br>
+<br>
+See <a href='http://code.google.com/p/chromium-os/wiki/GoogleSummerOfCode2010'>the Chromium OS page</a> for projects.