(2015-04-11, 21:33)DanCooper Wrote: (2015-04-11, 09:27)m.savazzi Wrote: (2015-04-10, 20:37)Cocotus Wrote: 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.
(2015-04-11, 21:33)DanCooper Wrote: 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
(2015-04-11, 21:33)DanCooper Wrote: The final version of 1.4 should include:
- the new "Custom Media List Editor"
no impact expected on await/async
(2015-04-11, 21:33)DanCooper Wrote: - a new genre handling (i've a good idea how it should be working)
no impact expected on await/async
(2015-04-11, 21:33)DanCooper Wrote: - 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.
(2015-04-11, 21:33)DanCooper Wrote: - 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.
(2015-04-11, 21:33)DanCooper Wrote: - some other small changes like Kodi-compatible stacking regex system (i've already started coding for this)
no impact expected on await/async
(2015-04-11, 21:33)DanCooper Wrote: - 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
(2015-04-11, 21:33)DanCooper Wrote: - generally bugfixing
always nice
(2015-04-11, 21:33)DanCooper Wrote: 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
(2015-04-11, 21:33)DanCooper Wrote: - 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
(2015-04-11, 21:33)DanCooper Wrote: - change the API to get a working "headless" version of Ember
not clear what this means... can you explain better?
(2015-04-11, 21:33)DanCooper Wrote: - 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?
(2015-04-11, 21:33)DanCooper Wrote: 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.