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.

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.

This test recorder and generator is still quite young, and lacks some cool stuff. Here are some area where a contribution would be welcome:

This test recorder and generator is still quite young, and lacks some cool stuff. Here are some area where a contribution would be welcome:

+

* Support more SWT UI actions/events

* Support for GEF/GMF events: read in the Draw2d event stack and deduce which operations were actually performed by users and turn them into Java code using SWTBot API.

* Support for GEF/GMF events: read in the Draw2d event stack and deduce which operations were actually performed by users and turn them into Java code using SWTBot API.

* Improve usability: Currently starting the recorder is not an easy task (relies on system properties). Also once it is started, it only shows the lines of codes to copy-paste. Some things could be improved to make it more user-friendly (syntax highlighting, automatic creation of a Java file,...)

* Improve usability: Currently starting the recorder is not an easy task (relies on system properties). Also once it is started, it only shows the lines of codes to copy-paste. Some things could be improved to make it more user-friendly (syntax highlighting, automatic creation of a Java file,...)

* Kanarupan Kularatnarajah (kanarupanxiii@gmail.com, University of Moratuwa): Worked on Automating UI testing for an Eclipse based product via an integration of Maven and SWTBot. In those test cases, along with several SWT widgets, GEF editor scenarios were included.

* Kanarupan Kularatnarajah (kanarupanxiii@gmail.com, University of Moratuwa): Worked on Automating UI testing for an Eclipse based product via an integration of Maven and SWTBot. In those test cases, along with several SWT widgets, GEF editor scenarios were included.

