I heard Myddrin said:
> No, I mispoke. Slots should be signals above.
Oh! I see. :)
> I would need to take a generic (or ones that inherit from say
> MydWidget) object X and discover it's signals so I can subscribe to
> them and then call the "webbrowser scripts"....
Well, I'm not really sure I grasp your problem there... Signals and
slots are pretty much a compile-time information, as per Qt's design,
and I'll venture to say that if you need to discover them at run-time
there might be a design issue in your program maybe...?
For instance, if you don't know before run-time what signals are likely
to get emitted, and thus don't know their semantics, what exactly will
you be doing with them? Connect them to slots that may end up being
incompatible...? Darn, I really feel that I must be missing something
here. Argh.
If they are hand-made Python signals, maybe the most effective approach
would be to register them at class level... I mean, what if MyWidget
had something like a signalRegistry attribute that would contain the
name of the PYSIGNALs that particular instance will want to emit? Or
better yet, have a single signal that would emit its type as an
argument, such as, say, webEvent("linkClicked", url), where
"linkClicked" would be the type of the webEvent signal...
Or something like that. I'm really having a hard time seeing the big
picture about your approach, so I could be missing something.
Good luck with the house hunting!
-- S.
_______________________________________________
PyKDE mailing list [EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
