Code Documentation

[blackheart42]

Originally Posted by James

I have updated the wiki with the first Documentation for MediaPortal II

The documentation is in the MediaPortal Development Section -> http://wiki.team-mediaportal.com/MediaPortalDevelopment

Direct links:

Architecture overview -> http://wiki.team-mediaportal.com/Med...cture/Overview
Compiling -> http://wiki.team-mediaportal.com/Med...tal2/Compiling
Debugging -> http://wiki.team-mediaportal.com/Med...tal2/Debugging

@eagle, The full documentation will most likely not be finised until the next release and can be announced then. You can follow the developed in the Project Management System if that is easier for you. There is now a Task for documentation.

James, I read the documents and have a couple of questions.

In the architecture overview you show a nice modular structure. Will there be APIs defining the interaction between modules? While APIs do take time and effort to create and maintain I believe that they improve stability by isolating the modules from each other. Like DricuS I was going to try my hand at contributing to MP, but when I found out that there wasn't even an API between the core and the skin I backed off.

In the 'Compiling' document it says that Visual C# Express is a prerequisite but is unsupported. Is there a technical reason to not support C# Express? Or is this perhaps a way to ensure that anyone who wants to develop for MP has a certain level of proficiency (assuming that anyone who pays significant money for the full package will likely have more skill than someone who just downloads the freebie). Please don't misunderstand me - establishing a minimum requirement for developers isn't necessarily a bad idea, but it will certainly reduce the number of developers. A middle ground might be to require Visual Studio for the core, but support C# Express for plugins.

Blackheart

[James]

Hi Blackheart,

Thanks for you comments.

Originally Posted by blackheart42

I read the documents and have a couple of questions.

In the architecture overview you show a nice modular structure. Will there be APIs defining the interaction between modules? While APIs do take time and effort to create and maintain I believe that they improve stability by isolating the modules from each other. Like DricuS I was going to try my hand at contributing to MP, but when I found out that there wasn't even an API between the core and the skin I backed off.

There are defined interfaces between all modules. We will document all the interfaces and interactions between the modules. The documentation is still being written, as is the code. Some things have changed in the last week and will continue to change. We hope to have the core complete and all the interfaces stable and documented for the next release.

I will post new pages as they are available.

In the 'Compiling' document it says that Visual C# Express is a prerequisite but is unsupported. Is there a technical reason to not support C# Express? Or is this perhaps a way to ensure that anyone who wants to develop for MP has a certain level of proficiency (assuming that anyone who pays significant money for the full package will likely have more skill than someone who just downloads the freebie). Please don't misunderstand me - establishing a minimum requirement for developers isn't necessarily a bad idea, but it will certainly reduce the number of developers. A middle ground might be to require Visual Studio for the core, but support C# Express for plugins.

VS C# Express is not currently supported, because no one on the team uses it and secondly with the amount of changes still happening maintaining multiple solution files is too much work.

I cannot promise a team supported VS express solution file any time soon.

VS Express can be used to compile the core (if you create your own solution file) and can definitely be used for plugin development. The problem is that we use solution folders which are not supported by VS Express. These need to be flattened out in a VS Express solution.

We are certainly not trying to exclude any developers and welcome comments and feedback, but please bear with us, because the MediaPortal II project is still in an early stage of development.

Regards,

/James

[frodo]

Like DricuS I was going to try my hand at contributing to MP, but when I found out that there wasn't even an API between the core and the skin I backed off.

In MP-II we try to keep the skin (GUI) and logic (plugins & models) completely seperated
That is:
- the skinengine does not know about any plugins or models
- the plugins and models dont know about any gui
The advantage here is that:

1) you can use any behaviour from any model in any GUI screen ,
example show weather info on the home-menu
2) We can easily extend skinengines without breaking the plugins & models
3) We can even switch skinengines (like we do now with the new WPF engine) without breaking the plugins
4) It gives much more freedom to skinners

This is the reason why you dont see a pre-defined API between the skin and the plugins/models.
The skinengine uses databinding to databind to properties and collections which are provided by the plugins/models.
And for executing commands, the skinengine uses reflection to do it.
So using the skinengine you can:
- databind your GUI controls to any property or collection exposed by plugins/models
- databind your GUI controls to any property or collection exposed by the core
- let the GUI call any method on your model using commands
- let the GUI call any method on the core using commands


An example how this is done in the new WPF engine:

Databinding:

<Canvas xmlns:local="clr-namespace:Model;assembly=mymovies">
   ...
   <ListView ...  ItemsSource="{Binding Movies}" ... />
  ...
</Canvas>

The first line imports an plugin (mymovies.dll in this case)
finds & instansiates the Model class from it
and sets the instance of the Model class it into the Context of the canvas

The second line draws a list view where the items in the listview are databound.
The databinding is set the the Movies property and since the Context of the canvas is set to
mymovies.Model the complete databinding will be set
to public IEnumerable mymovies.Model.Movies {get;} property

As long as this property returns an IEnumerable the listview will be able to draw the items
(Note that for a ListView the model will usually return an ItemsCollection which is a class defined in the Core
This class simply holds a collection of ListItem and can send events when the collection changes so the skinengine can
update its databinding and refresh the listview )

Commands:

<ListView ... Command="{Binding Path=Select}" CommandParameter="{Binding Path=this.CurrentItem}" .../>

Here we setup a command using the same principle as above
When you click on an item in the listview, it will call:
public mymovies.Model.Select( ListItem currentItem)
The movies model will handle the select and might for
example update its Movies property if you are browising your movies folder.

As you can see no interfaces are needed between the skinengine & plugins/models
because of the databinding & command architecture.

Frodo

[James]

We have been putting work into the documentation and are making progress

-> MediaPortal2 Development - MediaPortal Wiki Documentation