Difference between revisions of "SummerofCode2011 Timotei21"

From The Battle for Wesnoth Wiki
m (→‎IRC)
(more work on the proposal)
Line 13: Line 13:
 
gna.org: timotei
 
gna.org: timotei
  
−
<i>Page Last Updated: 24th March 2010 </i>
+
=Proposal Summary=
 +
<i>Page Last Updated: 29th March 2010 </i>
 +
 
 +
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:
 +
http://dl.dropbox.com/u/462510/personal/soc/installations_management.PNG
 +
 
 +
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:
 +
* http://wiki.eclipse.org/PDE/Build
 +
* http://wiki.bioclipse.net/index.php?title=How_to_build_plugins_headless
 +
* http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.pde.doc.user/guide/intro/pde_overview.htm
 +
* http://www.eclipse.org/articles/Article-PDE-Automation/automation.html
 +
 
 +
==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==
  
−
=Proposal Summary=
 
  
 
=Timeline=
 
=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 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.
 
Here is a table with key periods of the time spend on this project.
 
{| border="1"
 
{| border="1"
−
|Period || Actions
+
|'''Period''' || '''Actions'''
 
|-
 
|-
−
| April 15 || Get accepted, and start the work
+
| 23 May || Work starts
 
|-
 
|-
−
| July 15|| Mid-term evaluations deadline
+
| 23 May - 3 June || Add Support for multiple installations
 
|-
 
|-
−
| August 15 || Suggested 'pencils down' date. Take a week to scrub code, write tests, improve documentation, etc.
+
| 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=
 
=Tasks=
−
This is a list of the "atomic" tasks that need to be done. I will update this table based on my current progress
+
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.
  
 
{|border="1"
 
{|border="1"
−
|Project part || Details || Status (Legend: <span style="color:green">Done</span>, <span  style="color:red">Not done</span>, <span style="color: gold;">In Progress</span>  
+
|Project part || Details || Status (Legend: None,  <span style="color:green">Done</span>, <span  style="color:red">Not done</span>, <span style="color: gold;">In Progress</span>)
 +
|-
 +
| 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=
 
=Questionnaire=
 
The questionnaire can be found here: http://wiki.wesnoth.org/User:Timotei21/Questionaire
 
The questionnaire can be found here: http://wiki.wesnoth.org/User:Timotei21/Questionaire

Revision as of 17:31, 29 March 2011


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

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: installations_management.PNG

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:

  1. Alert the user that the installation doesn't bind, and let him chose the current matching installation for his plugin.
  2. Default automatically to the current plugin's default installation.
  3. "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

Retrieved from "https://wiki.wesnoth.org/index.php?title=SummerofCode2011_Timotei21&oldid=41262"