Kicker child panels' PanelAppletOpMenu

[Aaron J. Seigo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 17 October 2002 04:04, Scott Wheeler wrote:
> Here's the one that I like:
>
> Create a base class that both Panel and ChildPanelExtension both use that

well, ChildPanelExtension subclasses KPanelExtension in kdelibs, as do all the 
other extensions. i don't think you'll get Panel and ChildPanelExtension both 
subclassing from the same item without breaking either the main panel or the 
other extensions. unless, of course you start treating the child panel 
specially seperate from the other extensions.

all ugly and Bad.

if you want to get this invasive, you may as well go whole hog: get rid of the 
main panel altogether, merge the panel and extension managers, move all the 
loading/registration of extensions into the Kicker class and use a childpanel 
for the main panel instead. this removes the "special case" scenario. there 
is still the challenge of getting the applet container talking to the 
extension it is in, but that isn't nearly as a big a problem once you have 
gotten rid of the hardcoded panel class.

this is really 3.2 material, however.

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

"Everything should be made as simple as possible, but not simpler"
    - Albert Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9r1141rcusafx20MRAqzSAJ9pYiJ9v6anAPnBA1jlKZGagCe7UQCgqok7
MJYvrDh5C8Jkk3277x9CEzY=
=6kak
-----END PGP SIGNATURE-----