Historical:SoC 2007 project New GUI Framework

See SoC 2007 overview for usage hints and a page list.

Project Status

This project is now accepted for Ippei UKAI, with Yuval Levy assigned as his mentor.

Schedule

I haven't planned much about this summer yet. No trips planned so far, nor any part time jobs to keep myself socialise still mainly working with this project on full-time basis. In fact, not even where to stay; most likely in Edinburgh or back home in Japan, but who knows.

The major steps of this project are:

1. Design: of both the GUI and internal architecture
   • This is the most important.
2. Implementation: of the main application and some sample modules
   • This would take longest.
3. Specification: of the things left to be done after the summer as well as the module interface and templates
   • This is necessary to make the outcome of the project meaningful

The detailed but rough schedule is currently:

• Before the official start
  • May 17: Last Exam; Kick-start on the project after some celebration.
  • - May 27: Decide the toolkit. Use-case survey; specification of the end product with illustration or mock-up.
• First half
  • - Jun 03 (Week 1): Rough internal design of the system and interface between the components
  • - Jun 10 (Week 2): Setting up the environment; installation of the toolkit and build system setup
  • - Jul 08 (Week 3-6): Basic framework of the application; module handling, interface with lower level libraries etc.
  • Jul 09: Mid-term evaluations begin
• Second half
  • - Jul 29 (Week 7-9): Most implementations to be done except the modules
  • - Aug 5 (Week 10): Some modules to be written.
  • - Aug 12 (Week 11): Finalise the module interface and template, and the list of module specifications for the future development.
  • - Aug 19 (Week 12): A week to spare if lucky; but more debugging and more modules would be waiting anyway
• Aug 20: Final evaluations begin

New extensible modular GUI framework

The goal of this project is to build a highly extensible GUI framework for Panorama creation, with simple yet intuitive layouts that both beginners and advanced users would be comfortable to use. The application should stay cross-platform, and will reuse the existing back-end panorama creation functionality embodied by Hugin. This GUI framework would be intended to replace the existing Hugin GUI when mature.

Design Goal

This project is committed to two groups of people:

• All programmers interested in panorama photography and existing PanoTools-related developers
• End-users of panorama photography with any level of experience from first timers to professionals

For the programmers, the new program will be a modular framework for which they can write modules that extend any aspect of panorama creation. Think of it as the Eclipse for panorama photography. Extensible and flexible plug-in architecture with minimum dependancy. Of course, it will provide the basic functionalities like project handling, command history, and beyond (to what extent will be subject to debate especially as to the level of image handling).

For the users, the details as to what's happening inside the framework means nothing. This is important. How we make the end-users, especially new users, believe what program does is up to the program design. Ask Dilbert; the engineers' job is to explain to idiots what we do. They don't need to know how we do it or even what it exactly does; only what they see on the screen is what the program does to them. If the program is too technical and complicated, then we have to rearrange it so that it makes more sense either by wrapping it around or making the change to the way it works. Reshaping the panorama creation to what users can understand, and presenting it with GUI is our commitment to the users.

Those two goals may conflict with each other. As more features get available, the more complicated the program may look. Even the user commitment itself isn't simple as we have already enough features that most beginner users do not simply understand or care. How we satisfy both requirements and what to compromise when we can't make every one happy, is the decision we'd have to make. Of course I will try my best to set the architecture/framework design to accommodate the needs of as many people as possible especially the entry level users.

Deliverables

1. Cross-platform Application
   • Acceptable look-and-feel with every platform's standard
   • Minimum amount of platform specific code
2. Completely modular system for organising the functionalities
   • Clear separation of the interface and implementations
   • Intuitive GUI for displaying those modules suitable for different levels of users
3. Designs of the modules to be implemented
   • Specifications of all the basic modules
     • Implementing all the modules would be impossible during the summer
     • The whole community including myself would continue working on those implementations after the summer
     • Specifications can include mock-up or illustration to guide the implementation effort
   • Organisation of the modules that show where those modules will fit into
     • How they will be presented to the users
     • Possibly several sets of the organisation for users from different background
   • Implementation of some modules to demonstrate how the new application works
     • Template for the modules to be written
     • At least one sample module for basic tests

The new framework shall be constructed such that users can interact with various aspects of a panorama project through modules (plug-ins), each of which provides a single, specific function. The application should provide an intuitive interface for the users to choose what to edit and display with what aspect.

The modular system is crucial because panorama stitching workflows contain many steps (e.g. select or generate matching control points, optimize image placement, measure and/or correct for camera deficiencies such as vignetting, chromatic aberration, etc.). Moreover, the community comes up with new variations of each step every year, with new features and possibilities suggested every month.

Also crucial is the way those modules should be organised and presented to the users. Advanced users want to have access to every available feature, while there are many beginners who need access only to the basic tasks and options in a simple and intuitive interface.

Since it would be impossible to implement the entire application in one summer, this project should focus on laying the foundation upon which the community can continue work on further implementations and improvements. Once the modular framework is set and the specifications of the required tasks are presented, new interface functionality can be implemented independently and in parallel. This is also why a solid, flexible, and well-documented modular system is of such important.

Q&A

• Choice of GUI Toolkit: Qt4 is modern and has good support on most of major platforms. wxWidgets is okay, but best of all we have many lines of code that are written for wxWidgets. Scripting languages like Python may have advantages in debugging and module managements. Which one would you use?
  • Personally, I want to give Qt4 a try. Though its widgets look weird on Mac sometimes, it has more to offer outside the GUI itself. --Ippei 20:05, 17 March 2007 (CET)
    • Qt 4.3 is getting the QtScript support as a default module; surely it's gonna be a powerful addition. --Ippei 00:59, 21 March 2007 (CET)

• Possible division of the project: Dividing this project into two parallel tasks that would have little dependancy to each other would enable more work to be done this summer. Would it be possible?
  • The project could be divided up into two parts. However, the rough design of the entire application has to be drafted first so that the both work will be done towards the same objective. Based on that: 1. One of the tasks is to implement each module and the structure/interface of the 'Panorama project' data representation; 2. The other task is to implement the plug-in architecture and the main application that uses those plug-ins. Then the modules from task 1. can be wrapped into that plug-in architecture determined by task 2. Of course, collaboration is required. Interfaces needed by the modules created in task 1 has to be present in the plug-in architecture from task 2, and the modules from task 1 have to fit well into the main application created in task 2. --Ippei 00:26, 29 March 2007 (CEST)