Reply to thread

Message

I spent the weekend with spying on the messages MedioPortal sends around.
A typical message reads like
[code]Message=GUI_MSG_GET_ITEM
Sender = 0
Target = 50
Parameter = 10[/code]
This way MedioPortals core (Sender=0) queries the menu item number ten (Parameter=10) from the to-me-unknown target #50.

The reply is not sent this way.

I guess only #50 knows the clear text name of item #10 - so the LCD plugin had to ask #50 at the very moment the plugins spies #0 doing this (doubling the traffic in MediaPlayers message system).
This MIGHT be the way to read the content of menus and filelists.

Now if the users presses "Escape" to navigate back in the menu hierarchy, the parent menu is made visible (not created again, it was simply hidden), so a LCD plugin had to keep the parent menu in memory as well. In general, a LCD plugin had to imitate every aspect of MediaPortals menu management.

Copying big parts of MediaPortal just to get the menus is NOT the way to go.

Well, we have modules. Let's see what they do.

- The video module. The core (not the video module) tells us, that playback has started and sends the file path of the currenty played video file. Hooray! Something useful!
- The music module. The core tells us, that playback has started and gives us the file path of the currenty played music file. No ID3 tags. This is lousy, but it could be worse...
- ... like in the picture module. Nothing is sent while displaying a picture. Cool.

Okay. What do we have? Modules, keeping their knowledge. A core, keeping its knowledge as well, but revealing some secrets of some of the modules.

This said, it is possible to write a useless LCD plugin. It seems impossible to me to write a useful LCD plugin at this state of MP and its modules.

Okay, somebody might reprogram the core, the message system and the modules... I won't, because I can't.

<blockquote data-quote="Anonymous" data-source="post: 4121">I spent the weekend with spying on the messages MedioPortal sends around. A typical message reads like [code]Message=GUI_MSG_GET_ITEMSender = 0Target = 50Parameter = 10[/code]This way MedioPortals core (Sender=0) queries the menu item number ten (Parameter=10) from the to-me-unknown target #50.The reply is not sent this way. I guess only #50 knows the clear text name of item #10 - so the LCD plugin had to ask #50 at the very moment the plugins spies #0 doing this (doubling the traffic in MediaPlayers message system).This MIGHT be the way to read the content of menus and filelists.Now if the users presses &quot;Escape&quot; to navigate back in the menu hierarchy, the parent menu is made visible (not created again, it was simply hidden), so a LCD plugin had to keep the parent menu in memory as well. In general, a LCD plugin had to imitate every aspect of MediaPortals menu management. Copying big parts of MediaPortal just to get the menus is NOT the way to go.Well, we have modules. Let's see what they do.- The video module. The core (not the video module) tells us, that playback has started and sends the file path of the currenty played video file. Hooray! Something useful!- The music module. The core tells us, that playback has started and gives us the file path of the currenty played music file. No ID3 tags. This is lousy, but it could be worse...- ... like in the picture module. Nothing is sent while displaying a picture. Cool.Okay. What do we have? Modules, keeping their knowledge. A core, keeping its knowledge as well, but revealing some secrets of some of the modules. This said, it is possible to write a useless LCD plugin. It seems impossible to me to write a useful LCD plugin at this state of MP and its modules.Okay, somebody might reprogram the core, the message system and the modules... I won't, because I can't.</blockquote>

[QUOTE="Anonymous, post: 4121"] I spent the weekend with spying on the messages MedioPortal sends around. A typical message reads like [code]Message=GUI_MSG_GET_ITEM Sender = 0 Target = 50 Parameter = 10[/code] This way MedioPortals core (Sender=0) queries the menu item number ten (Parameter=10) from the to-me-unknown target #50. The reply is not sent this way. I guess only #50 knows the clear text name of item #10 - so the LCD plugin had to ask #50 at the very moment the plugins spies #0 doing this (doubling the traffic in MediaPlayers message system). This MIGHT be the way to read the content of menus and filelists. Now if the users presses "Escape" to navigate back in the menu hierarchy, the parent menu is made visible (not created again, it was simply hidden), so a LCD plugin had to keep the parent menu in memory as well. In general, a LCD plugin had to imitate every aspect of MediaPortals menu management. Copying big parts of MediaPortal just to get the menus is NOT the way to go. Well, we have modules. Let's see what they do. - The video module. The core (not the video module) tells us, that playback has started and sends the file path of the currenty played video file. Hooray! Something useful! - The music module. The core tells us, that playback has started and gives us the file path of the currenty played music file. No ID3 tags. This is lousy, but it could be worse... - ... like in the picture module. Nothing is sent while displaying a picture. Cool. Okay. What do we have? Modules, keeping their knowledge. A core, keeping its knowledge as well, but revealing some secrets of some of the modules. This said, it is possible to write a useless LCD plugin. It seems impossible to me to write a useful LCD plugin at this state of MP and its modules. Okay, somebody might reprogram the core, the message system and the modules... I won't, because I can't. [/QUOTE]