> So, the question is, whether or not there's a common bus/dispatcher in which B
> can put some information and whoever wants to be triggered by it, can?
If you have an event in B, the only thing that can handle it is B, and
if not B, then A gets a shot at it, I don't know how you plan on
getting it down to F without writing some really strange event filters
for D and each of its children, then your notion of a Nanny parent
really comes into reality, especially if your driving it down the
children of another branch. Not only would A have to handle the event
of B, it would have to know all its children and children's children.
> Adam, if I follow your suggestion, then parents must really know
> their children well in order for signalling to work.
Perhaps I'm using the wrong term when I say namespace, but what I'm
trying to say is the only thing that needs to be done in A is define
signal connections. After the signals are connected, A is out of the
picture. I think this would be the cleanest code because within the A
block (and by the way I'm assume A is a class), you have a section
where you define signals. If you need to change a signal, you know
right where to look, they're all in one place.
A is not being called and passed variable, nor is it calling children
on events. Its just simply the parent of B and D, and a good place to
stick connections. Think of signal connections as assigning variables
in the __init__ function of a class. If you have a signal emitted in
B, B does not need to know where the slots are, if any. PyQt receives
all the signals, and if there was a valid connection defined for one
of them, it executes it.
I might scan a few pages from my book an email them to ya :P
- Adam
On Fri, Sep 4, 2009 at 8:42 PM, William<abecedarian314...@yahoo.com> wrote:
> Adam and Phil, thanks for your time. I think I almost understand--but, I
> still have some confusion.
> Adam, if I follow your suggestion, then parents must really know their
> children well in order for signalling to work. Which can be the case
> sometimes. But, what I would like is:
> B generates a custom event (rather than a signal). Upon that event, C can
> take an action. I think it would be cleaner if neither B nor C required the
> mediation of A. Why do this? Suppose A has 15 distinct children that need
> to be triggered upon a signal from B? Or, suppose the heirarchy changes so
> that instead we have:
>
> A
> / \
> B D
> / \
> C E
> \
> F
> Now, if a method in C still needs to be triggered based on something that
> happens in B, then code in A has to be rewritten, along with new code added
> to D. Suppose that I create a new window F that also needs to be triggered
> by something in B?
> Whereas the essential relationship (communication wise) is still
> fundamentally between B and C.
> So, it sounds like the signal slot pattern is not the way I want to go,
> because unless I directly connect B and C then the communication pathway is
> fragile.
> But, if I generate an EVENT (sorry for the language sloppiness earlier) B,
> it will go up to A and disappear, unless I propagate it down to the leaves
> (which could be dangerous). So, the question is, whether or not there's a
> common bus/dispatcher in which B can put some information and whoever wants
> to be triggered by it, can?
>
>
> ________________________________
> From: Adam W. <awasile...@gmail.com>
> Cc: pyqt@riverbankcomputing.com
> Sent: Friday, September 4, 2009 7:53:17 PM
> Subject: Re: [PyQt] A simple question about signals and slots
>
> I keep forgetting to CC the newsgroup...
>
> Anyway, I think you're still melting the two terms together.
>
>> what I'm asking is if there's a mechanism in pyqt to emit an event in B
>
> What you want to do is connect the signal from B to slot C, and signal
> C to slot B in the namespace of A, not in the namespace of B and C.
> This is the way its done in all the examples in Summerfield's book.
> The only event you need to worry about is if there is no signal for
> move (which I don't think there is), then you need to use an event
> handler to make your own signal.
>
>> which can be detected in C....
>
> Signals are not "detected". After you connect a signal to a slot, and
> said signal is emitted, the slot immediately gets called. There is no
> listening needed.
>
> I hope that makes some sort of sense. If not I can try to rephrase it.
>
> - Adam
>
> On Fri, Sep 4, 2009 at 7:32 PM, William<abecedarian314...@yahoo.com> wrote:
>> You are correct, what I want is an event. For example, the user does an
>> action in one window (for example, moving a rectangle around) and when
>> they
>> are done, it emits an event
>> (for example,
>> self.emit(SIGNAL("rectangleMoved"),'moved')
>> )
>> , which another window can listen for and when it detects the event, can
>> act
>> (for example, update a plot). I can do this if the window is higher in
>> the
>> heirarchy for example if window A in my diagram acts upon an event
>> generated
>> by B, what I don't know is a clean way for C to receive events generated
>> by
>> A. I could directly connect things in B and C, but tight coupling seems
>> likely to lead to less maintainable code. I could let the event pass up
>> to
>> A and then have A connect down to C, but having "god" classes also seems
>> like a step away from the road to maintainability. So, what I'm asking is
>> if there's a mechanism in pyqt to emit an event in B, which can be
>> detected
>> in C....
>> Thanks,
>> William
>> ________________________________
>> From: Adam W. <awasile...@gmail.com>
>> To: William <abecedarian314...@yahoo.com>
>> Sent: Friday, September 4, 2009 7:17:35 PM
>> Subject: Re: [PyQt] A simple question about signals and slots
>>
>> If B and C are under the same namespace as A, you can connect Signals
>> with one of these:
>> s.connect(w, SIGNAL("signalSignature"), functionName)
>> s.connect(w, SIGNAL("signalSignature"), instance.methodName)
>> s.connect(w, SIGNAL("signalSignature"), instance, SLOT("slotSignature"))
>> where s and w are QObjects with s usually being self (in your example
>> the A object), and w the object whose signal you want to connect.
>>
>> But I think you're confusing the signals and slots with events and
>> event handlers.
>>
>> Paraphrasing from Mark Summerfield's book: Qt has two communication
>> mechanisms: a low-level event-handling mechanism which is similar to
>> those provided by all other GUI libraries, and a high-level mechanism
>> which Trolltech have coined "signals and slots". Every QObject
>> supports some predefined signals/slots. You can create your own
>> signals and slots too. If you need an even that is not available as a
>> signal, like capturing a keypress, then you need to use events.
>>
>> If a signal is not connected to a slot of function, thats the end of
>> the road for it. However its unhandled events that climb the parent
>> latter till it eventually hits top window and is discarded.
>>
>> Hope that helps,
>> - Adam
>>
>> On Fri, Sep 4, 2009 at 6:38 PM, William<abecedarian314...@yahoo.com>
>> wrote:
>>> Hi! I have what I hope is a simple question about signals and slots. As
>>> I
>>> understand it,
>>> if events aren't acted upon, then they propogate upwards. But suppose
>>> you
>>> have something like this:
>>> A
>>> / \
>>> B C
>>>
>>> Where B and C are children of A. How does B send a signal to C? I'd
>>> like
>>> to keep B and C decoupled
>>> (for example, B and C could be dockwidgets, or even other main windows).
>>> Is there something like wx.py.dispatcher?
>>>
>>> Thanks,
>>> William
>>>
>>> _______________________________________________
>>> PyQt mailing list p...@riverbankcomputing.com
>>> http://www.riverbankcomputing.com/mailman/listinfo/pyqt
>>>
>>
>>
>
> _______________________________________________
> PyQt mailing list PyQt@riverbankcomputing.com
> http://www.riverbankcomputing.com/mailman/listinfo/pyqt
>
>
_______________________________________________
PyQt mailing list PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
