Simple IPC: sharing wx.FileHistory across processes

wxPython Users
1

I used to launch "new window"s of my program (which is tabbed, so each
window represents a single document with many pages) by creating new
instances of the GUI frame and Show()ing it. However, after converting
a lot of my application to use PubSub, I ran into problems with a
single message being generated by a Frame being broadcast to all
Frames

I worked around this by creating each new window by re-launching the
.py script that starts my application using Subprocess.

However now I want to share a common state between instances. when one
process opens a file, the wx.FileHistory is updated; I'd like this to
be reflected across all processes. I could do it nastily by polling
the history file using a timer but that's not very nice.

Any suggestions?

3

Hi,

I used to launch "new window"s of my program (which is tabbed, so each
window represents a single document with many pages) by creating new
instances of the GUI frame and Show()ing it. However, after converting
a lot of my application to use PubSub, I ran into problems with a
single message being generated by a Frame being broadcast to all
Frames

I worked around this by creating each new window by re-launching the
.py script that starts my application using Subprocess.

However now I want to share a common state between instances. when one
process opens a file, the wx.FileHistory is updated; I'd like this to
be reflected across all processes. I could do it nastily by polling
the history file using a timer but that's not very nice.

Any suggestions?

1) Go back to using a single process with multiple windows there are
many ways to work around all of them receiving messages.

* In the message handler call back you can use 'frame.GetActive()' to
check if its the currently active window and if its not just return
without doing anything in your handler.

* Send an identifier with your message data so that when your callback
method is invoked you can check it to see if it should be ignored or
not.

2) If you want to stay with multiple processes then using sockets for
IPC will be your best cross platform choice.

How about having a hidden FileHistorySharer that uses pubsub to the other
processes.

Pubsub does not work between processes, to make it work you would
still need some form of IPC.

Cody

···

On Fri, Jun 18, 2010 at 6:58 AM, <GadgetSteve@live.co.uk> wrote:

4

Hi fellow Steve,

How about having a hidden FileHistorySharer that uses pubsub to the other
processes.
Gadget/Steve

Because each process' pubsub has no knowledge of the others. The main
reason I decided to launch new windows as new processes is because the
only other way would be to make each pubsub call aware of which Frame
it belongs to, which kills off the whole purpose of using pubsub ---
to decouple my objects.

Hi,

1) Go back to using a single process with multiple windows there are
many ways to work around all of them receiving messages.

* In the message handler call back you can use 'frame.GetActive()' to
check if its the currently active window and if its not just return
without doing anything in your handler.

* Send an identifier with your message data so that when your callback
method is invoked you can check it to see if it should be ignored or
not.

2) If you want to stay with multiple processes then using sockets for
IPC will be your best cross platform choice.

How about having a hidden FileHistorySharer that uses pubsub to the other
processes.

Pubsub does not work between processes, to make it work you would
still need some form of IPC.

But some of my Model data objects call pub.sendMessage. They would
have to provide a reference to the frame that they "belong" to, which
they have no knowledge of. I did discuss this issue (multiple Frames
all receiving the same published messages) with PubSub's creator,
Oliver, but Google Groups is sending me in an infinite redirect loop
when trying to access pubsub's homepage.

Or, it means changing *every* listener function to check whether its
frame is the active Frame. My main Frame contains a couple of custom
panels (some of which has its own custom panels) -- it might get
rather nested to test for the active frame in each of these methods.

Looks like there's no simple way :frowning:
I'll take a look at sockets, never really done much low-level coding.

···

On 18 June 2010 12:58, <GadgetSteve@live.co.uk> wrote:
On 18 June 2010 13:23, Cody Precord <codyprecord@gmail.com> wrote:

On Fri, Jun 18, 2010 at 6:58 AM, <GadgetSteve@live.co.uk> wrote:

6

Hi fellow Steve,

How about having a hidden FileHistorySharer that uses pubsub to the other
processes.
Gadget/Steve

Because each process' pubsub has no knowledge of the others. The main
reason I decided to launch new windows as new processes is because the
only other way would be to make each pubsub call aware of which Frame
it belongs to, which kills off the whole purpose of using pubsub ---
to decouple my objects.

You could dynamically create the pubsub topic names to include some frame ID, then those messages would only be published to those handlers that used that ID. For example, instead of something like "foo-message" you use "foo-message.frame1", "foo-message.frame2" etc. Then if something wants to subscribe to all of those messages without caring about which frame it is, they can subscribe using just "foo-message" and those that do care can use the full name.

But some of my Model data objects call pub.sendMessage. They would
have to provide a reference to the frame that they "belong" to, which
they have no knowledge of.

In that case you could do the same type of thing by using unique object identifiers in your model, and make them be part of the pubsub topic.

Or if you don't like making the topic names hierarchical and data specific like that then you can make all the frames (or other views) aware of the model IDs that they are responsible for and just pass that model ID along with the messages. Then the subscribed handlers can check the model ID coming in with the message and ignore the message if it is not the ID that this view is editing/viewing.

···

On 6/18/10 5:36 AM, Steven Sproat wrote:

On 18 June 2010 12:58,<GadgetSteve@live.co.uk> wrote:

--
Robin Dunn
Software Craftsman

7

No need for polling. The simplest is to update the file history list just before the list gets shown: when the user open the File menu, open the History dialog or whatever your case may be. As another poster indicated, if your multi-window app is only ever used by one person at a time, there is no risk for multiple windows writing to the file history file simultaneously.

Oliver

···

On Fri, Jun 18, 2010 at 5:20 AM, Steven Sproat sproaty@gmail.com wrote:

I used to launch "new window"s of my program (which is tabbed, so each

window represents a single document with many pages) by creating new

instances of the GUI frame and Show()ing it. However, after converting

a lot of my application to use PubSub, I ran into problems with a

single message being generated by a Frame being broadcast to all

Frames

I worked around this by creating each new window by re-launching the

.py script that starts my application using Subprocess.

However now I want to share a common state between instances. when one

process opens a file, the wx.FileHistory is updated; I’d like this to

be reflected across all processes. I could do it nastily by polling

the history file using a timer but that’s not very nice.

Any suggestions?

–

To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com

or visit http://groups.google.com/group/wxPython-users?hl=en