On Fri 11-Mar-2011 at 07:22 -0800, kfj wrote:
On 11 Mrz., 00:56, Bruno Postle <br...@postle.net> wrote:
I think the solution is obvious: plugins that don't require input or
provide output can work as they do currently. Any other plugins
need to use wxPython to provide a GUI.
It looks obvious, but it makes the whole show much more involved.
First, the wxWidgets instance that's running in hugin has to be
relayed to the plugin. The plugin has to receive this information and
build any GUI it wants to display on hugin's wxWidgets instance.
Does it? Surely the plugin script can launch its own Window with
wxpython and doesn't need to embed in the Hugin GUI.
The next problem is that all plugins that want to acquire parameters
would have to import wxPython which isn't a standard module, but has
to be installed. So there would be another library dependency, and a
distribution distributing the Python interface would either have to
provide wxPython or ask the user to acquire it - no problem on Linux,
but maybe a hassle on other platforms.
If a library is important then we'll make it a dependency. Part of
the idea of python bindings is to investigate ultimately moving the
entire Hugin GUI to wxpython.
I also feel that forcing every plugin that merely needs a few
parameters to write it's own GUI to acquire them is counterproductive.
This can be modularised. If you are going to write code to
autogenerate GUIs for python scripts, it makes sense to do it all in
python. Though autogenerated GUIs don't sound very appealing in
usability terms.
--
Bruno
--
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
