Stefan Lucke wrote: > On Sonntag, 31. Juli 2005 16:56, Klaus Schmidinger wrote: > ... >>I'm thinking about a function like >> >> cOsdObject *cPlugin::Popup(void); >> >>which would be called in every turn of the main loop (i.e. from the >>foreground thread) whenever there is no OSD display open. A plugin >>could either return a cOsdObject that will be presented to the user, >>or could directly display a message (even with user interaction, if >>necessary) and retrun NULL. Of course, if a plugin's thread wants to >>issue a message, it will have to store the message inside the plugin >>and wait until asked through a call to its Popup() function. >> >>Would that be a useful solution? >> > > > In some way yes, as it is something like InteractiveHousekeeping(). > But that would introduce message queueing code into each plugin, which > wants to display a message. The condition "whenever there is no OSD > display open" will cause an undetermined delay. "normal" OSDs have > an area where such messages could be displayed. > I would prefer something like Skins.QueueMessage() so that there is > only one peace of code and each plugin can use it. > For more complex OSDs (interactive ones) Popup() is more suitable: > "You've new mail: read now (y (green) / n (red)) ?" Why would you want to queue such messages? If I understand this correctly, the original purpose of this was to display some sort of progress indication. So, if a plugins's background thread has something to say (like "processed x out of y items"), it can do so at any time. There's no need to queue all messages, like processed 10 out of 1000 items processed 20 out of 1000 items processed 30 out of 1000 items processed 40 out of 1000 items processed 50 out of 1000 items processed 60 out of 1000 items processed 70 out of 1000 items processed 80 out of 1000 items If VDR's main loop decides to ask the plugin whether it has something to say, it doesn't really matter whether this is processed 20 out of 1000 items or processed 70 out of 1000 items The key point here is that the background thread does _not_ direcly display a message. It rather keeps some indication of its current state, and whenever suitable, the foreground thread will be asked to display it. Klaus
