Idea: Eventing architecture (1 Viewer)

[niekh]

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]

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]

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:

	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]

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.

 

[samuel337]

In that case, I think the examples I gave pretty much answer your question.

Sam