as far as I can tell, in kde 3.3, that is the case as well: kicker
won't reload plugins unless restart, or after an execute of kdeinit

On 6/9/05, Randy Carnahan <rcarn@chartermi.net> wrote:
> 
> Sorry to keep harping on this, but bugs irritate me, especially when I
> can't fix them,. ;)  The geek in me refuses to give up...
> 
> Is there, especially in KDE 3.4, any reason that kicker applets are
> *not* removed from memory after being removed from the panel?  I ask,
> because in trying to troubleshoot my prior kclip applet issue, I
> restarted the project in KDevelop, but instead of having it display
> Desktop Name when the desktop is changed, I had it set the text to
> foobar:
> 
>   deskLabel->setText("foobar");
> 
> ...then from the Build menu, 'Build Project' and then 'Install As Root'
> and then re-moved and re-added the applet to my panel.  Lo and Behold,
> the label does *not* change to 'foobar' at all, but behaves exactly as
> the normal build of the applet.  The .la and .so files *are* being
> updated in /usr/kde/3.4/lib/ -- but just for kicks, I deleted those
> files, rebuild, reinstall, reload and still same thing.
> 
> If I use dcop to call 'kicker Panel restart' and *then* load the applet,
> it changes the label to 'foobar' as expected.  Therefore, it definitely
> appears that the kicker is *not* truly unloading applets when removed.
> I'm about to submit a bug report, because nothing else can explain this
> behavior of why a label is not respecting font color once assigned, or
> why after rebuilding the applet, it refuses to load a newer version.
> 
> Again, if I a missing something, clue me in, please.  :)
> 
> Randy Carnahan
> 
> 
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
> 


-- 
"People's characters are strengthened through struggle against
difficulties; they are weakened by comfort."
- Old Chinese adage
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<