[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: DCOP methods in kicker.. "hidden"?
From: Kurt Granroth <granroth () kde ! org>
Date: 2002-04-05 17:02:06
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic