On August 14, 2011 05:32:45 am kfj wrote: > I spent half a day surfing and inverstigating, looking for a suitable > substrate.
I appreciate that and agree with you that we need more investigation. > when having a good long look at what Qt (and it's python binding pyQt) Have you checked PySide [0]? IMHO it has a better chance to thrive in the future than pyQt, even if its corporate sponsor's FLOSS strategy is consistently erratic. And have you looked at [1]? maybe that's the next tool you want to add a Python interface too ;-) > we should spend a good long time browsing for the > very foundation to build stuff on before we even consider setting up a > project. Makes sense. And we should also know what we are browsing for. > If we'd switch to a different GUI framework, everything would > become much more involved anyway, although the idea to just basically > clone hugin with different means would be still a good policy, as it > lowers the complexity of the task by not asking us to redisign the UI > at the same time. Cloning Hugin with different means would indeed be a good way of going about it. Splitting the big endeavor into multiple milestones, cloning Hugin would be a first milestone. However, it may be an unnecessary milestone. What do you use the Hugin GUI for? What are the most important tasks accomplished in there? To me they are: 1. Manual editing/setting CPs when necessary (e.g. vertical lines). And this is less and less a necessity. 2. Visual preview of the output and framing it (playing around with the fast preview to set different projection, cropping, field/point of view). This is where I spend most of my time with Hugin. 3. Masking. Depending on your subject and workflow, this can be critically important. Everything else is a boring time waste. An hygiene factor (needs to be there). All lists and tables, pretty much standard widgets in any modern GUI- Toolkit. Why work hard to re-create hygiene factors if they can be had almost automatically? I would interface into a standard image browsing tool with a single menu entry to generate a pto (currently I do this on the command line with a set of scripts summarized in a single command) from a selection of images; or even identify groups of ptos. Such an assistant on steroids would come as a KIPI plugin and work by default with tools such as Digikam or Gwenview which are much better to browse a list of images in a project than our Images tab. Somebody using Windows/Mac could port this for Lightroom or whatever image browser they want to use. Not much of a Hugin GUI needed, and definitely not the wxWidget stuff we have currently. The "fast preview" would become the hub of munin (hey, I am adopting your name). Open a pto file and display it in there. The question is whether it makes sense to do it in wxWidgets, or take the Open Sourced version of Panini/pvqt as the basis to redevelop the fast preview. For the masking Hugin has a great masking tool, and actually also an alternative masking tool buried in a gsoc2008 project worth reviving. And yet some people still prefer to edit bitmap masks in Photoshop or Gimp or Inkscape. What we need here is a good interface to transform all sorts of masks into the data stored in the pto file format. We can source the mask editor to a separate application. We can also source the CP editor into a separate application, but this one we'd have to design and implement ourselves because it is very specific to our app. Just launch those separate apps from the hub, passing along the .pto file (or whatever changed file format we'll have by then) and a few arguments. Technically it would be possible (although not necessarily desirable) to mix and match GUI toolkits. So the initial mask editor and CP editor could be slimmed down versions from the current Hugin. This is another way of breaking the large task into many smaller one: once each of these editors are stand- alone, coding a drop-in replacement using Qt (or other suitable substrate) become less difficult than coding a complete replacement of the whole Hugin. Break the monolith. Eventually development resources will focus on those areas where such work brings more benefit. E.g. as far as I am concerned, the current stitching engine (PT Batcher) does not need rewriting, just a few changes here and there to make it more user friendly. > Strangely enough hugin's GUI is what I have the least problem with, you mean in technical terms, or as a user? > my hope is that a good framework will take so much load off the > development by providing a readymade infrastructure, that the work > will be more interesting - basically doing application-specific stuff > rather than bothering with making everything work together. yes, that's the objective. plus splitting the monolith into multiple tools again will help too. > > My wish would be a Skype conference call. > > We can try that, but I'm not sure if it's going to be so effective. I > think the written word has it's advantages - it's browsable, to > mention one thing. Bit slower, but more structured. Maybe we could set > up a new ML for the topic rather than cluttering hugin-ptx (we could > always do a bit of cross-posting to lure people over :) The written word has indeed its advantage. This is what meeting minutes are for. And documents produced by the individual team members to be presented/discussed at meetings. But holding the discussion in writing, especially an ML, is IMHO a big time waster. I would be fine with holding it on IRC or Twitter, though, with a clear time and space limit. The way I would organize such a project: An initial meeting, preferably face to face, or teleconference if a physical handshake is not possible. Brain storming ideas, getting on the same page, setting a goal, list the tasks that needs to be completed and split responsibilities for those tasks amongst those present/available. Agree what each of us will deliver. That delivery will be in writing, as will the meeting minutes. Hold regular (weekly if there are enough full-time participants; monthly plus on-demand if we are mostly part-timers) progress meetings where each of us would present his current status so that we could give each other feedback and input. Limit that feedback and input to the two hours meeting (as opposed to an ML where the bike-shedding problem compound into endless threads). If more time is needed than two hours, increase the frequency of the meetings, but no more than once per week. If more than two hours per week are needed, rethink the organization. Move forward from meeting to meeting toward our goal, fine-tuning along the way (e.g. if somebody has more time available, agree on transferring more responsibilities to them). > I also wonder if we shouldn't plain ask for help. Our question is > simple: We want a powerful python-based cross-platform application > framework to write a hugin clone with as little fuss as possible. I > wonder where we should post such a question, but I'm sure we'd benefit > from outside intelligence. Any ideas? We'd definitely benefit from outside intelligence. Places I can imagine to ask: - the create ML. representative from most graphics FLOSS projects are there and can probably give opinions. However there are clear cut lines / rifts between gtk vs. Qt types, so you will have to filter the relevant information from the opinions. - stackoverflow.com - an amazing source of answers tapping into the experience and opinions of seasoned coders. Actually... [2] after finding [3],[4]. > > When are you going to the mountains again? > > as soon as the weather stabilizes. I wish you good weather ASAP; a safe and enjoyable trek; come back with beautiful panos and share the views, please. > It might even get worse in the winter if I go to the Himalaya Oh, wow, don't miss the opportunity if you get it. > web access there is usually very slow, so it's better for pure > programming and conceptual work. Please don't. Enjoy the place, talk with people shoot pictures. You can always get back to programming and/or conceptual work back home. Yuv [0] http://www.pyside.org/ [1] http://pvqt.svn.sourceforge.net/viewvc/pvqt/ [2] http://stackoverflow.com/questions/7058947/can-you-recommend-a-good-cross- platform-application-development-framework [3] http://stackoverflow.com/questions/394039/which-python-gui-framework [4] http://stackoverflow.com/questions/3037678/python-which-multi-platform- gui-framework-to-use
signature.asc
Description: This is a digitally signed message part.
