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
- Join our IRC channel
- 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:
- Overview mode, which announces the document headings
- Section skipping to allow swift to access to the next part of the document
- Repetition of the current section or skipping back to previous sections
- How to differentiate link text from the rest of the text
- How to handle emphasis tags; <em> and <strong>
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:
-
Use vtables rather than known function names + switching on node type
A vtable is a structure containing function pointers. Each node type will populate the vtable with the appropriate functions. These may then be called by any client without the client needing to know what the node type is.
-
Implement the rest of DOM 3/2/1/0, primarily:
- Events
- HTML
- Other DOM modules
-
Test suite
The W3C provide a test suite for DOM implementations. It is stored in an XML format and currently, has transformations from this format to Java and JavaScript source code. Ideally, a transformation into C source code will be written so that LibDOM may be tested automatically.
-
Integration with NetSurf
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:
- Stacking order (
z-index
) - Fixed position (
position: fixed;
) - Fixed backgrounds (
background-attachment: fixed;
) - Vertical alignment (
vertical-align
) - Handling of white space and wrapping (
white-space
)
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:
- A plotter-based treeview for global history, cookie manager and bookmarks.
- A plotter-based (single & multi line) text input widget.
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:
- Find
- Bookmarks (also see core UI enhancements idea)
- Improved contextual right-click menu ("Save image as..." and "Open in new tab..." for example)
- GUI should adjust to match GTK interface preferences (icons in menu, text under toolbar buttons, etc.)
- File uploads
- View source
- Documentation (user guide)
- Favicons
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:
- Tabs
- Download window
- Bookmarks, also see core UI enhancements idea
- History, also see core UI enhancements idea
- Fix <frame> support, also see core UI enhancements idea
- Printing
- Preferences window
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:
- Tabs
- Better config e.g. web page language choice option
- Richer status bar, perhaps progress bar and icons for SSL, and to indicate what it's doing
- OLE
- Favicons
Skills required: C, RISC OS Wimp programming using OSLib
Difficulty: Medium
Existing code: RISC OS specific code
References: OSLib