On 17 Mai, 00:44, Yuval Levy <[email protected]> wrote: > Hallo Kay, > > how is the wandering in the Alps going? >
Fine, thanks. Came back with lots of material, I'm just about done stitching the panoramas and I also have other stuff to do, but I have a bit of time for hugin. > > - Mac support is still missing > IIRC this is unobtrusive, i.e. if we were to release 2011.2 right after > merging, Mac users would have the same functionality as 2011.0? That's the plan. We've set it all up so that compiling with hsi/hpi becomes an option, and we've made an effort to assure that, if compiled without hsi/hpi, the product should be precisely the same as the default branch - my last bundle brings python_scripting up to 5209; the functionality would therefore not be 2011.0 but that of the bleeding edge. Mac builders could just compile as usual (BUILD_HSI is currently OFF per default) and everything should be as before - and if the default becomes to have it ON, they can switch it off and it should behave as if hsi/hpi had never happened. Windows and Ubuntu and maybe other Linuxes should be fine to compile with hsi/hpi support, and builders could produce a build with Python support with little effort to offer binaries to early adopters who nevertheless don't compile themselves - probably this would be mainly Windows users, as compiling hugin there is a bit more work than on Linux. Mind you, as far as I'm aware none of the builders has published binaries from the python_scripting branch, which would have been just as easy, and noone has asked for them either :-( I even have hopes that hsi/hpi enabled hugin should run just fine even on machines without whatever necessary additional infrastructure it might need on a target system - in my code I've made an attempt to postpone using any hsi/hpi related resources until a plugin is actually called, and then fail gracefully if it can't be done. > > > - parameter passing to Python plugins and/or use of GUI elements by > > plugins is unresolved > > this is a bigger one. I hope that once your code is integrated in default and > released it will attract more users and more developers and eventually > somebody will feel an itch and scratch it. > It'd all be easier if we could just use the same libraries/versions on all platforms. On my Kubuntu system, I can just use wxPython from the plugin. But on Windows (I suppose because everything is statically linked there) this doesn't work. On Mac OS - no idea, since even hsi/ hpi hasn't been made to run there. With my woa script/plugin I have demonstrated how parameters can be passed platform-neutral by means of an .ini file, so this method is usable while other routes are closed, but the real issue of creating a proper plugin interface on the GUI side of things is unresolved - so far it's fire it up and wait for it to complete (or crash...), as there isn't even a way to show a plugin's console output - only on Linux you can start hugin from the command line and see the plugin's print statements, but, yet again, I've been told that on Windows this can't be done. I did hope that the GUI code that offers the choice of a python plugin and triggers it's execution would extend to supply some sort of handle to write text to (like in the case of the CPGs and the stitcher), but it didn't and I didn't touch it either. But with all these limitations, I can only say from my personal use of hsi/hpi that even just the two properly fleshed out plugins I've written so far (woa and crop_cp) are very useful to me and I use them often. I also hope having hsi/hpi in the default branch will attract more users and developers. 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
