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. _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
