Difference between revisions of "SoC 2007 project New GUI Framework"

From PanoTools.org Wiki
Jump to: navigation, search
(Deliverables)
(New extensible modular GUI framework)
Line 1: Line 1:
 
= New extensible modular GUI framework =
 
= 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.
+
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 interface with the existing  back-end panorama creation functionality embodied by [[Hugin]].  This GUI framework would be intended to replace the existing [[Hugin]] GUI when mature.
  
  

Revision as of 22:15, 23 March 2007

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 interface with the existing back-end panorama creation functionality embodied by Hugin. This GUI framework would be intended to replace the existing Hugin GUI when mature.


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.

Rough schedule

  • - May 27: Decide the toolkit; 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

Discussion

  • 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.
    • 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)

Students planning to apply