Disruption Simple Content Manager

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_Simple_Content_Manager

Description

Disruption - Simple Content Manager

Brief: I want to write a Java Simple Content Manager. The most important thing about it would always be simplicity in terms of not requiring technical knowledge at all, so potential contributors in areas like graphics, music, or other artwork could join the community and help with ease.

The idea is developing the project in a Java environment, as java is supported in most OS(Apart from Mac, Unix and Windows, it can also be used in most mobile platforms and systems). Another reason for choosing java is that is very easy to design a cute GUI that don't scares the user away, and also the GUI adapts its “look and feel” to the system it is running in, so the user sees it like another of his programs, rather than an external, strange tool. In terms of programming, as described before, the idea is taking a MVC approach, implementing first the view, and preparing then a modular controller for all the functionality needed. As Java has JUnit tests and a powerful debugger, it's easy to track down bugs and fix them, as well and check that every part works correctly and incrementally, so you can be sure that a new functionality doesn't break an older one(As you can add tests while you develop, so you always execute 100% of the tests).

IRC

Disruption

Submitted Patches

Enemy leaders never appearing on status table

Bug URL: https://gna.org/bugs/?17985 Patch URL: https://gna.org/patch/index.php?2623

Brief about the bug: The check done when showing leaders on status table only checked if our side "knows" the leader's side. As the 'know' function always return false for enemies on fogged maps, it was impossible for enemy leaders to appear on status table on fog/shroud maps.

Brief about the solution: The solution was to add a new boolean check, testing if the leader's position was currently fogged/shrouded. If enemy leader is not on fogged hex, leader is shown on table.

Application GUI Mockup

Here I show a mockup GUI for the Java Simple Content Manager application. It's not very "pretty" as it's intended to show the flow of actions throught the GUI rather than the final aspect, which will vary, maintaining the same functionality.

Main Window

Window seen when the application is open.The main window offers 3 main options, checkout, update, and commit, that are the general options available for any versioning system. It also has a menu bar, with tabs for the configuration options.

Configuration Windows

There are two configuration windows, the account set up one, to insert the repository user/password data in order to be able to commit, and the folder set up, to specify the checkout folder.

Checkout Option

The checkout option checks if checkout if possible, and if possible it shows the progress window. If checkout is not possible, an informative dialog is showed.

Update Option

Like the checkout option, it checks if update is possible, and if possible it shows the progress window. If update is not possible, an informative dialog is showed.

Upload Contributions Option

The upload contributions option checks if checkout folder is up to date prior to going to the file selection view. The file selection view shows a file explorer with trunk on the left, and a file list on the left with the changed files preselected. The list can be modified by adding or taking files out

After the list is complete, the user can go on to the second phase, where the commit description is written.

When details are finally introduced, commit takes place, with details about it showed in a view.

GUI Mockup Jar

The gui mockup .jar can be downloaded from: http://www.programarte.org/guimockup/StandardJar.jar

The gui mockup source code project(For JDeveloper) can be downloaded from: http://programarte.org/guimockup/SCM.rar Even though the project is for JDeveloper, it contains normal .java files, so you should be able to explore the code from any interface, or directly using text editors like gedit, wordpad, text wrangler...

The file explorer used for the mockup is a very inefficient version, so the .jar should be executed inside a directory with little content(That is, only a few folders or subfolders), as the file explorer goes recursively from the folder the .jar is placed getting as deep as possible and obtaining the full directory structure below the .jar(That is, if you place the .jar inside your main checkout directory, the file explorer will show Wesnoth's trunk content, although it will take a few seconds to load(I just tested it)).

Rememeber that it is only intended to be a GUI Mockup to see the program's flow, so values entered in configuration windows, or in intermediate views such as the first or second views in the commit options are not stored. Checkout and Update options always work(that is, there are never checkout conflicts), and, of course, it doesn't really download anything at all.

Application Brief and Workflow

Brief: The SMC will give users an easy-to-use program for checkout,update and commit operations, without requiring any S­­V­­N knowledge at all.

Workflow:

A)Checkout

