[DanCooper]

thoughI believe there WILL be problems after Dan merges this massive commit!

Yes for sure! Its a major change in the code, it adds real multi thread done natively with .NET and removes a lot of the .Thread commands.
Also this will be the first step... once it works fine we can take full advantage of it moving to real parallel download of all images and art, file saving, and much more. (I have some really nice ideas here and did some tests on my dev environment )

Also it will introduce a real "cancel activity" that will stop all threads/actions immediately and in a clean way.

On the scraper side we will be able to use native libraries and not C# ones.

Finally we will be able to remove all those events/messages that create a mess and loopbacks in the dialog opening and status updates moving to a much cleaner structure...



so it will require a little bit of time and effort to get 100% working.
The code I submitted was working in the basic scenarios I tested but (for sure) is not 100% perfect but I think EMM will really benefit a lot from this

Hello mr. Savazzi. Sorry for my late answer.
I was not able to merge your commit... to many changes between your branch and the latest code.

I have planned the following:
We continue to work without async/await to release a final version of Ember 1.4. The final version of 1.4 should include:
- the new "Custom Media List Editor"
- a new genre handling (i've a good idea how it should be working)
- a new images select dialog for movies and tv show images
- recode the tv show process to same system like you have done for movies
- some other small changes like Kodi-compatible stacking regex system (i've already started coding for this)
- maybe a working XML scraper (fully compatible with Kodi scrapers) for movies and tv shows
- generally bugfixing

For Ember 1.5 i've planned:
- change from WindowsForms to WPF (for this we need a lot of async/await code)
- move a large part of the code from "frmMain.vb" to the API (there are so many features that actually belong to the API)
- change the API to get a working "headless" version of Ember
- create a HTML/JSON interface/API to control headless or default WPF version by web and Android or Apple apps

But... i've no experience with WPF :-)
IMO WPF has a lot of more opportunities then WindowsForms like skinning, mordern GUI, animations ... and for me, the single most important argument: the possibility to develop the processes independent of GUI ! It's so frustrating to merge the code, if two persons working on the same form at the same time. It's nearly impposible to merge to code without lost changes or manually fix all errors step by step.

[m.savazzi]

thoughI believe there WILL be problems after Dan merges this massive commit!

Yes for sure! Its a major change in the code, it adds real multi thread done natively with .NET and removes a lot of the .Thread commands.
Also this will be the first step... once it works fine we can take full advantage of it moving to real parallel download of all images and art, file saving, and much more. (I have some really nice ideas here and did some tests on my dev environment )

Also it will introduce a real "cancel activity" that will stop all threads/actions immediately and in a clean way.

On the scraper side we will be able to use native libraries and not C# ones.

Finally we will be able to remove all those events/messages that create a mess and loopbacks in the dialog opening and status updates moving to a much cleaner structure...



so it will require a little bit of time and effort to get 100% working.
The code I submitted was working in the basic scenarios I tested but (for sure) is not 100% perfect but I think EMM will really benefit a lot from this

Hello mr. Savazzi. Sorry for my late answer.
I was not able to merge your commit... to many changes between your branch and the latest code.

DanCooper,
we follow your lead
do not worry for late answer as I've been missing for some time due personal and work issues so I had to catch up with the excellent work the team has done.

I have planned the following:
We continue to work without async/await to release a final version of Ember 1.4.

Fine. This is a pitty as it means we will have to redo great part of the work as it will not merge for sure but the experience I got in the first conversion is not lost so I hope next round to be a little quicker

The final version of 1.4 should include:
- the new "Custom Media List Editor"

no impact expected on await/async

- a new genre handling (i've a good idea how it should be working)

no impact expected on await/async

- a new images select dialog for movies and tv show images

if we do not touch the download part no impact expected on await/async
otherwise the impact will be massive and I would not recomend to do it now as otherwise all the work will have to be redone.

- recode the tv show process to same system like you have done for movies

this will change quite a lot with the async/await as all the download part changes.

- some other small changes like Kodi-compatible stacking regex system (i've already started coding for this)

no impact expected on await/async

- maybe a working XML scraper (fully compatible with Kodi scrapers) for movies and tv shows

I would keep this for 1.5 as kodi is evolving very quickly

- generally bugfixing

always nice

For Ember 1.5 i've planned:
- change from WindowsForms to WPF (for this we need a lot of async/await code)

Great the impact will be massive moving to XAML (WPF) will allow us to do very nice things and yes async/await is mandatory at that point as otherwise the gui thread gets deadlocked and the app will not work. I've developed several apps for WP8 and I've used XAML but I'm not good at graphics. It would be great and needed to find someone that have good experience on XAML.

Do we have some candidates for this?

XAML is very difficult to debug/fix if you do not have great experience.

To fully exploit the power of WPF/XAML we have to move to a MVVM model to perfectly separate the presentation layer with the application layer with the data layer
I've done it in my apps and once you get the grip on it is great

Data binding is something I love but it was very chellengin (for me) to fix when it does not work

- move a large part of the code from "frmMain.vb" to the API (there are so many features that actually belong to the API)

totally agree

- change the API to get a working "headless" version of Ember

not clear what this means... can you explain better?

- create a HTML/JSON interface/API to control headless or default WPF version by web and Android or Apple apps

not clear to me this. Using XAML (WPF) will make Ember a full native W8 (Windows 10) application an will run on any Windows Platform.
It will not make it a Web Application nor I would do it otherwise is a mess for people to run it.
Am I wrong?

But... i've no experience with WPF :-)
IMO WPF has a lot of more opportunities then WindowsForms like skinning, mordern GUI, animations ... and for me, the single most important argument: the possibility to develop the processes independent of GUI ! It's so frustrating to merge the code, if two persons working on the same form at the same time. It's nearly impposible to merge to code without lost changes or manually fix all errors step by step.

totally agree. The separation of UX from View (aka application) and from Data is great to allow more dynamic development.

On the other side we must be sure everyone on the team will follow us or it could be a little bit challenging


So in the end I will put aside my old commit and will restart a new trunk fresh from yours.
Note that all the process to invoke the dialogs to select the images (fanart, clear art, etc...) is broken in 1.4 (it works but is broken effectively) but it makes no sense to fix it now.

[m.savazzi]

Ok I deleted my fork (after I've done a copy) and forked again.

[m.savazzi]

For the MVVM toolkit I have tested several and this is the best I've found:
http://mvvmlight.codeplex.com/

also here more info: http://www.mvvmlight.net

It's great and works very very well, also is updated very often.

He is swiss: http://blog.galasoft.ch/posts/category/mvvm/
and a great guy

In fact is already working with the latest tools:
I am very excited to talk about Xamarin and MVVM Light at VS Live in Las Vegas this year. I have two sessions:

An Overview of the Xamarin Programming Platforms

The majority of software code on Windows is developed in .NET and C#. The tools and languages provided by Microsoft are unmatched in terms of productivity to create applications, from rich desktop suites to small fluid mobile apps. You can reuse your skills, tools, language and even design on each platform. The big sensation these days is Xamarin. This lets you use .NET to create fully native apps on iOS and Android. In this session, Laurent Bugnion will show you how to get started with Xamarin and what you need to create apps on all these platforms.


In fact if we want to have EMM 1.5 to be an application to run on iOS and Android in addition to W8 W10 we will have to use Xamarin (I do not know what it is... will check)

[m.savazzi]

Xamarin is a pay platform not good for us!

[AbelToy]

I think at the moment we don't need to use Xamarin.

What I interpret from what DanCooper said, he plans to have a base WPF application running on Windows, and later adding web / mobile interfaces to it so you can talk to Ember Media Manager using your phone, but still having the windows application running on your PC.

We would only need WPF using C# with .NET to do that.

However, if we really needed Xamarin (for example, to build the mobile application using c#, and to have mac / linux versions, etc.), open source projects can apply for a free license: http://resources.xamarin.com/open-source...butor.html

[Cocotus]

I think at the moment we don't need to use Xamarin.

What I interpret from what DanCooper said, he plans to have a base WPF application running on Windows, and later adding web / mobile interfaces to it so you can talk to Ember Media Manager using your phone, but still having the windows application running on your PC.

We would only need WPF using C# with .NET to do that.

However, if we really needed Xamarin (for example, to build the mobile application using c#, and to have mac / linux versions, etc.), open source projects can apply for a free license: http://resources.xamarin.com/open-source...butor.html

Yes I Agree! Developing in Visual studio like we did before will be sufficient for Ember I think. I don't think its planned to develop an apk/Android application for Ember. I think what Dan meant was to create an API/JSON Interface of Ember that other projects (maybe then a small android application) can use to control Ember? But for that to work I guess Ember needs to be publish an Webservice?! I don't have any idea on how to do this

As for Ember 1.5: I have experience in XAML design since I created the GUI (creating style dictionary, usercontrols and such) of some applications based on VB.NET/WPF. I didn't develop/participate at the viewmodel design part though so it will be something new for me too! Like msavazzi said - XAML can be really hard to debug. Most XAML designer I know, develop XAMLs using a simple texteditor, that means no more click and drop like we can in Windows Forms projects (I tried with Xpression Blend but it's a mess for me, like WYSWYG Editors for HTML). But I will help since Ember is such a great project and learning developing in WPF will be rewarding

[m.savazzi]

Yes I Agree! Developing in Visual studio like we did before will be sufficient for Ember I think. I don't think its planned to develop an apk/Android application for Ember. I think what Dan meant was to create an API/JSON Interface of Ember that other projects (maybe then a small android application) can use to control Ember? But for that to work I guess Ember needs to be publish an Webservice?! I don't have any idea on how to do this

As for Ember 1.5: I have experience in XAML design since I created the GUI (creating style dictionary, usercontrols and such) of some applications based on VB.NET/WPF. I didn't develop/participate at the viewmodel design part though so it will be something new for me too! Like msavazzi said - XAML can be really hard to debug. Most XAML designer I know, develop XAMLs using a simple texteditor, that means no more click and drop like we can in Windows Forms projects (I tried with Xpression Blend but it's a mess for me, like WYSWYG Editors for HTML). But I will help since Ember is such a great project and learning developing in WPF will be rewarding

Great news!!!!

The MVVM model is very nice, the videos on Laurent site explain it very well. But in a nutshell is very easy:
1) you create a class with the Data (Model). That class is reponsible for holding the data, loading it and saving it.
2) you create a View Model that is the Application logic over the Data. So is a class that istantiate one or more Model objects to handle the data
3) you create a GUI (View) that binds to the View Model. Using XAML bind function everything is done on the fly

Essentially is great as the Model changes very rarely and only when the data structure changes. In addition to that the fact that the object itself is responsible for the load/save it means that you can change DB, save on File, go on Cloud without (almost) any modification of the other levels.

The View Model is the one that interacts with the application logic and where you can put callbacks, events, and a lot of nice stuff

Finally the GUI relies only on the properties exposed from the View Model so it can be twicked, changed, skinned, as you like

Also in the MVVM model there is standard way to pass commands between layers that works very well and is quite simple to implement! (i.e. you have a button that should refresh a record so from View down to the Model. Or when you have a parent/child view... if the parent is changed the child view should be updated)

I would suggest you look at different Laurent's videos and we will need to use it

[DanCooper]

Hi guys.

I've changed all TMDB addons to a new NuGet wrapper. I've also massive reduced the API calls to be in the (new) request limits on TMDB. There is still one bug in new wrapper, but the developer will fix and test that tonight. Also plot/overview for collection is missing in latest version, but it's already fixed for next NuGet release.

I've started working on new tv show module calls to change it to the same way like movie scrapers. TVDB is nearly complete and tv shows from TMDB coming soon also :-)

[m.savazzi]

Great!

[DanCooper]

TMDBLib has fixed an added all missing fields, all TMDB scrapers are done now :-)

[brunosso]

Hi guys i start to edit my fork of EMM, and i want to ask you if is possible to edit the visual style of the "Settings" form. I use a notebook with a resolution of 1366x768, and everytime i need to move the orizontal or vertical bar to find the option i need to edit!
I try to open the file dlgSettings.vb but i don't see all the item, like button, combobox, textbox, etc etc.

How can i do this edit?

[DanCooper]

Hi guys i start to edit my fork of EMM, and i want to ask you if is possible to edit the visual style of the "Settings" form. I use a notebook with a resolution of 1366x768, and everytime i need to move the orizontal or vertical bar to find the option i need to edit!
I try to open the file dlgSettings.vb but i don't see all the item, like button, combobox, textbox, etc etc.

How can i do this edit?

Please don't change something in dlgSettings.vb.
It was very complex to change all paneles to autosized. The whole dialog is to big and complex. I will spit it to single panels after 1.5 release.

[brunosso]

Hi guys i start to edit my fork of EMM, and i want to ask you if is possible to edit the visual style of the "Settings" form. I use a notebook with a resolution of 1366x768, and everytime i need to move the orizontal or vertical bar to find the option i need to edit!
I try to open the file dlgSettings.vb but i don't see all the item, like button, combobox, textbox, etc etc.

How can i do this edit?

Please don't change something in dlgSettings.vb.
It was very complex to change all paneles to autosized. The whole dialog is to big and complex. I will spit it to single panels after 1.5 release.

OK dan, so i wait new version.

[cg110]

Hi Dan,

What's the current build requirements for EMM? Is it studio 2015 or 2013? Also which VLC version (2.2.1? 32 or 64bit?) does it need, as that seemed to be one of the pain points with the VLC COM interop library.

I tried building it a few of days ago and had issues.

I was hoping to update the performance tweaks I did a while back and do some pull requests.

Thanks,
Chris