Skip to main content
Jump to: navigation, search

Google Summer of Code 2013 Ideas

Revision as of 14:00, 12 March 2013 by (Talk | contribs) (GEF: Record figures and HTML-like labels in DOT for Zest: Re-add note for interested students)

Existing bugs marked "helpwanted" are a good source of project ideas.


  • Be creative
  • Be specific: what do you want to be implemented
  • If you are willing to mentor those ideas, add your name and email to the idea.
  • GSoC project ideas should align with an existing Eclipse project
  • If you're an interested student, add your name and email next to the idea. It is ok to have several students interested in one idea.
  • Aspiring students and mentors need to register and submit their proposals on the SoC app

Mentors info

If you were a mentor last year then you are automatically in the list this year (the GSoC site may require that you re-register, but we think of you as "in").

Note that we only accept as mentors people who are known to us. This includes Eclipse committers. If you would like to be a mentor, please either introduce yourself to the group using the soc-dev mailing list, or send a note to EMO.

Ideas submission

Idea proposal should contain the following information:

  • project title, like "WTP - Improve auto-complete in xml editor"
  • description with links to bug reports, project wiki pages, etc
  • Reporter: who submitted idea (optional e-mail)
  • Possible Mentors: who would like to mentor the students
  • More info: other links or e-mail
  • Eclipse Project: link to main eclipse project that improvement is targeting
  • Potential students: who is interested (with optional e-mail). This one completely informal, to actually be interested you need to submit the proposal. Contact the idea owner or possible mentor to get some details before submitting it.


These are some ideas. Students feel free to base your GSoC proposals on these ideas (note that you are more likely to find a mentor for an idea that has been proposed by a mentor). Some of these ideas can be factored into multiple projects; a GSoC project proposal can work on parts of these ideas (i.e. you don't necessarily have to do it all).

There are other sources of ideas. There are numerous bugs in the Eclipse Bugzilla issue tracking system marked as "helpwanted" that may give you ideas.

Eclipse Code Recommenders: Workspace-Local Code Search

When writing software, developers frequently find themselves in a situation where they are absolutely certain that someone else must have faced (and solved!) the same problem before, but they just cannot find that piece of code. This is where the proposed code search feature can help: Based on the context the developer currently is in (e.g., the current method and the available objects), code search will search through the entire workspace and present pieces of code that match the current context. For this proposal to work well, the search engine must be (1) fast and (2) present its results in a condensed snippet form, so that the developer can quickly decide which results are worth a closer look.

A prototype of a code search engine has already been developed as a Master's thesis at Technische Universität Darmstadt. This project could either build upon that prototype or, taking into account the lessons learned there, start from scratch.

Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the mailing list)

Additional Resources: Prototype implementation in incubator

Interested students : Kavith Thiranga Lokuhewage (

Eclipse Code Recommenders: Social Snippets

With SnipMatch, Eclipse Code Recommenders already offers one way of searching for and accessing snippets. However, at the moment, there is no easy way to create new snippets and to share these snippets with other developers. This goal of this proposal is thus to create a social snippets infrastructure, which allows developers to create and rate snippets. This infrastructure should then support multiple backends, SnipMatch and its collection of snippets being one of them.

Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the mailing list)

Eclipse Code Recommenders: Social Extdoc

Currently, the Extdoc view provides extended documentation one classes and methods which has been data-mined from code; there is no way for the user to influence the documentation yet. The goal of this proposal is to enhance Extdoc such that users can create, annotate, and rate contributions to the documentation of classes or methods.

Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the mailing list)

Eclipse Code Recommenders: Usage Data Collection for Code Completion and Beyond

Do you know how much time code completion saves you per day? No? Well, this proposal should address that by (locally) collecting usage data that can answer this and more sophisticated questions. Moreover, the collected data can then be used to make recommendations on the most effective use of your IDE, e.g., recommending a keyboard shortcut that you don't use (and presumably don't even know about).

Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the mailing list)

Interested Student: Timur Achmetow

Additional Resources:

Eclipse Code Recommenders: Advanced Ranking Mechanisms for Multiple Code Recommenders

Over the years, Eclipse Code Recommenders has developed and experimented with numerous code completion engines, providing intelligent code completion for method calls, method overrides, call chains and (soon) types, not to mention subwords completion. In the course of this work, it turned out that the existing ranking mechanisms of JDT leave something to be desired. The goal of this project is thus to come up with a mechanism that can incorporate a variety of recommenders and produces the ranking the user expects, even if the individual engines disagree on what constitutes the perfect recommendation.

Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the mailing list)

Additional Resources:

Eclipse VJET: Improve VJET's support for JQuery UI

