On 11 Aug., 15:09, Yuval Levy <goo...@levy.ch> wrote: > On August 11, 2011 05:17:41 am kfj wrote:
> > To put it very bluntly: It's a techies' show. > > Scary thought. I prefer to see it as a time-share. It is time for the > techies to drive now, and for the rest of us to take a back seat. What I mean is: it's the 'techies' who write the program. The others test, use, discuss, like, dislike it. > > > 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. > > Will you deliver? I rather under-promise and over-deliver than the other way > around. I feel this is an unfair and suggestive question. I am not intending to do this alone, and I don't know if it will succeed. I'm certainly not putting myself in a situation where I might have to 'deliver' something. I may contribute. I hope my arguments are sound enough to get a few people on board. If not, hugin can just carry on as it is, but I may loose interest in it's development because there's too much effort involved to achieve too little. I'm not a GUI person - the only GUI code I ever handled was when I reverse-engineered a GUI library that was in use on some obsolete system which was ported to a UNIX network. All I did was analyze the code and write the cross-compiler to translate all calls to use the new GUI library. I'm interested in the part that I've already been working on, mainly the data-carrying backend, some maths and the integration of collateral code. My interests are C++, python and computer language design, with a smattering of automatic code generation, data bases, DSP and image processing thrown in. And I suppose I have a reasonably good understanding of overall software design. So here you have my under-promise. > > 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? > > http://ippei.wordpress.com/2007/05/30/the-tasks/http://ippei.wordpress.com/2007/06/02/categorising-the-header-files/http://ippei.wordpress.com/2007/06/04/progress-4th-june-run-out-of-cr... > titles/ etc. etc. I did not find these links helpful. I was hoping for a 'proper' paper. Presentations is what you project on the wall while you give a lecture. I'd rather have the lecture than the presentation. But that you should have come up with these links sheds a light on the state of affairs. Is this what we have when it comes to cenceptual work and documentation? > If we structure the code well enough, we can make it as GUI-toolkit-agnostic > as possible. Do you have a favorite GUI-toolkit? I don't, since I don't know them well enough to make intelligent comments on them. I suppose it's wise to stick with as many components we are already familiar with as possible - unless there's a good reason not to. Porting stuff to another library would be more difficult than just change the interface. > Isn't it you the shadow I see in the driver's seat of the bus I am sitting > in? > Or should I worry and get off at the next stop? I'm not buying the bus analogy. What I have experienced in this discussion is that apart from you who seems to think a rewrite is a good idea the most enthusiastic response has been Harry's 'I'm the last to try to stop it.' If it turns out to be just me (once you're off again) it won't happen. I may do a bit of tinkering on my own if I have time, but I'll certainly not push it. > > codename munin > > http://munin-monitoring.org/ so what? http://www.hugin.com/ I suppose Munin/Muninn is a given name, so there's nothing stopping us from using it. If the need arises we can always make it MUNIN and have a contest here for the best suggestion what the acronym stands for ;-) > The power is not in the tool. The power is in the people. In how we > structure ourselves, empower each other, learn from each other, encourage > (sometimes prod) each other to progress, try new things, and move forward to > where Hugin has never been before. And in how we comfort each other when > things crash, as they sometimes do. yes. > Do you want to set up a project on Github? I know you don't like > SourceForge. It's a historical given. Launchpad is great for tracking > tickets (and being able to add attachment up to 100MB and answer by email > helps a lot), but I don't like bzr. We could also try tracking on Github as > well and see how it goes? I'm not sure if we're there yet, and I feel I'm not competent to make the choice. What's wrong with mercurial? I thought you were all for it. Since it'd be a FOSS project, we might have the repository hosted with bitbucket. Anything wrong with that? I think we need something for brainstorming and structuring. Any suggestions? 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
