Google Summer of Code Ideas

This page lists our project ideas for Google Summer of Code 2009.

Before applying for a project
  • Join our IRC channel #netsurf on Freenode and introduce yourself. Also, subscribe to the developer mailing list.
  • Have access to a computer with supported OS (RISC OS, Linux, FreeBSD, BeOS, AmigaOS etc) or an OS relevant for the project you want to apply for (Windows, Mac OS).
  • Get up to speed with Git, as we use this for source control, and get the NetSurf source code.
  • Build NetSurf and enjoy using it. (Ask if you need help.)
  • Get familiarised with the source code – read the code documentation.
  • Consider submitting a patch to fix an issue on our bug tracker or feature request tracker
When applying for a project
  • Tell us about yourself, your experience, and why you want to work with us.
  • Describe the project you want to do, and how you plan to go about doing it. Do not simply copy the project description from the ideas page.
  • Create a set of project milestones (ranging from a couple to maximum 10) with expected completion dates. This will be useful for you as guidance and for us to set our expectations right.
  • Describe how you will test your contributions.
  • Include your IRC nick in your application if you've spoken with us on #netsurf, so that we recognise you. We strongly recommend that you communicate with us before submitting an application.
  • We expect GSoC to be mostly equivalent to a full-time job. Therefore, please tell us if you have any other demands on your time.
During the project
  • Most of NetSurf team communication happens via #netsurf IRC during evenings and nights (CET). We expect you to join in on a regular basis for help, discussions and project updates. Note that you're not restricted to speaking to your assigned mentor; the whole development team are willing to help wherever they can.
  • When improving NetSurf's layout engine, be able to create test cases and verify that existing test cases don't get broken.
  • Keep NetSurf's project goals in mind, especially the first point.

There is some more information in the GSoC section of our wiki. Note particularly the student guidelines.

Please get in touch if any of these ideas appeal to you or if you have your own idea for either NetSurf or one of NetSurf's sub-projects. Come and chat to the developers in the NetSurf IRC channel or post to the developer mailing list.

All these ideas require knowledge of C, as NetSurf is entirely written in C.

See the Feature Requests tracker for more ideas.

Keyboard navigation

The browser currently requires a mouse to use. Keyboard shortcuts would move between and activate links, inputs, etc. The document structure is stored in a tree, and algorithms for walking through the tree to find the next link or input would need to be developed. A further improvement would be to take layout position into account and implement moving in 2D.

Skills required: C, HTML, CSS, usability

Difficulty: Easy

Existing code: Key press handling, Box tree structures

References:

Page reader

The web is a vast resource of information and services. Traditional browsers enable its access for people who can see. NetSurf attempts to help partially sighted users with a sophisticated scaling / zoom feature, however it could be improved further with a page reading option. Speech synthesis could be used to render pages as spoken output.

There are already several libraries for speech synthesis. This project would first involve enabling NetSurf to speak the textual content of a page. Further work would improve the usability of the system by consideration for such factors as:

Skills required: C, accessibility

Difficulty: Medium – Hard

Existing code:

References: eSpeak text to speech synthesizer

LibDOM

LibDOM is an implementation of the W3C DOM. It currently implements a large proportion of DOM Level 3 Core. It is a work in progress and requires a fairly large number of fixes and additions before it can be integrated into NetSurf. Note that the scope of this project is quite large. We expect you to prioritise the parts you intend to implement.

Things that need doing include:

Skills required: C, DOM, XSLT (for the test suite)

Difficulty: Medium – Hard

Existing code: LibDOM sources

References: DOM specifications

Layout engine improvements

The layout engine forms part of the core of the browser. It is responsible for calculating the position of each part of the page. It currently has a number of deficiencies which should be addressed. These include the following parts of the CSS specification:

There are also other layout issues which could be tackled. For example in table layout some CSS properties, like height, are not handled for table rows.

Skills required: C, HTML, CSS

Difficulty: Medium – Hard

Existing code: layout engine, rendering code

References: CSS 2.1 specification, CSS 2.1 property index

