DCOP methods in kicker.. "hidden"?

[John Firebaugh]

On Friday 05 April 2002 9:02, Kurt Granroth wrote:
> 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.

Huh? No, this is correct. The default object is "Panel", as it has always 
been. If you want to access methods of kicker, use "kicker". What's the 
problem here?

> 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.

This would not be backwards compatible with older scripts. Besides, the 
"Panel" object is more useful (provides more dcop methods) than the 
application object. Anyway, I don't see that there is any bug.

later,
John