* add yourself here and get in contact on the [https://dev.eclipse.org/mailman/listinfo/swtbot-dev swtbot-dev] mailing list (with CC to [https://dev.eclipse.org/mailman/listinfo/soc-dev soc-dev])

* add yourself here and get in contact on the [https://dev.eclipse.org/mailman/listinfo/swtbot-dev swtbot-dev] mailing list (with CC to [https://dev.eclipse.org/mailman/listinfo/soc-dev soc-dev])

Line 286:

Line 288:

* add yourself here and get in contact on the [https://dev.eclipse.org/mailman/listinfo/swtbot-dev swtbot-dev] mailing list (with CC to [https://dev.eclipse.org/mailman/listinfo/soc-dev soc-dev])

* add yourself here and get in contact on the [https://dev.eclipse.org/mailman/listinfo/swtbot-dev swtbot-dev] mailing list (with CC to [https://dev.eclipse.org/mailman/listinfo/soc-dev soc-dev])

* add yourself here and get in contact on the [https://dev.eclipse.org/mailman/listinfo/soc-dev soc-dev] mailing list.

== Eclipse JDT: Folding for Java code blocks ==

== Eclipse JDT: Folding for Java code blocks ==

Line 311:

Line 318:

** I am not a committers on the JDT project, which means that I do not have an inside track in terms of getting the code accepted by the project. It would be better to find a mentor from that JDT for this GSoC project.

** I am not a committers on the JDT project, which means that I do not have an inside track in terms of getting the code accepted by the project. It would be better to find a mentor from that JDT for this GSoC project.

−

Interested students:

+

Interested Students:

+

* add yourself here and get in contact on the [https://dev.eclipse.org/mailman/listinfo/soc-dev soc-dev] mailing list.

The Orion editor displays annotations and one nice extensible annotation might be for Git Blame. You can see the [http://wiki.eclipse.org/EGit/New_and_Noteworthy/1.0.0#Blame_Annotations Eclipse version of Git Blame here]. This project would be to implement similar functionality utilizing the APIs for annotation and if required extending the RESTful Git APIs to the Orion server to provide the required annotations.

At the moment the Orion editor has a built in styler that can handle CSS and JavaScript files. A separate styler is used for HTML. The first part of this project is to add support to the built in styler for HTML and mixed-mode (JS + HTML + CSS).

+

+

The second part of this project is to define an extensible styler API and provide additional stylers for other languages.

+

+

These would replace our use of CodeMirror modes for styling other languages and file types since including these stylers in products is difficult due to licensing restrictions. The team would like to see more Orion developed EDL licensed code for styling other file formats.

Latest revision as of 05:06, 1 May 2013

Feel free to contribute the discussion on an Eclipse bug. Keep the discussion on bugs technical. The bugs are not a good place to talk about Google Summer of Code participation. Use the soc-dev mailing list for that.

Rules

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.

Ideas

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.

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.

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.

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.

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).

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.

Eclipse Code Recommenders draws its knowledge about how to use an API from so-called models. Whenever you trigger code completion, for example, Code Recommenders looks up the correct model and uses it to make a prediction about the method you are most likely to call. Now, code completion is not the only intelligent recommender system in store for Code Recommenders. We have ideas for about a dozen more. Consequently, the logic managing the models needs a big overhaul to cope with this wealth of models.

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 -http://git.eclipse.org/c/vjet/org.eclipse.vjet.typelibs.git/tree/JQueryTL ) with jQuery UI support. The secondary goal is to come up with an extension to support the JQuery plugin model.

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.

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. Another idea is to implement Stack Trace folding as in IntelliJ Idea (search for 'Console Folding'). Optional this work could also start the migration of this view to Eclipse 4.

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.

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)

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.

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.

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 some (optimally arbitrary) other programming 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.

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

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.

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.

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.

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.

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.

SWTBot is mainly a high-level API that is meant to interact with Eclipse applications through code with the same "grain" as end-users operate with it. It's a layer on top of SWT that wraps event management in APIs descibing user-actions. These API make it much easier and much more productive to write UI tests.
Recently, a test recorder & generator was added to SWTBot. The goal of this recorder is to simply monitor SWT events produced by a normal usage of an application, and to generate some code relying on SWTBot APIs. Using this tool, one can simply reproduce a bug scenario and will immediatly have a code skeletton of a UI tests to reproduce it, saving a lot of time.

This test recorder and generator is still quite young, and lacks some cool stuff. Here are some area where a contribution would be welcome:

Support more SWT UI actions/events

Support for GEF/GMF events: read in the Draw2d event stack and deduce which operations were actually performed by users and turn them into Java code using SWTBot API.

Improve usability: Currently starting the recorder is not an easy task (relies on system properties). Also once it is started, it only shows the lines of codes to copy-paste. Some things could be improved to make it more user-friendly (syntax highlighting, automatic creation of a Java file,...)

Multi-event mappings: Current Test Recorder & Generator associate individual events to UI operation. It's OK for SWTBot, but some more complex SWTBot methods (showView...) actually map multiple events. Generator should support this mutli-event mapping. was already contributed as part of https://bugs.eclipse.org/bugs/show_bug.cgi?id=406005

Possible mentors:

Mickael Istria (JBoss Tools, Red Hat) (mistria@redhat,com)

Interested students:

Rohit Agrawal (rohi0012@e.ntu.edu.sg) prefered Drag and Drop proposal

Kanarupan Kularatnarajah (kanarupanxiii@gmail.com, University of Moratuwa): Worked on Automating UI testing for an Eclipse based product via an integration of Maven and SWTBot. In those test cases, along with several SWT widgets, GEF editor scenarios were included.

add yourself here and get in contact on the swtbot-dev mailing list (with CC to soc-dev)

Drag and Drop is a quite common UI operation. A lot of Eclipse-based tools use it for example to drag things inside a tree or a list, or to drag things from a Tree to another. However, this concept is not supported by SWTBot (except in gefEditor), and it is something that have been requested a lot: https://bugs.eclipse.org/bugs/show_bug.cgi?id=285271 (25 people in CC list ;). In the context of Google Summer of Code, the student will have to design/implement/test (better in reverse way: write test as a specification for design, and then implement) a general, unified and usable way to include Drag and Drop support in SWTBot API.

Possible mentors:

Mickael Istria (JBoss Tools, Red Hat) (mistria@redhat.com)

Interested students:

add yourself here and get in contact on the swtbot-dev mailing list (with CC to soc-dev)

We'd like to explore adding a means of drawing more attention to Eclipse Foundation events (e.g. EclipseCon), security alerts, and other activities into the IDE. A few good ideas are being bandied about, including the creation of an 'events' view, lower-left screen pop-ups, and entries on the welcome page. There is naturally a 'call home' nature to this; we need to make sure that this is handled delicately.

Please see bug 404825. Comment on the bug or on the soc-dev mailing list. An important step in the direction of 'getting this right' might be to do it wrong at least once... A solution that provides part of the answer, or allows us to test some ideas would be considered a success, even if it doesn't end up in the distribution.

Eclipse JDT: Folding for Java code blocks

Eclipse has general folding functionality for editors (classes, methods, comments). It does not, however, currently have support for folding Java code blocks (any
pair of {...} including if, for, do/while, try/catch/finally, unnamed and synchronized blocks). According to comments on bug 60929 adding this support should be relatively easy. A Google Code project apparently includes an implementation, but I haven't looked at the it, I don't know how good/useful it is, and the project seems to be dead. At very least, there should be some good ideas in there that can be leveraged to provide a solution. Depending on licensing and provenance, we may even be able to leverage some code from that project.

Possible mentors:

Other mentors: feel free to add yourself to this idea.

Wayne Beaton (The Eclipse Foundation)

I am not a committers on the JDT project, which means that I do not have an inside track in terms of getting the code accepted by the project. It would be better to find a mentor from that JDT for this GSoC project.

Eclipse Packaging Project: Make it easy to access "development" updates

I envision a preferences setting that configures an Eclipse IDE to pull updates from the latest (milestone and release candidate) builds from the current release train. A user might, for example, download and install the 'Juno' version of an Eclipse package. If they turn this option on, the 'Juno' Eclipse will automatically be configured to pull in Kepler milestone updates (thereby enabling the user to "live on the edge" while giving greater exposure to the milestones).

I believe that this is a relatively simple matter of adding and enabling a software repository URL to the "Available Software" preference. Socializing the location and presentation of this sort of extension would be an interesting part of the problem.

I'm not entirely convinced that this has to be a preference, but that seems like a reasonable place to put it.

The Packaging project seems like an interesting enough place to put this. The first step would be to create bug for the feature to gather feedback and other input. An enterprising student could do this at any time (hint, hint).

The Orion editor displays annotations and one nice extensible annotation might be for Git Blame. You can see the Eclipse version of Git Blame here. This project would be to implement similar functionality utilizing the APIs for annotation and if required extending the RESTful Git APIs to the Orion server to provide the required annotations.

At the moment the Orion editor has a built in styler that can handle CSS and JavaScript files. A separate styler is used for HTML. The first part of this project is to add support to the built in styler for HTML and mixed-mode (JS + HTML + CSS).

The second part of this project is to define an extensible styler API and provide additional stylers for other languages.

These would replace our use of CodeMirror modes for styling other languages and file types since including these stylers in products is difficult due to licensing restrictions. The team would like to see more Orion developed EDL licensed code for styling other file formats.