Re: gnome-panel transparency problems

[Kurt Fitzner <kfitzner excelcia org>]

Mark McLoughlin wrote:
> 	The whole applet background thing has been broken for a long time now.
> There's at least one bug against libpanel-applet which discusses at
> length the "pixmap backgrounds don't work". We need someone to debug it
> and figure out whats going on - there have been several attempts and I
> haven't tried myself in a long time.

My work originally was specifically aimed at gnome_swallow (not -yet- in 
gome-applets), which I have now got to work just fine with pixmap 
backgrounds.  I've, in fact, not been able to break it.  Of course, "it 
works for me" is much different than it works in general, but aside from 
the issue I noted earlier, pixmap backgrounds work just fine.

> 	Yeah, that's definitely a bug. Log it, fix it, kill it :-)

Definitely will log it. :)  As to fixing it... if no one else is 
actively working on it at the moment, I'll definitely take a shot at it. 
 But, see below for an alternative...

> 	Hack! We definitely want a real fix ..

Well, yes, but this might be the way people might want to implement it. 
 Simply to ease the CPU load when the transparency slider is being 
manipulated.  Do you really want 10 or 20 applets all continuously 
stressing the system trying to keep their background pixmaps updated in 
realtime?  It's going to be flickery anyways.  Best to just have them 
wait until there hasn't been a change for a tenth of a second or so, 
then update.  Any time the user hovers the slider for any length of time 
they update, and it saves a lot of cpu time.

To be honest, the system I made works so well (for me), I'd suggest the 
whole idea of the change-background signal might want to get looked at. 
 Why bother going to the expense of having gnome-panel calculate the 
background pixmaps for a dozen applets in real-time when many applets 
might want to implement the background changes like I do?  It would 
simplify matters if the change-background signal was just that... a 
signal that the background was changing. And then require the applets to 
call panel_applet_get_background() whenever they want to update 
themselves.  It saves on processing for those applets that don't care 
about updating in real-time, but it still allows those that want to to 
do so.  Since I can't tell that the change-background signal was even 
being SENT prior to 2.6, I can't see how the new method would even break 
any existing applets.  You can keep the callback function structure the 
way it is now, but deprecate it - and simply feed it nulls for its data. 
 It might seem to some to be a cop-out on fixing the bug, but I think 
it's a technically superior idea.

> > Incidentally, I am wondering if a patch to gnome-applets with 
> > pseudo-transparency support for all the applets would be welcome.
>
> 	Yeah, it would, except for the problem that some applets are going to
> be near impossible to use on some backgrounds - e.g. I wouldn't accept a
> transparent background patch for the clock applet without some hack to
> draw the text in white with a black shadow or something - the way
> Nautilus does the text under icons on the desktop.

All right. I'll do it for those applets for which it will make sense 
right now, and do some more thinking for some of the others that could 
be harmed.  Maybe XORing text on the background??

	Kurt.