Hi Rogier, On December 30, 2010 05:12:26 am Rogier Wolff wrote: > It seems we're pretty much fully in disagreement on this issue...
... and it is not a problem at all for us to keep working together and collaborating on Hugin. The development process and repository structure I have put in place enable just that: We have 'default' that is the integration codeline. In there go feature that are declared mature according to the maturity criteria set out in [0]. There is the only point where we need to reach consensus. From there out we branch into our different interests. People who want to add new features branch out a development codeline. People who want to polish an existing set of features work on the a release codeline until they declare it final. You can even branch out your own personal flavor - other projects like VLC do this too. Once the branch is your, you can do whatever you want with it. If others will like it, it will be added to the integration queue and go into mainstream. > Hugin is a user-friendly open-source solution allowing stitching of > multiple photo images into a single output image. From stitching three > six-megapixel images together into a wide-FOV panorama to > multi-gigapixel HDR panos. Nothing prevents you from branching out any time in the project history and transform Hugin into what you believe fits the above vision. > Because of a good software engineering design, hugin allows several > steps of the workflow to be dispatched to subprograms that can easily > be replaced, compared, extended and researched. And nothing prevents people interesting in adding features to Hugin to do this. In fact, what you are writing above has just been improved with the new Makefile lib. > As a side note: Maybe Hugin has too many controls for the first-time > user. But because of reasonable GUI design with an "assistant" a first > time user can achieve results. This is actually inconsistent with the feedback we're getting. Users (and what is even more worrying: not only first-time users) run into optimization problems of all sorts. That's not reasonable GUI design. A reasonable GUI design would prevent that. If somebody is interested into researching and developing a proper GUI design for such a complex multi-faceted problem, here is a very interesting challenge. And it would not yet be a finished product. In 2007 Ippei did such a research, and the idea was to switch to a Qt based UI. The branch dried out after GSoC 2007 and things have moved on with the existing wxWidgets UI. The refactoring of the code however helped bringing more clarity and a better architecture on which the current Hugin builds, a few iteration and many massive changes later. Yuv [0] <http://wiki.panotools.org/Development_of_Open_Source_tools#Maturity_Criteria>
signature.asc
Description: This is a digitally signed message part.
