On 9 Mrz., 19:37, Bruno Postle <[email protected]> wrote: > On Tue 08-Mar-2011 at 01:41 -0800, kfj wrote:
> > For me, the Python interface works, and I've hardly modified it in > > the last weeks even though I'm using it on a daily basis. > > I really would like to use it and see what I can do, but I'm aware > that there are some deadlines approaching and that these have > priority. I suspect that most 'development time' at the moment is > working towards getting the 2011.0.0 release out. Well, Bruno, I suppose you're not the only one busier with something else. So, just to remind every one, nothing much is happening with the Python interface. Let me give you a brief status update on the current issues: - still nothing at all on Mac OS. Would a Mac programmer please come forward and help compile the Python module? - another issue that's been discussed but not solved is how Python plugins could be given GUI access. Using wxPython from plugins works on Linux with Python <= 2.7 but not Python 3.X, and not at all on Windows, quite probably because wxWidgets is linked statically there. On the positive side, the Python scripting interface (hsi) seems to be running just fine on Linux and Windows. This means that Python programs can use pretty much all of hugin's backend functionality. I've writtten a very long involved Python program doing just that. It's great. And it can be called from hugin, it's only the GUI sharing that isn't yet happening. The GUI issue affects the hugin plugin interface (hpi). Nothing is wrong with the hugin scripting interface (hsi) apart from the missing Mac port. I wonder if it might not help progress on the Python front if binaries of the Python module were offered for download for Linux and Windows? I find the Python interface immensely useful, as it allows me to access most of hugin's functionality from Python. Being able to call Python plugins from hugin is a nice-to-have extra and mostly works, and GUI access from Python is another nice-to-have thing, but waiting for it to materialize before distributing the Python module seems silly. If interested parties could get easy access to the Python module, the body of hsi code might grow, at the same time uncovering issues that have not surfaced yet. On Linux, getting the module is reasonably straightforward, but requires compilation of a specific hugin branch. On Windows, this is probably more involved. Offering the binaries would lower the threshold. Is this feasible? Would it be necessary to offer a complete 'hugin with Python capability' bundle or would it be enough to merge the python_scripting branch into default and make BUILD_HSI = ON the default, so hugin and collateral software would be the same throughout - would the resulting binaries run on systems without Python? I've written hpi (the hugin plugin interface) so that embedded Python is only initialized if the interface is used. I'm not sure what happens on a system without Python, or with the wrong version, but when I wrote it I hoped that the code would simply produce an error if Python wasn't available, returning an error code. Has anyone tried? This would be easy on Windows, where Python is optional. The test would be to run hugin built from the python_scripting branch with Python uninstalled and see what happens when calling a plugin. If it merely says something like 'script return -X' this would mean it' safe. Maybe the presence of Python could be detected, and if it's missing the plugin call could be grayed out? I'd welcome your comments. Kay Kay -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx
