[Bf-committers] Web Plugin Status #2

[Marcelo Coraça de Freitas]

Just to let everyone know, it's working perfectly!


We still gotta sandbox python and implement scripting support.

Also, as the blenderplayer executable that's generate is 20m big each
plugin instance uses at least this ammount of memory.

A simple but yet efficient solution to this is to link the player
dynamically.

With this there is the problem of distributing a game created in
blender, but couldn't we simply link another executable and use it,
leaving the current blenderplayer executable the way it is?


regards

Em Qui, 2008-08-21 às 21:33 -0300, Marcelo Coraça de Freitas escreveu:
> Some more comments.
> 
> Em Sex, 2008-08-22 às 01:26 +0200, Enrico Fracasso escreveu:
> 
> > Problems I've found:
> > * scripting isn't so easy (IPC between processes)
> 
> It's not a real issue.
> 
> As I see, we have two different options. One is to implement a simple
> interface for IPC. This interface will have only what's really needed to
> implement scripting.
> 
> Then we can implement this interface using different API for ICP,
> depending on OS. In linux I'd sugest dbus. In windows there are other
> options, some of them already included in windows.
> 
> 
> The easier approach is to use dbus or other ICP library, such ICE or
> CORBA, in both. There is a port of dbus to windows, but that'd require
> the user to also have dbus. We can arrange that for him in a transparent
> way (embeding dbus in the plugin code - when the plugin is loaded a dbus
> server is created) but I don't know (yet) if it's really the best
> option.
> 
> I'd go for dbus in either way because it's already comming with almost
> every linux distribution and also because we can implement dbus
> scripting in our .blend files.
> 
> That'd be actually pretty cool!
> 
> Imagine having a Browser module inside your blender that actually calls
> browser's methods from JavaScrtip?
> 
> 
> Browser.alert( "the plugin whants your attention!" );
> 
> 
> cool! :D
> 
> 
> > * AFAIK it works only on unix
> 
> I'm not sure about that. From what I noticed, the only significant
> change is that the XID you receive in your SetWindow method is one that
> can be used in other proccesses. I tried to do that without XEmbed and
> it didn't work... maybe all I was missing is to create a inner window
> and use it. :D
> 
> If that's so, we could implement our own XEmbed and use it in Windows
> and MacOS. But I'm sure the Mozilla folks already thought about that. :D
> 
> That was actually my first approach in creating this plugin and then you
> came with your patch and I got excited about fixing the existing plugin.
> This was awesome because I actually know something about Ketsji and more
> about mozilla's plugins. And because I had lots of fun! :D
> 
> I think it's the best approach for all platforms, including for IE
> plugin. The ActiveX plugin itself would be only a wrapper to fork the
> procces and scripting.
> 
> > * running FPSTemplateLightMap.blend (that requires mouse and keyboard
> > input) sometimes the plugin gets "confused" about the keyboard status.
> 
> Maybe we just gotta tell mozilla to ignore all events comming from the
> plugin Window. Once I get your plugin working in here I'm gonna try some
> things in here! :D
> 
> 
> Regards;
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers