On 11 Mrz., 23:23, Bruno Postle <[email protected]> wrote: > >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.
This does not seem to be the case, much as one would wish for it. Let me point you quite specifically to the very short readme that goes with the example files for embedding wxPython in a program using wxWidgets. This text seems to imply that there is a close relationship between the two and they are not independent: http://svn.wxwidgets.org/viewvc/wx/wxPython/trunk/samples/embedded/README.txt?view=markup please correct me if I misinterpret these data. > >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 hadn't hoped that this was part of a longer-term perspective, but I am glad to hear it, because I think that from a design viewpoint it makes a lot of sense. If we take wxPython in as an integral part, then we'll have to follow the path outlined by the embedding example anyway, so I'll look into the matter beyond the bit of diagonal reading I've done so far. Keep in mind though that I'm largely ignorant about wxWidgets and wxPython, which is one of the reasons why I am asking for opinions in the matter - I'm convinced that others in the team can judge much more competently what the implications and possibilities are, if only they contributed to the discussion. > >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. This is a good point. It makes sense to do as much of this as possible in Python, since dealing with Python objects from C++ is cumbersome. Luckily we already have a SWIG interface established and a Python module that is loaded into hugin, so the pain of moving data to and fro can be much reduced. Still the question remains of how to establish some sort of communication between a plugin and hugin. We'd need to specify a protocol. I see various possible routes: - the plugin might publish what parameters it accepts and expect to be called with them - the plugin might call back into hugin to ask for parameters - the arguments might be kept in a file to be accessed by hugin or the plugin as need arises In every case the plugin would receive the current panorama - plugins for images, masks etc. might be added later as separate entities. Some of the plugin's need for parametrization can be satisfied via the panorama. I have used information like the ROI or the 'active' state of images to modify plugin behaviour, and this fits nicely into the GUI and feels natural. It's more the type of 'on or off' flags, or the odd threshold value for an operation, a target file name, a directory - so stuff like strings and numbers - that have no obvious channel of communication. Data of these types can be easily acquired via dialog boxes, though. With the perspective of having xwPython as an integral part of hugin in the future, the parameter acquisition might be made a Python domain, but should not be left (entirely) to the plugin itself for reasons I've outlined before. Having the parameter set(s) in files has other benefits: The same settings can be used from hugin and from the plugin when it's run as a standalone script, and the parameter sets are easily shared, archived and documented - and they would be under the user's control to be handled with tools outside hugin, and allow other tools to interact with the plugins in the same way. I find these advantages quite appealing. Implementing a file-based mechanism would also be inexpensive - I'm sure I could come up with a working prototype in a coulpe of days. > Though autogenerated GUIs don't sound very appealing in usability terms. I share your reservations about auto-generated GUI content. As long as it's only a matter of a few numbers and strings - the order of magnitude of a command line - maybe the reservations could be lessened. If the parameter sets were in some sort of .ini file, the infrastructure might be a simple editor and could even be delegated to an external editor. Only when it comes to tighter intergration with plugins, where there's real communication (interactively manipulating data with visual feedback), the plugins would have to make the effort to properly integrate with hugin's GUI, and a communication protocol would have to be established. 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
