Problem with Panel from CVS this morning

Benedikt Meurer benedikt.meurer at unix-ag.uni-siegen.de
Tue Jul 27 09:07:29 CEST 2004


Brian J. Tarricone wrote:
> Marc Schwartz wrote:
> 
>> On Mon, 2004-07-26 at 12:51, Brian J. Tarricone wrote:
>>  
>>
>>> it's possible that this has something to do with the new 
>>> multithread-awareness of the panel.  there are probably some plugins 
>>> that have yet to be updated...
>>>
>>>     -brian
>>>   
>>
>> Brian,
>>
>> Is this something that would have been new as of mid-to-late last week?
>> I had last done a CVS update early in the week.
>>
>> If so, that would seem a reasonable cause. Otherwise, prior to the CVS
>> update over the weekend, the clipboard plug-in had been working without
>> locking the panel.
>>
> yes, the panel changes went in on the 23rd, around 5pm US eastern, so if 
> you checked out the panel after that, it's possible this is the 
> problem.  lemme have a look at the clipboard plugin....  yep, it appears 
> that the clipman plugin sets a couple timout events.  yep, that appears 
> to be the case.  try the attached patch to the clipman plugin.
> 
> benny: i noticed you did the XFCE_PANEL_LOCK() stuff by putting a 
> condition in depends.m4.  is there any reason you didn't just define it 
> in a panel header like so:
> 
> #define XFCE_PANEL_LOCK() \
>    do {\
>       if(g_thread_supported())\
>          gdk_threads_enter();\
>    } while(0)
> 
> g_thread_supported() will return FALSE if the GThread system hasn't been 
> initialised.  this seems like a better way than m4 stuff, so the plugins 
> won't have to worry about the new m4 file.  what do you think?

Yes, theres a reason I put this into the m4 file: This way, the plugins 
will continue ti work with old panels and you have everything in one place.

Benedikt



More information about the Xfce mailing list