The checkout operation will be a standard trunk checkout operation, downloading the whole wesnoth source with a sole click into a specified folder.

Workflow:

* Check if directory for checkout is empty

* If directory is not empty -> Check if directory is already a checkout.

* If directory is a checkout -> Ask user if he wants to update, and if so, perform update.

* If directory is not a checkout -> Tell the user that the selected checkout directory is not empty and not a wesnoth checkout, so he must choose another directory.

* In case directory is empty -> Checkout trunk in selected folder.

B)Update

The update operation will be a standard trunk update operation, downloading the new revisions into the checkout folder with a sole click.

Workflow:

* Check if checkout directory is empty

* If directory is empty -> Tell user he has to checkout instead of update

* If directory is not empty -> Check if directory is a checkout directory

* If directory is not checkout directory -> Tell user that selected directory is not checkout directory, and ask user to change to an empty or checkout directory

* If directory is checkout -> Check if current revision is last revision

* If current revision is last revision -> Tell user no update is needed

* If current revision is not last revision -> Check for conflicts

* If conflicts appear -> Tell user about conflicts and check if merge is possible

* If no conflicts appear -> Update to last revision.

C)Upload

The upload operation will work as a commit operation per se, showing the user a split view with a file browser to the left, and the detected files needing commiting to the right. From this view, user will be able to modify the commited files, in case he wants to commit only a few of them and not all.

Workflow:

* Check if checkout directory is empty

* If directory is empty -> Tell user to configure his checkout directory to the checkout directory he has worked in.

* If directory is not empty -> Check if directory is a checkout directory

* If directory is not checkout directory -> Tell user that selected directory is not checkout directory, and ask user to change to an empty or checkout directory.

* If directory is checkout directory -> Check if current revision is last revision

* If current revision is not last revision -> Tell user that before commiting it's compulsory to update to the last revision.

* If current revision is last revision -> Check if user credentials are set

* If user credentials are not set -> Tell user to configure his account before commit.

* If user credentials are set -> Show user a split view containing, in the left side, a file explorer for the checkout folder, and in the right side a list showing all the candidate files for commiting. In this view, user will be able to add to or erase files from the commit list. After the user is happy with the commit list, he can continue to the final commit phase

* Check files in commitment list, erasing unchanged files from commitment list

* Show user the final commit window, allowing him to write a description for the commit, and showing him the final list of files to be commited, with the options of commiting or going back.

* If commit is selected -> Check again if revision has changed while selecting files.

* If revision has changed during the file selection -> Tell user that revision changed and ask him to update before commiting.(Update can be done without closing commit window)

* If current revision is last revision -> Perform commit

* If back is selected -> Go back to the file selection screen so user can perform changes

IRC Discussions

This section is intended to hold useful IRC discussions in order to be able to have all the feedback obtained together for later use, or for other users to get ideas for new feedback.

thespaceinvader Feedback

thespaceinvader: hrm...

thespaceinvader: the major operations would be checkout and update, for me. I rarely use any other S­­V­­N operations

thespaceinvader: solving conflicting merges would be useful, too

thespaceinvader: I suspect, also, that there are operations I ought to be doing that I don't - setting file types, for instance, is something I've never quite worked out how to do, and which I think I ought to do

Disruption: setting file types?

thespaceinvader: if it could also incorporate things like optipng and the various WML sanity checkers that would be useful

thespaceinvader: yes

thespaceinvader: I'm not really sure, it's something that i recall being told i ought to do a couple of years ago

thespaceinvader: it's entirely possible I'm completely making it up

Disruption: Oh, it's ok, I just don't seem to understand right now what you are refering to :)

Disruption: thanks for your feedback :)

Timeline

