I was tracking down why there wasn't a 'popopKMenu' (or similar) DCOP method 
in kicker since.. well, it makes a lot of sense.  In the course of doing 
so, I discovered that there *is* such a method.. it's just "hidden".

Lemme 'splain.  In kicker.h, we see a few k_dcop methods -- including one 
popupKMenu(QPoint).  The 'Kicker' class doesn't virtually inherit 
DCOPObject since it's derived from KUniqueApplication which does (and hence 
ambiguity).  So, to use DCOP within it, we have this line in the Kicker 
constructor:

dcopClient()->setDefaultObject("Panel");

So far, so good, right.  Well... browsing through the methods using kdcop or 
'dcop' we see that the Panel object has very different methods than the 
ones described in kicker.h.  That's because of 'panel.h/cpp' which has the 
normal DCOPObject("Panel") constructor call.  This effectively overwrites 
the Kicker setting.

Now this is either a bug or an attempt to use a feature that doesn't exist.  
In the latter case, we would need some sort of DCOPObject "merging".  This 
would allow multiple C++ classes to provide methods to the same "virtual" 
DCOP object.  Very interesting.  Not sure it would be possible, off hand.

If it's a bug, then the fix is trivial: change the 'setDefaultObject' to 
"Kicker" instead of "Panel" and it works.

What are the thoughts, here.  Would it be worth investigating DCOP Object 
merging?
-- 
Kurt Granroth - "KDE -- Conquer Your Desktop"
KDE Developer/Evangelist | granroth@kde.org
http://www.granroth.org  | kurt@granroth.org