Slicer3:UIEngineering - Revision history

Grundlett: Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/"

2017-07-10T18:00:13Z

Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/"

Marianna: Unprotected "Slicer3:UIEngineering"

2008-05-20T18:58:53Z

Marianna: Replacing page with ''''Note:''' We are migrating this content to the slicer.org domain - The newer page is [http://www.slicer.org/slicerWiki/index.php/Slicer3:UIEngineeri...'

2008-05-20T18:58:40Z

Replacing page with '<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [http://www.slicer.org/slicerWiki/index.php/Slicer3:UIEngineeri...'

Wjp: /* GUI architecture and interface to application layer */

2007-07-24T17:31:13Z

GUI architecture and interface to application layer

Wjp: /* GUI architecture and interface to application layer */

2007-07-24T17:30:15Z

GUI architecture and interface to application layer

Wjp: /* Independent stateless GUI layer */

2007-01-30T12:47:40Z

Independent stateless GUI layer

Wjp: /* Architecture of a Module GUI */

2007-01-30T12:47:21Z

Architecture of a Module GUI

Wjp: /* Current status and TO-DO */

2007-01-30T12:44:00Z

Current status and TO-DO

Wjp: /* Architecture of a Module GUI */

2007-01-30T12:43:31Z

Architecture of a Module GUI

Wjp: /* GUI architecture and interface to application layer */

2007-01-30T12:41:45Z

GUI architecture and interface to application layer

← Older revision		Revision as of 18:00, 10 July 2017
Line 1:		Line 1:
−	<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [~~http~~://www.slicer.org/~~slicerWiki/index.php~~/Slicer3:UIEngineering here]</font></big>	+	<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [https://www.slicer.org/wiki/Slicer3:UIEngineering here]</font></big>

← Older revision		Revision as of 18:58, 20 May 2008
Line 1:		Line 1:
−	~~[[Slicer3:Interface_Design\|Return to Slicer3 Interface Design and Usability ]]~~	+	<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [http://www.slicer.org/slicerWiki/index.php/Slicer3:UIEngineering here]</font></big>
−
−	~~== Slicer3 GUI layer architecture and engineering ==~~
−
−	~~=== GUI architecture and interface to application layer ===~~
−
−	Our goal was to create a thin and stateless GUI layer for Slicer3 whose architecture allows the flexible expression of interfaces that are appropriate for Slicer’s different use scenarios: an end-user application graphical user interface; script-driven batch processing and unit testing; and command-line style interaction for launching pipeline/grid processing, debugging during development, ''~~etc~~''.
−
−	The schematic below shows the Slicer3 GUI layer design and its interface with the application layer (which includes the logic layer and the data model as shown). The design isolates the application layers from GUI code, allowing them to be invoked by the Slicer3 desktop application and GUI (Slicer3), or a custom application with or without a graphical user interface, or which may use a completely different GUI toolkit.
−
−	~~[[Image:Slicer3ArchitectureHalfsize.png\|[[Image:Slicer3ArchitectureHalfsize.png\| Slicer3 GUI, Logic and Data layers ]]]]~~
−
−	User input to the GUI layer modifies parameters in the MRML scene and Logic classes, and updates and executes pipelines. So that the GUI can accurately reflect application state, it maintains observers on the MRML scene, MRML nodes, and Logic objects; when the application state encapsulated in the parameters of those objects changes, events are generated, then observed and processed by the GUI to update its widgets' ~~transient state (like entry widgets or scale values, and rendered image output).~~
−
−	~~The GUI~~'~~s visual style is being designed to reflect Slicer3 brand. Developers~~ are ~~encouraged to adhere~~ to ~~style guidelines to maintain a consistent look and feel across core and custom modules and to make Slicer3 easier to learn. The style is defined and described by~~ the ~~Tk Options Database configured by a Slicer3 class (vtkSlicerTheme~~.~~h/cxx). These options can be overridden in an module's GUI, if a developer finds this necessary, by redefining new Tk options for widgets defined there.~~
−
−	=~~== Architecture of a Module GUI ===~~
−	~~A schematic showing classes from which a developer's module GUI are derived~~ is ~~shown below. For more detailed information about adding a module GUI to Slicer, see:~~ [~~[Slicer3~~:~~Interface_Design#First_steps:_How_to_build_a_Slicer3_Module_GUI \| How to build a Module GUI~~.]]
−
−	~~[[Image:Slicer3MyModule~~.~~png \| Module base classes and their methods ]]~~
−
−
−	~~=== Independent stateless GUI layer ===~~
−
−	~~An important design features is the restriction of application state to the MRML and Logic classes; the GUI layer is completely independent of these two application layers~~. This stateless GUI layer offers many benefits. For one, any MRML scene may be deleted or loaded and the GUI will automatically track that scene; for another, Slicer's full functionality is available even when Slicer operates without the GUI layer, or with another GUI entirely. For more information about how this design is accomplished, see: [[Slicer3:~~StatelessGUI \| Keeping the GUI layer independent and stateless ]].~~
−
−	~~''' Return to TOC '''~~
−
−	~~[[Slicer3:Interface_Design\|Return to Slicer3 Interface Design and Usability ]~~]

@@ Line 5: / Line 5: @@
 === GUI architecture and interface to application layer ===
-Our goal is to create a thin GUI layer for Slicer3 whose architecture allows the flexible expression of interfaces that are appropriate for Slicer’s different use scenarios: an end-user application graphical user interface; script-driven batch processing and unit testing; and command-line style interaction for launching pipeline/grid processing, debugging during development, ''etc''.
+Our goal was to create a thin and stateless GUI layer for Slicer3 whose architecture allows the flexible expression of interfaces that are appropriate for Slicer’s different use scenarios: an end-user application graphical user interface; script-driven batch processing and unit testing; and command-line style interaction for launching pipeline/grid processing, debugging during development, ''etc''.
 The schematic below shows the Slicer3 GUI layer design and its interface with the application layer (which includes the logic layer and the data model as shown). The design isolates the application layers from GUI code, allowing them to be invoked by the Slicer3 desktop application and GUI (Slicer3), or a custom application with or without a graphical user interface, or which may use a completely different GUI toolkit.

← Older revision		Revision as of 17:30, 24 July 2007
Line 6:		Line 6:

	Our goal is to create a thin GUI layer for Slicer3 whose architecture allows the flexible expression of interfaces that are appropriate for Slicer’s different use scenarios: an end-user application graphical user interface; script-driven batch processing and unit testing; and command-line style interaction for launching pipeline/grid processing, debugging during development, ''etc''.		Our goal is to create a thin GUI layer for Slicer3 whose architecture allows the flexible expression of interfaces that are appropriate for Slicer’s different use scenarios: an end-user application graphical user interface; script-driven batch processing and unit testing; and command-line style interaction for launching pipeline/grid processing, debugging during development, ''etc''.
−
−	Slicer2's GUI code is quite dense, mixed in with application control logic and data model. There is no way to separate the gui from the rest of the Slicer2 application which limits the ability to perform automated tests of modules and makes development and maintenance of software more challenging. To meet our goal, the Slicer3 architecture requires a thoughtful translation of existing Slicer2 modules' functionality, and won't be as simple as dropping in a new set of widgets. The aim is to provide a framework that makes this task as easy as possible for Slicer developers while separating the Slicer3 GUI code from the application layer.

	The schematic below shows the Slicer3 GUI layer design and its interface with the application layer (which includes the logic layer and the data model as shown). The design isolates the application layers from GUI code, allowing them to be invoked by the Slicer3 desktop application and GUI (Slicer3), or a custom application with or without a graphical user interface, or which may use a completely different GUI toolkit.		The schematic below shows the Slicer3 GUI layer design and its interface with the application layer (which includes the logic layer and the data model as shown). The design isolates the application layers from GUI code, allowing them to be invoked by the Slicer3 desktop application and GUI (Slicer3), or a custom application with or without a graphical user interface, or which may use a completely different GUI toolkit.

@@ Line 25: / Line 25: @@
 === Independent stateless GUI layer ===
-An important design features is the restriction of application state to the MRML and Logic classes; the GUI layer is completely independent of these two application layers. This stateless GUI layer offers many benefits. For one, any MRML scene may be deleted or loaded and the GUI will automatically track that scene; for another, Slicer's full functionality is available even when Slicer operates without the GUI layer, or with another GUI entirely. For more information about how this stateless GUI is accomplished, see: [[Slicer3:StatelessGUI | Keeping the GUI layer independent and stateless ]].
+An important design features is the restriction of application state to the MRML and Logic classes; the GUI layer is completely independent of these two application layers. This stateless GUI layer offers many benefits. For one, any MRML scene may be deleted or loaded and the GUI will automatically track that scene; for another, Slicer's full functionality is available even when Slicer operates without the GUI layer, or with another GUI entirely. For more information about how this design is accomplished, see: [[Slicer3:StatelessGUI | Keeping the GUI layer independent and stateless ]].
 ''' Return to TOC '''
 [[Slicer3:Interface_Design|Return to Slicer3 Interface Design and Usability ]]

← Older revision	Revision as of 18:58, 20 May 2008
(No difference)

← Older revision		Revision as of 12:47, 30 January 2007
Line 23:		Line 23:


		+	=== Independent stateless GUI layer ===

		+	An important design features is the restriction of application state to the MRML and Logic classes; the GUI layer is completely independent of these two application layers. This stateless GUI layer offers many benefits. For one, any MRML scene may be deleted or loaded and the GUI will automatically track that scene; for another, Slicer's full functionality is available even when Slicer operates without the GUI layer, or with another GUI entirely. For more information about how this stateless GUI is accomplished, see: [[Slicer3:StatelessGUI \| Keeping the GUI layer independent and stateless ]].

	''' Return to TOC '''		''' Return to TOC '''

	[[Slicer3:Interface_Design\|Return to Slicer3 Interface Design and Usability ]]		[[Slicer3:Interface_Design\|Return to Slicer3 Interface Design and Usability ]]

← Older revision		Revision as of 12:44, 30 January 2007
Line 22:		Line 22:
	[[Image:Slicer3MyModule.png \| Module base classes and their methods ]]		[[Image:Slicer3MyModule.png \| Module base classes and their methods ]]

−	~~=== Current status and TO-DO ===~~	+

@@ Line 18: / Line 18: @@
 === Architecture of a Module GUI ===
-A schematic showing classes from which a developer's module GUI are derived is shown below. For more detailed information about adding a module GUI to Slicer, see:
+A schematic showing classes from which a developer's module GUI are derived is shown below. For more detailed information about adding a module GUI to Slicer, see: [[Slicer3:Interface_Design#First_steps:_How_to_build_a_Slicer3_Module_GUI | How to build a Module GUI.]]
 [[Image:Slicer3MyModule.png | Module base classes and their methods ]]

@@ Line 17: / Line 17: @@
 The GUI's visual style is being designed to reflect Slicer3 brand. Developers are encouraged to adhere to style guidelines to maintain a consistent look and feel across core and custom modules and to make Slicer3 easier to learn. The style is defined and described by the Tk Options Database configured by a Slicer3 class (vtkSlicerTheme.h/cxx). These options can be overridden in an module's GUI, if a developer finds this necessary, by redefining new Tk options for widgets defined there.
+[[Image:Slicer3MyModule.png | Module base classes and their methods ]]
 === Current status and TO-DO ===