MPEM Development Info & Testversion (2 Viewers)

[chefkoch]

To give you also some topic related, constructive feedback:

I've tested the tool from Debug.rar and it's awesome great work.

Here is a minor improvement suggestion:
Scrolling horizontal by mouse wheel does not work.

 

[Edalex]

It doesn't look like it will be simple to port this UI to MP GUI plugin

 

[sa_ddam213]

To give you also some topic related, constructive feedback:

I've tested the tool from Debug.rar and it's awesome great work.

Here is a minor improvement suggestion:
Scrolling horizontal by mouse wheel does not work.
View attachment 128649

Ahhh.. i froget about mouse suff as i write Touchscreen applications all day and night , LOL

It has fancy IPhone flick style scrolling at the moment, but I can add mouse wheel support too

 

[sa_ddam213]

It doesn't look like it will be simple to port this UI to MP GUI plugin

Why would we need to do that?

 

[Dadeo]

I also agree to these two points.
But, besides MPEM itself (container-format, external WPF-Management app, inbuilt plugin/browser), especially these two points are heavily related to the online component: the repository, gallery or call it whatever you want.

I don't see these issues being resolved completely by keeping the existing repository.

Can we please wait and see what sa_ddam213 actually needs and what our online repository can provide for him before we start talking about changing it? Do I need to remind you of the 3 years of torture and nightmare we lived through trying to get any developer to work on our old repo? As soon as the repo becomes dependent on some developer, it is very likely we will not find anyone to update it as is proven by history! We have barely managed to get a developer interested to work on MPEM (and as you know few were interested in working on MPEI in spite our our constant requests) so I get really nervous about making our whole Online Repository dependent on getting even more developers interested.

 

[seco]

Can we please wait and see what sa_ddam213 actually needs and what our online repository can provide for him before we start talking about changing it? Do I need to remind you of the 3 years of torture and nightmare we lived through trying to get any developer to work on our old repo? As soon as the repo becomes dependent on some developer, it is very likely we will not find anyone to update it as is proven by history! We have barely managed to get a developer interested to work on MPEM (and as you know few were interested in working on MPEI in spite our our constant requests) so I get really nervous about making our whole Online Repository dependent on getting even more developers interested.

Still I would highly recommend to listen to people who actually publish plugins and have to live with the current stuff. Few days ago I spent three hours trying to get two plugins to repository so that everything would work for both MP 1.3 and 1.4. There are problems in repo, Extensions Installer and dependency stuff that we should not bring to new MPEM and all of them are connected.

 

[Dadeo]

I know there are issues Seco. I am also constantly reporting (i.e. complaining ) about them to the Team . I always post downloads on Google Code for exactly that reason, as many extensions do. And I agree 100% that issue (of multiple versions) has to be resolved. But my point is we don't know YET exactly what the requirements are, so we can't determine the best solution. We may even be able to customize the current Repo software, or request a new feature. I just don't want to start talking about a whole new repo before we know.

 

[jameson_uk]

Why would we need to do that?

The original idea was for users to be able to browse and install plugins inside MP. Having to close MP, open a new app, close that, reopen MP is a bit of a faff and not that simple if you only control the machine with a remote.

I am still a little unclear as to the scope of this. Are we just replacing the desktop installer or are we going to address some of the issues in the back end?

 

[sa_ddam213]

Can we please wait and see what sa_ddam213 actually needs and what our online repository can provide for him before we start talking about changing it? Do I need to remind you of the 3 years of torture and nightmare we lived through trying to get any developer to work on our old repo? As soon as the repo becomes dependent on some developer, it is very likely we will not find anyone to update it as is proven by history! We have barely managed to get a developer interested to work on MPEM (and as you know few were interested in working on MPEI in spite our our constant requests) so I get really nervous about making our whole Online Repository dependent on getting even more developers interested.

Still I would highly recommend to listen to people who actually publish plugins and have to live with the current stuff. Few days ago I spent three hours trying to get two plugins to repository so that everything would work for both MP 1.3 and 1.4. There are problems in repo, Extensions Installer and dependency stuff that we should not bring to new MPEM and all of them are connected.

The idea behind MPEM is to solve exactly these issue, I myself have a plugin that cannot be installed using MPEI.

The MPEM UI will create the installers using a wizard(or code for more advanced users) and then publish to the repo all in one nice screen flow.

Like:
Plugin Details > Add Files > Pick MP versions(compatibility) > Publish to MP repo > Ready to download by users

And there should be a bunch of pre-defined installer templates

• Skin
• Skin & Plugin
• Plugin
• Plugin & Application/Service
• Codecs
• Logos
• Just wrap a existing installer
• Patches
• Updates

Also let people create publish their own installer templates so others can use them as well, that will come in handy for skin mods etc.

And I will be asking for a LOT of input from every plugin developer, but if we make a nice modular install wizard adding new requirements can be done easily.

The installers themselves are still a tricky area, MPEI was great except if you need to install parts onto a pc without MP, like your TVServer or laptop.

1. Use EXE or MSI installers so they can be used anywhere
2. Make MPEM portable so that can be used to install features onto other machines
3. Add functionality to creation process to add extra installers than can be extracted by MPEM to be used on other pc's

The repo stuff is really not my area, I have very little web skill except simple MVC junk, but there will need to be changes and I'm really going to need input from other developers on how it all works now and what can be done, The NuGet gallery idea looked pretty cool and simple but I'm still researching NuGet myself to figure out how it all works so perhaps others with more Nuget knowledge can comment further on this.

 

[sa_ddam213]

Why would we need to do that?

The original idea was for users to be able to browse and install plugins inside MP. Having to close MP, open a new app, close that, reopen MP is a bit of a faff and not that simple if you only control the machine with a remote.

I am still a little unclear as to the scope of this. Are we just replacing the desktop installer or are we going to address some of the issues in the back end?

I think I misunderstood that persons question.


The MPEM manager UI is mainly going to be used for creating packages but also has the same functions as the MediaPortal GUI plugin will have (Search, Install, Update etc) and as this can be used over the local network this will also be very handy when browsing installing plugins.

The UpdateSevice will be the one doing the installs so both MPEM/Plugin can do the same thing.

Well that's what I thought was the plan, LOL