[Bf-committers] Re: listener object

[Vio]

Perhaps overkill, but I guess you could also use OpenSSL for 
inter-process (and networked)
communications (or some other socket lib without incryption, which may 
sound better here, but never
tried those before. OpenSSL is pretty straightforward, coming with its 
own socket lib, if I recall).
Alternatively, I guess you could run Blender inside a wxGLCanvas (after some
additional hacking at Blender sources, perhaps wrapping it inside a c++ 
class so it behaves nicely
in wx's c++ world :), therefore you can skip the IPC layer.
My (overblown) 2 c.
-vio




Martin DeMello wrote:

>I want it for Blender - the main purpose is to allow external programs
>to interact with a running Blender session. My problem with letting
>anything be handled by a script is that as far as I can tell, scripts
>either block the UI or remain inactive when they don't have focus.I
>need some way to wake up a script, ideally by triggering when data is
>written into a socket.
>
>As an example of what I need this for, we have an "interior
>decoration" program that we want to use in parallel with Blender, so
>that we can design a house in Blender and then use the other program
>to apply colour schemes and wallpapers to the inside. The interior
>decoration app has a fairly complex wxPython UI that I don't want to
>port over to Blender, and I want to keep both programs open at the
>same time without either of them being blocked. I can have a redraw
>scriptlink in Blender feeding information to the other app, but
>there's no current way to do the reverse. A socket listener with a
>scriptlink attached to it would do this nicely (of course, to make it
>general we'd need a way to make it an actual Blender object,
>instantiable within the UI by typing in a port number and visible when
>adding scriptlinks).
>
>martin
>
>On 5/6/05, Ton Roosendaal <ton at blender.org> wrote:
>  
>
>>Hi,
>>
>>It's also important to define whether you want it for Blender (i.e. the
>>UI) or for running games?
>>
>>I don't think an "Always scrptlink" is the way to go... we should keep
>>things fully event based in Blender's UI.
>>Would it be possible for Python to add callbacks instead? Meaning, it
>>assigns to an external program the means to insert events in the main
>>queue, which is then being handled by another script. Could also be a
>>means to plugin input devices.
>>
>>-Ton-
>>
>>
>>On 6 May, 2005, at 13:21, Martin DeMello wrote:
>>
>>    
>>
>>>On 5/6/05, Martin DeMello <martindemello at gmail.com> wrote:
>>>      
>>>
>>>>I'd like to add a "listener" object to blender, to allow a script to
>>>>be triggered by an external program writing to a socket. (Not
>>>>necessarily proposing this be added to blender proper, but it would be
>>>>very useful for my own copy.) Is this an intrinsically dangerous idea?
>>>>(i.e. could it cause instability or crashes in blender?) If not, how
>>>>would I go about doing it? (i.e., where in the code should I be
>>>>looking to add something like this?)
>>>>        
>>>>
>>>Also, antont suggested on IRC that an 'always' scriptlink that
>>>activated once every timer tick would be another nice way to
>>>accomplish this. The triggered python script could then poll the
>>>socket.
>>>      
>>>