Idea: Eventing architecture (1 Viewer)

niekh

Portal Member
October 19, 2004
17
0
I think MP could benefit from implementing an eventing architecture where application events (not .NET framework events) can be propagated to enlisted subscribers.

MP would then fire events e.g. when:
- starting
- closing
- entering a module
- playing something
- changing channels
etc.

This way integration of plug-ins would be facilitated, I believe.

Combining this approach with a script plugin would allow for a simple but powerful solution to common automation problems (e.g. "Dim the lights to 25% when I start playing a movie/DVD and at the same time power on the surround receiver and set its volume level to X").

A GUI to show current event wire-up wouldn't hurt either!

Integrating, for instance, LCD-plugins should become a whole lot easier too!

What say ye?

/Nils
 

LordMessi

Retired Team Member
  • Premium Supporter
  • July 4, 2005
    449
    0
    43
    Ørsø, Dronninglund, Denmark
    Home Country
    Denmark Denmark
    niekh said:
    I think MP could benefit from implementing an eventing architecture where application events (not .NET framework events) can be propagated to enlisted subscribers.

    MP would then fire events e.g. when:
    - starting
    - closing
    - entering a module
    - playing something
    - changing channels
    etc.

    This way integration of plug-ins would be facilitated, I believe.

    Combining this approach with a script plugin would allow for a simple but powerful solution to common automation problems (e.g. "Dim the lights to 25% when I start playing a movie/DVD and at the same time power on the surround receiver and set its volume level to X").

    A GUI to show current event wire-up wouldn't hurt either!

    Integrating, for instance, LCD-plugins should become a whole lot easier too!

    What say ye?

    /Nils

    Well this sounds like a good idea - when do you start?
     

    samuel337

    Portal Pro
    August 25, 2004
    772
    0
    Melbourne, Australia
    You might want to start monitoring the event that's fired when a property in the property manager is changed. It will give you all this information and more - you just need to filter and respond to the appropriate ones.

    Also, monitor the event that fires when ThreadMessages are fired - this will also give you a lot of information. Here's a list of all the messages that can be fired:

    Code:
    	GUI_MSG_WINDOW_INIT,
    				GUI_MSG_WINDOW_DEINIT,
    				GUI_MSG_SETFOCUS,
    				GUI_MSG_LOSTFOCUS,
    				GUI_MSG_CLICKED,
    				GUI_MSG_VISIBLE,
    				GUI_MSG_HIDDEN,
    				GUI_MSG_ENABLED,
    				GUI_MSG_DISABLED,
    				GUI_MSG_SELECTED,
    				GUI_MSG_DESELECTED,
    				GUI_MSG_LABEL_ADD,
    				GUI_MSG_LABEL_SET,
    				GUI_MSG_LABEL_RESET,
    				GUI_MSG_ITEM_SELECTED,
    				GUI_MSG_ITEM_SELECT,
            GUI_MSG_ITEM_FOCUS,
    				GUI_MSG_LABEL2_SET,
    				GUI_MSG_SHOWRANGE,
            GUI_MSG_GET_ITEM,
            GUI_MSG_START_SLIDESHOW,
            GUI_MSG_ITEMS,
            GUI_MSG_GET_SELECTED_ITEM,
            GUI_MSG_PLAYBACK_STOPPED,
            GUI_MSG_PLAYLIST_CHANGED,
            GUI_MSG_PLAYBACK_ENDED,
            GUI_MSG_PLAYBACK_STARTED,
            GUI_MSG_PERCENTAGE_CHANGED,
            GUI_MSG_PLAY_FILE,
            GUI_MSG_STOP_FILE,
            GUI_MSG_SEEK_FILE_PERCENTAGE,
    				GUI_MSG_RECORDER_ALLOC_CARD,
            GUI_MSG_RECORDER_FREE_CARD,
            GUI_MSG_RECORDER_STOP_TIMESHIFT,
            GUI_MSG_TUNE_EXTERNAL_CHANNEL,
            GUI_MSG_GET_STRING,
            GUI_MSG_GET_PASSWORD,
            GUI_MSG_SWITCH_FULL_WINDOWED,
            GUI_MSG_PLAY_AUDIO_CD,
            GUI_MSG_CD_REMOVED,
            GUI_MSG_CD_INSERTED,
            GUI_MSG_PLAYING_10SEC,//file is playing 10 sec
            GUI_MSG_PLAY_RADIO_STATION,
            GUI_MSG_SHOW_WARNING,
            GUI_MSG_RESUME_TV,
            GUI_MSG_SEEK_FILE_END,
            GUI_MSG_REFRESH,
            GUI_MSG_ASKYESNO,
            GUI_MSG_NEW_LINE_ENTERED,
            GUI_MSG_FILE_DOWNLOADED,
            GUI_MSG_FILE_DOWNLOADING,
            GUI_MSG_USER,
            GUI_MSG_MSN_MESSAGE,
            GUI_MSG_MSN_STATUS_MESSAGE,
            GUI_MSG_MSN_CLOSECONVERSATION,
            GUI_MSG_ITEM_FOCUS_CHANGED,
    				GUI_MSG_PLAY_ITEM,
    				GUI_MSG_RECORDER_VIEW_CHANNEL,
    				GUI_MSG_RECORDER_STOP_VIEWING,
    				GUI_MSG_GOTO_WINDOW,
    				GUI_MSG_RECORDER_TUNE_RADIO,
    				GUI_MSG_RECORDER_STOP_RADIO,
    				GUI_MSG_VOLUME_INSERTED,
    				GUI_MSG_VOLUME_REMOVED,
    				GUI_MSG_AUTOPLAY_VOLUME,
    				GUI_MSG_SHOW_DIRECTORY,
    				GUI_MSG_SHOW_MESSAGE,
    				GUI_MSG_HIDE_MESSAGE,
    				GUI_MSG_NOTIFY,
    				GUI_MSG_RECORDER_STOP_TV,
    				GUI_MSG_CLICKED_UP,
    				GUI_MSG_CLICKED_DOWN,
    				GUI_MSG_RECORDER_ABOUT_TO_START_RECORDING,
    				GUI_MSG_NOTIFY_TV_PROGRAM,
    				GUI_MSG_RESTART_REMOTE_CONTROLS,
    				GetList,
    				GUI_MSG_SEEK_POSITION,
    				GUI_MSG_PLAYER_POSITION_CHANGED,
            GUI_MSG_RECORD

    Also, the player component also fires events when an item starts playing (song, video, tv etc.), when it stops, when the next item is played in the playlist etc.

    So I think more the point is that some one needs to go in and make sure all these messages are fired at the appropriate moment, rather than creating a new event manager.

    EDIT: Hang on - what do you mean by 'application events (not .NET framework events)'?

    Sam
     

    niekh

    Portal Member
    October 19, 2004
    17
    0
    samuel337 said:
    EDIT: Hang on - what do you mean by 'application events (not .NET framework events)'?

    Just a statement to raise the abstraction level a bit!

    What I mean is that the events we are interested in are the ones where MP's state changes in such a way as in the examples I presented rather than events like "Widget X was clicked".

    That's why I said "(not .NET framework events)" although I fully understand that .NET events can be used when implementing an eventing architecture.

    I have just started studying MP's sources (and it's a daunting task!) so I can't say for sure that support for feature X is missing or not but I do believe that plugin authors and MP as a whole could benefit from a unified way of receiving and raising application events (if it's already there, great!). That in combination with my lack of knowledge of MP's internals is why I made the proposition hoping that some of the more seasoned MP devs would consider it and comment upon it.
     

    Users who are viewing this thread

    Top Bottom