On Thursday 23 August 2001 11:46, Michael Goffioul wrote:
> Matthias Elter wrote:
> > On Thursday 23 August 2001 10:55, Michael Goffioul wrote:
> > > > > Now, I'll think I'll wait for some reaction from a real kicker
> > > > > maintainer to know what to do with the code (throw it, commit it or
> > > > > adapt it before commiting).
> > > >
> > > > Nice work. Commit it.
> > >
> > > OK, here's my proposal:
> > >
> > > A good thing would then be to move the 2 other extensions (kpanelapplet
> > > and kpanelextension) from kdeui to this libkicker library. And to keep
> > > consistency PanelMenu should be renamed to KPanelMenu, the class in
> > > kdeui must then be renamed to something different (KPanelDCOPMenu,
> > > KPanelExtMenu, KPanelAppMenu, ...). But I won't do that at first time,
> > > I'll only put my PanelMenu in libkicker, keeping the name unchanged.
> >
> > Nobody _ever_ used the KPanelMenu class in kdeui. You can simply replace
> > it.
>
> That's what I thought also. But I think we should keep it (you never know)
> and rename it. Maybe it can also be integrated in libkicker?

AFAIR the DCOP menus are no longer part of kicker, so removing the client 
class is a good idea.

> Should I do the whole stuff now, before commiting, or going step by step?
> Complete changes include:
> - moving KPanelApplet and KPanelExtension to libkicker
> - moving KPanelMenu (from kdeui) to libkicker and renaming it to
> KPanelAppMenu (because it's related to a running application)
>
> Is this OK? (can do the whole stuff tomorrow, as BIC changes are to be made
> on fridays).

We should keep the KPanel* classes in kdeui to maintain source compatibility. 
Existing applets outside of KDE cvs do not link against libkicker.

Greetings,
Matthias