From	To	Description	Type
23 May	22 August	Full Project Duration	Compulsory
23 May	30 May	Design SCM GUI and prepare Java framework	Compulsory
31 May	13 June	Implementation of S­­V­­N support for the SCM	Compulsory
14 June	16 June	Time Buffer	Optional
17 June	17 June	GUI callback configuration and set up	Compulsory
18 June	18 June	Set up windows implementation	Compulsory
19 June	30 June	Checkout operation implementation with conflict resolution	Compulsory
1 July	11 July	Update operation implementation with conflict resolution	Compulsory
12 July	22 July	Commit Operation implementation	Compulsory
23 July	25 July	Time Buffer	Optional
26 July	11 August	Implementation of GIT support for the SCM	Optional
12 August	14 August	Time Buffer	Optional
15 August	22 August	Final testing and polishing	Compulsory

Timeline is made thinking of the worst case. Main application should be finished by the 22 of July(From then, only GIT support and testing and polishing is left).

GIT support is marked as optional because in case some other main functionality requires more time, it would take it from the GIT support time range. As there is a whole month from the end of the last main functionality(22 July) and the end of the GSoC(22 August), it should be more than enough to cope with any unexpected problems that could arise.

Questionnaire

1) Basics

1.1) Write a small introduction to yourself.

I'm both a gamer and a programmer. Finishing my University studies being only 23 years old I want to dedicate my life to the world of game programming.

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

Disruption

1.4) Why do you want to participate in summer of code?

I think it's an interesting way of getting to know how big projects work, by directly participating in them.

1.5) What are you studying, subject, level and school?

I'm finishing my studies on Computer Engineering, which is a 5-year career here in Spain.

1.6) What country are you from, at what time are you most likely to be able to join IRC?

I'm from Spain, and in Summer I'm able to join IRC all day around from 9:00h to 23:00h GMT+1

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

I don't have any other commitments nor will go on vacations.

2) Experience

2.1) What programs/software have you worked on before?

I have worked developing php/mysql webpages, as well as programs in C,C++, Java, Objective C(for Mac, and iOS), and many others. I have used many IDEs, like Eclipse, Netbeans, JDeveloper, XCode, Bloodshed's DevCpp, and also Kate Editor for Linux environments(Which adds a console to the text editor so you can quickly compile and test) for it's simplicity and lightness.

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

As part of my University training I have had to develop software forming teams several times, following the standard procedure: elaborating diagrams, iterating using something like SCRUM, preparing all the design documents, documenting the code, etc. One of the main projects developed in team was a frame for online flash game uploading, playing, and rating, such as what you can find in www.kongregate.com, using java implemented web services called through nuSoap and a php bridge to call them from flash, and also a test flash game which implemented all that with some level of playability.

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

No, I have never participated in GSoC.

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

I have helped in some open source projects, such as kradview(A medical image visor) providing a few patches or gestas(A free web-based association management frame) as main developer.

2.5) Gaming experience - Are you a gamer?

2.5.1) What type of gamer are you?

I play a lot, but a game must have that little “something” that makes you play for a long time to hook me up. If not, I usually play a few minutes, and leave the game forever.

2.5.2) What type of games?

I play any kind of games, wheter it's RPG, RTS, Turn-Based Strategy, Arcade, FPS, Graphic Adventure... I think all of them have pros and cons.

2.5.3) What type of opponents do you prefer?

It's always better to play against other humans, but AI is useful to be able to play without network connection, or when nobody is available.

2.5.4) Are you more interested in story or gameplay?

I think that the best is a good balance between them. A game with nice gameplay but awful story will make you feel like you are always doing the same, as the story doesn't really keep you playing. On the other hand, a game with a good story, but awful gameplay will lead to a bad playing experience due to it's frustrating play mode. Both ways the game end up unplayed after a while, which is just wrong.

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

I played Battle for Wesnoth when it was around version 1.24. I really enjoyed playing it, but due to my university studies being a bit overwhelming I had to stop playing. I loved both single and multiplayer modes, but at the moment I played multiplayer was very buggy(Connection was lost regularly, and multiplayer failed suddenly) so it was difficult to finish a game, and it ended up being somehow frustrating.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our S­­V­­N (during the evaluation period or earlier) please state so.

Info about submitted patches can be found in a specific section in this wiki page. 3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

I can write English fluently.

3.2) What spoken languages are you fluent in?

Spanish and English

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

