[PyKDE] Notifying self on all emits _OR_ overriding default emit behavior

[Sundance]

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

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:
http://developer.kde.org/documentation/library/3.0-api/classref/kparts/
KParts__BrowserExtension.html

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.
Wicked.
6,000 years of civilization, and then we invent the NDA. Go us.

> <widget>
> 	<property name="height" value="10" />
> 	<mouseover>
> <![CDATA[
> # python code goes here
> ]]>
> 	</mouseover
> </widget>

Note that this would be a slot, not a signal. A signal doesn't contain 
code.

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

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

Yep.

> Thanks, talking this out solved the problem, it was a design issue
> after all.

It often is.

-- S.