On 27 Feb., 00:05, Bruno Postle <br...@postle.net> wrote: > Sorry, I haven't had time to look into this.
You are missing out. I had hoped that you'd be more interested in my project, being of the scripting kind yourself. Let me point out that SWIG, which I use to generate the Python interface, can generate interfaces for other languages as well (something like two dozen), among them perl. I had suspected you'd start playing with the SWIG code to let it make a perl interface - I made a feeble attempt to do so, but knowing nothing of perl I gave up at the first hurdle... > I think initially the > python interface would be useful even if it presents as a menu of > functions that don't take any parameters apart from the currently active panorama, that is. But it's a severe limitation. For example now I'm working on a plugin that works on image pairs. I either have to hardcode the image numbers into the script, write GUI code myself to let a window pop up to ask for them, or require the user to make the desired images 'active' and 'deactivate' the others. This is not nice. The clean way would be for the user to highlight the images in question in the image tab and then call the plugin from the contect menu. > i.e. it can be merged > more-or-less in the state it is in. I think so as well. Just today I thought about how I could modify it so that all dependencies to the hsi python module are removed from hugin itself. This would mean a totally neutral python interface, and the conversion of C++ pointers into python objects would be done by code outside hugin. This change of design would mean that - other people would be free to write their own python modules rather than having to rely on hsi - hugin would merely be extended by a dependency on python (maybe not even a run-time dependency, the way I think it can be done is only require python if the plugin interface is actually used) and not be dependent on hsi I feel that this might make the introduction into the mainstream even less of a concern. I'll look into the matter and report back, with a bit of luck the changes should be small (couple of days) > >Then there is an issue I'd like to have considered by the group: the > >hsi python module could be considered a library, since it can do hugin- > >ish stuff outside hugin, probably linking in a few shared libraries, > >but if it was linked statically, not even that. A lot of hugin's code > >is GPLed. Is there a problem with that? > > Please use 'GPL version 2 or later', this makes it easier to ship > with Hugin. Are you concerned about how this effects the license of > potential 3rd party plugins? What I mean is this: hsi, the python module that is generated by SWIG and contains the hugin functionality, can be imported by any python script that cares to do so. It's like loading a shared library from an executable program, in fact, technically, this is just what happens. But the code that finds it way into the script via this route is GPLed. Therefore, if I understand things rightly, the module would have to make itself known as GPL software, prohibit closed-source users to import it and point a way to it's sources, plus whatever other requirements the GPL imposes. This is why libraries are often put under LGPL or a similar less restrictive license, so that anyone can use them with their code, even if they're commercial. I don't want to infringe upon the rights of any of the hugin contributors by opening up a route of access to their code that goes against their licensing of it. This is why I want the issue discussed. I think the ideal solution would be if the developers who have contributed code that is exposed via hsi might modify their licensing to allow use of their code via hsi under a less restrictive license, but if this is not feasible I want to be certain that all requirements are met to satisfy the contributors' current licensing under GPL. > >And one more thing: I'd like to see a discussion about a perspective > >for merging the python_scripting branch back into the mainstream. > >Thomas and I have made a good effort to parametrize everything in > >cmake and make the scripting capability a compile-time option. The > >intersections with other code are minimal and well #ifdeffed. > > I would like to see the current Hugin 'trunk' move to a 2011.0.0 > release branch as soon as possible. So the python interface should > then be merged so that it goes into the next release after that. Sadly, the Python scripting project is slightly stalled currently. This is due to the Mac side of things - Harry couldn't get it to run, went away on a holiday and noone else took over. The Linux and Windows side seems fine and ready to be merged. Harry said to go ahead, though, never mind the Mac problems. So I hope that maybe we'll soon have hpi in 'bleeding edge' mainstream and that it can maybe be part of the next release. 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
