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