[PyKDE] Notifying self on all emits _OR_ overriding default emit behavior
sundance at ierne.eu.org
Tue Oct 7 14:58:01 BST 2003
I heard Myddrin said:
> Back to my original example. I webbrowser does _NOT_ know the events
> (or signals or whatever) of every component that might get loaded
> into it. Yet I can use Flash, Real Player, etc in both IE and
> Netscape and receive events without the ie and netscape developers
> having a priori knowledge of every component that might be loaded
> inside it.
Uh. As far as I know, (Netscape-style) plug-ins do not tell much at all
to the browser -- they have their own event loop and handle their
display themselves, with the browser none the wiser, except for a few
predefined hooks such as "go to that URL". ActiveXs are slightly
different, they work by exporting an interface over COM+, but unless
I'm mistaken that interface has to derive from a 'known' interface for
IE plug-ins -- so there's no 'new function' discovery. (Been long since
I had to bang my head against them ActiveX though, so don't quote me on
You may want to peek at the KParts documentation, since it's readily
available, topical for this list, *and* not bad at all. :)
Here for the KPart Browser Extension:
You'll note that the browser checks for the presence of *known* slots to
which it can connect its signals. An unknown slot won't be used.
Which brings us back to the previously mentionned design issue. When
you're loading some component into some framework, the framework must
somehow know how to interoperate with the component. Typically the
framework will call an initialization method on the component -- which
implies that a method with that name MUST exist in the component -- and
the component will return a list of capabilities, which can be as
extensive as you'll want (for example the ability to register a menu
entry in the framework...), but can't exceed the capabilities of the
framework. Or the component can list its abilities in some attribute,
in which case that attribute MUST exist in the component, so that the
framework can go peek at it, etc.
> Another example of what one might do (and I'm restricted here by an
> NDA and can't tell you exactly what I'm planning on doing with it)
So you need help on something, but can't tell us what.
6,000 years of civilization, and then we invent the NDA. Go us.
> <property name="height" value="10" />
> # python code goes here
Note that this would be a slot, not a signal. A signal doesn't contain
> But I think in this case, I just answered my own question. I don't
> need connect to all signals, just the ones that are in the file.....
In this case, the widget doesn't need the parent app in any way though,
it can check for the mouse's position relatively to itself on its own.
But I see what you're trying to do. You'll note that if 'mouseover' is
a capability (slot) that the widget advertises, then the parent
application will NEED to know what that 'mouseover' thing is in the
first place, and that it should be triggered when the mouse is over the
widget, or it won't be able to do anything with it on its own.
Assuming you're working on, say, something like a tool to automatically
make wizards based on an XML description file, for example, then you
can simply create a dictionary attribute called 'mySlots' on the widget
object when you create it from that .ui excerpt, and the parent app
could simply check the content of this dictionary to know what
capabilities the widget has to offer, and what methods are to be called
to trigger each capability. Look at that KPart web page again, that's
actually how it works.
> Heck, since python can add methods at runtime, I could add them to
> the object and do a straight connection rather than having an
> observer class like I'd originally thought......
> Thanks, talking this out solved the problem, it was a design issue
> after all.
It often is.
More information about the PyQt