oliver wrote:
However: There could be more than one Canvas in an app. In that case,
if Canvas_A's Bounding Box changes, the scrollbars associated with
Canvas_A need to update, but the scrollbars associated with Canvas_B
don't.
How do I handle that?
[sorry this is a bit longer than intended]
not that long, and very helpful.
Well, a message is basically an event. The topic is the event type. Therefore I would recommend making the event types (topic names)
relate to what's happening on the floatcanvas (e.g., 'floatcanvasChange.newScale', 'floatcanvasChange.newBBox', etc), and
the event data carry a reference to the originator (name, id, actual
reference, etc).
So this would mean that, for instance, all the scrollbars would
subscribe to the floatcanvasChange.newBBox event, then look at the event
data to see if it's the Canvas it cares about. That seems like I'm
putting the same code (event.data.sourcecanvas is ThisCanvas) in lots of
places -- that scrollbar is never going to want to know about what any
other Canvas is doing.
Note that this is similar to the way events are implemented in wx.
well, sort of. IN the wx case, you bind to an event from a particular
source. The way I write my code, I rarely need to check what source an
event came from, and in any case, it's not required.
There are surely cases where you could have an event type be specific
to the originator, e.g. 'floatcanvasChange.newScale.canvasA'. But
this is likely a hack: every level of the topic tree should probably
make sense as an event:.
maybe, but this seems like a purity issue.
Really subtopics ought to be more specific events, so a subtopic of newScale could be 'scaleIncreased', 'scaleDecreased' etc. So you
would have 'floatcanvas.newScale.scaleIncreased' and 'floatcanvas.newScale.scaleDecreased', and most listeners would not
care whether the change was increase or decrease so they would just
subscribe to 'floatcanvas.newScale', but some might just be
interested in increases (e.g., an overlay that shows an arrow going
up if there was an increase).
Thanks -- this does help me "get" pubsub better.
That being said, it sounds like you are really looking for an
Observer pattern rather than a publish subscribe pattern. Would it
make sense that more than one object listen to changes to your canvas
bbox?
yes.
Would it happen often?
Actually, I think it would be pretty common in that case, and many others.
Probably not. But if it's something you want to support, then
Observer is not adequate
why not? can't multiple objects Observe the same source?
So in the end maybe purity is getting in the way of JUST HAVING FUN using the stuff!! 
That's true -- I need to pick something, many approaches would work.
Robin Dunn wrote:
Since pubsub allows for hierarchical topics, you could make a canvas
identifier be part of the topic that is published, something like
this: "BoundingBoxChanged.Canvas-A" The subscribers that want to
listen for messages from all canvases can subscribe to
"BoundingBoxChanged" and those that just care about Canvas-A can use
the full topic.
and I could still put data in that identified the source, etc if I
wanted. Could I do:
"Canvas-A.BoundingBoxChanged"
somehow that feels more natural, but then I might need to able to
subscribe to : "*.BoundingBoxChanged" -- can you do that?
Bill Baxter wrote:
To me using pubsub for this sort of thing just doesn't smell right.
I see what you mean. However, this is integrated into apps that might be
using MVC-type structure, and in that case, pubsub makes sense -- I want
to be able to sent out a message from the model, and monitor such
messages with little connection between them.
why should they have to go through a 3rd party (a global one, no
less) to communicate?
I think this is my question, too: I avoid global everything else, why
use global events? If the is only one of each kind of object in app, it
makes little difference, but if there are multiple instances of things,
you then need separate them out again by hand.
what use would an object have for knowing about every bounding box in
the app? The opposite is probably more common, wanting to know
about every message from a given object.
exactly.
Pubsub really only makes sense to me in the case where you have some kind of global state.
yup -- it seems like a great way to handle application global messaging,
but there really isn't much of that. I was hoping to use the same thing
everywhere, though -- how may messaging systems do you want to use?
oliver wrote:
However, there isn't much difference between an observer pattern and
a pubsub-with-originator pattern.
exactly -- though what I want is the originator to be handles for me, without me having to check it in every method that subscribes to a message.
I ended up using a slightly modified version of Patrick Chasco's signals.py. (Self-managing, maintenance-free Signals implementation « Python recipes « ActiveState Code)
thanks for the link.
I can research this for myself, but while we're on the topic:
what is the difference between signals and regular old wx events? It seems that with wx events, Windows raise events, and you can tell other objects to watch for particular events from particular windows -- how are signals different?
I'd rather not have FloatCanvas depend on anything more, so I'm leaning toward using regular wx events for FloatCanvas changes, and maybe pubsub at the application level.
-Chris
···
On Thu, Oct 23, 2008 at 1:25 PM, Christopher Barker > <Chris.Barker@noaa.gov <mailto:Chris.Barker@noaa.gov>> wrote:
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
