On 28 Jul., 20:48, Yuval Levy <goo...@levy.ch> wrote: > On July 28, 2011 08:18:54 AM kfj wrote:
> > The looming five or twenty or 65 man years question musn't keep us > > from asking: > > ... > Very good questions. And very good argument for a clean rewrite, with a > clearly defined goal of recreating the existing application in a simpler and > well documented code. I am with you. > > The question is *how*? > > - how to plan? > - how to structure? > - how to execute? You've identified the core problems. In doftware design, it's often a single individual ore a small group of people who succeed in implementing a coherent, manageable, elegant novel design (Linux, Python). If the software is larger, it is often successful because there is yet again a single individual (BDFL) or a core group who steer matters. So first of all we have to find who this is for hugin and win them for the cause. Who is it? Will our guru please step forward? We have a problem here: hugin started out as yet another GUI for panotools. Panotools may be very efficient and clever software, but AFAIK it was never documented properly, abandoned by it's original creator and now there are bits of it we use in very central parts of the software, but the knowledge what it does how and why is in the heads of a few core developers and not generally available. So this part of the code was encapsulated in an object layer, but yet again the functionality of that object layer hasn't been well-documented, and again we have a few developers who are familiar with it, but newcomers hit the 'read-the-code' barrier. Panotools turns out not to be merely a library doing pano maths, but also a selection of standalone programs doing stuff. Because their original creator never released the code, replacements were written. They ended up doing similar things to their templates but most of them still weren't well- documented. Pto format is in the very center of our project with a bunch of fervent defenders, but do you know of a proper, complete documentation? The panotools GUI approach has precipitated the current structure of hugin: An attempt at a modern GUI with lots of clever ideas callling console helper programs as separate processes sharing data with them via files on a magnetic drive. Internally it's keeping it's data in C+ + objects and stuff like linked lists and arrays, using integral indexes for identification. From what I've seen (which is little) I feel the approach at data handling is erratic. It scales badly. Why is it that when you have a few tens of thousands of control points, the GUI at times takes seconds to respond to mouse clicks which have nothing to do with CPs? Maybe the undo/redo mechanism copies the complete state, even though the only thing changed was some pokey flag? My criticism is mainly with the back end, as I've looked at it a bit, wrapping it for hsi. So this is where I'd see the greatest need for change: - reliable data storage and transaction control in a database - a clean, unconvoluted presentation of these data to the program - independence from libpano and panotools - pulling the helper processes into the main process to facilitate data exchange - putting a clean API layer on top of the back end going further, I'd like to see - putting the logic into python where it's much easier to maintain - let the GUI use wxPython for the same reason > We need to rally consensus around a plan/design. > * can we agree on a vision: the same Hugin, The only changes are under the > hood. No UI redesign or other features, they can all be postponed to future > iterations. yes > * can somebody take the role of architect and come up with a *code* design, > and can we rally around it, abstracting from the UI? > * can the architect publish a set of APIs that we can all agree to? > * can we split the existing code base into smaller chunks, so that all > available contributors can execute on them in parallel? > > Now is IMHO a good time. Most of the features that were waiting to be > integrated into Hugin have found their way into the codebase. The 2011.2 > release process has hit a limit. I am in favor of dropping 2011.2 or calling > it final, and moving on to plan, structure, and execute a refactoring, so that > 2012.0 will be a refactoring release based on the features currently in > default. Nothing more. Maybe something less (there are a lot of redundant > tools, and I am tempted to follow Thomas' lead and remove obsolete/redundant > stuff [1] [2] [3]. Hang on! Is this wise? We cant't just assume we'll certainly succeed and happily go skipping towards the precipice. I proposed a project codenamed 'munin'. I see it as developing separately from hugin, like as if we were trying to clone hugin from scratch, but with an awareness of the tools available in 201X and not in 199X. Leave hugin to carry on! If it does what it's supoosed to do it does it well. Kindly ask hugin developers to make an attempt at documentation, modularization, portability, clarity - and if their code qualifies, it may eventually be absorbed by the munin project. Nothing would be more detrimental to the infant clone than having to forcedly mature to become hugin 2012.0 - with a hesitant developer crew and meagre resources. I'm sure it'd fail. I'd want it to grow slowly and by being fed carefully selected, well-chosen components to eventually emerge as the platform of choice to do panorama stuff in, so that people happily join in when they see how good it is. Hugin itself shouldn't be replaced by decree but eventually fall into dignified disuse because there's something better people prefer to it. In software, we've seen how rarely (if ever) a revamped version of some program becomes the new shooting star - it's something else doing something similar, but better, quicker, easier, in new ways (think of browsers or social networks). I'd like to finally see a mature munin to look back and say: 'I owe a lot to the hugin project and a fair amount of my code originates there'. 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
