On 20 Jun., 06:09, Yuval Levy <goo...@levy.ch> wrote: > Well, to lay out a good plan one has to start with the end in mind, and my > vision is for Python / wxPython to become the main glue of the whole Hugin > GUI.
Make a start then and install the wxPython package ;-) crop_cp.py, which failed on your system because wxPython wasn't installed, already shows a dialog box with wxPython - at least on my system, but your's should really do the same. > Won't happen overnight, but once the current GUI gets wrapped, we can > re-use its widgets (e.g. the fast preview) within wxPython, progressively > separating performance-critical code (stays C++) from non-performance-critical > code (replaced by Python glue that is more flexible). I have thought about this process, and I have mixed feelings about it. Why? Hugin is already an object-oriented layer on top of old C code and many external libraries, with the wxWidgets code as yet another layer on top of it. The C++ code in itself seems to have grown by accretion and aggregation, tending towards convolution and redundance (or, call it bloat). Now this code has to be worked over so it can be broken up into independent objects that can be manipulated from a python master process. Things are getting difficult to disentangle. In my own projects, when I was at leasure to do so, I would regularly start afresh at some point. If you have an idea what's amiss with your current setup (after all you've been maintaining it for all this time and know precisely what irks you), you can start again with a fresh groundworks, and if any of your previous incarnation's code is well- made you can copy and paste it into the new skeleton, while new stuff can be integrated from the start rather than having to be wedged in somewhere which was never made to accomodate it. Since you (hopefully) have a clear vision now of what you want, you can approach the design in a differnt way - I find that I often start prototypes and early versions bottom-up, whereas later iterations become more top-down, as I become confident that the nitty-gritty will work rather than being the make-or-break part of the project. I'd extend the vision: Python mother process holding it all together wxPython-based GUI using dynamically loaded libraries on all platforms Database-like backend to contain projects simple, powerful, extensible, readable replacement for pto specific, modular, well-defined C/C++ libraries for time-critical stuff [add your piece of mind] code name munin. many of these can be achieved by using appropriate python modules, which really are C code made accessible in a flexible and intelligen fashion - and interoperable, because of python. I've even been tempted to try and create such a groundworks, put it out there and see if it might not be populated with reusable old code and new additions. I think such a route may be less effort than trying to refacture hugin's current code base by operating on the live patient - particularly since the code is so meagrely documented and convoluted. I only fear that the general response to such an approach will be along the lines of 'why do we need that, our system works just fine' > The Images and Lens tabs are excellent candidates to be moved over to Python, > and even the outdated CP tab. But then, you know the code, and I've hardly peeked in at all. If you think such a transition is less painful than a redesign, I'm looking forward to see it. 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
