Problem with Panel from CVS this morning

[Brian J. Tarricone]

Benedikt Meurer wrote:

> 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.

hmm... i see your point, though it puts the burden of grabbing a new m4 
file on the plugin authors, rather than just getting the macro 
automatically with the new header files.  ah well, no way around it, i 
guess.

    -brian