On 21 Mrz., 00:40, Bruno Postle <[email protected]> wrote:
>
> >- 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'm not sure that the Windows Hugin package absolutely has to be
> statically linked, this may just be the most convenient way to do it
> up until now.

When I started looking into hugin's code last autumn, I was still
running a Windows system. I was doing my C/C++ programming using msys/
minGW, and I managed to compile libpano with it, but failed with
hugin, because I tried to follow the linl-statically-on-Windows
paradigm. It was frustrating. All the libraries were there to be
dynamically linked, I had a gnu compiler, but I got stuck trying to
compile stuff like openEXR on minGW. Eventually I gave up on it and
migrated to Linux for good, to start with a big sigh of relief and no
desire ever to go back. But if someone with more knowledge of hugin's
code base and of cmake came and ported hugin to minGW using the same
dynamic linking as on Linux, we might gain immensely:

- We'd be using the same compiler on all platforms
- We'd be rid of MS's closed-source compiler with all it's
idiosyncracies
- We could use the readily available DLLs on Windows

Since I've not followed it through when still on windows, I may not
see the full picture, but there is promise along these lines. But I am
not doing it.

> >On the positive side, the Python scripting interface (hsi) seems to be
> >running just fine on Linux and Windows. This means that Python
> >programs can use pretty much all of hugin's backend functionality.
> >I've writtten a very long involved Python program doing just that.
> >It's great. And it can be called from hugin, it's only the GUI sharing
> >that isn't yet happening.
>
> As I understand, currently plugins can only be run without any
> user configuration, since adding a GUI is appearing problematic.

I'm trying to implement a mechanism using configuration files for
platforms where using wxPython is not an option. This looks feasible
and may be a bridge technology.

> An intermediate solution would be to accept that, for the time
> being there isn't going to be any GUI configuration and add the
> plugins to Hugin in multiple places.

> e.g. plugins that operate on the project as a whole can go in the
> the main menu.  Plugins that operate on a selection of photos
> can go in a pull-down menu on the Images tab, etc...

I think we aren't clear yet how to integrate the plugins into the GUI.
So far, you can choose a Python file to be executed as a plugin - the
individual plugins aren't listed as menu items. If tighter integration
is desired, so that eventually the distinction of calling a C++
routine and calling a Python plugin becomes invisible, other
mechanisms than the current 'call a Python script' have to be
established. I have worked with what I was offered as best as I could.
I don't really feel inclined to learn wxWidgets on top of everything
else to write code for the hugin side of things. I hope to find people
from the hugin developer team to come up with propositions and
prototypes (that's why this thread is called 'developers liaise') -
and I'm happy to play and modify the Python interface to be accessed
in different ways. What I don't want to do is design and write the GUI
side of the plugin interface. I'm more the backend type.

> Would this restrict the functionality too much?

I always thought that having different types of plugins, called from
different contexts, would be a good idea, and I thought that a context
menu call would be the most natural way of achieving this. On the
Python side, the call signature can be analyzed to determine what
parameters have been passed and make sure that the plugin in question
is compatible with the parameters at hand. I hope to see experimental
branches forking off demonstrating various ways of dealing with the
issue, so we can play and learn what is best.

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

Reply via email to