VJET Is a JavaScript IDE which provides the best development experience for developers building object based JavaScript. With content assist for classes which are comparable to Java content assist and support for concepts which are exclusive to JavaScript and javascript frameworks. We are looking for help with improving the Jquery support and supporting the JQuery plugin model. VJET has developed a type system for JavaScript which allows for static and dynamic typing. The primary goal is to add to the JQuery meta type library (currently lives here - ) with jQuery UI support. The secondary goal is to come up with an extension to support the JQuery plugin model.

Possible Mentor: Justin Early (contact us on the mailing list)

Interested Student: Atul Pratap Singh

Eclipse VJET: Help test and improve VJET's NodeJS support

VJET Is a JavaScript IDE which provides the best development experience for developers building object based JavaScript. With content assist for classes which are comparable to Java content assist and support for concepts which are exclusive to JavaScript and javascript frameworks. We are looking for help with testing NodeJS support provided by VJET and supporting the NodeJS user defined modules. VJET has developed a type system for JavaScript which allows for static and dynamic typing. The primary goal is to test the support for NodeJS that VJET supports. The secondary goal is to come up with an extension to VJET to support the NodeJs module system.

Possible Mentor: Justin Early (contact us on the mailing list)

Eclipse Platform: Create filterable Console View

The console view is a very important tool for developers, the analyse stacktraces here, look at System.out messages, etc. It should allow to have a filter to filter for example for a package name. It should be possible to save defined filters similar to the Android LogCat view based on fields. Optional this work could also start the migration of this view to Eclipse 4.

Possible Mentor: Lars Vogel and Markus Alexander Kuppe