Automated layout test engine

When NetSurf's layout engine is modified there is a risk that the change may break other pages. When problems are found, we create test cases which demonstrate the problem and keep them as regression tests once the issue is fixed. Currently, it takes quite a lot of manual effort to test NetSurf against all these test pages manually.

This project will create a tool for automatically testing NetSurf's layout engine for regressions. There are three components that will make up the completed project:

Minimal test front end

The first task will be to write the code necessary to call NetSurf's core engine to fetch a page, perform layout on it and dump the page's box tree. The box dump specifies the x/y coordinates, width and height of every box in the render tree, as well as other pertinent information.

This will involve the implementation of a simple test "front end". Unlike the GTK, RISC OS or BeOS, etc front ends, it is not to be a usable web browser, but a command line tool. The minimal debug and framebuffer front ends can be used as example code.

A defined test data format

The existing test data is fine for manual testing. However, for automated testing to work, there needs to be some ground truthed comparison data for each test input. There also needs to be a way of determining which comparison data is associated with which test.

To ensure that the test front end is working correctly, some amount of test input and comparison data will need to be created. The existing test suite can be used as a starting point for this.

A test runner

This can be some kind of script that runs the NetSurf test code for each page in the test suite and compares the box dump NetSurf produces with the expected data. It can output the test name and then PASS or FAIL.

Skills required: C, HTML, CSS, scripting

Difficulty: Medium

Existing code: existing test case repository, box dump code – box_dump() (note that this is extremely verbose and contains much data that is of little use in automated testing), debug front end, framebuffer front end

References:

Core UI enhancements

So that NetSurf can draw pages on different platforms, there is an interface between the core cross-platform code and the front end UI code that abstracts plotting. This interface is used to plot everything within the browser's content area.

There are parts of NetSurf's user interface which are common across platforms. However, each platform frontend has to implement these separately. This results in unnecessary duplication of functionality. Therefore, it would be good to move support for some of the common widgets into the core and draw them using the same plotting interface as used for the content area.

Initially, this will require:

Further to the above, the way NetSurf's core implements HTML frames is not particularly portable. This could be addressed as an extension.

Skills required: C, Usability

Difficulty: Easy – Medium

Existing code: Core treeview interface, Core treeview code

References: plotters interface, textarea widget code

Native Windows or Mac OS X port

NetSurf currently has user-interface layers for several systems including RISC OS, GTK (on Linux, FreeBSD, etc.), AmigaOS and BeOS. The GTK interface works on Windows or Mac OS X, but a native interface for these systems would give a better experience.

The existing front end implementations can be used as examples. Of these, the framebuffer front end is very self contained and the debug front end is the most minimal. For the rendering of NetSurf's content area, a set of plotters needs to be implemented for drawing primitives such as rectangles, plotting bitmaps and text.

Skills required: C, Windows UI development or Mac OS X UI development

Difficulty: Medium

Existing code: Declarations of functions that each interface must implement, plotters interface, RISC OS specific code, GTK specific code, BeOS specific code, AmigaOS specific code, framebuffer specific code

References:

Improved GTK front end

NetSurf's GTK front end is fairly usable at present, but would benefit from enhancement.

Outstanding functionality includes:

Skills required: C, GTK

Difficulty: Easy – Medium

Existing code: GTK specific code

References:

Improved Haiku/BeOS front end

NetSurf's BeOS frontend is reasonably usable, but would benefit from some enhancement.

Outstanding functionality includes:

Note: Any student interested in working on this front end should apply to both the NetSurf and Haiku organisations. The developer who would mentor this project is also a mentor for the Haiku organisation.

Skills required: C++, BeOS/Haiku UI toolkits

Difficulty: Easy – Medium

Existing code: BeOS specific code

References: Haiku organisation ideas

Improved RISC OS front end

NetSurf's RISC OS front end is the most feature complete. There are various ways in which it could be improved. These include:

Skills required: C, RISC OS Wimp programming using OSLib

Difficulty: Medium

Existing code: RISC OS specific code

References: OSLib