Hi Dusty,
I think I need to develop some sort of MVC framework in which multiple
windows are showing the same data in different widgets, possibly in
different ways. For example, I might have two listboxes showing the
same data but scrolled to different positions. What sort of support
does wxPython have for this sort of sharing of data?
I don't think wx or wxPython directly supports this sort of thing.
What I'd most likely do is create the two listboxes and load the data
into each separately, then whenever the data changes, have it send a
callback to each control to update it, probably using some sort of
'data.addListener' approach. Then when that callback is fired, reload
and refresh each view that receives the callback. (Probably storing
the scroll position and selection state and restoring them as well.)
Indeed, that's what I was planning on doing. The problem is, each
plugin will have to take care of this itself, and I don't like to put
this onus on the plugin developers.
Well, you could probably get around that by devising a special method like UpdateViewData that is fired on initial load and also when the data changes. This way they don't have to code two methods - one to load the data, and one to 'refresh' it. You could have the listener automatically bind itself to the plugin depending on how you pass the data around, etc. It might require some refactoring of existing code, but I'm pretty sure it could be doen.
Actually, I think I'll go into more detail, as someone may be able to
suggest a better solution to my problem than the one I'm designing.
I'm trying to design a multi-window docking manager for my text
editor, Pallavi (http://pallavi.sf.net/), which uses AUIManager for
docking and floating plugin windows. Multiple top-level frames is
going to be quite simple, but I'm not certain how to handle docking
windows for plugins. My plan is to have plugins that provide docking
windows to have to have a "createPanel" method that creates a separate
docking window for each top level frame. That way, each top-level
window can have a different set of docking windows visible, according
to user preference. Clearly, some plugins will want to have different
data for each view (ie: find and replace), while others will want to
have the same data in each one. For example, a recent documents list
would probably be the same in every window. This latter case is the
one I'm trying to support with some sort of MVC architecture.
An alternative would be to support plugins having only one docking
window for all views and it can be docked into any one of the multiple
open views. This may (or may not!) make more sense from a useability
standpoint, but I'm not certain if its even possible using current
versions of wx.aui.
Well, there's one way to find out. 
It shouldn't be too hard to
test, IMHO. Actually, for your case, it might make your life a lot
easier if this does work as expected.
An easier life would be lovely. I did try it, but it doesn't seem
to work out of the box; floating windows are very clearly attached to
the frame they were initially docked to. I see no documentation
indicating this is possible.
Oh, I thought you meant you wanted several AUIManagers to share one control, i.e. have the plugin create an wxAUIPaneInfo at startup, and share it amongst all the AUI windows in your app. That way, you don't create two controls for two top level windows, etc.
But if you mean you want the plugin's view to float and/or be "app-wide" rather than document-centric (i.e. not bound to a particular document/TLW), I don't think AUI is going to help you there. You'll need to create those views as wxMiniFrame's or similar if you want to do that, although you lose the ability to easily 'dock' them then. But AUI is really designed around the Win/Linux principle of "one window per app", and so I don't think it was really designed for the use case of having multiple top level windows, each with their own AUI manager and various views that are not attached to a particular TLW. (Which to me also means it's not really designed around the common Mac use case, but I digress. 
I think that if they wanted to allow for this, they'd have bound the AUIManager to the wxApp object, rather than to a wxTLW.
To be honest, I've been hoping to put together a framework that allows the user to choose between using AUI for the entire interface, or not using it and having 'utility views' (plugins in your terminology, I suspect) appear as mini frames. It would do this by keeping track of the documents and utility views in the application, and spawning an AUI pane, mini frame, etc. based on the user's choice. It wouldn't be too hard to do, it's just that I have about ten other things I need to do first.
Perhaps it would be possible to listen for drag events and if a
PaneInfo handled pane is dropped on a different Window, reparent the
frame to that AUIManager. I have a feeling this would be buggy though.
It seems it would be that way to me, too. :-/
Regards,
Kevin
···
On Sep 27, 2007, at 8:12 PM, Dusty Phillips wrote:
Dusty
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org