Wolfgang Rohdewald wrote: > On Sonntag 31 Juli 2005 16:56, Klaus Schmidinger wrote: > >>Stefan Lucke wrote: >> >>>Isn't it more suitable to make Skins.Message() usable for plugins ? >>>Klaus ? >> >>A plugin may well call Skins.Message(), but only from the _main_ >>thread. >> >>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? > > > Sounds good to me. > > How long would the cOsdObject be displayed? Could this be definable > by a parameter like in cSkins::Message()? The cOsdObject would be displayed until its ProcessKey() function returns osEnd. Note that this would be like any other menu, and it would run in the _foreground_ thread. > Does vdr have a way to notice if a background thread accesses the > OSD? A background thread should never access the OSD directly. > If so, and if this happens thru cSkins::Message() or cInterface::Confirm(), > could vdr automatically handle this? Or just issue a warning > like "You should use ::Popup()" Again: if a plugin wants to interact with the user "out of the blue" (meaning: not through the plugins main menu entry), cPlugin::Popup() can either return a cOsdObject (which can be anything) that will be further handled by VDR's main loop and will end when its ProcessKey() function tells VDR to do so (or when the user hits kMenu - maybe there are even other reasons), or it can do something like directly call Skins::Message() and display a message (and return NULL). But all this will be done from the _foreground_ thread, so any information a plugin's _background_ thread wants to display needs to be stored in the plugin somehow, until the plugin is asked for it by a call to its Popup() function. I don't think that this will be much of a problem, because typically such messages would be progress messages, like "processed x out of y items", so the background thread could simply increment some counter and the foreground thread could display the message whenever the difference between the previous message and the current counter exceeds some limit. OMHO there is most certainly no need for a "message queue" for background thread messages. Klaus
