[PATCH] fix segfault in cSkins::Message

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stefan Lucke wrote:
> On Dienstag, 26. Juli 2005 18:52, Wolfgang Rohdewald wrote:
> 
>>On Dienstag 26 Juli 2005 14:29, Luca Olivetti wrote:
>>
>>>Stefan Lucke wrote:
>>>
>>>>Is there another way for a plugin to display a message during
>>>>background processing ? 
>>>>Preferably a _non_ blocking way,as I noticed that Skins.Message()
>>>>does it's job blocking.
>>>
>>>Is there a solution for this problem?
>>>I now also need to notify the user of a background event, and the 
>>>Housekeeping method (a possible candidate since it's called from the 
>>>foreground thread) isn't suitable, since it's called only once every 60 
>>>seconds.
>>
>>as far as I can see the only other method is to connect to port 2001.
> 
> 
> The SVDRP port is not hardcoded, it can be specified via "-p number".
> So the next question would be, how can a plugin read the port
> our main program is listening on ? So plugins need the -p option too.
> 
> 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?

Klaus


[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux