Report No.3 GSoC 2012

Briefly description of the  progress is:


Done: 

• All Rules' and Roles' properties are editable ( properties and collections - Add /remove and edit the property of an item in the collection).
• User Control Editable List.  In order to simplify editing and synchronizing the views (Source value and Evaluated ), UC  have own ViewModel and it is used  in both views - Binding is made on different properties of an Editable Item. The evaluation rule  for Value is set through delegate, when Collection of Editable items is created. 
• DataTemplated View for the Define Rules 
• Save, Reset, Undo, Redo Buttons functionalities

To do:

• Guiding user how to edit :

           - Display Help Tip for each rule and property 
           - Display warnings (Ex. when a define property is removed, to display warning in the rules where   define is used)    
           - Focus issue - to choose the best option (Attached Property, Routed Event , Focus Manager?)

• In the Files' Include List add browse file functionality
• Test with different packages
• Work on UI

                   ---WPF fun stuff has just began :)   ---
 

To think about and discuss (Extra features):
Quick edit : Wizard tool that include steps - Reading data form the installed certificate and  drag&drop files.

Report No.2 GSoC 2012

This week I succeed with reading the source values/evaluated values and started with real editing.

So, for each rule 3 kinds of views are available:

- Source 

- Evaluated

- Package (Source String)

1. Source

In this view are displayed source values for properties, and user can edit the value. 

All the changes are reflected in the second - Evaluated View.

2. Evaluated

In this view are displayed evaluated values for properties, and user can only view (text boxes are disabled).

3. Source String

I added this view in order to offer the user a clear view of  the part of  .autopkg file, which is edited from the first tab - Source Value. Source String tab is in a view only mode - not for editing.

For the Undo/Redo functionality I used  Monitored Undo Framework  from  http://muf.codeplex.com/ 

The Root of the History is  MainViewModel and it keeps  the stack of changes for all View Models (Source Values). After Editing a Source Value, user can navigate to the Evaluated tab and see the changes (I think is especially interesting/important to see the reevaluated values when source value have parameters, ex: glib[${flavor}]  or  "libffi[${flavor}]-${libffi-dep-version}-${arch}-${libffi-dep-publickeytoken}"). When user press undo/redo having focus on the evaluated tab,  the reevaluated undo/redo undo is shown ( is not needed to navigate back to the source values to perform undo/redo - both view models are updated/synchronized).

Next week problems to solve:

• WPF Focus  Issue - when perform undo/redo for the different rules located on different tabs, to set the focus on the corresponding control - tab, textbox etc. 
• Support editing and undo/redo for the collections - ex: list of assemblies for the manifest rules, list of files, required package collections
• Create User control  'Editable List for the Collections'
• Create the Dynamic view for the #define rule

               For this rule the view is different, because there are no fixed properties which are expected,

               so the list of properties could be like : 

 #define {

    general-description : "GLib is a general-purpose utility library for C, mostly used with GTK and GNOME.";

};

#define {

    package-version : 2.32.3.7;

    author-version : 2.32.3;

    outercurve-publickeytoken : 1e373a58e25250cb;

    deps-publickeytoken : "${outercurve-publickeytoken}";

    libintl-dep-version : 0.18.1;

    libintl-dep-publickeytoken : "${deps-publickeytoken}";

    libffi-dep-version : 3.0.10;

    libffi-dep-publickeytoken : "${deps-publickeytoken}";

    zlib-dep-version : 1.2.5;

    zlib-dep-publickeytoken : "${outercurve-publickeytoken}";

    flavor : "${comp??vc10}";

    arch : "${plat??x86}";

};

Report No.1 GSoC 2012

 I started with Creating View Models for each rule/role, using the information from http://coapp.org/developers/autopackage.html . I used factory method to create all View Models in the MainView Model. Package data is loaded using https://github.com/coapp/devtools/blob/master/Packaging/PackageSource.cs  and I  created a Reader class,
getting values by:  RoleName, PropertyName, Parameters  etc

Testing part:
- Unit test for ChangePropertyInTheRule OnPropertyEvent raised.
- Unit Testing for Command New and Remove a Rule
 All test were created for checking local collections of rules and properties, more exactly -  if my bindings and commands works fine.



UI:
I started with creating simple basic UI, without adding styles and fixed my attention on functionality.
In order to simplify the binding between rules list and  rules details(properties),  I chose the structure TabControl in TabControl.

For displaing rules with parameters, for example Files:
I chose to display them in a list, using a data template with expander and grouping them by categories:

Created commands:
Add New and  Remove(implemented) ; save, reset, undo, redo.
Changes are stored in the local collection and when user press Save button, changes will be written in the file.

Next week I will continue with:
- display source values and values views.
- editing,  introduce validation data rules (data type - to restrict wrong input values and guide user ).
- undo redo mechanism

CoApp Package Maker GUI

I'm really happy to write here that I have been selected to develop a project for CoApp in the frame of GSoC. The project’s name is CoApp Package Maker GUI and it is mentored by Eric Schultz. Here follows a short description of the project:

The CoApp project has a command line tool that allows a developer to create packages. The purpose of the project is to create a desktop application that would allow software publishers to create a package in a GUI, instead at the command line. Creating package in GUI has a lot of advantages: an intuitive UI is easier to use for most of the users and don’t need long learning time; offer easy view and control for multiple items, so it's more faster ; package creation is a multi-step task that can easily be grouped together in a way that prevent wrong input. This would be a great advantage for open source developers who wish to create packages, but are a little daunted by the script-based package creation.

Feel free to visit my project proposal and github repository .

In this blog I will share the information about my progress and describe step by step my work. I look forward to any comments, suggestions and encourage everyone to give feedback.

This is going to be a fun summer of coding!