This page is related to Summer of Code 2011

See the list of Summer of Code 2011 Ideas

This is a Summer of Code 2011 student page

Project: SoC_Ideas_Eclipse_Plugin2011

Description

timotei - Improving the Eclipse Plugin

I aim at improving the plugin, so it will become the tool used by all UMC Authors.

Contacts

IRC

timotei, timotei21

Other

Forum: timotei
gna.org: timotei

SoC Application

Battle for Wesnoth - Google Summer of Code Application

Proposal Summary

Page Last Updated: 29th March 2010

In the following lines I will give details on how I'm planning to implement some of the required tasks, and also add some new ones.

Multiple Wesnoth installations

Having multiple wesnoth setups, and working with them at the same time would be nice to be done from inside the plugin. For that, there will be a new preferences page. The page will look something like this:

There will be buttons that add/remove/edit a certain wesnoth installation. When adding/editing an installation, a new page like the current one (in which we set the paths), will be shown. The user will be able to name it and specify the version (I could automatically get the version by invoking wesnoth --version). The current page for setting the paths will act as a default installation.

After we have configured the paths, the user can chose the installation to which the (new) projects are bound, by opening the project properties. There will be a wesnoth-related page, where the user will be able to chose to what installation the project binds. With that, every command that uses the paths, won't use the single current paths, but the ones assigned to each project.

There would be a problem in case the project will be migrated between 2 different plugin's versions. For example, in one place we would have defined "1.9.4svn" but on the other there would be "trunk".

We can solve this in 3 ways:

Alert the user that the installation doesn't bind, and let him chose the current matching installation for his plugin.
Default automatically to the current plugin's default installation.
"Hardcode" the version, so that there may be defined just installations like: 1.8.0, 1.9.3. With this we lose some flexibility, but we could use this as base version for new installations, so for example, a user can have two 1.9.3 installations. Provided this, we have again a possible problem, which can be solved again by 1) or 2), but this time, trying to match the base version first.

With this feature, the user won't need to restart the plugin at all, switching workspaces.

Regarding the technical PoV, all paths will be stored using eclipse's preferences system, by appending an unique id of each installation to each path in that set.

Enhance the autocomplete feature

The autocomplete framework is very extensible but it lacks proper contexts for providing the content. I was thinking of trying to accomplish the generation of the autocompleted entries by using a config file where it can be used.

Variables

The variables will be parsed from each processed file by the WesnothProjectBuilder, using the WMLSaxHandler.

Variables definitions can be triggered using:

{VARIABLE var_name "value"}

or

[set_variable]
	name=my_var
	value="value"
[/set_variable]

The ConfigFile class in the org.wesnoth.wml.core already has a list of variables. The Variable class has some fields that allow its identification. We will build that list when we parse each file, and when the content assist finds the '$' character, will add to the list the variables found with the offset in the file lower than current one (that is, declared before their usage).

TODO: handle the case when deleting the variables.

Events

Attributes

Attributes Values

Macros

Automatic/headless building

The eclipse plugins can be automatically built from command line, provided there is the eclipse sdk and the eclipse delta pack on the builder's machine. The plugin can also use Buckminster tool to automate the building of the plugin.

More info at:

Standalone app auto-update

The current standalone application doesn't offer the same eclipse's update system. I will add it, so anytime there is a new version of the plugin, it can be updated with a single click by the user, without the needing to download a new standalone app again.

Documentation

The current existing readme will be split in 2 manuals: User Manual and Developer Manual (Don't forget to add images where relevant).

The user manual will contain:

Prerequisites and Installing the prerequisites
Installing the plugin / standalone version
Using the plugin
Plugin features
Step-by-step use cases
- Setupping the workspace
- Creating a new project and running it in the game
- Importing existing projects
- Using the WML Editor
- Updating the plugin
Frequently Asked Questions

The developer manual will contain:

Prerequisites and Installing the prerequisites
Adding the plugin's projects in the
Compiling and Running the plugin
Deploying the plugin and standalone app

Other ideas

Timeline

The GSOC period is between 24th May and 20th August. But since I have exams for about 3 weeks (during 31.05-20.06.2010), I will start working on the plugin before the 24th of May. The timeline will be written as the coding starts on 23 May.

Here is a table with key periods of the time spend on this project.

Period	Actions
23 May	Work starts
23 May - 3 June	Add Support for multiple installations
4 June - 11 June	Allow headless build of the plugin
12 June - 19 June	Add the auto-update feature for the standalone app
20 June - 27 June	Create the documentation




15 July	Mid-term evaluations deadline
15 August	Suggested 'pencils down' date. Take a week to scrub code, write tests, improve documentation, etc.

Tasks

This is a list of the "atomic" tasks that need to be done, based on the project part. I will update this table based on my current progress.

Project part	Details	Status (Legend: None, Done, Not done, In Progress)
Multiple installations	Implement the preferences pages	None
Multiple installations	Implement the logic for saving and loading the installations's paths on the disk	None
Multiple installations	Implement the project preferences page	None
Multiple installations	Rewrite the current mechanisms that use the paths to use the ones based on the project.	None
Headless build	Research about what system to use for automatic building of the plugin	None
Headless build	Implement the chosen system for the wesnoth plugin	None
Auto-update	Implement the auto-update feature.	None
Documentation	Write the User Manual	None
Documentation	Write the Developer Manual	None
		None

Questionnaire

The questionnaire can be found here: http://wiki.wesnoth.org/User:Timotei21/Questionaire

SummerofCode2011 Timotei21

Contents