On 20 Mrz., 18:56, Yuval Levy <[email protected]> wrote:
> 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. I understand that this would be helpful, but I will not be available so much during the summer. This is why I called it my 'winter of code'. In summer I spend more time in the italian Alps trekking and doing photography. I have also pushed aside all other interests during this winter in favour of the hugin Python interface, and I definitely want to do some GIS programming during the summer. I have made an effort to liberally comment everything and hope my code is clear and concise, so I hope that my absence won't be a problem. When the gsoc proposals were discussed, Thomas commented that as far as the Python interface is concerned we have the basic functionality up and running - as I understood it he felt it wasn't necessary to propose it for gsoc, because it's there already. I haven't looked into the proposals later on to see what actually was proposed in the end. The question is, do we want to put much more effort in? I've tried to get it all done with minimal overhead - mostly wrapped the headers instead of hand-writing the interface, kept the call interface so general that it can handle any parameter constellation - and in retrospect I think this course of action was wise. It can stay as it is without much modification (the parameter passing and GUI access remaining an open issue but not a show-stopper) until someone finds a very good reason to change it fundamentally. > 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? The way I've set it up, the python_scripting branch should compile to exactly the same result if the BUILD_HSI switch is off at compile- time. I've last merged default into python_scripting a couple of weeks ago and I can do it again before it's merged into default so the latter merge becomes trivial. On top of that I've hopes that it may be possible to compile with BUILD_HSI=ON and use the resulting binary even if Python isn't available; the interface works so that the first actual call to run a plugin activates the interface, so if the interface has dangling references, they would do no harm - if unused, noone would notice, and if used, the activation should fail gracefully. But I'm not sure. In a statically linked system, having dangling references may not be possible. That's why I asked for a Windows binary to be put online, so that Roger, who has offered to do so, can try what happens on a system without Python. > If yes, this should not hinder you or anybody else from making progress on > Python scripting and integrating it in the main codeline. I've made an effort to make it as unobtrusive as possible. I'm confident noone will notice it's there unless they want to use it, but I can only test on Linux. > Sooner or later, somebody on the Mac OSX side of things will feel an itch to > scratch. You can ignore it for now. Indeed. I hope that once plugins and standalone hsi aplications start appearing the Mac OS faction will become envious and start scratching the itch. > > - 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. Even though there are some systems where Python 3.X is already the standard, I think most systems still use 2.X. I'd say the main reason is the incompatible change to the module import mechanism which makes it impossible for 3.X code to import 2.X modules. There is a huge body of code out there which runs on 2.X, and I suppose quite a few of these modules have been made by people just like us who just about managed to invest the resources to do it and have moved on since - to go 3.X, someone has to touch the code again and get it to work on 3.X, and the older the code and the more involved, the more difficulties arise. This extends to very central and highly useful modules. On the other hand, parallel installations aren't usually a problem, so if need be, systems with 3.X might install 2.X as well and use that to run plugins with GUI. The interface itself, thanks to Thomas' effort, is 3.X able. > 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. Bruno pointed out that it would be wise to do as much of the GUI stuff as possible in Python, and I agree. If there is a problem using wxPython, maybe we could think of an object written in C++ that uses wxWidgets C++ code to offer the parameter acquisition. We have a swig interface already, so if we'd pass that object to the Python side, it could use it to do the needful. Just an idea. But ultimately, wxWidgets would be the best. Bruno has assured me that it might be made part of the packet, and for simple tasks even inexperienced users could get away with a bit of copying and pasting from a good example. The availability issue remains. > 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? The design would be, I suppose, quite expensive. If someone came forth willing to do it, it might beome a cherished asset, but it would require a good deal of effort. > 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. I agree. My dream scenario, actually. Make hugin a Python application with all the power that comes from an interpreted language, and have a fast C++ backend for number-crunching. And Bruno has emitted signals that I might not be the only one dreaming along these lines. > how critical is GUI sharing? GUI sharing in itself is actually not critical. But what I feel is critical is parametrization of the plugins. There are different approaches possible, and they aren't mutually exclusive, but a standard way would be best, and this should be via a GUI. Where that is impossible, configuration files can be used. > > 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). I was hoping for the PPAs. I have a suspicion that Linux users might be more interested in hsi/hpi than others anyway, since Python is already on their systems and they may be more script-inclined than others. > Sorry if we are not following you as fast as you would like. I was just trying to get everything afloat as best as I can before I become less available during the summer. > > 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. Seems like a good plan. When is after 2011.0? I'll be here for another two weeks or so, after that on and off. I'll try to put everything in order before I'm off - go over the documentation, publish my large Python program, merge default in once more. > The specific branch requirement will fall very soon after 2011.0 is out the > door. Great. > 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. You have to detect what's there. On Linux systems, there is one version that's part of the system, and you can't just simply install something else unless you know what you're doing and don't produce conflicts with the system status quo. I lack the experience to tell what would need to be done in which environment, and what is least obtrusive and most straightforward. I hope my code is defensive enough to play well with whatever method is chosen utimately. 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
