On 11 Aug., 04:15, Yuval Levy <goo...@levy.ch> wrote: > while waiting for build-install cycles to complete, I had the time to write > this.
there you go ;-) > On August 8, 2011 09:15:37 am Harry van der Wolf wrote: > > > = User friendliness (not mentioned before, but my point of view): > > I can't read Kay's mind, but I think that user friendliness is one of the > major motivator for his proposal. Right now I am experiencing Hugin's > *codebase* user unfriendliness. This is what set me off. Back when I wanted to compile hugin on a windows system using minGW. No way. Statically linked libraries forcing me to also try and compile the libraries myself instead of just using the DLLs. I gave up halfway through, I think somewhere inside compiling openEXR. Switched to Linux. I've compiled a good many programs in my life, but for what hugin is it's got an exceptionally long compile time. If small changes require a near-full recompile of the whole system (including most helper programs) you can bet you have: spaghetti code this means that rather than having orthogonal modules which encapsulate their functionality in a well-defined parcel and stand by themselves, unaffected by changes in other parts, it's all one big entangled mess. Common in C++: very tempting to stick code inline into a header file, for example - but instead of serving as an interface definition, all of the sudden the header contains code. change the code, everything including the header will be touched and have to be recompiled. C++ is extremely powerful and complex, so to succeed in creating a good C++ program you have to design very carefully. Growth by accretion is a road to disaster. > > > - All solutions offered so far come from the "techies" and relate to the > > code base, and off course they are the driving force behind the hugin > > community, but the techies are only 5% (maximum!) of the end-user base > > where both the windows end users (by far the biggest amount) and OSX > > end-users are (almost by definition) not the most technical users. > > I do not want to go there. No, really not. A skyscraper has dozens of levels > but only one basement. Take the basement away and the skyscraper falls. So > much said. To put it very bluntly: It's a techies' show. If you're happy with what you have, noone stops you to feed your feline predators the food the techies have made for them. It will always be there: be it 2010.4 or 2011.0. You have extended you zoo and want to feed them something better? Go to the 'techies' and say 'please' - or touch the thing yourself - which all of the sudden makes YOU a techie. > > All solutions should aim for more user friendliness. > > Kay's current proposal, from an end-user point of view, is STATUS QUO. Not > better not worse. Simply unchanged. It is user friendliness for the users of > the codebase, i.e. the developers. I beg to differ. I hope it will be better, because it should be faster and crash less. > Programming the screen widgets (and the user interaction) is 80% of the work; > and although I expect that that work will be much faster on the Python > steroids, it is better to start small and stick to Kay's plan: refactor the > existing code base to make it more coder-friendly while keeping the exact > functionality as it is, or even shedding some of it temporarily. I wonder if there isn't a way to migrate the existing wxWidgets code to wxPython. On my (Kubuntu) system the two can coexist peacefully. Maybe one can wrap the wxWidgets code so that it can be called from wxPython, so we'd still have the old GUI but could start putting logic into python. I know nothing of the design concepts and implementation strategy behind hugin's GUI, but maybe someone from that end can comment? Like point me to a technical outline? > > By now the python > > integration is certainly a help for new functionality but it's not user > > friendly. I disagree. From the code side the python interface is a self- contained module which is included into hugin's code by means of a single function declaration. It doesn't get simpler than that. Extremely user-friendly. From the GUI side, when you get a plugin you see a new menu entry show up which you can click on. Something happens. What can be more user-friendly? I think you may not even have seen it in action, because you haven't managed to get it to run on Mac OS. The user-unfriendly thing here is your OS of choice which put's spanners in your works when you're trying to port free software to it. And comes up with a new spanner every so often and even charges you for it. > > When looking at first at the code, it is always tricky to find your way. > > Disagree. There is readable code and there is convoluted code. And then > there is mess. Just simple things such as consistent indentation are an > obstacle to get into the Hugin code. We had a long cycle of adding feature > after feature after feature for the end-user and it is time now to think of > the coders and make their life easier. yes. And, by the way, indentation is part of python's syntax - meaning that you can't have inconsistent indentation :) > > - Again: the techies know their way in the program as they are experienced, > > some with many, many years of experience. It still strikes me that so many > > users experience issues on "simple user-friendly" functionality (note: > > simple and user-friendly to the experienced users). > > How about mirroring this argument? why should the techies do with unfriendly > stuff and the end-users not? IMHO the techies deserve a friendlier > code-base at least as much as the users deserve friendlier functionalities, > and ultimately friendlier functionalities depend from a friendlier code-base > more than the other way around. to me it looks often enough that the 'techies' are hard pressed to offer yet another workaround on some issue that can't be solved. I'd be much happier to offer solutions than workarounds - or have no need for workarounds at all because everything goes straight where it's supposed to go. > > - Do we implement our own sqlite3 "engine" into the package or make it a > > system dependency which will certainly hinder a lot of end users. http://pypi.python.org/pypi/pysqlite/2.6.3 > > = (wx)Python: > > - Kay suggest to move to (wx)Python for logic and gui. Currently python is > > an issue on both windows and OSX. That doesn't mean that it can't have a > > glorious future but we are certainly not there yet. C(++) is a well defined > > standard. Python should definitely fully backward compatible to at least > > 2.6. as far as I know, hsi/hpi runs just fine on Windows, using either python 2.X or 3.X, thanks to Thomas' work on the code. Where's the issue? On MacOS, the issue is that we have noone who has a sound understanding of how it needs to be linked and integrated into the system - you've demonstrated it compiles there with a bit of modification, but the rest never worked. That's an issue. Whatever python code I wrote was written on a python 2.6 system, so it's sure compatible. If Thomas got it to run on Windows, it should really be no problem on MacOS which is even a UNIX system in disguise. > On what basis do you say that Python should be fully backward compatible to at > least 2.6? why not 2.4? or 3.2? I wonder that myself. But it's probably because on MacOS, python is already part of the system. So it's easiest to go with what there is, rather than installing a different python version in parallel to work with hsi/hpi. Anyway, I don't see the problem. > > - When moving to (wx)Python: what will it do to performance? > > This has already been discussed. I hope the answer helped. It should not make a difference. wxPython is merely a wrapper around wxWidgets, so the vast majority of the binary code is just plain the same. > > A compiled binary is AFAIK much faster than any interpreted program. I think you still haven't fully grasped the python way of doing things. Python is a way of gluing code segments written in C/C++ together. It directly uses and calls the C/C++ object code. That's the beauty of it. You may, of course, use only 'pure' python and achieve the same thing - in this case the C object code you use is what python provides in it's (extremely comprehensive) standard library. And if you have existing C/C++ code, you can simply wrap it into a python interface, as I've done with a lot of hugin's C/C++ code - and use it from Python. > With Python you can mesh up scripted/interpreted program and compiled binary. > > The canonical way of developing is to first script everything (unless you > already have compilable code at hand, which is Kay's idea of copy&pasting from > the existing codebase). Then you identify where in the script are the > bottlenecks and you rewrite those functions (and only those function) that are > performance-critical. indeed. > > - To me the python extension (note my wording) is very good functionality > > to be able to build new functionality (by the experts) to be later on > > built (using C++) into Hugin for the greater, lesser skilled community > > (also related to end user friendliness). > > sometimes you just don't need to rewrite it in C++ because Python does the job > fast enough that you don't notice a difference. let me add: it is really oftentimes, and often it allow you to be even faster. Why? Python is extremely efficient for an interpreted language, and offers very good libraries (usually written in C/C++ and available precompiled for many different systems) for things which are more complex. Instead of coding stuff yourself, you end up delegating stuff to these libraries (called modules in python) because they're all just there and interoperable, rather than writing your 100th for- loop or doer-of-thing object in C++. It's called the 'batteries included' approach. Why not have a look at http://www.python.org/about/ > > - We have some C(++) programmers on board. How many (wx)Python programmers > > do we have? This is a neccessity for continuity. I am a competent C/C++ programmer. Yet I know next to nothing of wxWidgets. But what I know is that wxPython offers pretty much the self same interface to programmers as wxWidgets - same function and object names, same parameter names - in Python you often happily use even the documentation from the C/C++ libraries, since there is very liitle difference. Just that all the complexities of fixed types and header files are gone and you can focus on using the code. If you can write wxWidgets code in C++ and try and code the same in wxPython, you may all of the sudden breathe a sigh of relief and scratch your hand in puzzlement why you ever put up with programming it in C++ ;-) Actually at the moment we have nobody on board. It's a matter of perspective. > This is Open Source, everybody is free to come and go as they see please. At > the moment we have a complex codebase that prevent many potential > contributors from coming on board. We've had this feedback consistently from > many students since the first Google Summer of Code edition we participated > to. So there we go. Anybody who can program wxWidgets and has a smattering of python (which isn't hard to acquire) can program in wxPython. We haven't got them quite yet but they're not far away. Not to mention new people who might be attracted by the new opportunities and their ease of use. > > = how? or why? codename munin > This is no corporate environment and there is no need for a business case. > It's a scratch your own itches environment. If Kay has an itch, he will > scratch it. And if more than one person has an itch and want to team up, they > will. This is no place to argue for or against: everybody is free to do what > they want; and without meaning to be derogatory, it is no democracy either. > It is not 95%. It is not even 5%. It is an individual choice for each and > every person in the room. What can I do and what do I want to do. Kay > definitely seems to want to go this way and I am with him. For as much as my > participation is worth. In four weeks I will be reading only legal code and > writing exams. If I'm not mistaken, hugin took of as an individual's project. See what became of it! The foundations were laid, the concept was good, it attracted people who put their bit in, and now we have an extremely powerful tool which demonstrates what can be done and how to do it. And which we can use as a template, as inspiration, and as code base for the munin project. > > I don't give much answers or solutions. Merely things to consider when > > doing such a major step which could break hugin easily for at least a year > > (or worse). > > This won't break Hugin. Not more than it is broken already. precisely. I'm talking about a parallel project. I hope it will resurrect hugin's spirit in a new body. > This won't touch the Hugin default branch. It will be a separate branch. Or > maybe it even makes sense to start a new repository, from scratch, and > carefully cherry-pick / migrate by copy&paste desirable code while leaving the > cruft behind. I'd do the latter. And start with the basics, preferably with some sort of application template mechanism that takes care of the standard basics. Then fill it in with hugin-specific content. As few reinvented wheels as possible. The time passed since hugin's inception should have expanded the universe of available tools so much that a lot of stuff which still was hand-coded in hugin could now be taken from standardized sources. It ought to be a huge relief. Just a bit of brainstorming here: I did some 3D graphics a few years back, still on windows. I used Pov-Ray, a 3D SDL and ray-tracer. On Windows, it has an IDE which works nicely. When I tried to find the same on Linux, initially I was frustrated because 'the same thing' just wasn't there. So I dug deeper and found: Pov-Clipse, an implementation of a Pov-Ray IDE in eclipse. It took some installation effort and a bit of fiddling, but sure enough there it was, doing as expected. I don't think this would have been feasible or even available ten years ago. In a way hugin is an IDE as well, so a tool like eclipse could be used to model the workflow. As we progress in software, we must embrace ever more complex and powerful tools to harness the ever-increasing power, complexity and sheer volume of our systems. Or stagnate. We can choose. I gritted my teeth and learned enough cmake and mercurial to work on hugin, but it was time well-spent and it expanded my horizon. I gritted my teeth some more and learned swig to write the python interface. I'll have to grit my teeth to learn whatever tools we decide to help us create the munin project, but I'm sure eventually I'll be glad of having done so. > Starting from scratch has a few advantages. > ... > We could (don't jump at me, please) drop *in*the*short*term* the multi- > platform requirement and initially focus on achieving quick results for the > one platform that we (team of people that decide to join Kay) choose as ours. > > If what we do is good, others will adopt and adapt it for their platforms as > the project grows. I think this would be wise. If we keep in mind that we want it to run on all platforms again eventually, we could have a munin policy to use only such modules (or versions thereof) which are available on all platforms, and be conservative with very bleeding-edge features > It's Open Source business as usual: individual contributors decide on a case > by case basis where and when they want to contribute their precious time and > what they want to do with it. Nobody can tell them what to do. Within an > established organization / project like Hugin, there are rules. On the green > field the only rule is: you can join and influence or you can stay out and > watch. Given the choice, and if I have the time, I rather do the first. I > think Kay is on the right direction and I am willing to follow him with the > little time I can dedicate to FLOSS at this moment. Let me add: There's no threat to the established system. Noone is going to 'break' that or render it inoperable. If munin fails, the only loss to hugin will be the development time which people devote to munin rather than struggling on with hugin. And hugin might even be able to salvage the odd non-stick pan from 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
