SoC 2007 project New GUI Framework - Revision history

Ippei: steps of the project

2007-04-17T11:13:37Z

steps of the project

Ippei: revision after acceptance

2007-04-17T10:04:09Z

revision after acceptance

Ippei at 22:30, 28 March 2007

2007-03-28T22:30:18Z

Ippei: /* Discussion */ Dividing this project into 2 parallel tasks

2007-03-28T22:26:10Z

‎Discussion: Dividing this project into 2 parallel tasks

Erik Krause: overview link added

2007-03-24T14:14:02Z

overview link added

Jdsmith: /* New extensible modular GUI framework */

2007-03-23T22:15:31Z

‎New extensible modular GUI framework

Jdsmith: /* Deliverables */

2007-03-23T22:13:31Z

‎Deliverables

Ippei at 00:54, 21 March 2007

2007-03-21T00:54:08Z

Ippei at 00:14, 21 March 2007

2007-03-21T00:14:17Z

Ippei: /* Timeline */

2007-03-21T00:00:47Z

‎Timeline

@@ Line 7: / Line 7: @@
 == 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 on GSoC full-time basis. In fact, not even where to stay; most likely in Edinburgh or back home in Japan, but who knows.
+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.
 * Before the official start
-** - May 17: Exams. Kick-start on the project after some celebration.
+** 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

@@ Line 1: / Line 1: @@
 See [[SoC 2007 overview]] for usage hints and a page list.
 = 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.
+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.
 == Deliverables ==
@@ Line 35: / Line 70: @@
 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.
-* - May 27: Decide the toolkit; specification of the end product with illustration or mock-up
+= Q&A =
-* 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.
+* 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. <small>--[[User:Ippei|Ippei]] 20:05, 17 March 2007 (CET)</small>
 *** Qt 4.3 is getting the QtScript support as a default module; surely it's gonna be a powerful addition. <small>--[[User:Ippei|Ippei]] 00:59, 21 March 2007 (CET)</small>
-* 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.
+* 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. <small>--[[User:Ippei|Ippei]] 00:26, 29 March 2007 (CEST)</small>
 [[Category:Community:Project]]

@@ Line 58: / Line 58: @@
 * 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.
-** 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 the plug-ins. Then the modules from task 1. can be wrapped in 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. <small>--[[User:Ippei|Ippei]] 00:26, 29 March 2007 (CEST)</small>
+** 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. <small>--[[User:Ippei|Ippei]] 00:26, 29 March 2007 (CEST)</small>
 == Students planning to apply ==

@@ Line 1: / Line 1: @@
 See [[SoC 2007 overview]] for usage hints and a page list.
@@ Line 56: / Line 55: @@
 ** 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. <small>--[[User:Ippei|Ippei]] 20:05, 17 March 2007 (CET)</small>
 *** Qt 4.3 is getting the QtScript support as a default module; surely it's gonna be a powerful addition. <small>--[[User:Ippei|Ippei]] 00:59, 21 March 2007 (CET)</small>
 == Students planning to apply ==

← Older revision		Revision as of 14:14, 24 March 2007
Line 1:		Line 1:
		+
		+	See [[SoC 2007 overview]] for usage hints and a page list.
		+
	= New extensible modular GUI framework =		= New extensible modular GUI framework =

← Older revision		Revision as of 22:15, 23 March 2007
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.

@@ Line 25: / Line 25: @@
-The new framework shall be constructed as such that users can edit/use various aspect of panorama project through modules (plug-ins) each of them providing one specific functions. The application should provide intuitive interface for the users to choose what to edit and display with what aspect.
+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 the panorama stitching is consist of several steps and the community comes up with new variations of each step every year, and each of them advances with new features every month.
+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 and those who need access to only the basic tasks and options in simple and intuitive interface.
+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 then work on further implementations and improvements. Once the modular framework is set and the specifications of the required tasks are presented, anyone can work on them independently in parallel. This is also why the good modular system is so important.
 == Rough schedule ==

← Older revision		Revision as of 00:54, 21 March 2007
Line 34:		Line 34:


−	== ~~Timeline~~ ==	+	== Rough schedule ==

	* - May 27: Decide the toolkit; specification of the end product with illustration or mock-up		* - May 27: Decide the toolkit; specification of the end product with illustration or mock-up