Hi Kay, On March 20, 2011 05:40:02 am kfj wrote: > you're not the only one busier with something > else. So, just to remind every one, nothing much is happening with the > Python interface.
I am one of those guilty with not participating in your effort, although I find it important and laudable. The time I am putting into Hugin now goes toward the 2011.0 release, and this is, in a sense, a contribution to the Python interface, because once 2011.0 is out the door we can integrate the Python interface into the main codeline and give it the extra attention it deserves. I would suggest that you sign up as a Google Summer of Code mentor when Habi launches the call for mentors; and I hope we can find a student to work on the Python interface with your guidance. > - still nothing at all on Mac OS. Would a Mac programmer please come > forward and help compile the Python module? My understanding is that the Python module must be activated at build time. As long as it is not activated, the python_scripting branch builds and works on Mac OSX too, just without the Python functionality. Is this correct? If yes, this should not hinder you or anybody else from making progress on Python scripting and integrating it in the main codeline. Sooner or later, somebody on the Mac OSX side of things will feel an itch to scratch. You can ignore it for now. > - 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. I have skimmed over the discussion and I like both suggested solutions. I am afraid that for now we can't count on the combination of wxPython and Python 3.0. http://groups.google.com/group/wxpython-users/t/59d9f9b5e3adf513 http://docs.python.org/dev/howto/cporting.html Python 2.7 will be supported for years to come, but if I recalled correctly from my skimming of all the back and forth, there was an issue with using Python 2.7? I like both ideas expressed: the MathMap-like interface, simple, pragmatic, unified; and the completeness of a wxPython solution. Both have advantages and disadvantages, and both raise questions. MathMap-like: some plug-in may need additional user-input / interaction. How would that happen? wxPython linked from the plugin, external and oblivious to Hugin? What I like about wxPython is that eventually we can move more and more parts of the Hugin interface from C++ to Python, making it more accessible for users to customize/improve/contribute. > On the positive side, the Python scripting interface (hsi) seems to be > running just fine on Linux and Windows. I am sorry I have not had time to test it but it is positive news indeed. > it's only the GUI sharing that isn't yet happening. how critical is GUI sharing? > 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? Sure it would. Once the 2011.0 release is out of the door and the python_scripting branch is merged, the Hugin PPA's nightly will offer binaries for download, at least for Ubuntu. Currently the Hugin PPA nightlies are broken (for another, trivial but time consuming reason); and a change is discussed that would provide nightlies not only of the main codeline, but also of all development codelines. Too late for python_scripting, but will definitely help monitoring progress and advanced testing for the GSoC2011 branches. At least on Ubuntu (and it would probably be only one series, not all supported series). Sorry if we are not following you as fast as you would like. > 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. Agree. Let's integrate the Python interface as-is asap after 2011.0 and look at the nice-to-have extras such as the ability to call Python plugins from Hugin, and GUI access from Python, later on. > 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. Yes, the faster we add this to the main release line, the sooner we'll find and clean rough edges and attract additional contributors. > On Linux, getting the module is reasonably > straightforward, but requires compilation of a specific hugin branch. The specific branch requirement will fall very soon after 2011.0 is out the door. > 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. Python is Free software so there is no obstacle to distribute Python with the Hugin installer. I would not bother too much about detecting, making exceptions, or other things to make Python "optional". The switch is in the CMake build, and when built with BUILD_HSI = ON Python becomes a mandated dependency of Hugin. This leaves builders and distributors on platforms without package manager (Windows and OSX) two choices: Build a version of Hugin with HSI and add Python to the installer/bundle; or build a version of Hugin without HSI and don't add Python to the mix. Thank you for your contribution and your patience, Kay! Yuv
signature.asc
Description: This is a digitally signed message part.
