[vdr] [PATCH] fix segfault in cSkins::Message

Klaus Schmidinger Klaus.Schmidinger at cadsoft.de
Sun Jul 31 18:35:33 CEST 2005

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

   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.


More information about the vdr mailing list