Interested student: Lukas Zorich (

Eclipse Platform: Create Eclipse 4 (e4) based Progress View (see bug #401655)

The progress view provides the main status overview for the Jobs API and is used not only in the Eclipse IDE itself but also by many RCP apps. With the move to e4, the progress view has not been adapted to the new API though and thus is currently not useable in plain e4 apps. If time permits other legacy views (e.g. the console view) could be ported to Eclipse 4 too.

Possible Mentor: Lars Vogel, Markus Alexander Kuppe and Sopot Çela

Eclipse Orion: Create a app store or portal for Orion plugins

At the moment, the Orion list of PlugIns is housed at a team member's GitHub account and it's desirable to create a more formal approach to how and where Orion Plugins are managed. This could take into account teams or products which want to host their own (possibly internal) list of approved plugins, for example. This task may also include dynamic lists of plugin providers for an Orion installation.

Possible Mentor: Ken Walker and Mark Macdonald (contact us on the mailing list)

Eclipse Platform: Implementing generic in JFace viewers

JFace viewers are heavily used in Eclipse and developers could benefit from Generic support to avoid unnecessary casting. suggested that we move the JFace viewers to generics.

Possible Mentor: Lars Vogel and Markus Alexander Kuppe
Interested non-student: Peter Andberg (

Eclipse Nebula: Provide Nebula Integration for WindowBuilder


The Nebula and WindowBuilder projects are seeking a mechanism to enable inclusion of (Nebula) widgets into the WindowBuilder pallete. Nebula users would then be able to effortless use the widgets by using the provided drag and drop mechanism in WindowBuilder. We are looking for a general abstraction that enables us to easily incorporate widgets into the WindowBuilder pallete and let WindowBuilder consume specific widget parameters and hints to optimize the user experience. Tooling and extension points are already available in WindowBuilder and we are looking for ways to leverage this. The inclusion should not only work for Nebula widgets but for all widgets. The solution could include some sort of discovery mechanism to automatically detect and include widgets.

New Components Manual

Designer Customization

We are looking for creative visually oriented students who love to push pixels.

Possible Mentor: Wim Jongman

eTrice: Provide Error Markers and Quick Fixes in State Chart Diagrams

Last year we had three successful GSoC projects. One of those was the Extended Validation and Proposal Generation for State Machines.

This year we would like to make the markers (infos and warnings) that are generated by the algorithm available in the diagram. The goal is to

  • provide visual feed back for infos and warnings
  • create a mechanism to allow the user to pick from a list of proposals (similar to quick fixes)

One kind of proposal is that an incoming message should be handled. That could be handled in two ways: add the corresponding trigger to an existing transition starting at this state or create a new transition with this trigger. To initiate this kind of action a button could be added to Graphiti's context button pad that opens a dialog with a list of proposals or quick fixes.

For this project some knowledge of Graphiti and ideally of eTrice's implementation of the State Machine Editor would be helpful.

Possible mentor: Henrik Rentz-Reichert

Eclipse Orion: Debugger Plug-in for Client- and Server-side

A debugger to inspect code execution at runtime is an often used tool and taken for granted in mature desktop-based IDEs. This is not yet the case for web-based IDEs like Orion. The goal of this project is to develop a browser-based debugger that integrates into Orion and allows for a consistent use of the IDE without the need to switch to specialized tools when debugging JavaScript on the client-side or (optimally) some other arbitrary language on the server-side.

The principle to control the client and server debugger is the same: through a remote debugging protocol. Therefore it should be possible to use the same UI parts for every line-based debugger that supports remote debugging just by implementing a connector module, that abstracts from the specifics of the debugging protocol.

The Orion project already has a working solution to communicate with the Chrome browser, which can be used as an orientation. The goals would be to

  • provide a reusable debugging infrastructure,
  • a connection to a client-side and to a server-side debugger and
  • a debugger UI that integrates into Orion.

Possible Mentor: Simon Kaegi

Possible Student: Leo Roos

Nebula NatTable: CSS styling support

NatTable already supports a flexible way for styling. This styling configuration is currently done in code by setting SWT styles into the ConfigRegistry of NatTable. To separate styling information out of the source code, there should be CSS styling support in NatTable. This way NatTable can be included and styled in an Eclipse 4 application like any other control.

Possible Mentors: Dirk Fauth, Edwin Park

Nebula NatTable: Next Generation NatTable architecture

NatTable is a framework to create enterprise ready tables/grids to an application that is based on SWT. It is very flexible in terms of configuration and extension and can handle huge datasets. It's huge feature set makes it interesting in various projects and use cases. Unfortunately the current architecture has reached its limits and needs to be overhauled. With this project we would like to:

  • ensure that NatTable will be a project that is important in the future
  • lower the costs for learning to use NatTable
  • make it easier to configure NatTable
  • make it easier to extend NatTable
  • add support for additional UI toolkits

We are currently specifying the new architecture based on dependency injection and the presentation model. For that specification we are working on an experimental branch, to prove that the concept is working. Note that we don't want to throw away the current NatTable code, we want to reuse it by refactoring it to match the new architecture. In various places this might mean to reimplement stuff, in some cases it will simply be removing SWT dependencies and hard references.

Possible Mentors: Dirk Fauth, Edwin Park

Interested Student: Timur Achmetow

Nebula NatTable: Next Generation NatTable extensions

One of the main concepts in NatTable is, that is can be used with only the necessary libraries (currently this means SWT), and can be extended with specific extensions (e.g. GlazedLists). For the next generation architecture we would like to extend that approach to make it possible to configure in which environment the NatTable should be used. This includes the selection of the DI container (Eclipse 4, Spring, Guice) and the UI toolkit (SWT, JavaFX, Swing, HTML5). Of course there are others out there that can be added to those lists. This project is intended to create those extensions based on the results of the Next Generation NatTable architecture project.

Possible Mentors: Dirk Fauth, Edwin Park

Eclipse Platform: Implement annotations for databinding

Databinding is in the current version quite a verbose task. By using annotations the required code can be reduced and more readable. This can be done by annotating a field and refering to the bound field with required binding properties. The framework would then need to scan for the annotation and create the bindings.

This implementation might look like the following:

 @Bind(bindCondition=WidgetProperties.text(SWT.Modify), targetClass=Todo.class, targetMethod="summary")
 Text text;

The annotation would then, togeter with the annotated field, have all required information to create observable objets and the binding

Interested non-student: Peter Andberg (

GEF: Record figures and HTML-like labels in DOT for Zest

The GEF Zest visualization toolkit contains support for a subset of the Graphviz DOT language (see DOT for Zest). The Graphviz DOT language supports HTML-like labels and record-based nodes (see Graphviz documentation on html shapes and record shapes). This allows very versatile renderings and therefore is a widely used feature of the DOT language. The Xtext-based DOT grammar in Zest is compatible with record labels (since they are represented as strings), but the interpreter does not render record nodes yet. HTML-like labels are currently not valid according to the grammar. The goal of this project is to:

  • implement custom figures and render record-based nodes from DOT input
  • extend the Xtext-based DOT grammar to support HTML-like labels
  • enhance the figures for the many styling options of HTML-like labels
  • add HTML-like labels to the DOT export for Zest graphs with record figures

This feature has been requested by the community (see bug 321775 and bug 337640) and its implementation would be a very useful contribution.

Possible mentor: Fabian Steeg (; interested students: add yourself here and get in contact on the gef-dev mailing list (with CC to soc-dev)

Interested students: Mayur Patil (

Back to the top