Hello,

first of all a big compliment to all the people that have donated some (i guess allot of) spare time to develop MediaPortal; it looks and feels like an application that has a promising future ahead...

At this moment i am reading through the sources in order to start implementing my first plugin. I am a proud owner of a MSI MEGA 180 and want to use MediaPortal on it as interface for my home theater. The plugin i want to develop (i haven't got much spare time so it will take me a while) will enable users to interface with their radiotuners. In my case this would be the MEGA 180's tuner, but such a plugin should be written so that other people could use their tuners also.

The problem i am having is how such a plugin should be implemented. In my opinion a plugin should contain the code that is related to the plugin, except code that is common to allot of modules in the application. I can be wrong and do not want to be annoying but if i interpreted the sources correctly, the code that is related to the configuration of a plugin (like the weather plugin) is not contained into the plugin itself.

May i be so inpolite to ask why this is done? i know that it is quite simple to also implement the configuration interface within the related plugin. I do not know if this could be possible with MediaPortal but i guess it is something to keep in mind when looking at the big picture. When allot of people start to implement plugins for MediaPortal it is not an option to recompile the core each time; i guess this could lead to conflicts within the software.
In the ideal situation a plugin would consist of one or more Assemblies with one or more related layout XML files and images etc. and should get registered somehow.

I think that imho the boundaries between the core and plugins should be a bit less fuzzy.

Please forgive me if a wrote allot of noncense above, i am only trying to help become MediaPortal even better.

Feedback is welcome!

Greetings,

Peter Vrenken @ sittin' with his laptop on the balkony in the sunny Netherlands...

[tomtom21000]

Radio integration would be cool.

i have this done with myhtpc.

there is a program called axife fmlite. it has command line controls, is free (though not open source) in the light version (no mp3 recording) and can be integrated in the background like wmp9 is. maybe this could be used and save you some work.

http://www.axife.com/axfm/fmlite.html

i have a cinergy tv 600 with radio. it worked with it. don´t think it could use the mega 180 radio. I have a mega 651.

here ar the supported cards:

http://www.axife.com/axfm/cards.html

the other things you point out sound logical, but as i am no programmer someone else should comment on that. anyway i like the idea that the project attracts some programmers to support frodo.

tomtom21000

[Mr.Mitchell]

The following text was copied from the todo.txt file:
--------
My Radio:
- AM/FM
- Scan channels
- Name channels
- listen to channel
--------

So I think that it is safe to assume that radio support is in the works.

[tomtom21000]

Originally Posted by Mr.Mitchell

The following text was copied from the todo.txt file:

[frodo]

A plugin can now have its own setup/configuration form(s)
I've setup a simple interface :

using System;

namespace MediaPortal.GUI.Library
{
  /// <summary>
  /// Interface for plugin setup configuration screens. 
  /// 
  /// Plugins may have a configuration screen. By implementing this interface in your plugin
  /// MediaPortal will add it to the tools->plugin menu where users can configure your plugin
  /// Look at the home subproject for a sample 
  /// </summary>
  public interface ISetupForm
  {
    string PluginName();  // Return the name which should b shown in the plugin menu
    string Description(); // Return the description which should b shown in the plugin menu
    string Author();      // Return the author which should b shown in the plugin menu
    void   ShowPlugin();  // show the setup dialog
    bool   CanEnable();   // Indicates whether plugin can be enabled/disabled
    int    GetWindowId(); // get ID of plugin window

    /// <summary>
    /// If the plugin should have its own button on the home screen then it
    /// should return true to this method, otherwise if it should not be on home
    /// it should return false
    /// </summary>
    /// <param name="strButtonText">text the button should have</param>
    /// <param name="strButtonImage">image for the button, or empty for default</param>
    /// <param name="strButtonImageFocus">image for the button, or empty for default</param>
    /// <param name="strPictureImage">subpicture for the button or empty for none</param>
    /// <returns>true  : plugin needs its own button on home
    ///          false : plugin does not need its own button on home</returns>
    bool   GetHome(out string strButtonText, out string strButtonImage, out string strButtonImageFocus, out string strPictureImage); 
  }
}

If your own plugin contains class(es) which implement this interface they will show up on the tools->plugin... menu
When a user wants to configure the plugin the ShowPlugIn() will be called

Frodo

I'm looking into creating a plugin to handle bluetooth phones. i would like to display contacts, recent calls, missed calls etc... pause whatever is playing when an incomming call comes in perhaps.
I'm looking at some of the existing plugins and am having a hard time figuring out what i have to implement. I'm at a "hello world" stage right now when it comes to media portal plugins.
Any pointers? Or if it's easy enough how about a simple example that has a button and a label. Set the label upon clicking the button.
I could see all the neccessary plumbing from that example i'm sure.
Thanks a bunch for any help. I'm really looking forward to working on this.
I plan on using media portal in my car with my 7" widescreen touchscreen display.

[jadz]

I am hoping to get some more information on guidelines for writing plugins.

If the plugin is to have a window then it has to implement the GUIWindow
interface right correct?

What about if the plugin is windowless, is there anything special that has to be done? I have put a bit of code in the class that implements the ISetupForm interface MessageBox.Show("implemented lass with ISetupForm interface"); for example and it seems to be executed twice when media portal starts, ie I would get two messageboxes.

Is this the wrong place to put my code (in the class with the ISetupInterface)? If I put it in another class how does MediaPortal know to execute the code?

-Joe

[Mars Warrior]

Originally Posted by jadz

I have put a bit of code in the class that implements the ISetupForm interface MessageBox.Show("implemented lass with ISetupForm interface"); for example and it seems to be executed twice when media portal starts, ie I would get two messageboxes.

Well, if I simply check the startup, MP reports the following:

plugin:My Music
plugin:My Pictures
plugin:My Radio
plugin:Topbar
plugin:My TV
plugin:My Videos
plugin:My Weather
plugin:Settings
plugin:My Music
plugin:My Pictures
plugin:My Radio
plugin:Topbar
plugin:My TV
plugin:My Videos
plugin:My Weather
plugin:Settings
plugin:My Music
plugin:My Pictures
plugin:My Radio
plugin:Topbar
plugin:My TV
plugin:My Videos
plugin:My Weather
plugin:Settings

Each plugin is seen multiple (3) times. Donno what that means, but it might be the same you see with your dialog boxes...

[jadz]

This is from GuiWindowManager.cs, and I'm not sure I fully understand it.

    static public void LoadPlugin(string strFile)
    {
			try
			{
        Assembly assem = Assembly.LoadFrom(strFile);
				if (assem!=null)
        {
					Type[] types = assem.GetExportedTypes();

          foreach (Type t in types)
          {
            try
            {
              if (t.IsClass)
              {
                TypeFilter myFilter = new TypeFilter(MyInterfaceFilter);
                Type[] foundInterfaces=t.FindInterfaces(myFilter,"MediaPortal.GUI.Library.ISetupForm");
                if (foundInterfaces.Length>0)
                {
                  object newObj=(object)Activator.CreateInstance(t);
                  ISetupForm  setup=(ISetupForm)newObj;
                  if (setup.CanEnable())
                  {
                    if (!PlugInEnabled(setup.PluginName()))
                    {
                      return;
                    }
                  }
                }
              }
            }
            catch (System.NullReferenceException)
            {
							
            }
          }

					foreach (Type t in types)
					{
						try
						{
							if (t.IsClass)
							{
								if (t.IsSubclassOf (typeof(GUIWindow)))
								{
									object newObj=(object)Activator.CreateInstance(t);
									GUIWindow win=(GUIWindow)newObj;
									win.Init();
									GUIWindowManager.Add(ref win);
                  //Log.Write("  found plugin:{0} in {1}",t.ToString(), strFile);
								}
							}
						}
						catch (System.NullReferenceException)
						{
							
						}
					}
				}
			}
			catch (Exception ex)
			{
        string strEx=ex.Message;
			}
    }

[Mars Warrior]

This is from GuiWindowManager.cs, and I'm not sure I fully understand it.

Well, it seems pretty straightforward ;-)
I think Frodo could probably explain it better, but this is what I understand:
1. It tries to load the assembly (ie the plugin)
2. If assembly loaded, it tries to find the ISetupForm interface and if it exists, it creates the plugin interface, and checks if this plugin can be enabled/disabled. If the plugin can be enabled/disabled and the plugin is disbled, the function returns, otherwise it continues with (3)
3. All GUIWindows defined by the plugin are created and initialized. Maybe if a plugin contains multiple windows, the plugin is called multiple times

That's basically it, as far as I understand.