On 20 Jun., 05:58, Yuval Levy <[email protected]> wrote: > > http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/patch5327 > > sorry I did not add them to the first beta release - was in a way too advanced > state when I saw your message.
I'm glad you did what you did. Well done. never mind the skeletons, after all they are plugins and can easily be loaded anytime. > indeed there are no provision in the CMake build system to remove old stuff. I > don't think it is critical. The set plugins that will be distributed with > Hugin will be determined once per release (so roughly 2-3 times per year), > ideally before starting a release cycle. In between releases there will be > other mechanisms to add/remove plugins. This time it is just too new so we > will do what we do and learn from the experience. So my delayed additions are the first opportunity to test the add/ remove mechanism :-) > I think dual_use.py and plugin_skeleton.py belong in a different place than > where your other plugins are stored and installed. I tagged then with 'Example', so your new mechnism would have had them in a different submenu, but I suppose you mean 'different' beyond that. > Your other plugins are productive, get installed into the system-wide plugin > directory and are accessible through the Actions menu. So I hope this will finally produce a bit more echo. Hope it's not all 'XXX doesn't work on YYY'. > These two have a different purpose. For now I put them in "plugins-dev", and > I commited them only to default. We need to think were to put them. > > In my opinion they are templates, so maybe we should install them in a > subdirectory of the user's home directory. But what will happen when a new > user account is created? Maybe it's silly to install them at all, since they are really just templates. They could be left in the source directory and they could go into the wiki as well. No need to see them from hugin's menu, since they don't do anything useful, and their (console) output can't even be seen. > Another possibility is to have a system-wide plugin-templates directory and a > function for the user to copy one into his local plugins directory and start > editing. I don't think this needs to be formalized. If the interested user/ potential plugin writer can find out where the relevant paths are (like, from the wiki), let them just take it from there. Mere users on the other hand should have a readymade infrastructure like the one you're working on. 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
