Hi all! The groundworks for a plugin interface for hugin is laid. The interface at the software level is deliberately unstructured - meaning that any number of hugin objects of arbitrary types can be passed to a plugin. But the GUI currently doesn't make use of this power; it merely allows to 'call a Python script' and passes just a single parameter - the currently active panorama. While this can already be useful, it is obviously very limited. Let me give you an example:
I've written a plugin that removes all control points outside the current ROI. The plugin can be run from the command line, where I offer a simple switch to reverse the behaviour and instead remove all CPs inside the current ROI. This switch is obviously missing from the current GUI interface, where you can only choose to 'run a Python script'. So I work around it by having the Python script (the plugin) open in an editor and changing the default, depending on what I want to do. Not so nice. At the same time, the plugin produces statistical information: how many CPs it has found, how many are removed, and how many are left. When the plugin is run standalone from the command line, this information is printed to the console. When it's run from inside hugin, the console output is invisible, and the only effect is the deletion of the CPs, which can quite easily go unnoticed until much later. Not nice either. Now you could say, why don't you save two versions of the script under different names. Might be done. But consider that the next plugin I want to launch already has about half a dozen parameters. The arithmetics clearly tell the approach to 'save each version under it's own name' is not feasible. Just as the CPGs and the other collateral software can be parametrized and can feed back this needs to be possible for plugins as well. The question is how to deal with these issues. I suspect a mechanism similar to the one used for CPGs might be usable: passing a command line which has %-placeholders for specific things (the panorama, an image etc.) and fixed parameters depending on the intended use. So for the case outlined above, you might have an entry for each version, if you use both. But the solution isn't really satisfactory, just as I always found the CPG interface awkward. Allowing the plugin to somehow interact with the user would be much nicer. In fact, plugins make very good glue code. a plugin might pop open a window offering visual manipulation of, say, the parameters to a CPG and proceed to call the CPG, which would be much prettier than the current state of having to navigate all the way into the preferences dialog and edit or newly create the desired parameter set - and much more flexible at the same time, since I can just edit the plugin's code if the CPG changes and don't need to compile and link. If you're still with me here, my bit of brainstorming may have inspired you to come up with a good solution to the problem. I'd like to see the matter discussed before trying to go ahead and 'just do something'. Also, I haven't really penetrated hugin's GUI (I've been too busy doing back end stuff), so I'm not sure what protocols and techniques would be needed to seemlessly integrate the plugins communication with hugin's GUI. 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