Yes. Some players are difficult to treat, mainly because they are actually children, or just have bad behaviour, but it's important to be able to separate manners from messages, so even if the player is being ill-manered you can understand the reasons behing it's complaints.

3.4) Do you give constructive advice?

I think constructive advice is the ONLY advice possible. It's good to say what's wrong, but it's better if you say how'd you fix it. Saying that something's wrong or could be better is very easy, but doesn't usually help anyone.

3.5) Do you receive advice well?

Receiving advice is the only way for improving or actually reaching a positive end, so, all advice is welcome.

3.6) Are you good at sorting useful criticisms from useless ones?

All criticisms are “useful” in some way(Except the ones saying “This sucks” or similar). If the critic actually talks about a failure, thing that could improve, or something similar, it can always be refined so you get at least some ideas for future fixes/features.

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want

I'm very autonomous when developing, taking some decisions “on the fly” to shorten develop times, but only if the decision is not critical, or it can be easily reimplemented. For high-level or important decisions is always better to ask first, code after.

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

I chose the idea “Create a simple content manager frontend for non-technical users”. I think it's a great idea to have a way for less-technical contributors to be able to collaborate.

4.2) If you have invented your own project, please describe the project and the scope.

---

4.3) Why did you choose this project?

It seems very interesting. I think that for an open source project, the fact of broadening the number of persons able to collaborate, in this case by simplifying the needed tool, is one of the most important things.

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

The development should be in a MVC way, so View and Controller are clearly separated. First the View design and development will come, in order to polish it and find what the final controls available will be. Next, callback functions in GUI items will be set, and all functionality will be implemented in a way as modular as possible to help maintainability. Apart from two or three exams in June, I'm free most of the day, most of the week, so I'll be able to work at a steady, regular rate, in order to finish everything in time.

4.5) Include as much technical detail about your implementation as you can

The idea is developing the project in a Java environment, as java is supported in most OS(Apart from Mac, Unix and Windows, it can also be used in most mobile platforms and systems). Another reason for choosing java is that is very easy to design a cute GUI that don't scares the user away, and also the GUI adapts its “look and feel” to the system it is running in, so the user sees it like another of his programs, rather than an external, strange tool. In terms of programming, as described before, the idea is taking a MVC approach, implementing first the view, and preparing then a modular controller for all the functionality needed. As Java has JUnit tests and a powerful debugger, it's easy to track down bugs and fix them, as well and check that every part works correctly and incrementally, so you can be sure that a new functionality doesn't break an older one(As you can add tests while you develop, so you always execute 100% of the tests).

4.6) What do you expect to gain from this project?

I want to gain experience working in a big community for a project that has been working successfully for a long time and is well stablished. I think I will learn a lot from it.

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

If I actually get to know the people developing Wesnoth(via IRC) and I feel comfortable with the community I will probably keep coding at one level or another.(Developing at big scale, or just making little bug fixes).

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?

• Sub­­version (used for all commits)

I have used S­­V­­N in a lot of projects

• C++ (language used for all the normal source code)

I have a lot of experience developing in C/C++

• STL, Boost, Sdl (C++ libraries used by Wesnoth)

I have used SDL a bit, never used STL of Boost.

• Python (optional, mainly used for tools)

Very low knowledge of script language Python

• build environments (eg cmake/scons)

A bit of knowledge in the cross platform make CMAKE

• WML (the wesnoth specific scenario language)

No experience at all

• Lua (used in combination with WML to create scenarios)

Some experience programming scripts in LUA

5.2) Which tools do you normally use for development? Why do you use them?

I usually use the lightest IDE I can find when it comes to C/C++ development, as I don't need tons of contextual advice or memory/processor consuming plug-ins. (i.e. Kate editor for Unix). When it comes to Java, due to it's high amount of classes and methods, IDE's like Eclipse or JDeveloper, with plug-ins and contextual method help are a must for quick development. For other languages, like Objective C, the only choice is XCode, so there's not much reasoning involved in the election.

5.3) What programming languages are you fluent in?

C,C++,Objective C, Java, PHP

SoC Application

Disruption SoC Application