https://www.slicer.org/w/api.php?action=feedcontributions&feedformat=atom&user=BarreSlicer Wiki - User contributions [en]2026-04-21T22:30:16ZUser contributionsMediaWiki 1.33.0https://www.slicer.org/w/index.php?title=Slicer3:Multiple_Cameras&diff=13295Slicer3:Multiple Cameras2010-04-07T21:45:23Z<p>Barre: /* Features */</p>
<hr />
<div>== Goals ==<br />
<br />
Bring core support for multiple cameras and 3D views in Slicer3.<br />
<br />
== Features ==<br />
<br />
The multi views and cameras framework is available from the "Camera" modules. This module displays two pull-down menus. The first one, "View", lists all available views and lets the user create new 3D views. The second one, "Camera", lists all available cameras, and lets the user create new cameras. <br />
<br />
[[File:Slicer3CameraModule.png]]<br />
<br />
Only one camera is used by a view at a time. When a view is selected from the pull-down, the camera it is currently using is automatically selected in the second pull-down. <br />
<br />
* Create a new camera. In the "Camera" pull-down menu, select "Create New Camera": a new camera node is created (most likely named "Camera1", as opposed to the default "Camera" node), and automatically assigned to the currently selected view node (named "View" by default). Try interacting with the 3D view.<br />
<br />
* Assign a camera to a view. Select any camera node from the "Camera" pull-down menu: the camera is assigned to the currently selected view. For example, try selecting back the "Camera" node if you have created a "Camera1" node in the previous step, and you should notice the 3D view on the right update itself to reflect the different point of view. Note: a camera can not be shared between two views: selecting a camera already used by a view will effectively swap the cameras between the two views.<br />
<br />
* Create a new view: select the "Tabbed 3D Layout" from the layout button in the toolbar. In the "View" pull-down menu, select "Create New View": a new view node is created (most likely named "View1", as opposed to the default "View" node), and displayed on the right under a new tab. You can select which view to display by clicking on the corresponding tab in the "Tabbed 3D Layout". Interacting in that view will automatically mark it as "active"; there can only be one "active" view at a time in Slicer3, and it always feature a thin dark blue border. Since a view can not exist without a camera, a new camera node is automatically created and assigned to this new view (most likely named "Camera2" if you have created "Camera1" in the previous steps). At this point, you can assign any of the previously created cameras to this new view (say, the "Camera" or "Camera1" nodes).<br />
<br />
== Implementation ==<br />
<br />
Here are a few pointers related to the new framework. What happens under the hood, and what events developers and module maintainers can intercept to use the new features.<br />
<br />
The workflow so far (Slicer 3.6, as of November 2009):<br />
<br />
When a vtkMRMLViewNode is created and added to the MRML scene (say by a module, or by the main app, or a third party):<br />
<br />
* vtkSlicerApplicationGUI, which listens to vtkMRMLScene::NodeAddedEvent, sees that a new view node has been <br />
created, and calls vtkSlicerApplicationGUI::OnViewNodeAdded().<br />
<br />
* OnViewNodeAdded() adds a few observers to the view node, and if there is no other vtkMRMLViewNode around (i.e. if it's the first one), it is automatically tagged as "Active". vtkSlicerApplicationGUI::UpdateMain3DViewers() is then called.<br />
<br />
* UpdateMain3DViewers(), a fair amount is done here, but the gist is: the function loops over all the vtkMRMLViewNode in the scene, and if it finds out that one doesn't have an associated vtkSlicerViewerWidget yet (i.e. the graphical part that really makes up the view), it allocates and Create()'s one and set its ViewNode ivar to the vtkMRMLViewNode pointer. This is the only place in Slicer3 where vtkSlicerViewerWidget::New() is created (this wasn't the case before, I factorized it). Note that some MRML nodes like vtkMRMLCamera maintain and allocate their VTK counterpart automatically (vtkCamera). This is not the case for vtkMRMLViewNode (I don't know why, but I didn't want to break that for backward compatibility, therefore that design didn't change).<br />
<br />
In a similar fashion, vtkSlicerApplicationGUI listens to vtkMRMLScene::NodeRemovedEvent, calls<br />
vtkSlicerApplicationGUI::OnViewNodeRemoved, which remove previous observers, and calls UpdateMain3DViewers() as well. This function still does what is described above, but also loops over all the vtkSlicerViewerWidget it knows: if the corresponding vtkMRMLViewNode doesn't exist anymore (since it was just removed), it deletes that viewer widget, which should free the corresponding graphic resources.<br />
<br />
Module maintainers should not have to worry about the creation of Slicer Viewer Widgets, as this is taken care of as described above. What a module should do:<br />
<br />
* listen to vtkMRMLScene::NodeAddedEvent, sent by the MRML scene: if a vtkMRMLViewNode has been added, that means you may have to prepare yourself for allocating the resources you will put in that view (vtkSlicerViewerWidget ),<br />
<br />
* listen to vtkMRMLScene::NodeRemovedEvent, sent by the MRML scene: if a vtkMRMLViewNode is being removed, this is definitely the time for your module to remove your resources from that view, and probably free them.<br />
<br />
* listen to vtkMRMLViewNode::ActiveModifiedEvent, sent by a vtkMRMLViewNode node (i.e. when a view node is added, it's up to you to add that observer on the view node, when the node is removed, you remove that observer): if a view becomes "active", it means that it is "selected". Right now, in dual view mode, the active view is the last one that was interacted with: it has a darker outline. This active event is useful essentially because of the left panel UI. If you have some UI that reflects the parameters used in VolumeRendering for example (say a LUT editor), it is possible you may want to apply those parameters only to the resources pertaining to a specific view. In any case, when you receive an Active event, your UI is given the opportunity to update the parameters that are only relevant to that specific view.<br />
<br />
What is said in that first bullet point is not exactly helping though: vtkMRMLScene::NodeAddedEvent is triggered when a vtkMRMLViewNode is added, but it is still too early for your module to add resources to that view (i.e. the renderers), because the corresponding vtkSlicerViewerWidget has not been created; this is done in UpdateMain3DViewers(). So even though you may want to listen to NodeAddedEvent to prepare some resources, you still can't add them, no renderers are ready for your actors. What you need is a way to know that the corresponding SlicerViewerWidget has been created. To fix that situation, your module should ultimately:<br />
<br />
* listen to vtkMRMLViewNode::GraphicalResourcesCreatedEvent, sent by a vtkMRMLViewNode node (same as #3, it's up to you to add that observer on the view node, by first listening to vtkMRMLScene::NodeAddedEvent). This event carries a pointer to the corresponding vtkSlicerViewerWidget that was just created in UpdateMain3DViewers(). Now seems a good time for you to add your actors to the renderers.<br />
<br />
Note that this doesn't necessarily conflict with the idea that a viewer widget, as Jim Miller suggested, could keep track of what is visible or not in its own render window... I guess for the time being we could <br />
let the modules automatically add their actors to each new view when they are added to the scene, as described above, and then later on we can come up with something to turn the visibility on/off of actors in each viewer...<br />
<br />
To sum up:<br />
<br />
* listen to vtkMRMLScene::NodeAddedEvent and vtkMRMLScene::NodeRemovedEvent on the scene,<br />
* received vtkMRMLScene::NodeAddedEvent and its a new vtkMRMLViewNode? Allocate your graphical resources (don't add them yet), add vtkMRMLViewNode::GraphicalResourcesCreatedEvent and vtkMRMLViewNode::ActiveModifiedEvent to this new view node to know when graphical resources have been created for that view (the renderwindow, renderers, etc), and when the view becomes "the active one",<br />
* received vtkMRMLViewNode::GraphicalResourcesCreatedEvent? time to add your actors to the corresponding view,<br />
* received vtkMRMLViewNode::ActiveModifiedEvent? time to refresh your UI in the left panel<br />
* received vtkMRMLScene::NodeRemovedEvent and it's a vtkMRMLViewNode? Time to remove your resources from that view.<br />
<br />
Now of course the choice of allocating resources *per view* depends on the module. One can technically add the same actor to different renderers, but this doesn't always do the trick (especially not for volume rendering). For example, fiducials use vtkFollower actors to make sure labels always face the camera. Since the camera is different for each renderer, this resource will have to be allocated for *each view*. It's likely up to the module to maintain some sort of STL map associating a view to the resources for that view.<br />
<br />
== TODO ==<br />
<br />
As of Slicer 3.6:<br />
* there is one 'full featured' 3D viewer, which is the one at the top in the default layout. This is the one where volume rendering, fiducials, ROIs (box widget), and other actions take place,<br />
* there can be multiple 'secondary' 3D views that have independent cameras but only see the models (essentially just the vtkActors but not widgets or volumes).<br />
<br />
All modules that display an actor on screen are technically concerned and need to be revisited to use the new framework. Now that the multi camera/views logic is in the core, it's a matter of letting the module maintainers<br />
know that they can upgrade their code to use this particular set of functionality (which didn't exist when modules<br />
like Fiducials, Volume Rendering, etc were first developed).<br />
<br />
Modules that need to be upgraded (please keep updating this list):<br />
* Fiducials<br />
* Volume Rendering</div>Barrehttps://www.slicer.org/w/index.php?title=File:Slicer3CameraModule.png&diff=13294File:Slicer3CameraModule.png2010-04-07T21:44:41Z<p>Barre: uploaded a new version of "File:Slicer3CameraModule.png"</p>
<hr />
<div></div>Barrehttps://www.slicer.org/w/index.php?title=File:Slicer3CameraModule.png&diff=13293File:Slicer3CameraModule.png2010-04-07T21:43:31Z<p>Barre: </p>
<hr />
<div></div>Barrehttps://www.slicer.org/w/index.php?title=Slicer3:Multiple_Cameras&diff=13292Slicer3:Multiple Cameras2010-04-07T21:43:02Z<p>Barre: /* Goal */</p>
<hr />
<div>== Goals ==<br />
<br />
Bring core support for multiple cameras and 3D views in Slicer3.<br />
<br />
== Features ==<br />
<br />
The multi views and cameras framework is available from the "Camera" modules. This module displays two pull-down menus. The first one, "View", lists all available views and lets the user create new 3D views. The second one, "Camera", lists all available cameras, and lets the user create new cameras. <br />
<br />
Only one camera is used by a view at a time. When a view is selected from the pull-down, the camera it is currently using is automatically selected in the second pull-down. <br />
<br />
* Create a new camera. In the "Camera" pull-down menu, select "Create New Camera": a new camera node is created (most likely named "Camera1", as opposed to the default "Camera" node), and automatically assigned to the currently selected view node (named "View" by default). Try interacting with the 3D view.<br />
<br />
* Assign a camera to a view. Select any camera node from the "Camera" pull-down menu: the camera is assigned to the currently selected view. For example, try selecting back the "Camera" node if you have created a "Camera1" node in the previous step, and you should notice the 3D view on the right update itself to reflect the different point of view. Note: a camera can not be shared between two views: selecting a camera already used by a view will effectively swap the cameras between the two views.<br />
<br />
* Create a new view: select the "Tabbed 3D Layout" from the layout button in the toolbar. In the "View" pull-down menu, select "Create New View": a new view node is created (most likely named "View1", as opposed to the default "View" node), and displayed on the right under a new tab. You can select which view to display by clicking on the corresponding tab in the "Tabbed 3D Layout". Interacting in that view will automatically mark it as "active"; there can only be one "active" view at a time in Slicer3, and it always feature a thin dark blue border. Since a view can not exist without a camera, a new camera node is automatically created and assigned to this new view (most likely named "Camera2" if you have created "Camera1" in the previous steps). At this point, you can assign any of the previously created cameras to this new view (say, the "Camera" or "Camera1" nodes).<br />
<br />
== Implementation ==<br />
<br />
Here are a few pointers related to the new framework. What happens under the hood, and what events developers and module maintainers can intercept to use the new features.<br />
<br />
The workflow so far (Slicer 3.6, as of November 2009):<br />
<br />
When a vtkMRMLViewNode is created and added to the MRML scene (say by a module, or by the main app, or a third party):<br />
<br />
* vtkSlicerApplicationGUI, which listens to vtkMRMLScene::NodeAddedEvent, sees that a new view node has been <br />
created, and calls vtkSlicerApplicationGUI::OnViewNodeAdded().<br />
<br />
* OnViewNodeAdded() adds a few observers to the view node, and if there is no other vtkMRMLViewNode around (i.e. if it's the first one), it is automatically tagged as "Active". vtkSlicerApplicationGUI::UpdateMain3DViewers() is then called.<br />
<br />
* UpdateMain3DViewers(), a fair amount is done here, but the gist is: the function loops over all the vtkMRMLViewNode in the scene, and if it finds out that one doesn't have an associated vtkSlicerViewerWidget yet (i.e. the graphical part that really makes up the view), it allocates and Create()'s one and set its ViewNode ivar to the vtkMRMLViewNode pointer. This is the only place in Slicer3 where vtkSlicerViewerWidget::New() is created (this wasn't the case before, I factorized it). Note that some MRML nodes like vtkMRMLCamera maintain and allocate their VTK counterpart automatically (vtkCamera). This is not the case for vtkMRMLViewNode (I don't know why, but I didn't want to break that for backward compatibility, therefore that design didn't change).<br />
<br />
In a similar fashion, vtkSlicerApplicationGUI listens to vtkMRMLScene::NodeRemovedEvent, calls<br />
vtkSlicerApplicationGUI::OnViewNodeRemoved, which remove previous observers, and calls UpdateMain3DViewers() as well. This function still does what is described above, but also loops over all the vtkSlicerViewerWidget it knows: if the corresponding vtkMRMLViewNode doesn't exist anymore (since it was just removed), it deletes that viewer widget, which should free the corresponding graphic resources.<br />
<br />
Module maintainers should not have to worry about the creation of Slicer Viewer Widgets, as this is taken care of as described above. What a module should do:<br />
<br />
* listen to vtkMRMLScene::NodeAddedEvent, sent by the MRML scene: if a vtkMRMLViewNode has been added, that means you may have to prepare yourself for allocating the resources you will put in that view (vtkSlicerViewerWidget ),<br />
<br />
* listen to vtkMRMLScene::NodeRemovedEvent, sent by the MRML scene: if a vtkMRMLViewNode is being removed, this is definitely the time for your module to remove your resources from that view, and probably free them.<br />
<br />
* listen to vtkMRMLViewNode::ActiveModifiedEvent, sent by a vtkMRMLViewNode node (i.e. when a view node is added, it's up to you to add that observer on the view node, when the node is removed, you remove that observer): if a view becomes "active", it means that it is "selected". Right now, in dual view mode, the active view is the last one that was interacted with: it has a darker outline. This active event is useful essentially because of the left panel UI. If you have some UI that reflects the parameters used in VolumeRendering for example (say a LUT editor), it is possible you may want to apply those parameters only to the resources pertaining to a specific view. In any case, when you receive an Active event, your UI is given the opportunity to update the parameters that are only relevant to that specific view.<br />
<br />
What is said in that first bullet point is not exactly helping though: vtkMRMLScene::NodeAddedEvent is triggered when a vtkMRMLViewNode is added, but it is still too early for your module to add resources to that view (i.e. the renderers), because the corresponding vtkSlicerViewerWidget has not been created; this is done in UpdateMain3DViewers(). So even though you may want to listen to NodeAddedEvent to prepare some resources, you still can't add them, no renderers are ready for your actors. What you need is a way to know that the corresponding SlicerViewerWidget has been created. To fix that situation, your module should ultimately:<br />
<br />
* listen to vtkMRMLViewNode::GraphicalResourcesCreatedEvent, sent by a vtkMRMLViewNode node (same as #3, it's up to you to add that observer on the view node, by first listening to vtkMRMLScene::NodeAddedEvent). This event carries a pointer to the corresponding vtkSlicerViewerWidget that was just created in UpdateMain3DViewers(). Now seems a good time for you to add your actors to the renderers.<br />
<br />
Note that this doesn't necessarily conflict with the idea that a viewer widget, as Jim Miller suggested, could keep track of what is visible or not in its own render window... I guess for the time being we could <br />
let the modules automatically add their actors to each new view when they are added to the scene, as described above, and then later on we can come up with something to turn the visibility on/off of actors in each viewer...<br />
<br />
To sum up:<br />
<br />
* listen to vtkMRMLScene::NodeAddedEvent and vtkMRMLScene::NodeRemovedEvent on the scene,<br />
* received vtkMRMLScene::NodeAddedEvent and its a new vtkMRMLViewNode? Allocate your graphical resources (don't add them yet), add vtkMRMLViewNode::GraphicalResourcesCreatedEvent and vtkMRMLViewNode::ActiveModifiedEvent to this new view node to know when graphical resources have been created for that view (the renderwindow, renderers, etc), and when the view becomes "the active one",<br />
* received vtkMRMLViewNode::GraphicalResourcesCreatedEvent? time to add your actors to the corresponding view,<br />
* received vtkMRMLViewNode::ActiveModifiedEvent? time to refresh your UI in the left panel<br />
* received vtkMRMLScene::NodeRemovedEvent and it's a vtkMRMLViewNode? Time to remove your resources from that view.<br />
<br />
Now of course the choice of allocating resources *per view* depends on the module. One can technically add the same actor to different renderers, but this doesn't always do the trick (especially not for volume rendering). For example, fiducials use vtkFollower actors to make sure labels always face the camera. Since the camera is different for each renderer, this resource will have to be allocated for *each view*. It's likely up to the module to maintain some sort of STL map associating a view to the resources for that view.<br />
<br />
== TODO ==<br />
<br />
As of Slicer 3.6:<br />
* there is one 'full featured' 3D viewer, which is the one at the top in the default layout. This is the one where volume rendering, fiducials, ROIs (box widget), and other actions take place,<br />
* there can be multiple 'secondary' 3D views that have independent cameras but only see the models (essentially just the vtkActors but not widgets or volumes).<br />
<br />
All modules that display an actor on screen are technically concerned and need to be revisited to use the new framework. Now that the multi camera/views logic is in the core, it's a matter of letting the module maintainers<br />
know that they can upgrade their code to use this particular set of functionality (which didn't exist when modules<br />
like Fiducials, Volume Rendering, etc were first developed).<br />
<br />
Modules that need to be upgraded (please keep updating this list):<br />
* Fiducials<br />
* Volume Rendering</div>Barrehttps://www.slicer.org/w/index.php?title=Slicer3:Multiple_Cameras&diff=13287Slicer3:Multiple Cameras2010-04-07T19:58:56Z<p>Barre: </p>
<hr />
<div>== Goal ==<br />
<br />
== Implementation ==<br />
<br />
Here are a few pointers related to the new framework. What happens under the hood, and what events developers and module maintainers can intercept to use the new features.<br />
<br />
The workflow so far (Slicer 3.6, as of November 2009):<br />
<br />
When a vtkMRMLViewNode is created and added to the MRML scene (say by a module, or by the main app, or a third party):<br />
<br />
* vtkSlicerApplicationGUI, which listens to vtkMRMLScene::NodeAddedEvent, sees that a new view node has been <br />
created, and calls vtkSlicerApplicationGUI::OnViewNodeAdded().<br />
<br />
* OnViewNodeAdded() adds a few observers to the view node, and if there is no other vtkMRMLViewNode around (i.e. if it's the first one), it is automatically tagged as "Active". vtkSlicerApplicationGUI::UpdateMain3DViewers() is then called.<br />
<br />
* UpdateMain3DViewers(), a fair amount is done here, but the gist is: the function loops over all the vtkMRMLViewNode in the scene, and if it finds out that one doesn't have an associated vtkSlicerViewerWidget yet (i.e. the graphical part that really makes up the view), it allocates and Create()'s one and set its ViewNode ivar to the vtkMRMLViewNode pointer. This is the only place in Slicer3 where vtkSlicerViewerWidget::New() is created (this wasn't the case before, I factorized it). Note that some MRML nodes like vtkMRMLCamera maintain and allocate their VTK counterpart automatically (vtkCamera). This is not the case for vtkMRMLViewNode (I don't know why, but I didn't want to break that for backward compatibility, therefore that design didn't change).<br />
<br />
In a similar fashion, vtkSlicerApplicationGUI listens to vtkMRMLScene::NodeRemovedEvent, calls<br />
vtkSlicerApplicationGUI::OnViewNodeRemoved, which remove previous observers, and calls UpdateMain3DViewers() as well. This function still does what is described above, but also loops over all the vtkSlicerViewerWidget it knows: if the corresponding vtkMRMLViewNode doesn't exist anymore (since it was just removed), it deletes that viewer widget, which should free the corresponding graphic resources.<br />
<br />
Module maintainers should not have to worry about the creation of Slicer Viewer Widgets, as this is taken care of as described above. What a module should do:<br />
<br />
* listen to vtkMRMLScene::NodeAddedEvent, sent by the MRML scene: if a vtkMRMLViewNode has been added, that means you may have to prepare yourself for allocating the resources you will put in that view (vtkSlicerViewerWidget ),<br />
<br />
* listen to vtkMRMLScene::NodeRemovedEvent, sent by the MRML scene: if a vtkMRMLViewNode is being removed, this is definitely the time for your module to remove your resources from that view, and probably free them.<br />
<br />
* listen to vtkMRMLViewNode::ActiveModifiedEvent, sent by a vtkMRMLViewNode node (i.e. when a view node is added, it's up to you to add that observer on the view node, when the node is removed, you remove that observer): if a view becomes "active", it means that it is "selected". Right now, in dual view mode, the active view is the last one that was interacted with: it has a darker outline. This active event is useful essentially because of the left panel UI. If you have some UI that reflects the parameters used in VolumeRendering for example (say a LUT editor), it is possible you may want to apply those parameters only to the resources pertaining to a specific view. In any case, when you receive an Active event, your UI is given the opportunity to update the parameters that are only relevant to that specific view.<br />
<br />
What is said in that first bullet point is not exactly helping though: vtkMRMLScene::NodeAddedEvent is triggered when a vtkMRMLViewNode is added, but it is still too early for your module to add resources to that view (i.e. the renderers), because the corresponding vtkSlicerViewerWidget has not been created; this is done in UpdateMain3DViewers(). So even though you may want to listen to NodeAddedEvent to prepare some resources, you still can't add them, no renderers are ready for your actors. What you need is a way to know that the corresponding SlicerViewerWidget has been created. To fix that situation, your module should ultimately:<br />
<br />
* listen to vtkMRMLViewNode::GraphicalResourcesCreatedEvent, sent by a vtkMRMLViewNode node (same as #3, it's up to you to add that observer on the view node, by first listening to vtkMRMLScene::NodeAddedEvent). This event carries a pointer to the corresponding vtkSlicerViewerWidget that was just created in UpdateMain3DViewers(). Now seems a good time for you to add your actors to the renderers.<br />
<br />
Note that this doesn't necessarily conflict with the idea that a viewer widget, as Jim Miller suggested, could keep track of what is visible or not in its own render window... I guess for the time being we could <br />
let the modules automatically add their actors to each new view when they are added to the scene, as described above, and then later on we can come up with something to turn the visibility on/off of actors in each viewer...<br />
<br />
To sum up:<br />
<br />
* listen to vtkMRMLScene::NodeAddedEvent and vtkMRMLScene::NodeRemovedEvent on the scene,<br />
* received vtkMRMLScene::NodeAddedEvent and its a new vtkMRMLViewNode? Allocate your graphical resources (don't add them yet), add vtkMRMLViewNode::GraphicalResourcesCreatedEvent and vtkMRMLViewNode::ActiveModifiedEvent to this new view node to know when graphical resources have been created for that view (the renderwindow, renderers, etc), and when the view becomes "the active one",<br />
* received vtkMRMLViewNode::GraphicalResourcesCreatedEvent? time to add your actors to the corresponding view,<br />
* received vtkMRMLViewNode::ActiveModifiedEvent? time to refresh your UI in the left panel<br />
* received vtkMRMLScene::NodeRemovedEvent and it's a vtkMRMLViewNode? Time to remove your resources from that view.<br />
<br />
Now of course the choice of allocating resources *per view* depends on the module. One can technically add the same actor to different renderers, but this doesn't always do the trick (especially not for volume rendering). For example, fiducials use vtkFollower actors to make sure labels always face the camera. Since the camera is different for each renderer, this resource will have to be allocated for *each view*. It's likely up to the module to maintain some sort of STL map associating a view to the resources for that view.<br />
<br />
== TODO ==<br />
<br />
As of Slicer 3.6:<br />
* there is one 'full featured' 3D viewer, which is the one at the top in the default layout. This is the one where volume rendering, fiducials, ROIs (box widget), and other actions take place,<br />
* there can be multiple 'secondary' 3D views that have independent cameras but only see the models (essentially just the vtkActors but not widgets or volumes).<br />
<br />
All modules that display an actor on screen are technically concerned and need to be revisited to use the new framework. Now that the multi camera/views logic is in the core, it's a matter of letting the module maintainers<br />
know that they can upgrade their code to use this particular set of functionality (which didn't exist when modules<br />
like Fiducials, Volume Rendering, etc were first developed).<br />
<br />
Modules that need to be upgraded (please keep updating this list):<br />
* Fiducials<br />
* Volume Rendering</div>Barrehttps://www.slicer.org/w/index.php?title=Main_Page&diff=13286Main Page2010-04-07T19:43:55Z<p>Barre: /* News */</p>
<hr />
<div>=Welcome to the 3D Slicer Wiki pages!=<br />
<br />
<br />
Welcome to the Slicer Wiki Home Page.<br />
<br />
'''How to use this site:''' <br />
* The main [http://www.slicer.org slicer.org] pages provide a guided tour to the application, training materials, and the development community. New users should start there because we try to keep it organized and up to date.<br />
* These wiki pages are more free-form, with notes and reference pages that help support developers and users across multiple sites. You will find good information on the wiki, but it's possible that it's out of date or describes features that are still in the planning phase.<br />
<br />
<gallery widths="200px" perrow="4"><br />
Image:ExtractSubvolumeROI_gallery.png|[[Modules:ExtractSubvolumeROI-Documentation-3.5|ExtractSubvolumeROI is a new GUI module in Slicer 3.5]] that allows to extract and resample an arbitrary parallelepiped shaped region from a larger scalar image volume.<br />
Image:Qt-KWW-Transforms-2009-11-24.png|Frame from a movie showing Qt Transforms module. See whole movie [http://www.youtube.com/watch?v=oJFSJWBUFEI on youtube] or download [[file:QSlicerTransformsModule.ogg]].<br />
Image:VolumeRenderingICPE.png|Volume rendering: Illustrative Context Preserving Exploration<br />
Image:Dual 3D View.png|Multiple 3D rendering windows<br />
</gallery><br />
<br />
<br />
<br />
More images at the [[Slicer3:VisualBlog| Slicer3 Visual Blog...]]<br />
<br />
----<br />
<br />
In a nutshell, Slicer3 is:<br />
* A cross-platform end user application for analyzing and visualizing medical images.<br />
* A collection of Open Source libraries for developing and deploying new image computing technologies.<br />
* Intended to replace the venerable Slicer2 (see [[Slicer3:Transition_from_Slicer2 |information on the transition]])<br />
* An algorithm development platform with a powerful new [[Slicer3:Execution_Model_Documentation| Execution Model]] to facilitate creation of new modules.<br />
<br />
----<br />
<br />
==News==<br />
* April 2010<br />
* Feature Freeze month! Developers are working on bug fixes, documentation, and performance enhancement.<br />
* Check out [http://picasaweb.google.com/107065747472066371420 Andras Jakab's impressive surgery planning images]<br />
* March 2010<br />
** New infrastructure software is rapidly evolving in the context of the [http://www.na-mic.org/Wiki/index.php/Events:CTK-Pre-Hackfest-2010 Common Toolkit working meetings].<br />
** Planning underway for [[Slicer3:3.6Release|release 3.6 of 3D Slicer]]<br />
** [http://www.medfloss.org/node/263 A slicer review on medfloss]<br />
** [http://packages.debian.org/search?keywords=slicer&searchon=names&exact=1&suite=all&section=all slicer's debian package page]<br />
** [https://launchpad.net/ubuntu/+source/slicer/ slicer ubuntu package] that can be installed with the [http://www.ubuntu.com/testing/lucid/alpha3 alpha version of Ubuntu 10.04]<br />
** A [[Slicer3:Debian | page with information about installing slicer3 on Debian]] has been started.<br />
** We are starting to make plans for [[Slicer4|3D Slicer version 4 (also known as Slicer4)]]. A big step!<br />
* January 2010<br />
** [http://wiki.na-mic.org/Wiki/index.php/2010_Winter_Project_Week 10th project week]<br />
* December 2009<br />
** Lots of activity around the [[Slicer3:Developers:Projects:QtSlicer| Port of Slicer to Qt]]<br />
** [http://www.na-mic.org/Wiki/index.php/Dec-2009-SlicerAIMBrainstorming New Annotation Tools are in the works]<br />
* November 2009<br />
**Seb Barre from Kitware has taken the lead in [[Slicer3:Multiple Cameras|adding multiple cameras]] support to Slicer 3. The work is currently focused on multiple cameras and multiple views, but only one scene. The nightly build contains a new module, called cameras. Jim Miller has added a new layout, called Dual 3D Layout. [[Image:Dual 3D View.png|thumb|200px|Dual 3D layout]].<br />
<br />
* October 2009<br />
** Test of [http://wiki.slicer.org/slicerWiki/index.php?title=Main_Page&useskin=chick mobile friendly wiki skin]<br />
*September 2009<br />
** [http://www.na-mic.org/Wiki/index.php/Sept-2009-SlicerWidgetsBrainstorm Serious work is beginning] on a [[Qt_in_Slicer3|Slicer3 port to Qt]]. <br />
** Attila Nagy and his colleagues created a [http://www.orl.szote.u-szeged.hu/~attila/presentations.html very nice set of presentations and animations] with slicer to illustrate 3D reconstruction as applied to otorhinolaryngology. (See [[Nagy-videos-2009:Notes|Notes]]).<br />
*August 2009<br />
** New images in [[Slicer3:VisualBlog|the visual blog]] show integration of slicer and [http://www.bioimagesuite.org BioImageSuite].<br />
* July 2009<br />
** Several bug fixes are being rolled into a 3.4.1 patch release, expected for beginning of August<br />
* June 2009<br />
** [http://www.na-mic.org/Wiki/index.php/2009_Summer_Project_Week NA-MIC Summer Project Week] was a great success! <br />
** New documentation is available, thanks to the [http://www.na-mic.org/Wiki/index.php/Events:TutorialContestJune2009 Summer 2009 Tutorial Contest]<br />
* May 2009<br />
** [[Announcements:Slicer3.4|Slicer 3.4 release]]<br />
** The [http://viewvc.slicer.org/branches/Slicer-3-4/ 3.4 release branch has been created in subversion] <br />
** [http://tinyurl.com/cu9bzp A punch list of 3.4 bugs] is being maintained on the Mantis Bug Tracker.<br />
* March 2009<br />
** Development of slicer3.4 is still under way. To check the status, go to the bug tracker and search for the tag "3.4 Targeted fix". Our plan is to fix anything with that tag before branching the release. http://na-mic.org/Mantis/main_page.php The svn trunk for slicer3 is still in "feature freeze" mode, meaning that only fixes should be checked in. Any new development should occur in svn branches for now.<br />
** Developers, please be sure to apply the "3.4 Targeted fix" to anything you are working on for the release.<br />
* January 2009<br />
** A product release of Slicer 3.4 is scheduled for Feb/March<br />
** There will be a code freeze on Feb 4, 2009 <br />
** Slicer3 and related research project were highlighted and demoed as part of the External Advisory Board meeting of the [http://nac.spl.harvard.edu Neuroimage Analysis Center].<br />
* December 2008<br />
** Andrew Farke posted [http://openpaleo.blogspot.com/2008/12/3d-slicer-tutorial-part-iv.html some excellent tutorials] on the use of 3D Slicer in paleontology research.<br />
** A training course on [http://www.na-mic.org/Wiki/index.php/Events:RSNA2008 use of 3D Slicer by Radiologists] was held at [http://rsna2008.rsna.org/ RSNA] in Chicago.<br />
** [http://www.ncigt.org NCIGT] is hosting a [http://www.na-mic.org/Wiki/index.php/2008_IGT_Project_Week Project Week] for developing Image Guided Therapy software that features many slicer projects.<br />
* September 2008<br />
** Andras Jakab won second place in [http://www.kitware.com/viscontest/medicalviswinner.html Kitware's medical image visualization contest!]. The image combines slice viewing, models, volume rendering, and tractography applied to a gamma knife neurooncology radiotherapy planning case. Andras used slicer's registration tools to fuse CT and diffusion MR into a multimodal scene.<br />
[[Image:Andras-Jakab-brainconnectivity.png|thumb|200px|Andras Jakab's award winning slicer image.]]<br />
** [http://www.na-mic.org/Wiki/index.php/Miccai_2008_Tutorial A NA-MIC Workshop at MICCAI] addressed the creation of ITK-based command line modules for 3D Slicer.<br />
** Slicer user Attila Nagy presented on Slicer3 for inner ear imaging ([http://www.orl.szote.u-szeged.hu/~attila/NagyA-2008-Miskolc.ppt Slides - Hungarian])<br />
** Attila also provided patches to build Slicer3 and most of Slicer2 using the latest versions of Solaris and the optimized Sun C++ compilers.<br />
* August 2008 <br />
**[http://www.na-mic.org/Wiki/index.php/Events:August_2008_NCBC_AHM August 14, 2008: NCBC 2008 Science Fair "Three ways of using the NA-MIC Kit" ]<br />
**[http://www.na-mic.org/Wiki/index.php/Events:NCI_Workshop_August_2008 August 15, 2008: NCI Workshop - August 15, 2008 ]<br />
[[Image:NITRC logo Listed.jpg|thumb|200px|http://www.nitrc.org/projects/slicer/]]<br />
* July 2008<br />
** [http://www.airwayinspector.org Airway Inspector] is a powerful tool for lung image analysis build on slicer2. A port to slicer3 is getting under way in the next few weeks and is expected to take about 6 months.<br />
** Slicer and the NA-MIC software environment were presented as part of the [https://www.ipam.ucla.edu/schedule.aspx?pc=mbi2008 UCLA Institute for Pure and Applied Mathematics Summer School on Mathematics and Brain Imaging].<br />
** A [http://www.na-mic.org/Wiki/index.php/2008_July_Slicer_IGT_VV_Link_Session_II very productive working meeting] between researchers at BWH and Yale resulted in successful connection of Slicer3 to the BrainLab commercial image guided neurosurgery system.<br />
* June 2008<br />
** [http://www.na-mic.org/Wiki/index.php/2008_June_Workshop_Germany June 16-17, 2008: Training Event in Germany]<br />
** [http://www.na-mic.org/Wiki/index.php/2008_Summer_Project_Week June 23-27, 2008, Summer Project Week]<br />
* May 2008<br />
**[[Announcements:Slicer3.2|Slicer 3.2 release]]<br />
**Slicer3 included in review paper on [http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=2039808 "Rapid Development of Medical Imaging Tools with Open Source Libraries"]<br />
* April 2008<br />
**[http://www.ohloh.net/p/3376/factoids Slicer rated in the top 2% of project teams in Ohloh]<br />
**[[Slicer3:Slicer3_Workshop_UNC_Chapel_Hill_2008| April 14, 2008: Slicer 3 User and Developer Workshop, UNC Chapel Hill]]<br />
* March 2008<br />
**A new [http://en.wikipedia.org/wiki/3DSlicer 3D Slicer Wikipedia entry] has been created.<br />
* Feb 2008<br />
**February 20th, 2008, [[Slicer3:Spring-2008-User-Training| Spring 2008 Slicer3 User Training Workshop ]] in the SPL at 1249 Boylston St. Boston.<br />
* Jan 2008<br />
**[[tutorialwishlist|Wishlist for tutorials]]<br />
**Lots of Slicer development activity as part of '''[http://www.na-mic.org/Wiki/index.php/AHM_2008 NA-MIC All Hands Meeting] and [http://www.na-mic.org/Wiki/index.php/2008_Winter_Project_Week Winter Project Week]<br />
* December 2007<br />
**A three-day retreat for [http://www.na-mic.org/Wiki/index.php/2007_December_Slicer_IGT_Programming Slicer in Image Guided Therapy] was held in Boston.<br />
* November 2007<br />
** New builds are now available for [http://www.slicer.org/DownloadSlicer.php/Snapshots/linux-x86_64/Slicer3-3.0.2007-11-21-linux-x86_64.sh Linux 64], [http://www.slicer.org/DownloadSlicer.php/Snapshots/linux-x86/Slicer3-3.0.2007-11-21-linux-x86.sh Linux 32], [http://www.slicer.org/DownloadSlicer.php/Snapshots/win32/Slicer3-3.0.2007-11-19-win32.exe Windows], [http://www.slicer.org/DownloadSlicer.php/Snapshots/darwin-ppc/Slicer3-3.0.2007-11-19-darwin-ppc.sh Darwin PPC], and [http://www.slicer.org/DownloadSlicer.php/Snapshots/darwin-x86/Slicer3-3.0.2007-11-19-darwin-x86.sh Darwin x86]<br />
* June 2007<br />
** Lots of Slicer3 work at [http://wiki.na-mic.org/Wiki/index.php/Engineering:Programming_Events the Project Weeks]<br />
* March 2007<br />
** New Image Guided Therapy (IGT) functionality for tracking surgical instruments added by developers working at the [http://www.ncigt.org National Center for IGT].<br />
* February 2007<br />
** Feb 7-8, 2007. [[Slicer3:MiniRetreat February 7-8, 2007| Slicer3 Mini-Retreat, Boston]]<br />
** Resulted in the implementation of a [[Slicer3::Python | Python interface]] to Slicer3.<br />
<br />
* January 2007<br />
** Slicer3 developers are getting together in Salt Lake City for a "programming half-week" as part of the [http://wiki.na-mic.org/Wiki/index.php/AHM_2007 NA-MIC All-Hands Meeting]<br />
** [[Slicer3:Developers#Information_for_Developers| Lots of new developer documentation added!]]<br />
** Slicer3 beta released<br />
** [http://na-mic.org/Mantis/main_page.php New bug tracker installed]<br />
* December 2006<br />
** There was a big meltdown of the na-mic.org server in December, and some things were lost including wiki history, slicer3 bug tracker and doxygen, and some of the older download files. Please bear with us as we pick ourselves up and carry on.<br />
* November 2006<br />
** [[Slicer3_Alpha_builds| Slicer3 Alpha builds]] available for Linux (32 and 64 bit) and windows!<br />
* October 2006<br />
** Slicer3 development version shown at the [http://www.nbirn.net/press/current/ahm2006.shtm BIRN All Hands Meeting] as the platform for the BIRN Query Atlas Project and overall visualization issue in BIRN. See [[Media:BIRNFIPS2Slicer3-2006-10-24.ppt| these slides for more information]].<br />
* September 2006:<br />
** [http://wiki.na-mic.org/Wiki/index.php/2006_September_Slicer3_Update Development meeting at BWH September 19, 20.]<br />
* July, 2006:<br />
** There was active development of Slicer3 at and around the [http://wiki.na-mic.org/Wiki/index.php/2006_Programming/Project_Week_MIT NA-MIC Programming/Project week].<br />
** New Slicer3 wiki page organization is under way. Please send feedback to the [mailto:slicer-devel@massmail.spl.harvard.edu slicer-developers mailing list].<br />
<br><br />
----<br />
<br><br />
*[[Editing Guide:Getting Started|Wiki Editing Guide]]<br />
<br />
=== For Wiki Administration ===<br />
<br />
* [[Special:Userlogin|Create user account]]<br />
* [[Special:Listusers|Users List]]<br />
* Authorized users can commit edited web pages through [https://www.slicer.org/slicerWikiWeb/ slicer's wiki2web interface]</div>Barrehttps://www.slicer.org/w/index.php?title=Slicer3:Multiple_Cameras&diff=13283Slicer3:Multiple Cameras2010-04-07T19:20:06Z<p>Barre: Created page with '== Logic == Here are a few pointers related to the new framework. What happens under the hood, and what events developers and module maintainers can intercept to use the new fea…'</p>
<hr />
<div>== Logic ==<br />
<br />
Here are a few pointers related to the new framework. What happens under the hood, and what events developers and module maintainers can intercept to use the new features.<br />
<br />
The workflow so far (Slicer 3.6, as of November 2009):<br />
<br />
When a vtkMRMLViewNode is created and added to the MRML scene (say by a module, or by the main app, or a third party):<br />
<br />
* vtkSlicerApplicationGUI, which listens to vtkMRMLScene::NodeAddedEvent, sees that a new view node has been <br />
created, and calls vtkSlicerApplicationGUI::OnViewNodeAdded().<br />
<br />
* OnViewNodeAdded() adds a few observers to the view node, and if there is no other vtkMRMLViewNode around (i.e. if it's the first one), it is automatically tagged as "Active". vtkSlicerApplicationGUI::UpdateMain3DViewers() is then called.<br />
<br />
* UpdateMain3DViewers(), a fair amount is done here, but the gist is: the function loops over all the vtkMRMLViewNode in the scene, and if it finds out that one doesn't have an associated vtkSlicerViewerWidget yet (i.e. the graphical part that really makes up the view), it allocates and Create()'s one and set its ViewNode ivar to the vtkMRMLViewNode pointer. This is the only place in Slicer3 where vtkSlicerViewerWidget::New() is created (this wasn't the case before, I factorized it). Note that some MRML nodes like vtkMRMLCamera maintain and allocate their VTK counterpart automatically (vtkCamera). This is not the case for vtkMRMLViewNode (I don't know why, but I didn't want to break that for backward compatibility, therefore that design didn't change).<br />
<br />
In a similar fashion, vtkSlicerApplicationGUI listens to vtkMRMLScene::NodeRemovedEvent, calls<br />
vtkSlicerApplicationGUI::OnViewNodeRemoved, which remove previous observers, and calls UpdateMain3DViewers() as well. This function still does what is described above, but also loops over all the vtkSlicerViewerWidget it knows: if the corresponding vtkMRMLViewNode doesn't exist anymore (since it was just removed), it deletes that viewer widget, which should free the corresponding graphic resources.<br />
<br />
Module maintainers should not have to worry about the creation of Slicer Viewer Widgets, as this is taken care of as described above. What a module should do:<br />
<br />
* listen to vtkMRMLScene::NodeAddedEvent, sent by the MRML scene: if a vtkMRMLViewNode has been added, that means you may have to prepare yourself for allocating the resources you will put in that view (vtkSlicerViewerWidget ),<br />
<br />
* listen to vtkMRMLScene::NodeRemovedEvent, sent by the MRML scene: if a vtkMRMLViewNode is being removed, this is definitely the time for your module to remove your resources from that view, and probably free them.<br />
<br />
* listen to vtkMRMLViewNode::ActiveModifiedEvent, sent by a vtkMRMLViewNode node (i.e. when a view node is added, it's up to you to add that observer on the view node, when the node is removed, you remove that observer): if a view becomes "active", it means that it is "selected". Right now, in dual view mode, the active view is the last one that was interacted with: it has a darker outline. This active event is useful essentially because of the left panel UI. If you have some UI that reflects the parameters used in VolumeRendering for example (say a LUT editor), it is possible you may want to apply those parameters only to the resources pertaining to a specific view. In any case, when you receive an Active event, your UI is given the opportunity to update the parameters that are only relevant to that specific view.<br />
<br />
What is said in that first bullet point is not exactly helping though: vtkMRMLScene::NodeAddedEvent is triggered when a vtkMRMLViewNode is added, but it is still too early for your module to add resources to that view (i.e. the renderers), because the corresponding vtkSlicerViewerWidget has not been created; this is done in UpdateMain3DViewers(). So even though you may want to listen to NodeAddedEvent to prepare some resources, you still can't add them, no renderers are ready for your actors. What you need is a way to know that the corresponding SlicerViewerWidget has been created. To fix that situation, your module should ultimately:<br />
<br />
* listen to vtkMRMLViewNode::GraphicalResourcesCreatedEvent, sent by a vtkMRMLViewNode node (same as #3, it's up to you to add that observer on the view node, by first listening to vtkMRMLScene::NodeAddedEvent). This event carries a pointer to the corresponding vtkSlicerViewerWidget that was just created in UpdateMain3DViewers(). Now seems a good time for you to add your actors to the renderers.<br />
<br />
Note that this doesn't necessarily conflict with the idea that a viewer widget, as Jim Miller suggested, could keep track of what is visible or not in its own render window... I guess for the time being we could <br />
let the modules automatically add their actors to each new view when they are added to the scene, as described above, and then later on we can come up with something to turn the visibility on/off of actors in each viewer...<br />
<br />
To sum up:<br />
<br />
* listen to vtkMRMLScene::NodeAddedEvent and vtkMRMLScene::NodeRemovedEvent on the scene,<br />
* received vtkMRMLScene::NodeAddedEvent and its a new vtkMRMLViewNode? Allocate your graphical resources (don't add them yet), add vtkMRMLViewNode::GraphicalResourcesCreatedEvent and vtkMRMLViewNode::ActiveModifiedEvent to this new view node to know when graphical resources have been created for that view (the renderwindow, renderers, etc), and when the view becomes "the active one",<br />
* received vtkMRMLViewNode::GraphicalResourcesCreatedEvent? time to add your actors to the corresponding view,<br />
* received vtkMRMLViewNode::ActiveModifiedEvent? time to refresh your UI in the left panel<br />
* received vtkMRMLScene::NodeRemovedEvent and it's a vtkMRMLViewNode? Time to remove your resources from that view.<br />
<br />
Now of course the choice of allocating resources *per view* depends on the module. One can technically add the same actor to different renderers, but this doesn't always do the trick (especially not for volume rendering). For example, fiducials use vtkFollower actors to make sure labels always face the camera. Since the camera is different for each renderer, this resource will have to be allocated for *each view*. It's likely up to the module to maintain some sort of STL map associating a view to the resources for that view.<br />
<br />
== What remains to be done ==<br />
<br />
As of Slicer 3.6:<br />
* there is one 'full featured' 3D viewer, which is the one at the top in the default layout. This is the one where volume rendering, fiducials, ROIs (box widget), and other actions take place,<br />
* there can be multiple 'secondary' 3D views that have independent cameras but only see the models (essentially just the vtkActors but not widgets or volumes).<br />
<br />
All modules that display an actor on screen are technically concerned and need to be revisited to use the new framework. Now that the multi camera/views logic is in the core, it's a matter of letting the module maintainers<br />
know that they can upgrade their code to use this particular set of functionality (which didn't exist when modules<br />
like Fiducials, Volume Rendering, etc were first developed).<br />
<br />
Modules that need to be upgraded (please keep updating this list):<br />
- Fiducials<br />
- Volume Rendering</div>Barrehttps://www.slicer.org/w/index.php?title=Slicer3:GPURayCaster&diff=11786Slicer3:GPURayCaster2010-01-11T20:36:32Z<p>Barre: /* GPU Ray Caster */</p>
<hr />
<div>== GPU Ray Caster ==<br />
<br />
<br />
This project involves moving the GPU Ray Caster from VTKEdge into VTK, then making this volume mapper available from Slicer. <br />
<br />
<br />
'''Overview of GPU Ray Casting'''<br />
<br />
VTK supports several volume rendering techniques for both regular, rectilinear grids (vtkImageData), and tetrahedral meshes (represented by vtkUnstructuredGrid). Some of these volume mappers primarily utilize the CPU (relying on the GPU only for the final display of the resulting image), while other mappers make use of the resources available on the GPU such as 2D and 3D texture memory and texture mapping functionality. The new vtkKWEGPURayCastMapper in VTKEdge uses the latest advancements available on recent GPUs including fragment programs with conditional and loop operations, multi-texturing and frame buffer objects in order to deliver significantly improved performance over the CPU-based ray casting, while still maintaining high rendering quality.<br />
<br />
The basic ray casting concept is quite simple. For each pixel in the final image a ray is traced from the camera through the pixel and into the scene. As the ray passes through a volume in the scene the scalar data is sampled along the ray and those samples are processed and combined to form a final RGBA result for the pixel. The implementation of the ray casting algorithm within an object-oriented visualization system, such as VTK, that utilizes object-order rendering (polygonal projection) for other data objects in the scene is a bit more complex, requiring the ray casting process to consider the current state of the frame buffer in order to intermix the volume data with other geometric data in the scene. In our GPU implementation of ray casting, the volume data is stored on the GPU in 3D texture memory. Ray casting is initiated by rendering a polygonal representation of the outer surface of the volume. A fragment program is executed at each pixel to traverse the data and determine a resulting value that is combined with the existing pixel value in the frame buffer computed during the opaque geometry phase of rendering.<br />
<br />
For more detailed information, please see the July 2008 edition of The Source, which can be found here: http://kitware.com/products/archive/kitware_quarterly0708.pdf.<br />
<br />
<br />
'''Integration into VTK'''<br />
<br />
The GPU Ray Caster was initially funded by the following SBIR projects:<br />
<br />
"Visualization of Massive Multivariate AMR Data"<br />
National Science Foundation<br />
Contract Number OII-0548729 <br />
<br />
"Rapid, Hardware Accelerated, Large Data Visualization"<br />
Department of Defense / Army Research Laboratory<br />
Contract Number W911NF-06-C-0179<br />
<br />
The output of these projects was a new toolkit under GPL terms called VTKEdge. As part of this project, the GPU Ray Caster will be moved out of the VTKEdge toolkit into the BSD licensed Visualization Toolkit (VTK). In the process, the names of the classes will be changed to follow VTK conventions. <br />
<br />
This relocation is currently in process and is expected to be complete by January 11th. The new classes will be located in the VolumeRendering kit of VTK.<br />
<br />
<br />
'''Integration into Slicer'''<br />
<br />
The plan is to review the current Volume Renderer module and work with Yanling Liu <vrnova@gmail.com> and<br />
Alex Yarmarkovich <alexy@bwh.harvard.edu> to integrate the new mappers to the current Volume Rendering GUI, so that they can be selected at run-time.</div>Barrehttps://www.slicer.org/w/index.php?title=Qt_in_Slicer3&diff=10700Qt in Slicer32009-09-16T17:20:27Z<p>Barre: /* Considerations and Open Questions */</p>
<hr />
<div>This page captures the design considerations about moving Slicer3 from KWWidgets to [http://qt.nokia.com/ Qt]. As of August 2009 there are no concrete plans for a switch; however there is significant momentum around Qt as an open source technology and interest in making it available to the Slicer community.<br />
<br />
==Background==<br />
<br />
When Slicer3 was being designed in 2004 Qt was available only under the GPL license or a commercial (pay) license (See [http://en.wikipedia.org/wiki/Qt_%28toolkit%29 the wikipedia discussion]) and neither license option was acceptable to the community. In March 2009 Qt 4.5 was released under the LGPL license and became a possible technology for use in Slicer.<br />
<br />
Slicer3 is implemented using [http://www.kwwidgets.org KWWidgets] which has proven to be extremely capable and robust. However, due to the small size of the developer team for KWWidgets Kitware has been clear that it will not be able to compete with the features being added to Qt and is in fact adopting Qt for many of its internal projects (see, for example, [http://paraview.org ParaView] which migrated to Qt over the past several years).<br />
<br />
==Experiments==<br />
[[Image:Slicer3.5+Qt+Python-Test-2009-08-27.png|thumb|right|Screenshot from a version of slicer that has Qt accessible from the python console.]]<br />
In August of 2009 several members of the slicer development team have been learning about Qt and reviewing options. Things that are currently working:<br />
* Qt and KWWidgets can co-exist in same application environment (in different top level windows).<br />
* Qt widgets interfaces can be assembled using the QtDesigner, C++, or python.<br />
* It is feasible to create slicer widgets that use Qt (e.g. a NodeSelector widget).<br />
<br />
Overall the experience has been positive but the experiments have shown that there will be a significant amount of programming work to be done for each part of the interface. Most of the work is probably best characterized as "easy but time consuming". The net result of converting is expected to be positive but it is likely to be several years for there to be a payoff in terms of overall increased developer productivity and improved functionality of the overall package.<br />
<br />
==Development Plan Option for Transition to Qt==<br />
<br />
The following is a summary of the work to be done organized in a more-or-less priority order that would allow a transition in-place of functionality from KWW to Qt.<br />
<br />
# Configure CPack to include Qt libraries and turn on Qt support by default in nightly builds of slicer<br />
# Create prototype modules built using Qt (these would appear in a distinct top level window from the rest of slicer. The size and position would be under programatic control to make the two interface somewhat unified).<br />
# Migrate the vtkSlicerViewerWidget, vtkSlicerSliceControllerWidget, and vtkSlicerSliceWidget from KWW to Qt. This would allow the right side (2D/3D viewers) of the interface to exist in Qt with the left side (module interfaces) to exist in KWWidgets.<br />
# Migrate interfaces from modules and left side functions into Qt<br />
## the menu bar, tool bar, modules menu, module search and history controls<br />
## the CommandLineModuleGUI (so CLI modules will work in Qt)<br />
## the "Manipulate Slice Views" and "Manipulate 3D View" controls<br />
# Transition other dialogs and modules to Qt<br />
## Add Data, Add Volume, Save, Extension Wizard, Application Settings, Cache & Remote I/O Manager, Tcl/Python Interactors, ErrorLog Dialog, Keyboard Shortcuts...<br />
## Core Modules: Colors, Data, Editor, Fiducials, Measurements, Models, ROI, SlicerWelcome, Slices, Transforms, Volume Rendering, Volumes<br />
## Application Modules: Change Tracker, IA_FEMesh, Qdec, FetchMI, Query Atlas, AC/PC Transform, ModelMirror, EMSegment, LabelStatistics, Tractography, Fiber Bundles, NeuroNav, OpenIGTLink IF, ProstateNav, Clip Model, Extract Subvolume ROI, 4D Volume, 4D Analysis.<br />
## Extension Modules and DBP Projects: Perk Station, VMTK Vessel Tools, others...<br />
# Remove KWW from the builds and do a new release.<br />
<br />
==Slicer's KWWidgets-based GUI==<br />
===Statistics===<br />
* There are '''3309''' KWWidgets instances created in slicer core and modules (calls to New)<br />
* These calls are from '''123''' different KWWidget classes (including 'pure' KW classes in slicer that only depend on vtkKW and not MRML or other slicer code) <br />
* '''37''' KKWidgets subclasses are vtkKWMimx classes in the Meshing module<br />
* There are '''105''' classes that subclass from KWWidget classes<br />
<br />
See: [[Slicer3:KKWidgets_being_used| this list of KWWidgets being used in Slicer3]].<br />
<br />
''Statistics methods: Calculations based on slicer3 trunk revision 10456 2009-09-10. This does not include Tcl or Python code or extension modules (they use basically the same widgets).''<br />
<br />
grep -r vtkKW . | grep -v svn | grep New | wc<br />
grep -r vtkKW . | grep -v svn | grep "::New" | tr " " "\n" | tr "=" "\n" | tr ">" "\n" | grep -v "^//" | grep "vtkKW.*New" | sed 's/::New.*//' | sort | uniq | wc<br />
grep -r vtkKW . | grep -v svn | grep "::New" | tr " " "\n" | tr "=" "\n" | tr ">" "\n" | grep -v "^//" | grep "vtkKW.*New" | sed 's/::New.*//' | sort | uniq | grep Mimx | wc<br />
grep -r vtkKW . | grep -v svn | grep public | wc'<br />
<br />
==Qt widgets of interest==<br />
<br />
Playing with Qt Designer is a good way to explore Qt's core widgets. However, some KWW widgets are fairly complex, or uses Tk canvases pretty heavily; here are a few Qt widgets replacements worth considering. They are either found in the core distribution, or in [http://qt.nokia.com/products/appdev/add-on-products/catalog/4 Qt Solutions Catalog] (LGPL):<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:KWWidgetsCoreWidgetsOverview.png Thumbwheel]. Qt provides a [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtthumbwheel QtThumbWheel]<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:KWFileBrowserDialogExample.png FileBrowser] set of classes. Qt provides a [http://doc.trolltech.com/4.5/qfiledialog.html#sidebarUrls QFileDialog] class. It uses the native file dialogs on Win32/MacOS, and [http://doc.trolltech.com/4.5/qfiledialog.html#sidebarUrls a different one] on Unix, though it can use the same non-native dialog on all platforms. It can be set to pick directories only; a combination of QFile and QDirView can achieve a [http://doc.trolltech.com/4.5/images/dirview-example.png similar/better result]. ParaView uses a custom (rewritten) [http://wiki.slicer.org/slicerWiki/index.php/File:ParaViewQtFileDialog.png File Dialog] to handle client-server file browsing. Load/Save buttons are trivial to implement.<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:VtkKWColorPickerDialog_Classes.png Color Picker]. Qt provides a [http://doc.trolltech.com/4.5/qcolordialog.html#details QColorDialog], [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtcolorpicker QtColorPicker], [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtcolortriangle QtColorTriangle] and [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtcolorcombobox QtColorComboBox]. It is worth noting that QColorDialog offers basic colors (swatches), custom colors, RGB/HSV sliders on Win32/Unix, but uses a much more elaborate (native?) [http://www.randelshofer.ch/quaqua/guide/images/jcolorchooser.png dialog on Mac].<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:KWWidgetsTransferFunctionEditors.png Transfer Function Editors]. ParaView (BSD) and Maverick share a [http://wiki.slicer.org/slicerWiki/index.php/File:ParaViewTransferFunctionEditor.png similar transfer function editor] that is not as elaborated as KWW's, though this might do the trick for now. ParaView recently added a second (user-contributed) [http://wiki.slicer.org/slicerWiki/index.php/File:ParaViewTransferFunctionEditor2.png transfer function editor] that provides free-form and gaussian curves.<br />
<br />
* KWW's [http://www.slicer.org/slicerWiki/index.php/Modules:MainApplicationGUI-Documentation-3.4#Slicer_Viewers Collapsible Frames]. The first (easiest) solution is to use a [http://doc.trolltech.com/4.5/qgroupbox.html#details QGroupBox] and manually connect the checked SIGNAL with the setVisible SLOT of all the children. You would get the same behavior (a checkbox on the left of the title instead of a cross and arrow on the left). The second solution is to inherit from QGroupBox and change the display (change the mark in the checkbox display to have + and -). [http://wiki.slicer.org/slicerWiki/index.php/File:QGroupBox.png screenshot for both solutions]. Qt also offers tab widgets and toolboxes widgets to save space.<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:EMSegmentationModuleWizardAnimated.gif Wizard] classes. Qt provides sophisticated [http://doc.trolltech.com/4.5/qwizard.html#wizard-look-and-feel QWizard] classes, as well as a [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Utilities/qt-state-machine-framework/ Qt State Machine] framework. It is not clear if a Qt Wizard can be embedded inside another widget, since it inherits QDialog.<br />
<br />
* KWW's [http://wiki.slicer.org/slicerWiki/index.php/File:ParaViewTransferFunctionEditor2.png Range and Extent] Widgets. JS will show how to develop a [http://wiki.slicer.org/slicerWiki/index.php/File:QtSlicerDemoScreenshot-0.2.png Range slider] in a few minutes (ok, say a couple hours).<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:KWWidgetsLogDialog.png error/info log window]. A Qt [http://wiki.slicer.org/slicerWiki/index.php/File:KWQtLogDialog.png Log Dialog] was developed internally at Kitware (SB), and could most likely be reused.<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:KWWidgetsCoreWidgetsOverview.png Multi Column Widget and Tree]. Qt provides a sophisticated [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtpropertybrowser/ Qt Property Browser], as well as a large set of classes part of its [http://doc.trolltech.com/4.5/model-view-introduction.html Model/View Framework], including [http://doc.trolltech.com/4.5/model-view-view.html#using-an-existing-view tree, list and tables views/widgets], delegates, selection models, drag&drop, etc. See how it is used in Kitware's [http://wiki.slicer.org/slicerWiki/index.php/File:ScreenshotMerlinByKitware.png Merlin/Maverick].<br />
<br />
* Undo/Redo. Qt offers a [http://doc.trolltech.com/4.5/qundo.html Undo/Redo framework].<br />
<br />
* Misc. Qt [http://doc.trolltech.com/4.5/qdial.html#details QDial], [http://doc.trolltech.com/4.5/qcalendarwidget.html#details QCalendarWidget], [http://doc.trolltech.com/4.5/qprogressbar.html#details QProgressBar], [http://doc.trolltech.com/4.5/qspinbox.html#details QSpinBox], [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtpiemenu QtPieMenu]<br />
<br />
* Qt's resource editor is way more powerful and easy to use, and integrated in Qt Designer.<br />
<br />
==Considerations and Open Questions==<br />
# Coding styles and conventions for classes that interface vtk and Qt<br />
## inheritance<br />
## memory management (see [http://labs.trolltech.com/blogs/2009/08/25/count-with-me-how-many-smart-pointer-classes-does-qt-have/ how many smart pointer classes does Qt have?])<br />
# a significant number of higher level Qt widgets are required (Ranges, Extents, TransferFunctionEditors, Material Properties...)<br />
# Work needs to be coordinated among developers at multiple sites. Significant face-to-face time should be planned to keep everyone in sync on the progress.<br />
# It will be inevitable that revisiting some modules will involve redesign and feature improvements even if our focus is specifically on swapping the GUI.<br />
# Difficult bugs will occur somewhere along the process even if the plan appears smooth.<br />
# We should consider training courses or conferences to get us up to speed on best practices for development. (http://www.ics.com/QuickStart/, http://qt.nokia.com/qtdevdays2009)<br />
# What larger design re-works should be considered at the same time? I.e. should slicer functionality be re-organized as python packages so we can get away from the monolithic application attributes of the current main program (without a reduction in functionality or usability).<br />
<br />
==Development Approaches / Tradeoffs ==<br />
Several development approaches could be taken each of which has pros/cons and risks.<br />
<br />
# ''Immediate rewrite:'' this approach would be to start a from scratch to build a new GUI using Qt. Pros: likely to result in a cleaner architecture. Cons: all progress stops until new version is ready; current slicer developers are not Qt experts so not ready to build complex application from scratch; Qt does not have all the needed widgets to implement slicer (they need to be built along side slicer).<br />
# ''Wait and see:'' wait until Qt more 3rd party widgets fill in the missing functionality and then do the rewrite. Cons: any new GUI development in the old framework will seem like a dead end. Pros: the current framework isn't really broken so why change?<br />
# ''Peaceful coexistence:'' allow both GUI frameworks to be used together and allow people to develop in whichever is most productive for them. Cons: extra dependencies and potential maintenance issues; may require duplicated code; still need to resolve the architecture issues for mixing vtk and qt. Pros: removes pressure to do instant port; allows developers to get good at Qt before undertaking a big porting effort; allows development of 3rd party widgets that will make future ports easier.</div>Barrehttps://www.slicer.org/w/index.php?title=Qt_in_Slicer3&diff=10699Qt in Slicer32009-09-16T17:19:26Z<p>Barre: /* Qt widgets of interest */</p>
<hr />
<div>This page captures the design considerations about moving Slicer3 from KWWidgets to [http://qt.nokia.com/ Qt]. As of August 2009 there are no concrete plans for a switch; however there is significant momentum around Qt as an open source technology and interest in making it available to the Slicer community.<br />
<br />
==Background==<br />
<br />
When Slicer3 was being designed in 2004 Qt was available only under the GPL license or a commercial (pay) license (See [http://en.wikipedia.org/wiki/Qt_%28toolkit%29 the wikipedia discussion]) and neither license option was acceptable to the community. In March 2009 Qt 4.5 was released under the LGPL license and became a possible technology for use in Slicer.<br />
<br />
Slicer3 is implemented using [http://www.kwwidgets.org KWWidgets] which has proven to be extremely capable and robust. However, due to the small size of the developer team for KWWidgets Kitware has been clear that it will not be able to compete with the features being added to Qt and is in fact adopting Qt for many of its internal projects (see, for example, [http://paraview.org ParaView] which migrated to Qt over the past several years).<br />
<br />
==Experiments==<br />
[[Image:Slicer3.5+Qt+Python-Test-2009-08-27.png|thumb|right|Screenshot from a version of slicer that has Qt accessible from the python console.]]<br />
In August of 2009 several members of the slicer development team have been learning about Qt and reviewing options. Things that are currently working:<br />
* Qt and KWWidgets can co-exist in same application environment (in different top level windows).<br />
* Qt widgets interfaces can be assembled using the QtDesigner, C++, or python.<br />
* It is feasible to create slicer widgets that use Qt (e.g. a NodeSelector widget).<br />
<br />
Overall the experience has been positive but the experiments have shown that there will be a significant amount of programming work to be done for each part of the interface. Most of the work is probably best characterized as "easy but time consuming". The net result of converting is expected to be positive but it is likely to be several years for there to be a payoff in terms of overall increased developer productivity and improved functionality of the overall package.<br />
<br />
==Development Plan Option for Transition to Qt==<br />
<br />
The following is a summary of the work to be done organized in a more-or-less priority order that would allow a transition in-place of functionality from KWW to Qt.<br />
<br />
# Configure CPack to include Qt libraries and turn on Qt support by default in nightly builds of slicer<br />
# Create prototype modules built using Qt (these would appear in a distinct top level window from the rest of slicer. The size and position would be under programatic control to make the two interface somewhat unified).<br />
# Migrate the vtkSlicerViewerWidget, vtkSlicerSliceControllerWidget, and vtkSlicerSliceWidget from KWW to Qt. This would allow the right side (2D/3D viewers) of the interface to exist in Qt with the left side (module interfaces) to exist in KWWidgets.<br />
# Migrate interfaces from modules and left side functions into Qt<br />
## the menu bar, tool bar, modules menu, module search and history controls<br />
## the CommandLineModuleGUI (so CLI modules will work in Qt)<br />
## the "Manipulate Slice Views" and "Manipulate 3D View" controls<br />
# Transition other dialogs and modules to Qt<br />
## Add Data, Add Volume, Save, Extension Wizard, Application Settings, Cache & Remote I/O Manager, Tcl/Python Interactors, ErrorLog Dialog, Keyboard Shortcuts...<br />
## Core Modules: Colors, Data, Editor, Fiducials, Measurements, Models, ROI, SlicerWelcome, Slices, Transforms, Volume Rendering, Volumes<br />
## Application Modules: Change Tracker, IA_FEMesh, Qdec, FetchMI, Query Atlas, AC/PC Transform, ModelMirror, EMSegment, LabelStatistics, Tractography, Fiber Bundles, NeuroNav, OpenIGTLink IF, ProstateNav, Clip Model, Extract Subvolume ROI, 4D Volume, 4D Analysis.<br />
## Extension Modules and DBP Projects: Perk Station, VMTK Vessel Tools, others...<br />
# Remove KWW from the builds and do a new release.<br />
<br />
==Slicer's KWWidgets-based GUI==<br />
===Statistics===<br />
* There are '''3309''' KWWidgets instances created in slicer core and modules (calls to New)<br />
* These calls are from '''123''' different KWWidget classes (including 'pure' KW classes in slicer that only depend on vtkKW and not MRML or other slicer code) <br />
* '''37''' KKWidgets subclasses are vtkKWMimx classes in the Meshing module<br />
* There are '''105''' classes that subclass from KWWidget classes<br />
<br />
See: [[Slicer3:KKWidgets_being_used| this list of KWWidgets being used in Slicer3]].<br />
<br />
''Statistics methods: Calculations based on slicer3 trunk revision 10456 2009-09-10. This does not include Tcl or Python code or extension modules (they use basically the same widgets).''<br />
<br />
grep -r vtkKW . | grep -v svn | grep New | wc<br />
grep -r vtkKW . | grep -v svn | grep "::New" | tr " " "\n" | tr "=" "\n" | tr ">" "\n" | grep -v "^//" | grep "vtkKW.*New" | sed 's/::New.*//' | sort | uniq | wc<br />
grep -r vtkKW . | grep -v svn | grep "::New" | tr " " "\n" | tr "=" "\n" | tr ">" "\n" | grep -v "^//" | grep "vtkKW.*New" | sed 's/::New.*//' | sort | uniq | grep Mimx | wc<br />
grep -r vtkKW . | grep -v svn | grep public | wc'<br />
<br />
==Qt widgets of interest==<br />
<br />
Playing with Qt Designer is a good way to explore Qt's core widgets. However, some KWW widgets are fairly complex, or uses Tk canvases pretty heavily; here are a few Qt widgets replacements worth considering. They are either found in the core distribution, or in [http://qt.nokia.com/products/appdev/add-on-products/catalog/4 Qt Solutions Catalog] (LGPL):<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:KWWidgetsCoreWidgetsOverview.png Thumbwheel]. Qt provides a [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtthumbwheel QtThumbWheel]<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:KWFileBrowserDialogExample.png FileBrowser] set of classes. Qt provides a [http://doc.trolltech.com/4.5/qfiledialog.html#sidebarUrls QFileDialog] class. It uses the native file dialogs on Win32/MacOS, and [http://doc.trolltech.com/4.5/qfiledialog.html#sidebarUrls a different one] on Unix, though it can use the same non-native dialog on all platforms. It can be set to pick directories only; a combination of QFile and QDirView can achieve a [http://doc.trolltech.com/4.5/images/dirview-example.png similar/better result]. ParaView uses a custom (rewritten) [http://wiki.slicer.org/slicerWiki/index.php/File:ParaViewQtFileDialog.png File Dialog] to handle client-server file browsing. Load/Save buttons are trivial to implement.<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:VtkKWColorPickerDialog_Classes.png Color Picker]. Qt provides a [http://doc.trolltech.com/4.5/qcolordialog.html#details QColorDialog], [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtcolorpicker QtColorPicker], [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtcolortriangle QtColorTriangle] and [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtcolorcombobox QtColorComboBox]. It is worth noting that QColorDialog offers basic colors (swatches), custom colors, RGB/HSV sliders on Win32/Unix, but uses a much more elaborate (native?) [http://www.randelshofer.ch/quaqua/guide/images/jcolorchooser.png dialog on Mac].<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:KWWidgetsTransferFunctionEditors.png Transfer Function Editors]. ParaView (BSD) and Maverick share a [http://wiki.slicer.org/slicerWiki/index.php/File:ParaViewTransferFunctionEditor.png similar transfer function editor] that is not as elaborated as KWW's, though this might do the trick for now. ParaView recently added a second (user-contributed) [http://wiki.slicer.org/slicerWiki/index.php/File:ParaViewTransferFunctionEditor2.png transfer function editor] that provides free-form and gaussian curves.<br />
<br />
* KWW's [http://www.slicer.org/slicerWiki/index.php/Modules:MainApplicationGUI-Documentation-3.4#Slicer_Viewers Collapsible Frames]. The first (easiest) solution is to use a [http://doc.trolltech.com/4.5/qgroupbox.html#details QGroupBox] and manually connect the checked SIGNAL with the setVisible SLOT of all the children. You would get the same behavior (a checkbox on the left of the title instead of a cross and arrow on the left). The second solution is to inherit from QGroupBox and change the display (change the mark in the checkbox display to have + and -). [http://wiki.slicer.org/slicerWiki/index.php/File:QGroupBox.png screenshot for both solutions]. Qt also offers tab widgets and toolboxes widgets to save space.<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:EMSegmentationModuleWizardAnimated.gif Wizard] classes. Qt provides sophisticated [http://doc.trolltech.com/4.5/qwizard.html#wizard-look-and-feel QWizard] classes, as well as a [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Utilities/qt-state-machine-framework/ Qt State Machine] framework. It is not clear if a Qt Wizard can be embedded inside another widget, since it inherits QDialog.<br />
<br />
* KWW's [http://wiki.slicer.org/slicerWiki/index.php/File:ParaViewTransferFunctionEditor2.png Range and Extent] Widgets. JS will show how to develop a [http://wiki.slicer.org/slicerWiki/index.php/File:QtSlicerDemoScreenshot-0.2.png Range slider] in a few minutes (ok, say a couple hours).<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:KWWidgetsLogDialog.png error/info log window]. A Qt [http://wiki.slicer.org/slicerWiki/index.php/File:KWQtLogDialog.png Log Dialog] was developed internally at Kitware (SB), and could most likely be reused.<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:KWWidgetsCoreWidgetsOverview.png Multi Column Widget and Tree]. Qt provides a sophisticated [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtpropertybrowser/ Qt Property Browser], as well as a large set of classes part of its [http://doc.trolltech.com/4.5/model-view-introduction.html Model/View Framework], including [http://doc.trolltech.com/4.5/model-view-view.html#using-an-existing-view tree, list and tables views/widgets], delegates, selection models, drag&drop, etc. See how it is used in Kitware's [http://wiki.slicer.org/slicerWiki/index.php/File:ScreenshotMerlinByKitware.png Merlin/Maverick].<br />
<br />
* Undo/Redo. Qt offers a [http://doc.trolltech.com/4.5/qundo.html Undo/Redo framework].<br />
<br />
* Misc. Qt [http://doc.trolltech.com/4.5/qdial.html#details QDial], [http://doc.trolltech.com/4.5/qcalendarwidget.html#details QCalendarWidget], [http://doc.trolltech.com/4.5/qprogressbar.html#details QProgressBar], [http://doc.trolltech.com/4.5/qspinbox.html#details QSpinBox], [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtpiemenu QtPieMenu]<br />
<br />
* Qt's resource editor is way more powerful and easy to use, and integrated in Qt Designer.<br />
<br />
==Considerations and Open Questions==<br />
# Coding styles and conventions for classes that interface vtk and Qt<br />
## inheritance<br />
## memory management<br />
# a significant number of higher level Qt widgets are required (Ranges, Extents, TransferFunctionEditors, Material Properties...)<br />
# Work needs to be coordinated among developers at multiple sites. Significant face-to-face time should be planned to keep everyone in sync on the progress.<br />
# It will be inevitable that revisiting some modules will involve redesign and feature improvements even if our focus is specifically on swapping the GUI.<br />
# Difficult bugs will occur somewhere along the process even if the plan appears smooth.<br />
# We should consider training courses or conferences to get us up to speed on best practices for development. (http://www.ics.com/QuickStart/, http://qt.nokia.com/qtdevdays2009)<br />
# What larger design re-works should be considered at the same time? I.e. should slicer functionality be re-organized as python packages so we can get away from the monolithic application attributes of the current main program (without a reduction in functionality or usability).<br />
<br />
==Development Approaches / Tradeoffs ==<br />
Several development approaches could be taken each of which has pros/cons and risks.<br />
<br />
# ''Immediate rewrite:'' this approach would be to start a from scratch to build a new GUI using Qt. Pros: likely to result in a cleaner architecture. Cons: all progress stops until new version is ready; current slicer developers are not Qt experts so not ready to build complex application from scratch; Qt does not have all the needed widgets to implement slicer (they need to be built along side slicer).<br />
# ''Wait and see:'' wait until Qt more 3rd party widgets fill in the missing functionality and then do the rewrite. Cons: any new GUI development in the old framework will seem like a dead end. Pros: the current framework isn't really broken so why change?<br />
# ''Peaceful coexistence:'' allow both GUI frameworks to be used together and allow people to develop in whichever is most productive for them. Cons: extra dependencies and potential maintenance issues; may require duplicated code; still need to resolve the architecture issues for mixing vtk and qt. Pros: removes pressure to do instant port; allows developers to get good at Qt before undertaking a big porting effort; allows development of 3rd party widgets that will make future ports easier.</div>Barrehttps://www.slicer.org/w/index.php?title=Qt_in_Slicer3&diff=10698Qt in Slicer32009-09-16T06:31:12Z<p>Barre: /* Qt widgets of interest */</p>
<hr />
<div>This page captures the design considerations about moving Slicer3 from KWWidgets to [http://qt.nokia.com/ Qt]. As of August 2009 there are no concrete plans for a switch; however there is significant momentum around Qt as an open source technology and interest in making it available to the Slicer community.<br />
<br />
==Background==<br />
<br />
When Slicer3 was being designed in 2004 Qt was available only under the GPL license or a commercial (pay) license (See [http://en.wikipedia.org/wiki/Qt_%28toolkit%29 the wikipedia discussion]) and neither license option was acceptable to the community. In March 2009 Qt 4.5 was released under the LGPL license and became a possible technology for use in Slicer.<br />
<br />
Slicer3 is implemented using [http://www.kwwidgets.org KWWidgets] which has proven to be extremely capable and robust. However, due to the small size of the developer team for KWWidgets Kitware has been clear that it will not be able to compete with the features being added to Qt and is in fact adopting Qt for many of its internal projects (see, for example, [http://paraview.org ParaView] which migrated to Qt over the past several years).<br />
<br />
==Experiments==<br />
[[Image:Slicer3.5+Qt+Python-Test-2009-08-27.png|thumb|right|Screenshot from a version of slicer that has Qt accessible from the python console.]]<br />
In August of 2009 several members of the slicer development team have been learning about Qt and reviewing options. Things that are currently working:<br />
* Qt and KWWidgets can co-exist in same application environment (in different top level windows).<br />
* Qt widgets interfaces can be assembled using the QtDesigner, C++, or python.<br />
* It is feasible to create slicer widgets that use Qt (e.g. a NodeSelector widget).<br />
<br />
Overall the experience has been positive but the experiments have shown that there will be a significant amount of programming work to be done for each part of the interface. Most of the work is probably best characterized as "easy but time consuming". The net result of converting is expected to be positive but it is likely to be several years for there to be a payoff in terms of overall increased developer productivity and improved functionality of the overall package.<br />
<br />
==Development Plan Option for Transition to Qt==<br />
<br />
The following is a summary of the work to be done organized in a more-or-less priority order that would allow a transition in-place of functionality from KWW to Qt.<br />
<br />
# Configure CPack to include Qt libraries and turn on Qt support by default in nightly builds of slicer<br />
# Create prototype modules built using Qt (these would appear in a distinct top level window from the rest of slicer. The size and position would be under programatic control to make the two interface somewhat unified).<br />
# Migrate the vtkSlicerViewerWidget, vtkSlicerSliceControllerWidget, and vtkSlicerSliceWidget from KWW to Qt. This would allow the right side (2D/3D viewers) of the interface to exist in Qt with the left side (module interfaces) to exist in KWWidgets.<br />
# Migrate interfaces from modules and left side functions into Qt<br />
## the menu bar, tool bar, modules menu, module search and history controls<br />
## the CommandLineModuleGUI (so CLI modules will work in Qt)<br />
## the "Manipulate Slice Views" and "Manipulate 3D View" controls<br />
# Transition other dialogs and modules to Qt<br />
## Add Data, Add Volume, Save, Extension Wizard, Application Settings, Cache & Remote I/O Manager, Tcl/Python Interactors, ErrorLog Dialog, Keyboard Shortcuts...<br />
## Core Modules: Colors, Data, Editor, Fiducials, Measurements, Models, ROI, SlicerWelcome, Slices, Transforms, Volume Rendering, Volumes<br />
## Application Modules: Change Tracker, IA_FEMesh, Qdec, FetchMI, Query Atlas, AC/PC Transform, ModelMirror, EMSegment, LabelStatistics, Tractography, Fiber Bundles, NeuroNav, OpenIGTLink IF, ProstateNav, Clip Model, Extract Subvolume ROI, 4D Volume, 4D Analysis.<br />
## Extension Modules and DBP Projects: Perk Station, VMTK Vessel Tools, others...<br />
# Remove KWW from the builds and do a new release.<br />
<br />
==Slicer's KWWidgets-based GUI==<br />
===Statistics===<br />
* There are '''3309''' KWWidgets instances created in slicer core and modules (calls to New)<br />
* These calls are from '''123''' different KWWidget classes (including 'pure' KW classes in slicer that only depend on vtkKW and not MRML or other slicer code) <br />
* '''37''' KKWidgets subclasses are vtkKWMimx classes in the Meshing module<br />
* There are '''105''' classes that subclass from KWWidget classes<br />
<br />
See: [[Slicer3:KKWidgets_being_used| this list of KWWidgets being used in Slicer3]].<br />
<br />
''Statistics methods: Calculations based on slicer3 trunk revision 10456 2009-09-10. This does not include Tcl or Python code or extension modules (they use basically the same widgets).''<br />
<br />
grep -r vtkKW . | grep -v svn | grep New | wc<br />
grep -r vtkKW . | grep -v svn | grep "::New" | tr " " "\n" | tr "=" "\n" | tr ">" "\n" | grep -v "^//" | grep "vtkKW.*New" | sed 's/::New.*//' | sort | uniq | wc<br />
grep -r vtkKW . | grep -v svn | grep "::New" | tr " " "\n" | tr "=" "\n" | tr ">" "\n" | grep -v "^//" | grep "vtkKW.*New" | sed 's/::New.*//' | sort | uniq | grep Mimx | wc<br />
grep -r vtkKW . | grep -v svn | grep public | wc'<br />
<br />
==Qt widgets of interest==<br />
<br />
Playing with Qt Designer is a good way to explore Qt's core widgets. However, some KWW widgets are fairly complex, or uses Tk canvases pretty heavily; here are a few Qt widgets replacements worth considering. They are either found in the core distribution, or in [http://qt.nokia.com/products/appdev/add-on-products/catalog/4 Qt Solutions Catalog] (LGPL):<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:KWWidgetsCoreWidgetsOverview.png Thumbwheel]. Qt provides a [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtthumbwheel QtThumbWheel]<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:KWFileBrowserDialogExample.png FileBrowser] set of classes. Qt provides a [http://doc.trolltech.com/4.5/qfiledialog.html#sidebarUrls QFileDialog] class. It uses the native file dialogs on Win32/MacOS, and [http://doc.trolltech.com/4.5/qfiledialog.html#sidebarUrls a different one] on Unix, though it can use the same non-native dialog on all platforms. It can be set to pick directories only; a combination of QFile and QDirView can achieve a [http://doc.trolltech.com/4.5/images/dirview-example.png similar/better result]. ParaView uses a custom (rewritten) [http://wiki.slicer.org/slicerWiki/index.php/File:ParaViewQtFileDialog.png File Dialog] to handle client-server file browsing. Load/Save buttons are trivial to implement.<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:VtkKWColorPickerDialog_Classes.png Color Picker]. Qt provides a [http://doc.trolltech.com/4.5/qcolordialog.html#details QColorDialog], [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtcolorpicker QtColorPicker], [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtcolortriangle QtColorTriangle] and [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtcolorcombobox QtColorComboBox]. It is worth noting that QColorDialog offers basic colors (swatches), custom colors, RGB/HSV sliders on Win32/Unix, but uses a much more elaborate (native?) [http://www.randelshofer.ch/quaqua/guide/images/jcolorchooser.png dialog on Mac].<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:KWWidgetsTransferFunctionEditors.png Transfer Function Editors]. ParaView (BSD) and Maverick share a [http://wiki.slicer.org/slicerWiki/index.php/File:ParaViewTransferFunctionEditor.png similar transfer function editor] that is not as elaborated as KWW's, though this might do the trick for now. ParaView recently added a second (user-contributed) [http://wiki.slicer.org/slicerWiki/index.php/File:ParaViewTransferFunctionEditor2.png transfer function editor] that provides free-form and gaussian curves.<br />
<br />
* KWW's [http://www.slicer.org/slicerWiki/index.php/Modules:MainApplicationGUI-Documentation-3.4#Slicer_Viewers Collapsible Frames]. The first (easiest) solution is to use a [http://doc.trolltech.com/4.5/qgroupbox.html#details QGroupBox] and manually connect the checked SIGNAL with the setVisible SLOT of all the children. You would get the same behavior (a checkbox on the left of the title instead of a cross and arrow on the left). The second solution is to inherit from QGroupBox and change the display (change the mark in the checkbox display to have + and -). [http://wiki.slicer.org/slicerWiki/index.php/File:QGroupBox.png screenshot for both solutions]. Qt also offers tab widgets and toolboxes widgets to save space.<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:EMSegmentationModuleWizardAnimated.gif Wizard] classes. Qt provides sophisticated [http://doc.trolltech.com/4.5/qwizard.html#wizard-look-and-feel QWizard] classes, as well as a [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Utilities/qt-state-machine-framework/ Qt State Machine] framework. It is not clear if a Qt Wizard can be embedded inside another widget, since it inherits QDialog.<br />
<br />
* KWW's [http://wiki.slicer.org/slicerWiki/index.php/File:ParaViewTransferFunctionEditor2.png Range and Extent] Widgets. JS will show how to develop a [http://wiki.slicer.org/slicerWiki/index.php/File:QtSlicerDemoScreenshot-0.2.png Range slider] in a few minutes (ok, say a couple hours).<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:KWWidgetsLogDialog.png error/info log window]. A Qt [http://wiki.slicer.org/slicerWiki/index.php/File:KWQtLogDialog.png Log Dialog] was developed internally at Kitware (SB), and could most likely be reused.<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:KWWidgetsCoreWidgetsOverview.png Multi Column Widget and Tree]. Qt provides a sophisticated [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtpropertybrowser/ Qt Property Browser], as well as a large set of classes part of its [http://doc.trolltech.com/4.5/model-view-introduction.html Model/View Framework], including [http://doc.trolltech.com/4.5/model-view-view.html#using-an-existing-view tree, list and tables views/widgets], delegates, selection models, drag&drop, etc. See how it is used in Kitware's [http://wiki.slicer.org/slicerWiki/index.php/File:ScreenshotMerlinByKitware.png Merlin/Maverick].<br />
<br />
* Undo/Redo. Qt offers a [http://doc.trolltech.com/4.5/qundo.html Undo/Redo framework].<br />
<br />
* Misc. Qt [http://doc.trolltech.com/4.5/qdial.html#details QDial], [http://doc.trolltech.com/4.5/qcalendarwidget.html#details QCalendarWidget], [http://doc.trolltech.com/4.5/qprogressbar.html#details QProgressBar], [http://doc.trolltech.com/4.5/qspinbox.html#details QSpinBox].<br />
<br />
* Qt's resource editor is way more powerful and easy to use, and integrated in Qt Designer.<br />
<br />
==Considerations and Open Questions==<br />
# Coding styles and conventions for classes that interface vtk and Qt<br />
## inheritance<br />
## memory management<br />
# a significant number of higher level Qt widgets are required (Ranges, Extents, TransferFunctionEditors, Material Properties...)<br />
# Work needs to be coordinated among developers at multiple sites. Significant face-to-face time should be planned to keep everyone in sync on the progress.<br />
# It will be inevitable that revisiting some modules will involve redesign and feature improvements even if our focus is specifically on swapping the GUI.<br />
# Difficult bugs will occur somewhere along the process even if the plan appears smooth.<br />
# We should consider training courses or conferences to get us up to speed on best practices for development. (http://www.ics.com/QuickStart/, http://qt.nokia.com/qtdevdays2009)<br />
# What larger design re-works should be considered at the same time? I.e. should slicer functionality be re-organized as python packages so we can get away from the monolithic application attributes of the current main program (without a reduction in functionality or usability).<br />
<br />
==Development Approaches / Tradeoffs ==<br />
Several development approaches could be taken each of which has pros/cons and risks.<br />
<br />
# ''Immediate rewrite:'' this approach would be to start a from scratch to build a new GUI using Qt. Pros: likely to result in a cleaner architecture. Cons: all progress stops until new version is ready; current slicer developers are not Qt experts so not ready to build complex application from scratch; Qt does not have all the needed widgets to implement slicer (they need to be built along side slicer).<br />
# ''Wait and see:'' wait until Qt more 3rd party widgets fill in the missing functionality and then do the rewrite. Cons: any new GUI development in the old framework will seem like a dead end. Pros: the current framework isn't really broken so why change?<br />
# ''Peaceful coexistence:'' allow both GUI frameworks to be used together and allow people to develop in whichever is most productive for them. Cons: extra dependencies and potential maintenance issues; may require duplicated code; still need to resolve the architecture issues for mixing vtk and qt. Pros: removes pressure to do instant port; allows developers to get good at Qt before undertaking a big porting effort; allows development of 3rd party widgets that will make future ports easier.</div>Barrehttps://www.slicer.org/w/index.php?title=File:ScreenshotMerlinByKitware.png&diff=10697File:ScreenshotMerlinByKitware.png2009-09-16T06:22:07Z<p>Barre: </p>
<hr />
<div></div>Barrehttps://www.slicer.org/w/index.php?title=File:KWQtLogDialog.png&diff=10696File:KWQtLogDialog.png2009-09-16T06:14:36Z<p>Barre: </p>
<hr />
<div></div>Barrehttps://www.slicer.org/w/index.php?title=File:QtSlicerDemoScreenshot-0.2.png&diff=10695File:QtSlicerDemoScreenshot-0.2.png2009-09-16T06:07:59Z<p>Barre: </p>
<hr />
<div></div>Barrehttps://www.slicer.org/w/index.php?title=Qt_in_Slicer3&diff=10694Qt in Slicer32009-09-16T06:04:45Z<p>Barre: /* Qt widgets of interest */</p>
<hr />
<div>This page captures the design considerations about moving Slicer3 from KWWidgets to [http://qt.nokia.com/ Qt]. As of August 2009 there are no concrete plans for a switch; however there is significant momentum around Qt as an open source technology and interest in making it available to the Slicer community.<br />
<br />
==Background==<br />
<br />
When Slicer3 was being designed in 2004 Qt was available only under the GPL license or a commercial (pay) license (See [http://en.wikipedia.org/wiki/Qt_%28toolkit%29 the wikipedia discussion]) and neither license option was acceptable to the community. In March 2009 Qt 4.5 was released under the LGPL license and became a possible technology for use in Slicer.<br />
<br />
Slicer3 is implemented using [http://www.kwwidgets.org KWWidgets] which has proven to be extremely capable and robust. However, due to the small size of the developer team for KWWidgets Kitware has been clear that it will not be able to compete with the features being added to Qt and is in fact adopting Qt for many of its internal projects (see, for example, [http://paraview.org ParaView] which migrated to Qt over the past several years).<br />
<br />
==Experiments==<br />
[[Image:Slicer3.5+Qt+Python-Test-2009-08-27.png|thumb|right|Screenshot from a version of slicer that has Qt accessible from the python console.]]<br />
In August of 2009 several members of the slicer development team have been learning about Qt and reviewing options. Things that are currently working:<br />
* Qt and KWWidgets can co-exist in same application environment (in different top level windows).<br />
* Qt widgets interfaces can be assembled using the QtDesigner, C++, or python.<br />
* It is feasible to create slicer widgets that use Qt (e.g. a NodeSelector widget).<br />
<br />
Overall the experience has been positive but the experiments have shown that there will be a significant amount of programming work to be done for each part of the interface. Most of the work is probably best characterized as "easy but time consuming". The net result of converting is expected to be positive but it is likely to be several years for there to be a payoff in terms of overall increased developer productivity and improved functionality of the overall package.<br />
<br />
==Development Plan Option for Transition to Qt==<br />
<br />
The following is a summary of the work to be done organized in a more-or-less priority order that would allow a transition in-place of functionality from KWW to Qt.<br />
<br />
# Configure CPack to include Qt libraries and turn on Qt support by default in nightly builds of slicer<br />
# Create prototype modules built using Qt (these would appear in a distinct top level window from the rest of slicer. The size and position would be under programatic control to make the two interface somewhat unified).<br />
# Migrate the vtkSlicerViewerWidget, vtkSlicerSliceControllerWidget, and vtkSlicerSliceWidget from KWW to Qt. This would allow the right side (2D/3D viewers) of the interface to exist in Qt with the left side (module interfaces) to exist in KWWidgets.<br />
# Migrate interfaces from modules and left side functions into Qt<br />
## the menu bar, tool bar, modules menu, module search and history controls<br />
## the CommandLineModuleGUI (so CLI modules will work in Qt)<br />
## the "Manipulate Slice Views" and "Manipulate 3D View" controls<br />
# Transition other dialogs and modules to Qt<br />
## Add Data, Add Volume, Save, Extension Wizard, Application Settings, Cache & Remote I/O Manager, Tcl/Python Interactors, ErrorLog Dialog, Keyboard Shortcuts...<br />
## Core Modules: Colors, Data, Editor, Fiducials, Measurements, Models, ROI, SlicerWelcome, Slices, Transforms, Volume Rendering, Volumes<br />
## Application Modules: Change Tracker, IA_FEMesh, Qdec, FetchMI, Query Atlas, AC/PC Transform, ModelMirror, EMSegment, LabelStatistics, Tractography, Fiber Bundles, NeuroNav, OpenIGTLink IF, ProstateNav, Clip Model, Extract Subvolume ROI, 4D Volume, 4D Analysis.<br />
## Extension Modules and DBP Projects: Perk Station, VMTK Vessel Tools, others...<br />
# Remove KWW from the builds and do a new release.<br />
<br />
==Slicer's KWWidgets-based GUI==<br />
===Statistics===<br />
* There are '''3309''' KWWidgets instances created in slicer core and modules (calls to New)<br />
* These calls are from '''123''' different KWWidget classes (including 'pure' KW classes in slicer that only depend on vtkKW and not MRML or other slicer code) <br />
* '''37''' KKWidgets subclasses are vtkKWMimx classes in the Meshing module<br />
* There are '''105''' classes that subclass from KWWidget classes<br />
<br />
See: [[Slicer3:KKWidgets_being_used| this list of KWWidgets being used in Slicer3]].<br />
<br />
''Statistics methods: Calculations based on slicer3 trunk revision 10456 2009-09-10. This does not include Tcl or Python code or extension modules (they use basically the same widgets).''<br />
<br />
grep -r vtkKW . | grep -v svn | grep New | wc<br />
grep -r vtkKW . | grep -v svn | grep "::New" | tr " " "\n" | tr "=" "\n" | tr ">" "\n" | grep -v "^//" | grep "vtkKW.*New" | sed 's/::New.*//' | sort | uniq | wc<br />
grep -r vtkKW . | grep -v svn | grep "::New" | tr " " "\n" | tr "=" "\n" | tr ">" "\n" | grep -v "^//" | grep "vtkKW.*New" | sed 's/::New.*//' | sort | uniq | grep Mimx | wc<br />
grep -r vtkKW . | grep -v svn | grep public | wc'<br />
<br />
==Qt widgets of interest==<br />
<br />
Playing with Qt Designer is a good way to explore Qt's core widgets. However, some KWW widgets are fairly complex, or uses Tk canvases pretty heavily; here are a few Qt widgets replacements worth considering. They are either found in the core distribution, or in [http://qt.nokia.com/products/appdev/add-on-products/catalog/4 Qt Solutions Catalog] (LGPL):<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:KWWidgetsCoreWidgetsOverview.png Thumbwheel]. Qt provides a [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtthumbwheel QtThumbWheel]<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:KWFileBrowserDialogExample.png FileBrowser] set of classes. Qt provides a [http://doc.trolltech.com/4.5/qfiledialog.html#sidebarUrls QFileDialog] class. It uses the native file dialogs on Win32/MacOS, and [http://doc.trolltech.com/4.5/qfiledialog.html#sidebarUrls a different one] on Unix, though it can use the same non-native dialog on all platforms. It can be set to pick directories only; a combination of QFile and QDirView can achieve a [http://doc.trolltech.com/4.5/images/dirview-example.png similar/better result]. ParaView uses a custom (rewritten) [http://wiki.slicer.org/slicerWiki/index.php/File:ParaViewQtFileDialog.png File Dialog] to handle client-server file browsing.<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:VtkKWColorPickerDialog_Classes.png Color Picker]. Qt provides a [http://doc.trolltech.com/4.5/qcolordialog.html#details QColorDialog], [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtcolorpicker QtColorPicker], [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtcolortriangle QtColorTriangle] and [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtcolorcombobox QtColorComboBox]. It is worth noting that QColorDialog offers basic colors (swatches), custom colors, RGB/HSV sliders on Win32/Unix, but uses a much more elaborate (native?) [http://www.randelshofer.ch/quaqua/guide/images/jcolorchooser.png dialog on Mac].<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:KWWidgetsTransferFunctionEditors.png Transfer Function Editors]. ParaView (BSD) and Maverick share a [http://wiki.slicer.org/slicerWiki/index.php/File:ParaViewTransferFunctionEditor.png similar transfer function editor] that is not as elaborated as KWW's, though this might do the trick for now. ParaView recently added a second (user-contributed) [http://wiki.slicer.org/slicerWiki/index.php/File:ParaViewTransferFunctionEditor2.png transfer function editor] that provides free-form and gaussian curves.<br />
<br />
* KWW's [http://www.slicer.org/slicerWiki/index.php/Modules:MainApplicationGUI-Documentation-3.4#Slicer_Viewers Collapsible Frames]. The first (easiest) solution is to use a [http://doc.trolltech.com/4.5/qgroupbox.html#details QGroupBox] and manually connect the checked SIGNAL with the setVisible SLOT of all the children. You would get the same behavior (a checkbox on the left of the title instead of a cross and arrow on the left). The second solution is to inherit from QGroupBox and change the display (change the mark in the checkbox display to have + and -). [http://wiki.slicer.org/slicerWiki/index.php/File:QGroupBox.png screenshot for both solutions].<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:EMSegmentationModuleWizardAnimated.gif Wizard] classes. Qt provides sophisticated [http://doc.trolltech.com/4.5/qwizard.html#wizard-look-and-feel QWizard] classes, as well as a [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Utilities/qt-state-machine-framework/ Qt State Machine] framework. It is not clear if a Qt Wizard can be embedded inside another widget, since it inherits QDialog.<br />
<br />
==Considerations and Open Questions==<br />
# Coding styles and conventions for classes that interface vtk and Qt<br />
## inheritance<br />
## memory management<br />
# a significant number of higher level Qt widgets are required (Ranges, Extents, TransferFunctionEditors, Material Properties...)<br />
# Work needs to be coordinated among developers at multiple sites. Significant face-to-face time should be planned to keep everyone in sync on the progress.<br />
# It will be inevitable that revisiting some modules will involve redesign and feature improvements even if our focus is specifically on swapping the GUI.<br />
# Difficult bugs will occur somewhere along the process even if the plan appears smooth.<br />
# We should consider training courses or conferences to get us up to speed on best practices for development. (http://www.ics.com/QuickStart/, http://qt.nokia.com/qtdevdays2009)<br />
# What larger design re-works should be considered at the same time? I.e. should slicer functionality be re-organized as python packages so we can get away from the monolithic application attributes of the current main program (without a reduction in functionality or usability).<br />
<br />
==Development Approaches / Tradeoffs ==<br />
Several development approaches could be taken each of which has pros/cons and risks.<br />
<br />
# ''Immediate rewrite:'' this approach would be to start a from scratch to build a new GUI using Qt. Pros: likely to result in a cleaner architecture. Cons: all progress stops until new version is ready; current slicer developers are not Qt experts so not ready to build complex application from scratch; Qt does not have all the needed widgets to implement slicer (they need to be built along side slicer).<br />
# ''Wait and see:'' wait until Qt more 3rd party widgets fill in the missing functionality and then do the rewrite. Cons: any new GUI development in the old framework will seem like a dead end. Pros: the current framework isn't really broken so why change?<br />
# ''Peaceful coexistence:'' allow both GUI frameworks to be used together and allow people to develop in whichever is most productive for them. Cons: extra dependencies and potential maintenance issues; may require duplicated code; still need to resolve the architecture issues for mixing vtk and qt. Pros: removes pressure to do instant port; allows developers to get good at Qt before undertaking a big porting effort; allows development of 3rd party widgets that will make future ports easier.</div>Barrehttps://www.slicer.org/w/index.php?title=File:ParaViewTransferFunctionEditor2.png&diff=10693File:ParaViewTransferFunctionEditor2.png2009-09-16T06:01:41Z<p>Barre: </p>
<hr />
<div></div>Barrehttps://www.slicer.org/w/index.php?title=File:ParaViewTransferFunctionEditor.png&diff=10692File:ParaViewTransferFunctionEditor.png2009-09-16T05:57:20Z<p>Barre: </p>
<hr />
<div></div>Barrehttps://www.slicer.org/w/index.php?title=File:ParaViewQtFileDialog.png&diff=10691File:ParaViewQtFileDialog.png2009-09-16T05:55:35Z<p>Barre: </p>
<hr />
<div></div>Barrehttps://www.slicer.org/w/index.php?title=File:QGroupBox.png&diff=10690File:QGroupBox.png2009-09-16T05:46:29Z<p>Barre: </p>
<hr />
<div></div>Barrehttps://www.slicer.org/w/index.php?title=Qt_in_Slicer3&diff=10689Qt in Slicer32009-09-16T05:25:29Z<p>Barre: /* Slicer's KWWidgets-based GUI */</p>
<hr />
<div>This page captures the design considerations about moving Slicer3 from KWWidgets to [http://qt.nokia.com/ Qt]. As of August 2009 there are no concrete plans for a switch; however there is significant momentum around Qt as an open source technology and interest in making it available to the Slicer community.<br />
<br />
==Background==<br />
<br />
When Slicer3 was being designed in 2004 Qt was available only under the GPL license or a commercial (pay) license (See [http://en.wikipedia.org/wiki/Qt_%28toolkit%29 the wikipedia discussion]) and neither license option was acceptable to the community. In March 2009 Qt 4.5 was released under the LGPL license and became a possible technology for use in Slicer.<br />
<br />
Slicer3 is implemented using [http://www.kwwidgets.org KWWidgets] which has proven to be extremely capable and robust. However, due to the small size of the developer team for KWWidgets Kitware has been clear that it will not be able to compete with the features being added to Qt and is in fact adopting Qt for many of its internal projects (see, for example, [http://paraview.org ParaView] which migrated to Qt over the past several years).<br />
<br />
==Experiments==<br />
[[Image:Slicer3.5+Qt+Python-Test-2009-08-27.png|thumb|right|Screenshot from a version of slicer that has Qt accessible from the python console.]]<br />
In August of 2009 several members of the slicer development team have been learning about Qt and reviewing options. Things that are currently working:<br />
* Qt and KWWidgets can co-exist in same application environment (in different top level windows).<br />
* Qt widgets interfaces can be assembled using the QtDesigner, C++, or python.<br />
* It is feasible to create slicer widgets that use Qt (e.g. a NodeSelector widget).<br />
<br />
Overall the experience has been positive but the experiments have shown that there will be a significant amount of programming work to be done for each part of the interface. Most of the work is probably best characterized as "easy but time consuming". The net result of converting is expected to be positive but it is likely to be several years for there to be a payoff in terms of overall increased developer productivity and improved functionality of the overall package.<br />
<br />
==Development Plan Option for Transition to Qt==<br />
<br />
The following is a summary of the work to be done organized in a more-or-less priority order that would allow a transition in-place of functionality from KWW to Qt.<br />
<br />
# Configure CPack to include Qt libraries and turn on Qt support by default in nightly builds of slicer<br />
# Create prototype modules built using Qt (these would appear in a distinct top level window from the rest of slicer. The size and position would be under programatic control to make the two interface somewhat unified).<br />
# Migrate the vtkSlicerViewerWidget, vtkSlicerSliceControllerWidget, and vtkSlicerSliceWidget from KWW to Qt. This would allow the right side (2D/3D viewers) of the interface to exist in Qt with the left side (module interfaces) to exist in KWWidgets.<br />
# Migrate interfaces from modules and left side functions into Qt<br />
## the menu bar, tool bar, modules menu, module search and history controls<br />
## the CommandLineModuleGUI (so CLI modules will work in Qt)<br />
## the "Manipulate Slice Views" and "Manipulate 3D View" controls<br />
# Transition other dialogs and modules to Qt<br />
## Add Data, Add Volume, Save, Extension Wizard, Application Settings, Cache & Remote I/O Manager, Tcl/Python Interactors, ErrorLog Dialog, Keyboard Shortcuts...<br />
## Core Modules: Colors, Data, Editor, Fiducials, Measurements, Models, ROI, SlicerWelcome, Slices, Transforms, Volume Rendering, Volumes<br />
## Application Modules: Change Tracker, IA_FEMesh, Qdec, FetchMI, Query Atlas, AC/PC Transform, ModelMirror, EMSegment, LabelStatistics, Tractography, Fiber Bundles, NeuroNav, OpenIGTLink IF, ProstateNav, Clip Model, Extract Subvolume ROI, 4D Volume, 4D Analysis.<br />
## Extension Modules and DBP Projects: Perk Station, VMTK Vessel Tools, others...<br />
# Remove KWW from the builds and do a new release.<br />
<br />
==Slicer's KWWidgets-based GUI==<br />
===Statistics===<br />
* There are '''3309''' KWWidgets instances created in slicer core and modules (calls to New)<br />
* These calls are from '''123''' different KWWidget classes (including 'pure' KW classes in slicer that only depend on vtkKW and not MRML or other slicer code) <br />
* '''37''' KKWidgets subclasses are vtkKWMimx classes in the Meshing module<br />
* There are '''105''' classes that subclass from KWWidget classes<br />
<br />
See: [[Slicer3:KKWidgets_being_used| this list of KWWidgets being used in Slicer3]].<br />
<br />
''Statistics methods: Calculations based on slicer3 trunk revision 10456 2009-09-10. This does not include Tcl or Python code or extension modules (they use basically the same widgets).''<br />
<br />
grep -r vtkKW . | grep -v svn | grep New | wc<br />
grep -r vtkKW . | grep -v svn | grep "::New" | tr " " "\n" | tr "=" "\n" | tr ">" "\n" | grep -v "^//" | grep "vtkKW.*New" | sed 's/::New.*//' | sort | uniq | wc<br />
grep -r vtkKW . | grep -v svn | grep "::New" | tr " " "\n" | tr "=" "\n" | tr ">" "\n" | grep -v "^//" | grep "vtkKW.*New" | sed 's/::New.*//' | sort | uniq | grep Mimx | wc<br />
grep -r vtkKW . | grep -v svn | grep public | wc'<br />
<br />
==Qt widgets of interest==<br />
<br />
Playing with Qt Designer is a good way to explore Qt's core widgets. However, some KWW widgets are fairly complex, or uses Tk canvases pretty heavily; here are a few Qt widgets replacements worth considering. They are either found in the core distribution, or in [http://qt.nokia.com/products/appdev/add-on-products/catalog/4 Qt Solutions Catalog] (LGPL):<br />
<br />
* KWW's [http://www.kwwidgets.org/Wiki/Image:KWWidgetsCoreWidgetsOverview.png Thumbwheel]. Qt provides a [http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtthumbwheel QtThumbWheel]<br />
<br />
==Considerations and Open Questions==<br />
# Coding styles and conventions for classes that interface vtk and Qt<br />
## inheritance<br />
## memory management<br />
# a significant number of higher level Qt widgets are required (Ranges, Extents, TransferFunctionEditors, Material Properties...)<br />
# Work needs to be coordinated among developers at multiple sites. Significant face-to-face time should be planned to keep everyone in sync on the progress.<br />
# It will be inevitable that revisiting some modules will involve redesign and feature improvements even if our focus is specifically on swapping the GUI.<br />
# Difficult bugs will occur somewhere along the process even if the plan appears smooth.<br />
# We should consider training courses or conferences to get us up to speed on best practices for development. (http://www.ics.com/QuickStart/, http://qt.nokia.com/qtdevdays2009)<br />
# What larger design re-works should be considered at the same time? I.e. should slicer functionality be re-organized as python packages so we can get away from the monolithic application attributes of the current main program (without a reduction in functionality or usability).<br />
<br />
==Development Approaches / Tradeoffs ==<br />
Several development approaches could be taken each of which has pros/cons and risks.<br />
<br />
# ''Immediate rewrite:'' this approach would be to start a from scratch to build a new GUI using Qt. Pros: likely to result in a cleaner architecture. Cons: all progress stops until new version is ready; current slicer developers are not Qt experts so not ready to build complex application from scratch; Qt does not have all the needed widgets to implement slicer (they need to be built along side slicer).<br />
# ''Wait and see:'' wait until Qt more 3rd party widgets fill in the missing functionality and then do the rewrite. Cons: any new GUI development in the old framework will seem like a dead end. Pros: the current framework isn't really broken so why change?<br />
# ''Peaceful coexistence:'' allow both GUI frameworks to be used together and allow people to develop in whichever is most productive for them. Cons: extra dependencies and potential maintenance issues; may require duplicated code; still need to resolve the architecture issues for mixing vtk and qt. Pros: removes pressure to do instant port; allows developers to get good at Qt before undertaking a big porting effort; allows development of 3rd party widgets that will make future ports easier.</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/2008_Summer_Project_Week&diff=5283User:Barre/2008 Summer Project Week2008-06-27T14:58:58Z<p>Barre: </p>
<hr />
<div>Notes from what was done during [http://www.na-mic.org/Wiki/index.php/2008_Summer_Project_Week 2008 Summer Project Week] <br />
<br />
* Various user-friendly optimization (see [[User:Barre/TODO|TODO]])<br />
* Tuesday<br />
** Ipek Oguz: Help with Offscreen Rendering and making sure it can behave as a command-line program (without a KWW GUI)<br />
** Ragani: Try to convert legacy code, vtkImageResliceST.cxx, based on old vtkImageReslice<br />
** Craig Sharp: Help with Plastimatch; including the CMake code for a CLP was conflicting with his own CMake code. At the end of the day, his library needed to be linked against ITK, as opposed to just his executables; why the CLP CMake code revealed that "problem" is not clear, but in any case that's the way to go in general...<br />
** Luis: discuss the IO formats introspection (see [[User:Barre/TODO|TODO]])<br />
** Cleanup some installation/configuration rules in QdecModule and TumorGrowth<br />
* Wednesday<br />
** Gary Christensen & team: CMake/CPack presentation, help<br />
** Will: build Slicer3 (need to update the Wiki)<br />
** Alex: check the Models tree widget issue, i.e. that it is lacking the usability found in Slicer2 (see [[User:Barre/TODO|TODO]])<br />
** Add option vtkKWTreeWithScrollbars to resize the tree manually (see [[User:Barre/TODO|TODO]])<br />
* Steve Aylward: SlicerIGT funding<br />
* Thursday<br />
** Steve, Ron, Will: strategy for the infrastructure required to create Slicer3 binaries and separate modules that can be reviewed, downloaded, integrated in Slicer3. Not to be completed by RSNA. Experimentation for the moment. I (Seb) will produce some installers for Slicer3-Core + Modules, installers/ZIP for the CLP (which need to be fixed so that they can be built/installed separately against Slicer3), installers/ZIP for Slicer3-modules (using the macros that will pull them out of their repository and build them automatically), and a GUI in Slicer3 to fetch the ZIP and unpack them.<br />
** Wendy: got some info about the current font system, and make sure she agrees with the rewrite. We will stick to a simpler system, i.e. stick to the default system font and compute a smaller font from there. There will still be a (likely hidden) way to increase the font size globally, in case somebody is presenting through a projector. Feedback from the community will lead to some adjustment, but we will stay clear from hardcoding font size and family.<br />
** Bill: work on the launcher so that it supports a splash screen and the current StarKit launcher can be avoid in RPM installers... <br />
*** Win32 Resources:<br />
**** <small>[http://www.microsoft.com/msj/1099/c/c1099.aspx How can I implement a start-up screen that displays a bitmap in MFC?]</small><br />
**** <small>[http://support.microsoft.com/kb/815376 How to create and insert a splash screen in an SDI application or in an MDI application by using Visual C++ .NET or Visual C++ 2005]</small><br />
**** <small>[http://www.ucancode.net/Visual_C_Control/Splash-screen-of-transparent-bitmap-vc-sample.htm VC++ MFC Sample Code: Transparent bitmap splash screen]</small><br />
**** <small>[http://www.codeproject.com/KB/winsdk/win32splash.aspx Own-thread Win32 splash screen]</small><br />
**** <small>[http://www.codejock.com/support/articles/mfc/general/g_2.asp Dialog With Splash Screen]</small><br />
**** <small>[http://www.endurasoft.com/techtalk/splash.htm Making a Splash]</small><br />
**** <small>[http://www.codeproject.com/KB/dialog/splasher.aspx Splasher v1.32 - A Splash Screen Implementation]</small><br />
*** X11 Resources:<br />
* Friday<br />
** Bill: work on the launcher with splashscreen<br />
** Nathan (Gary Christensen): work on the Atlas app, optimize memory consumption</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/2008_Summer_Project_Week&diff=5279User:Barre/2008 Summer Project Week2008-06-27T13:47:38Z<p>Barre: </p>
<hr />
<div>* Various user-friendly optimization (see [[User:Barre/TODO|TODO]])<br />
* Steve Aylward: SlicerIGT funding?<br />
* Tuesday<br />
** Ipek Oguz: Help with Offscreen Rendering and making sure it can behave as a command-line program (without a KWW GUI)<br />
** Ragani: Try to convert legacy code, vtkImageResliceST.cxx, based on old vtkImageReslice<br />
** Craig Sharp: Help with Plastimatch; including the CMake code for a CLP was conflicting with his own CMake code. At the end of the day, his library needed to be linked against ITK, as opposed to just his executables; why the CLP CMake code revealed that "problem" is not clear, but in any case that's the way to go in general...<br />
** Luis: discuss the IO formats introspection (see [[User:Barre/TODO|TODO]])<br />
** Cleanup some installation/configuration rules in QdecModule and TumorGrowth<br />
* Wednesday<br />
** Gary Christensen & team: CMake/CPack presentation, help<br />
** Will: build Slicer3 (need to update the Wiki)<br />
** Alex: check the Models tree widget issue, i.e. that it is lacking the usability found in Slicer2 (see [[User:Barre/TODO|TODO]])<br />
** Add option vtkKWTreeWithScrollbars to resize the tree manually (see [[User:Barre/TODO|TODO]])<br />
* Thursday<br />
** Steve, Ron, Will: strategy for the infrastructure required to create Slicer3 binaries and separate modules that can be reviewed, downloaded, integrated in Slicer3. Not to be completed by RSNA. Experimentation for the moment. I (Seb) will produce some installers for Slicer3-Core + Modules, installers/ZIP for the CLP (which need to be fixed so that they can be built/installed separately against Slicer3), installers/ZIP for Slicer3-modules (using the macros that will pull them out of their repository and build them automatically), and a GUI in Slicer3 to fetch the ZIP and unpack them.<br />
** Wendy: got some info about the current font system, and make sure she agrees with the rewrite. We will stick to a simpler system, i.e. stick to the default system font and compute a smaller font from there. There will still be a (likely hidden) way to increase the font size globally, in case somebody is presenting through a projector. Feedback from the community will lead to some adjustment, but we will stay clear from hardcoding font size and family.<br />
** Bill: work on the launcher so that it supports a splash screen and the current StarKit launcher can be avoid in RPM installers... <br />
*** Win32 Resources:<br />
**** <small>[http://www.microsoft.com/msj/1099/c/c1099.aspx How can I implement a start-up screen that displays a bitmap in MFC?]</small><br />
**** <small>[http://support.microsoft.com/kb/815376 How to create and insert a splash screen in an SDI application or in an MDI application by using Visual C++ .NET or Visual C++ 2005]</small><br />
**** <small>[http://www.ucancode.net/Visual_C_Control/Splash-screen-of-transparent-bitmap-vc-sample.htm VC++ MFC Sample Code: Transparent bitmap splash screen]</small><br />
**** <small>[http://www.codeproject.com/KB/winsdk/win32splash.aspx Own-thread Win32 splash screen]</small><br />
**** <small>[http://www.codejock.com/support/articles/mfc/general/g_2.asp Dialog With Splash Screen]</small><br />
**** <small>[http://www.endurasoft.com/techtalk/splash.htm Making a Splash]</small><br />
**** <small>[http://www.codeproject.com/KB/dialog/splasher.aspx Splasher v1.32 - A Splash Screen Implementation]</small><br />
*** X11 Resources:<br />
* Friday<br />
** Bill: work on the launcher with splashscreen<br />
** Nathan (Gary Christensen): work on the Atlas app, optimize memory consumption</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/TODO&diff=5268User:Barre/TODO2008-06-26T20:32:22Z<p>Barre: </p>
<hr />
<div>==[[2008 June Workshop Germany |Training Event in Germany]]==<br />
<br />
Notes from a session with Ron, important items to address to improve Slicer3 usability.<br />
<br />
# Save Data: how can one save a data file as a specific/different ITK file format. ITK uses a IO plugin framework to support new file formats: is there a way to find the list of file formats supported by ITK at run-time.<br />
#* I (Seb) to check with Luis<br />
#* '''[UPDATE]''' see ImageFileReader<...>::GenerateOutputInformation, BUT every IO file/reader need to expose the list of file extensions it can read and write. Luis is on it, to be added 3.8 end of July. Luis is fast, it's [http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/IO/itkImageIOBase.h?root=Insight&r1=1.48&r2=1.49 in the CVS], and examplified in [http://public.kitware.com/cgi-bin/viewcvs.cgi/Testing/Code/IO/itkImageIOFileNameExtensionsTests.cxx?root=Insight&sortby=date&view=log itkImageIOFileNameExtensionsTests.cxx] <br />
# Save Data: the "Save" dialog in general is very confusing and buggy. The "Save All" and "Save None" button are mislabelled since they don't perform any save. Saving data to a new file format requires the user to double-click in the file name and manually change the file extension (provided that this extension is known to the user). Changing the data directory does not update the data locations in the multicolumn list (it does if you change the data directory twice). Changing the scene directory has no impact on the data directory.<br />
#* I (Seb) suggest that the "Save All/None" should be something like "Mark all for save", "Mark none for save". A button should be placed next to each data filename/location to quickly switch to a new file type (depending on what ITK can save to at run-time). The dialog is large, we have room to put a help string/label that explains a little more how the whole dialog works. Changing the data directory should update the location of each data entry in the multicolumn list correctly. A button should be added to quickly set the data directory to match the scene directory (it should not be automatic though).<br />
# Font Size: the font is definitely too small for the "Modules" menubutton or the filename label in any of the Red/Yellow/Green slice viewports. The "View -> Font Size" menu does not report the current font size. <br />
#* My (Seb) opinion is to avoid hard-coding font size as much as possible, and not let the user override either font size or font family: we can not support all the possible layout combinations, or guarantee it will all fit; let's focus instead on making sure it looks nice and fit decently with the default system font size. The label in the RYG slice viewports is cropped automatically to something likely too small, and not updated later on when the slice viewport is resized/maximized: to fix.<br />
#* Ron: Starting with the system default font is a good idea. I have encountered many situations where it is critical to be able to change the font to larger or smaller. Having a keyboard shortcut for situations where the menu is not accessible might be a good idea too: Ctrl + and ctrl - come to mind, like in firefox.<br />
#* '''[UPDATE]''' Starting the font cleanup, will keep only the default font size, and a smaller one computed from the system default (instead of hardcoding everything), and possibility of increasing from there. <br />
# Progress Bar: the progress bar used while loading data has been removed because it was triggering too many "update idletasks". We still need one though.<br />
#* Steve suggests creating an OpenGL progress bar directly inside a small renderwindow. I (Seb) checked VTK's scale/slider interaction widget to see if that would do the trick. To be investigated further with the VTK's widget guru, Will. <br />
#* '''[UPDATE]''' Actually a better starting point could be the vtkBarChartActor since each bar can be used for the multi-progress widget in KWW; Will will add an option to have it horizontal.<br />
# Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" may be too small for some users, as it gets more and more crowded.<br />
#* My (Seb) opinion is that we can't have it resize automatically because who knows how tall it could be, and it would push everything down. Ron is OK to have an option to do it manually, so I plan to add two icon/buttons to increase/decrease the height (numbe of lines) of the tree, say add 15 more lines, and double the size, etc. I wish we could just "drag" the whole tree frame to a new size, like expanding a window, but that's just too hard (or impossible) to implement with this Tk widget.<br />
#* '''[UPDATE]''' vtkKWTreeWithScrollbars has now a ResizeButtonsVisibility flag that is set for the models and MRML tree, and allow for two small resize buttons to be used to resize a tree.[[Image:KWWidgetsExpandTreeButton.png|center|thumb|250px]] <br />
# Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" is not as intuitive as the previous UI found in Slicer2; for each model, one could check/uncheck the visibility and change the opacity using controls placed directly next to the model's name (i.e. on the same row). The model name/label itself would use a background color matching the color used to display the model in the 3D view, a nice hint. The tree used in Slicer3 does not do nearly as much, i.e. the user has to select a node then change its visibily using a checkbutton placed in a different frame below the tree (note that the visibility and color can be changed quickly though, by using a popup menu by right-clicking on the tree leaf).<br />
#* I (Seb) had several discussion about this item with Alex, and I'm still not sure why this can't be done technically by adding custom widgets next to the label name for each leaf in the tree, but I will have a look at it again. Given the size of the testing scene (say, 200 elements), the multicolumn widget would be too slow if each row had a label, a color button, a visibility button, etc., and the indentation would be a ugly hack. The tree widget does support custom widgets per row, but not in separate columns: they would be misaligned (either on the left or right of a leaf label). <br />
#* '''[UPDATE]''' It seems we need the TkTreeCtrl widget which was added last year when this problem was raised already; Seb to create a C++ class around this monster library and expose only the methods we need for this very specific problem; it will take some time, since TkTreeCtrl is the most complex Tcl/Tk widget to be found in KWWidgets so far.</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/TODO&diff=5266User:Barre/TODO2008-06-26T20:20:49Z<p>Barre: </p>
<hr />
<div>==[[2008 June Workshop Germany |Training Event in Germany]]==<br />
<br />
Notes from a session with Ron, important items to address to improve Slicer3 usability.<br />
<br />
* Save Data: how can one save a data file as a specific/different ITK file format. ITK uses a IO plugin framework to support new file formats: is there a way to find the list of file formats supported by ITK at run-time.<br />
** <small>I (Seb) to check with Luis<br>'''[UPDATE]''' see ImageFileReader<...>::GenerateOutputInformation, BUT every IO file/reader need to expose the list of file extensions it can read and write. Luis is on it, to be added 3.8 end of July. Luis is fast, it's [http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/IO/itkImageIOBase.h?root=Insight&r1=1.48&r2=1.49 in the CVS], and examplified in [http://public.kitware.com/cgi-bin/viewcvs.cgi/Testing/Code/IO/itkImageIOFileNameExtensionsTests.cxx?root=Insight&sortby=date&view=log itkImageIOFileNameExtensionsTests.cxx]</small> <br />
<br />
* Save Data: the "Save" dialog in general is very confusing and buggy. The "Save All" and "Save None" button are mislabelled since they don't perform any save. Saving data to a new file format requires the user to double-click in the file name and manually change the file extension (provided that this extension is known to the user). Changing the data directory does not update the data locations in the multicolumn list (it does if you change the data directory twice). Changing the scene directory has no impact on the data directory.<br />
**<small> I (Seb) suggest that the "Save All/None" should be something like "Mark all for save", "Mark none for save". A button should be placed next to each data filename/location to quickly switch to a new file type (depending on what ITK can save to at run-time). The dialog is large, we have room to put a help string/label that explains a little more how the whole dialog works. Changing the data directory should update the location of each data entry in the multicolumn list correctly. A button should be added to quickly set the data directory to match the scene directory (it should not be automatic though).</small><br />
<br />
* Font Size: the font is definitely too small for the "Modules" menubutton or the filename label in any of the Red/Yellow/Green slice viewports. The "View -> Font Size" menu does not report the current font size. <br />
** <small>My (Seb) opinion is to avoid hard-coding font size as much as possible, and not let the user override either font size or font family: we can not support all the possible layout combinations, or guarantee it will all fit; let's focus instead on making sure it looks nice and fit decently with the default system font size. The label in the RYG slice viewports is cropped automatically to something likely too small, and not updated later on when the slice viewport is resized/maximized: to fix.</small><br />
** <small>Ron: Starting with the system default font is a good idea. I have encountered many situations where it is critical to be able to change the font to larger or smaller. Having a keyboard shortcut for situations where the menu is not accessible might be a good idea too: Ctrl + and ctrl - come to mind, like in firefox.</small><br />
<br />
* Progress Bar: the progress bar used while loading data has been removed because it was triggering too many "update idletasks". We still need one though.<br />
** <small>Steve suggests creating an OpenGL progress bar directly inside a small renderwindow. I (Seb) checked VTK's scale/slider interaction widget to see if that would do the trick. To be investigated further with the VTK's widget guru, Will. Actually a better starting point could be the vtkBarChartActor, Will will add an option to have it horizontal.</small><br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" may be too small for some users, as it gets more and more crowded.<br />
** <small>My (Seb) opinion is that we can't have it resize automatically because who knows how tall it could be, and it would push everything down. Ron is OK to have an option to do it manually, so I plan to add two icon/buttons to increase/decrease the height (numbe of lines) of the tree, say add 15 more lines, and double the size, etc. I wish we could just "drag" the whole tree frame to a new size, like expanding a window, but that's just too hard (or impossible) to implement with this Tk widget.<br>'''[UPDATE]''' vtkKWTreeWithScrollbars has now a ResizeButtonsVisibility flag that is set for the models and MRML tree, and allow for two small resize buttons to be used to resize a tree.</small>[[Image:KWWidgetsExpandTreeButton.png|center|thumb|250px]] <br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" is not as intuitive as the previous UI found in Slicer2; for each model, one could check/uncheck the visibility and change the opacity using controls placed directly next to the model's name (i.e. on the same row). The model name/label itself would use a background color matching the color used to display the model in the 3D view, a nice hint. The tree used in Slicer3 does not do nearly as much, i.e. the user has to select a node then change its visibily using a checkbutton placed in a different frame below the tree (note that the visibility and color can be changed quickly though, by using a popup menu by right-clicking on the tree leaf).<br />
** <small>I (Seb) had several discussion about this item with Alex, and I'm still not sure why this can't be done technically by adding custom widgets next to the label name for each leaf in the tree, but I will have a look at it again.<br>'''[UPDATE]''' Given the size of the testing scene (say, 200 elements), the multicolumn widget would be too slow if each row had a label, a color button, a visibility button, etc., and the indentation would be a ugly hack. The tree widget does support custom widgets per row, but not in separate columns: they would be misaligned (either on the left or right of a leaf label). It seems we need the TkTreeCtrl widget which was added last year when this problem was raised already; Seb to create a C++ class around this monster library and expose only the methods we need for this very specific problem; it will take some time, since TkTreeCtrl is the most complex Tcl/Tk widget to be found in KWWidgets so far.</small></div>Barrehttps://www.slicer.org/w/index.php?title=Slicer3:Build_Instructions&diff=5260Slicer3:Build Instructions2008-06-26T18:19:19Z<p>Barre: /* getbuildtest on linux */</p>
<hr />
<div>= All-in-one Script to checkout and build Slicer3 =<br />
<br />
To compile and build Slicer3, you need a set of development packages installed on your machine: <br />
* [[Slicer3:Build_Instructions#getbuildtest_on_linux| pre-requisite material for Linux]]<br />
* [[Slicer3:Build_Instructions#getbuildtest_on_windows| pre-requisite material for Windows]]<br />
* [[Slicer3:Build_Instructions#getbuildtest_on_Apple_Mac_OS_X |pre-requisite material for Mac]]<br />
<br />
There's a script called getbuildtest.tcl that makes the support libraries (VTK, ITK, teem, etc) and also builds slicer and does a dashboard submission. (Click [[Slicer3:getbuildtest | here for background on getbuildtest]] and the experimental getbuildtest2 version).<br />
<br />
<br />
== Building the 3.2 release ==<br />
<br />
Just do the following two commands (see [[Slicer3:Build_Instructions#getbuildtest_on_windows|for windows users]] below):<br />
<br />
<br />
svn co http://www.na-mic.org/svn/Slicer3/branches/Slicer-3-2 Slicer3<br />
<br />
./Slicer3/Scripts/getbuildtest.tcl<br />
<br />
== Building the latest development version ==<br />
<br />
svn co http://www.na-mic.org/svn/Slicer3/trunk Slicer3<br />
<br />
./Slicer3/Scripts/getbuildtest.tcl<br />
<br />
Note: that a Slicer3-lib and Slicer3-build directory will be created for you. This is meant to be used to set up new machines and to run nightly testing of the full builds.<br />
<br />
To run (all platforms):<br />
<br />
./Slicer3-build/Slicer3<br />
<br />
Note: the whole build environment takes about 8G of disk space.<br />
<br />
== Testing ==<br />
<br />
Note also that getbuildtest will do an Experimental submission to the [http://www.cdash.org/CDash/index.php?project=Slicer3 Slicer3 dashboard]. If you want to use getbuildtest without submitting to the dashboard, you can set the test type to nothing with<br />
<br />
getbuildtest.tcl -t ""<br />
<br />
Other options for the -t (--test-type) option are Nightly or Continuous (or any of the [http://www.cmake.org/Wiki/CMake_Testing_With_CTest CTest] options).<br />
<br />
== What does getbuildtest.tcl do? ==<br />
<br />
This script just automates the steps needed to build slicer. What you end up with is a set of source and build directories that can either be further manipulated with getbuildtest or can be worked with normally. That is, on windows you will have solution files that you can load in visual studio for debugging and further development.<br />
<br />
Specifically, getbuildtest does the following steps:<br />
<br />
* Refreshes Slicer3 svn<br />
* Runs Scripts/genlib.tcl which does the following for each of the support libraries<br />
** does a cvs/svn checkout/update<br />
** runs cmake with the correct settings for use with Slicer3<br />
** runs make (or developer studio) to build the libraries<br />
* Runs cmake on Slicer3<br />
* Builds Slicer3<br />
* Runs ctest on Slicer3<br />
* (optionally) Runs CPack on Slicer3<br />
<br />
== Usage ==<br />
<br />
Usage:<br />
<br />
usage: getbuildtest [options] [target]<br />
[target] is determined automatically if not specified<br />
[options] is one of the following:<br />
--help : prints this message and exits<br />
--clean : delete lib and build directories first<br />
-t --test-type : CTest test target<br />
--release : compile with optimization flags<br />
--update : does a cvs/svn update on each lib<br />
--pack : builds a distribution package (cpack)<br />
<br />
== Errors from getbuildtest ==<br />
<br />
You will need to have your firewall configured to allow access to cvs servers through port 2401. Also you need 8081 for submitting to the dashboard.<br />
<br />
Other errors might mean you don't have all the build tools (see next section).<br />
<br />
If you want to generate a log of the build process, you can use a command like the following:<br />
<br />
# for csh/tcsh:<br />
./Scripts/getbuildtest.tcl |& tee build.log<br />
or<br />
# for sh/bash:<br />
./Scripts/getbuildtest.tcl 2>&1 | tee build.log<br />
<br />
== Updating Your getbuildtest Build ==<br />
<br />
There are a few options:<br />
<br />
* you can re-run getbuildtest and it will update slicer3 and rebuild (just slicer3)<br />
* you can add the --update option and all the libs will get a cvs/svn update and will rebuild if needed (good for tracking the development head of VTK/ITK/KWWidgets etc).<br />
* you can just 'svn update' in the Slicer3 directory and then do 'make' in the Slicer3-build to get just the latest Slicer3 code.<br />
<br />
The following command for unix machines will update, build, and launch the latest Slicer3:<br />
<br />
svn update && (cd ../Slicer3-build; make && ./bin/Slicer3)<br />
<br />
Note that on Windows you can also use the CMakeSetup.exe interface to CMake and then use Microsoft Visual Studio for debugging. You can use a command like the following in a cygwin shell to use the slicer launcher to start up visual studio with the correct environment to find the .dll files needed for debugging.<br />
<br />
./Slicer3.exe --launch c:/Program\ Files/Microsoft\ Visual\ Studio\ 8/Common7/IDE/devenv.exe --detach Slicer3.sln<br />
<br />
== getbuildtest on linux ==<br />
<br />
To compile Slicer3 and do development, be sure you have a complete set of development packages installed on your machine. The exact packages vary by distribution, but include:<br />
* gcc<br />
* gcc-c++<br />
* libX11 <br />
* libX11-devel (libX11-dev on Ubuntu 7.04)<br />
* libXt-devel (libXt-dev on Ubuntu)<br />
* opengl/mesa (libgl1-mesa-dev on Ubuntu)<br />
<br />
Ubuntu one line install:<br />
<br />
sudo apt-get install subversion cvs tcl8.4 gcc g++ libX11-dev libXt-dev libxext-dev libgl1-mesa-dev libncurses5-dev tcsh<br />
<br />
Also, be sure you have OpenGL and the GLX extension to X working. To check the installation, it is usually enough to confirm that the command <pre>glxgears</pre> runs with no errors.<br />
<br />
== getbuildtest on windows ==<br />
<br />
The script should work fine on a properly configured windows environment. Current requirements are:<br />
<br />
* Developer Studio 8 2005 <br />
** For Developer Studio 9.0 2008 Visual C++ Express which is free from Microsoft [[Slicer3:Build_Instructions#Information_on_Free_Microsoft_C.2B.2B_Compiler_on_Windows|see below]].<br />
** Other releases of visual studio also work (7, and 7.1)<br />
** If they are installed in the default locations in "c:/Program Files" they will be detected by the build script automatically (you need to edit slicer_variables.tcl to point to the installation).<br />
* [http://www.cygwin.com Cygwin] with the following packages<br />
** tcltk<br />
** svn<br />
** cvs<br />
** unzip<br />
** curl<br />
* With Developers Studio and cygwin installed, you only need to do the svn checkout and getbuildtest script to get a fully working Slicer3 plus all the tools you need to develop new code.<br />
<br />
Note: CMake and VTK will not work on a FAT formatted disk (use NTFS).<br />
<br />
== getbuildtest on Apple Mac OS X ==<br />
<br />
For Mac OS 10.4.10 install the following from the OS disks (not installed by default on new machines):<br />
* Xcode Tools (OS Disk 1, default window)<br />
* X11: also on OS Disk 1, but you need to scroll down and find the Optional Installs installer and select X11 under Applications. See [http://porting.openoffice.org/mac/faq/installing/X11.html step-by-step instructions].<br />
* X11SDK - from OS Disk 1, Xcode Tools/Packages/X11SDK.pkg<br />
* Subversion. Installation [http://downloads.open.collab.net/binaries.html options here]. Get the latest svn version for compatibility with the server and be sure your client includes SSL (so it can access https repositories).<br />
<br />
Remember to run getbuildtest from an xterm so the tests can access the X server.<br />
<br />
Note: The X11 application on Mac OSX 10.5.x (Leopard) crashes frequently. This is a known issue that is still under investigation.<br />
<br />
== configuration options ==<br />
<br />
The file Slicer3/slicer_variables.tcl includes configuration options for which versions of support libraries to use. You may want to change these for testing or to get access to new functionality.<br />
<br />
These flags control the versions of code pulled from external repositories:<br />
<br />
set ::Slicer3_TAG "http://www.na-mic.org/svn/Slicer3/trunk"<br />
set ::CMAKE_TAG "CMake-2-6"<br />
set ::KWWidgets_TAG "Slicer-3-2"<br />
set ::VTK_TAG "VTK-5-2"<br />
set ::ITK_TAG ITK-3-6<br />
set ::PYTHON_TAG "http://svn.python.org/projects/python/branches/release25-maint"<br />
<br />
Other libraries, such as Tcl/Tk, teem, and curl, together with windows binaries for CMake and Tcl/Tk are mirrored for efficiency at http://www.na-mic.org/svn/Slicer3-lib-mirrors.<br />
<br />
For example, you may want a build against the ITK cvs head. Change the flag value and then run <br />
<br />
getbuildtest.tcl --update <br />
<br />
which will get the version from cvs, build it, and rebuild slicer3. Depending on how radically different the versions you build are, you may need to use the --clean option which will delete all build directories and rebuild.<br />
<br />
= Manual checkout/build of Slicer3 and support libraries: =<br />
<br />
Note: the getbuiltest script described above simply automates and systematizes a sequence of build operations that can be performed manually. You may want to use the manual method if you are testing against different versions of VTK or ITK, or if you have existing build trees that you want to re-use. ''Note that not all combinations of software versions and build flags are actively tested. The following information may not be up to date as new code is added to the various repositories.''<br />
<br />
<br />
== Prerequisite software ==<br />
<br />
You need to get and build the following packages if you aren't using the getbuildtest script:<br />
<br />
# [http://www.cmake.org CMake (2.4.1 or later)]<br />
# [http://www.tcl.tk Tcl/Tk (8.4 or later)]<br />
# [http://sourceforge.net/projects/incrtcl/ incrTcl (3.2.1)]<br />
# [http://www.vtk.org VTK 5.0]<br />
# [http://www.itk.org ITK 3.4]<br />
# [http://www.kwwidgets.org KWWidgets Slicer-3-0 tag]<br />
# [http://teem.sf.net Teem (1.9.0)]<br />
# [http://www.na-mic.org/svn/Slicer3-lib-mirrors/trunk/cmcurl/ SlicerLibCurl (HEAD tag)]<br />
<br />
== Build Steps ==<br />
<br />
Steps:<br />
<br />
$ svn co http://www.na-mic.org/svn/Slicer3/trunk Slicer3<br />
$ cvs -d :pserver:anoncvs@www.vtk.org:/cvsroot/VTK co VTK -r VTK-5-0<br />
$ cvs -d :pserver:anoncvs@www.itk.org:/cvsroot/Insight co Insight -r ITK-3-4<br />
$ cvs -d :pserver:anoncvs@www.kwwidgets.org:/cvsroot/KWWidgets co KWWidgets -r Slicer-3-0<br />
$ svn co http://www.na-mic.org/svn/Slicer3-lib-mirrors/trunk/cmcurl cmcurl<br />
<br />
<br />
=== Configure and build ITK ===<br />
<br />
* BUILD_SHARED_LIBS ON<br />
* CMAKE_SKIP_RPATH ON<br />
<br />
=== Configure and build VTK ===<br />
<br />
* All systems:<br />
** BUILD_SHARED_LIBS ON<br />
** CMAKE_SKIP_RPATH ON<br />
** VTK_WRAP_TCL ON<br />
** VTK_DEBUG_LEAKS ON<br />
<br />
<br /><br />
<br />
* MacOSX specific (Make sure to install [http://www.apple.com/downloads/macosx/apple/x11formacosx.html X11]):<br />
** VTK_USE_CARBON OFF<br />
** VTK_USE_X ON<br />
<br />
<br /><br />
<br />
* Note, those options '''should not''' appear, since they disapear since VTK5:<br />
** VTK_USE_HYBRID ON<br />
** VTK_USE_PATENTED ON<br />
<br />
* Make sure that the TCL and TK path are set properly<br />
** TCL_* and TK_*<br />
<br />
=== Configure and build KWWidgets ===<br />
<br />
* You need to specify where your VTK build tree is.<br />
* BUILD_SHARED_LIBS ON<br />
* CMAKE_SKIP_RPATH ON<br />
<br />
=== Configure and build curl ===<br />
<br />
* BUILD_SHARED_LIBS OFF<br />
<br />
== Build and Run Slicer3 ==<br />
<br />
=== Manually ===<br />
<br />
# Check out and build slicer3 (e.g. on linux)<br />
<br />
svn co http://www.na-mic.org/svn/Slicer3/trunk Slicer3<br />
mkdir Slicer3-build<br />
cd Slicer3-build<br />
ccmake ../Slicer3<br />
make<br />
<br />
Again make sure to turn:<br />
<br />
* BUILD_SHARED_LIBS ON<br />
* CMAKE_SKIP_RPATH ON<br />
<br />
<br /> Start slicer with the Slicer3 executable in your build directory.<br />
<br />
= SBuild =<br />
SBuild is a new, experimental build system for Slicer. It is based on getbuildtest2.tcl and genlib2.tcl, but rather than try to hid the gory details of building Slicer, SBuild attempts to expose a reasonable amount to the developer. The interface should be reasonably intuitive, but a brief walk through is useful. Click on the thumbnails for larger views. SBuild allows you to update and build just the portions of Slicer that you may require or want to build. Any of the required libraries may be specified to be build by SBuild, or to use an existing build. Existing libraries are not controlled by SBuild. Under the hood, SBuild calls CMake to do the heavy lifting, just like getbuildtest2.tcl.<br />
<br />
== Screenshots ==<br />
{|<br />
|+ SBuild screenshots<br />
|-<br />
| [[image:SBuild-MainWindow.png|center|250px|Main SBuild Window]] || [[image:SBuild-RequiredWindow.png|center|250px|Required libraries]] <br />
||[[image:SBuild-AllExternal.png|center|250px|SBuild configured for all external builds]] <br />
|}<br />
<br />
<br />
# Configure the "Slicer Source Directory" by clicking on the "..." button, or typing a path to where you would like Slicer source saved<br />
## Configure the "Slicer Build Directory" and "Slicer Library Directory" in the same fashion<br />
# (Optional:) Switch to the "Required Libs" tab<br />
## Configure any of the external builds that you may have by clicking on the checkbox next to the "Use external build" label<br />
## When prompted, find the external build directory<br />
## Note: SBuild looks for specific files inside the directory you choose, if not found you will be warned. In this case, choose better.<br />
## Any of the required libraries may be Updated, Configured, or Built from this tab.<br />
# To build everything, go to the Slicer3 tab and click "All"<br />
## Output of the build process should fly by.<br />
<br />
== Binary downloads ==<br />
<br />
* [[Media:SBuild-darwin-ppc.gz| Mac OSX PPC (must use X11)]]<br />
* [[Media:SBuild-darwin-x86.gz| Mac OSX x86 (must use X11)]]<br />
* [[Media:SBuild-linux-x86.gz| Linux x86]]<br />
* [[Media:SBuild-linux-x86_64.gz| Linux x86-64]]<br />
* [[Media:SBuild-win32_exe.gz| Win32 (please properly rename it)]]<br />
* [[Media:SBuild.kit.gz| Generic tclkit (any platform)]]<br />
<br />
== Adding new Libraries to SBuild ==<br />
The default package of SBuild contains the minimal number of required libraries to build Slicer. Currently no optional libraries are installed. The procedure for providing an SBuild plugin is modestly complicated, but several good examples exist. All plugins go in SBuild.vfs/lib/SBuildPlugins. As an example, let's create a plugin called Mythical, contained in SBuild.vfs/lib/SBuildPlugins/Mythical.tcl.<br />
<br />
In the Slicer3/Scripts/SBuild directory, run '''./bootstrap run''' to run SBuild, and '''./bootstrap build''' to build the Tcl Starkits.<br />
<br />
The first section of Mythical.tcl provides some housekeeping details:<br />
<br />
package provide SBuildPlugins 1.0 <br />
<br />
lappend ::SBuild(Plugins) Mythical <br />
<br />
set ::Plugin(Mythical,Type) "optional"<br />
set ::Plugin(Mythical,Order) 100<br />
set ::Plugin(Mythical,CanUseUserBuild) 1<br />
<br />
The Mythical plugin must append itself to ::SBuild(Plugins) to register, and declares itself optional, builds in order 100, and can use user provided builds.<br />
<br />
Each plugin must provide several Tcl procs to do various functions. The naming convention is PluginName-Function-Architecture. In this example PluginName is Mythical. SBuild first looks for the -Architecture variant, and failing, calls the PluginName-Function. For instance, Mythical-Update is the Tcl proc that updates the source for Mythical, while Mythical-Build-Windows is a specialization for Windows. The important functions are: Update, Configure, Build, and ConfigureSlicer. The ConfigureSlicer function may append a CMake argument to be used when Slicer is configured. If external packages are allowed, the ConfigureExternal function is called. ConfigureExternal usually looks for libraries and sets a LibPath to be used to configure Slicer. Examples of these functions are shown below.<br />
<br />
# Here is where we would add lines to the main Slicer3 configuration<br />
proc Mythical-Setup {} {<br />
global SBuild<br />
}<br />
<br />
# How do we setup for an external build<br />
proc Mythical-ConfigureExternal {} {<br />
global SBuild<br />
set SBuild(Mythical,LibPath) [file dirname [FindFile $::SBuild(Mythical,ExternalBuildPath) [list libMythicalCommon* MythicalCommon*.lib MythicalCommon*.dll]]]<br />
}<br />
<br />
# Add a line to Slicer's CMake command<br />
proc Mythical-ConfigureSlicer {} {<br />
global Plugin SBuild Slicer<br />
set dir [file join $SBuild(SlicerLibDir) Insight-build]<br />
if { $SBuild(Mythical,UseExternalBuild) } {<br />
set dir $SBuild(Mythical,ExternalBuildPath)<br />
}<br />
Debug "setting Mythical_DIR to $dir"<br />
lappend Slicer(CMakeArguments) -DMythical_DIR:FILEPATH=$dir<br />
}<br />
<br />
# How do we update Mythical?<br />
proc Mythical-Update {} {<br />
Debug "Checking out Mythical"<br />
global SBuild Plugin<br />
file mkdir Insight<br />
ExecuteCommand $SBuild(SVNCommand) co http://www.mythical.org/svn/Mythical/trunk Mythical<br />
}<br />
<br />
# Configure to build<br />
proc Mythical-Configure {} {<br />
Debug "Configure Mythical"<br />
global SBuild Plugin<br />
file mkdir Mythical-build<br />
cd Mythical-build<br />
ExecuteCommand $SBuild(CMake) \<br />
-G$SBuild(Generator) \<br />
-DCMAKE_CXX_COMPILER:STRING=$::SBuild(CompilerPath)/$SBuild(Compiler) \<br />
-DCMAKE_CXX_COMPILER_FULLPATH:FILEPATH=$::SBuild(CompilerPath)/$SBuild(Compiler) \<br />
-DBUILD_SHARED_LIBS:BOOL=ON \<br />
-DCMAKE_SKIP_RPATH:BOOL=ON \<br />
-DBUILD_EXAMPLES:BOOL=OFF \<br />
-DBUILD_TESTING:BOOL=OFF \<br />
-DCMAKE_BUILD_TYPE:STRING=$::SBuild(BuildType) \<br />
-DCMAKE_CXX_FLAGS_DEBUG:STRING=$::SBuild(CMakeCXXFlagsDebug) \<br />
../Insight<br />
}<br />
<br />
# How do we build on windows?<br />
proc Mythical-Build-Windows {} {<br />
global SBuild<br />
cd Insight-build<br />
ExecuteCommand $SBuild(Make) Mythical.SLN /build $SBuild(BuildType)<br />
}<br />
<br />
# How do we build on other Makefile-based systems?<br />
proc Mythical-Build {} {<br />
Debug "Building Mythical"<br />
global SBuild<br />
cd Insight-build<br />
eval ExecuteCommand $SBuild(Make) $SBuild(ParallelMake)<br />
}<br />
<br />
# Clean up Mythical (nothing for the moment).<br />
proc Mythical-Clean {} {<br />
Debug "Cleaning Mythical"<br />
}<br />
<br />
= Links =<br />
* [[Main_Page| Slicer Wiki Pages]]<br />
* [[Slicer3::Eclipse | Howto integrate Slicer3 into Eclipse]]<br />
<br />
== Information on Free Microsoft C++ Compiler on Windows ==<br />
To build with the free version of the windows compiler, follow the instructions [[Slicer3:Build_Instructions_Windows| here.]]<br />
<br />
As of April 11, 2008, this works with the slicer3 svn trunk. You will need to manually install a newer version of cmake as part of the process described in the link above.</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/2008_Summer_Project_Week&diff=5259User:Barre/2008 Summer Project Week2008-06-26T17:56:44Z<p>Barre: </p>
<hr />
<div>* Various user-friendly optimization (see [[User:Barre/TODO|TODO]])<br />
* Steve Aylward: SlicerIGT funding?<br />
* Tuesday<br />
** Ipek Oguz: Help with Offscreen Rendering and making sure it can behave as a command-line program (without a KWW GUI)<br />
** Ragani: Try to convert legacy code, vtkImageResliceST.cxx, based on old vtkImageReslice<br />
** Craig Sharp: Help with Plastimatch; including the CMake code for a CLP was conflicting with his own CMake code. At the end of the day, his library needed to be linked against ITK, as opposed to just his executables; why the CLP CMake code revealed that "problem" is not clear, but in any case that's the way to go in general...<br />
** Luis: discuss the IO formats introspection (see [[User:Barre/TODO|TODO]])<br />
** Cleanup some installation/configuration rules in QdecModule and TumorGrowth<br />
* Wednesday<br />
** Gary Christensen & team: CMake/CPack presentation, help<br />
** Will: build Slicer3 (need to update the Wiki)<br />
** Alex: check the Models tree widget issue, i.e. that it is lacking the usability found in Slicer2 (see [[User:Barre/TODO|TODO]])<br />
** Add option vtkKWTreeWithScrollbars to resize the tree manually (see [[User:Barre/TODO|TODO]])<br />
* Thursday<br />
** Steve, Ron, Will: strategy for the infrastructure required to create Slicer3 binaries and separate modules that can be reviewed, downloaded, integrated in Slicer3. Not to be completed by RSNA. Experimentation for the moment. I (Seb) will produce some installers for Slicer3-Core + Modules, installers/ZIP for the CLP (which need to be fixed so that they can be built/installed separately against Slicer3), installers/ZIP for Slicer3-modules (using the macros that will pull them out of their repository and build them automatically), and a GUI in Slicer3 to fetch the ZIP and unpack them.<br />
** Wendy: got some info about the current font system, and make sure she agrees with the rewrite. We will stick to a simpler system, i.e. stick to the default system font and compute a smaller font from there. There will still be a (likely hidden) way to increase the font size globally, in case somebody is presenting through a projector. Feedback from the community will lead to some adjustment, but we will stay clear from hardcoding font size and family.<br />
** Bill: work on the launcher so that it supports a splash screen and the current StarKit launcher can be avoid in RPM installers... <br />
*** Win32 Resources:<br />
**** <small>[http://www.microsoft.com/msj/1099/c/c1099.aspx How can I implement a start-up screen that displays a bitmap in MFC?]</small><br />
**** <small>[http://support.microsoft.com/kb/815376 How to create and insert a splash screen in an SDI application or in an MDI application by using Visual C++ .NET or Visual C++ 2005]</small><br />
**** <small>[http://www.ucancode.net/Visual_C_Control/Splash-screen-of-transparent-bitmap-vc-sample.htm VC++ MFC Sample Code: Transparent bitmap splash screen]</small><br />
**** <small>[http://www.codeproject.com/KB/winsdk/win32splash.aspx Own-thread Win32 splash screen]</small><br />
**** <small>[http://www.codejock.com/support/articles/mfc/general/g_2.asp Dialog With Splash Screen]</small><br />
**** <small>[http://www.endurasoft.com/techtalk/splash.htm Making a Splash]</small><br />
**** <small>[http://www.codeproject.com/KB/dialog/splasher.aspx Splasher v1.32 - A Splash Screen Implementation]</small><br />
*** X11 Resources:</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/TODO&diff=5258User:Barre/TODO2008-06-26T15:53:58Z<p>Barre: </p>
<hr />
<div>==[[2008 June Workshop Germany |Training Event in Germany]]==<br />
<br />
Notes from a session with Ron, important items to address to improve Slicer3 usability.<br />
<br />
* Save Data: how can one save a data file as a specific/different ITK file format. ITK uses a IO plugin framework to support new file formats: is there a way to find the list of file formats supported by ITK at run-time.<br />
** <small>I (Seb) to check with Luis<br>'''[UPDATE]''' see ImageFileReader<...>::GenerateOutputInformation, BUT every IO file/reader need to expose the list of file extensions it can read and write. Luis is on it, to be added 3.8 end of July. Luis is fast, it's [http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/IO/itkImageIOBase.h?root=Insight&r1=1.48&r2=1.49 in the CVS], and examplified in [http://public.kitware.com/cgi-bin/viewcvs.cgi/Testing/Code/IO/itkImageIOFileNameExtensionsTests.cxx?root=Insight&sortby=date&view=log itkImageIOFileNameExtensionsTests.cxx]</small> <br />
<br />
* Save Data: the "Save" dialog in general is very confusing and buggy. The "Save All" and "Save None" button are mislabelled since they don't perform any save. Saving data to a new file format requires the user to double-click in the file name and manually change the file extension (provided that this extension is known to the user). Changing the data directory does not update the data locations in the multicolumn list (it does if you change the data directory twice). Changing the scene directory has no impact on the data directory.<br />
**<small> I (Seb) suggest that the "Save All/None" should be something like "Mark all for save", "Mark none for save". A button should be placed next to each data filename/location to quickly switch to a new file type (depending on what ITK can save to at run-time). The dialog is large, we have room to put a help string/label that explains a little more how the whole dialog works. Changing the data directory should update the location of each data entry in the multicolumn list correctly. A button should be added to quickly set the data directory to match the scene directory (it should not be automatic though).</small><br />
<br />
* Font Size: the font is definitely too small for the "Modules" menubutton or the filename label in any of the Red/Yellow/Green slice viewports. The "View -> Font Size" menu does not report the current font size. <br />
** <small>My (Seb) opinion is to avoid hard-coding font size as much as possible, and not let the user override either font size or font family: we can not support all the possible layout combinations, or guarantee it will all fit; let's focus instead on making sure it looks nice and fit decently with the default system font size. The label in the RYG slice viewports is cropped automatically to something likely too small, and not updated later on when the slice viewport is resized/maximized: to fix.</small><br />
** <small>Ron: Starting with the system default font is a good idea. I have encountered many situations where it is critical to be able to change the font to larger or smaller. Having a keyboard shortcut for situations where the menu is not accessible might be a good idea too: Ctrl + and ctrl - come to mind, like in firefox.</small><br />
<br />
* Progress Bar: the progress bar used while loading data has been removed because it was triggering too many "update idletasks". We still need one though.<br />
** <small>Steve suggests creating an OpenGL progress bar directly inside a small renderwindow. I (Seb) checked VTK's scale/slider interaction widget to see if that would do the trick. To be investigated further with the VTK's widget guru, Will. Actually a better starting point could be the color bar actor.</small><br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" may be too small for some users, as it gets more and more crowded.<br />
** <small>My (Seb) opinion is that we can't have it resize automatically because who knows how tall it could be, and it would push everything down. Ron is OK to have an option to do it manually, so I plan to add two icon/buttons to increase/decrease the height (numbe of lines) of the tree, say add 15 more lines, and double the size, etc. I wish we could just "drag" the whole tree frame to a new size, like expanding a window, but that's just too hard (or impossible) to implement with this Tk widget.<br>'''[UPDATE]''' vtkKWTreeWithScrollbars has now a ResizeButtonsVisibility flag that is set for the models and MRML tree, and allow for two small resize buttons to be used to resize a tree.</small>[[Image:KWWidgetsExpandTreeButton.png|center|thumb|250px]] <br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" is not as intuitive as the previous UI found in Slicer2; for each model, one could check/uncheck the visibility and change the opacity using controls placed directly next to the model's name (i.e. on the same row). The model name/label itself would use a background color matching the color used to display the model in the 3D view, a nice hint. The tree used in Slicer3 does not do nearly as much, i.e. the user has to select a node then change its visibily using a checkbutton placed in a different frame below the tree (note that the visibility and color can be changed quickly though, by using a popup menu by right-clicking on the tree leaf).<br />
** <small>I (Seb) had several discussion about this item with Alex, and I'm still not sure why this can't be done technically by adding custom widgets next to the label name for each leaf in the tree, but I will have a look at it again.<br>'''[UPDATE]''' Given the size of the testing scene (say, 200 elements), the multicolumn widget would be too slow if each row had a label, a color button, a visibility button, etc., and the indentation would be a ugly hack. The tree widget does support custom widgets per row, but not in separate columns: they would be misaligned (either on the left or right of a leaf label). It seems we need the TkTreeCtrl widget which was added last year when this problem was raised already; Seb to create a C++ class around this monster library and expose only the methods we need for this very specific problem; it will take some time, since TkTreeCtrl is the most complex Tcl/Tk widget to be found in KWWidgets so far.</small></div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/2008_Summer_Project_Week&diff=5257User:Barre/2008 Summer Project Week2008-06-26T15:42:17Z<p>Barre: </p>
<hr />
<div>* Various user-friendly optimization (see [[User:Barre/TODO|TODO]])<br />
* Steve Aylward: SlicerIGT funding?<br />
* Tuesday<br />
** Ipek Oguz: Help with Offscreen Rendering and making sure it can behave as a command-line program (without a KWW GUI)<br />
** Ragani: Try to convert legacy code, vtkImageResliceST.cxx, based on old vtkImageReslice<br />
** Craig Sharp: Help with Plastimatch; including the CMake code for a CLP was conflicting with his own CMake code. At the end of the day, his library needed to be linked against ITK, as opposed to just his executables; why the CLP CMake code revealed that "problem" is not clear, but in any case that's the way to go in general...<br />
** Luis: discuss the IO formats introspection (see [[User:Barre/TODO|TODO]])<br />
** Cleanup some installation/configuration rules in QdecModule and TumorGrowth<br />
* Wednesday<br />
** Gary Christensen & team: CMake/CPack presentation, help<br />
** Will: build Slicer3 (need to update the Wiki)<br />
** Alex: check the Models tree widget issue, i.e. that it is lacking the usability found in Slicer2 (see [[User:Barre/TODO|TODO]])<br />
** Add option vtkKWTreeWithScrollbars to resize the tree manually (see [[User:Barre/TODO|TODO]])<br />
* Thursday<br />
** Steve, Ron, Will: strategy for the infrastructure required to create Slicer3 binaries and separate modules that can be reviewed, downloaded, integrated in Slicer3. Not to be completed by RSNA. Experimentation for the moment. I (Seb) will produce some installers for Slicer3-Core + Modules, installers/ZIP for the CLP (which need to be fixed so that they can be built/installed separately against Slicer3), installers/ZIP for Slicer3-modules (using the macros that will pull them out of their repository and build them automatically), and a GUI in Slicer3 to fetch the ZIP and unpack them.</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/TODO&diff=5256User:Barre/TODO2008-06-26T15:14:43Z<p>Barre: </p>
<hr />
<div>==[[2008 June Workshop Germany |Training Event in Germany]]==<br />
<br />
Notes from a session with Ron, important items to address to improve Slicer3 usability.<br />
<br />
* Save Data: how can one save a data file as a specific/different ITK file format. ITK uses a IO plugin framework to support new file formats: is there a way to find the list of file formats supported by ITK at run-time.<br />
** <small>I (Seb) to check with Luis<br>'''[UPDATE]''' see ImageFileReader<...>::GenerateOutputInformation, BUT every IO file/reader need to expose the list of file extensions it can read and write. Luis is on it, to be added 3.8 end of July. Luis is fast, it's [http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/IO/itkImageIOBase.h?root=Insight&r1=1.48&r2=1.49 in the CVS], and examplified in [http://public.kitware.com/cgi-bin/viewcvs.cgi/Testing/Code/IO/itkImageIOFileNameExtensionsTests.cxx?root=Insight&sortby=date&view=log itkImageIOFileNameExtensionsTests.cxx]</small> <br />
<br />
* Save Data: the "Save" dialog in general is very confusing and buggy. The "Save All" and "Save None" button are mislabelled since they don't perform any save. Saving data to a new file format requires the user to double-click in the file name and manually change the file extension (provided that this extension is known to the user). Changing the data directory does not update the data locations in the multicolumn list (it does if you change the data directory twice). Changing the scene directory has no impact on the data directory.<br />
**<small> I (Seb) suggest that the "Save All/None" should be something like "Mark all for save", "Mark none for save". A button should be placed next to each data filename/location to quickly switch to a new file type (depending on what ITK can save to at run-time). The dialog is large, we have room to put a help string/label that explains a little more how the whole dialog works. Changing the data directory should update the location of each data entry in the multicolumn list correctly. A button should be added to quickly set the data directory to match the scene directory (it should not be automatic though).</small><br />
<br />
* Font Size: the font is definitely too small for the "Modules" menubutton or the filename label in any of the Red/Yellow/Green slice viewports. The "View -> Font Size" menu does not report the current font size. <br />
** <small>My (Seb) opinion is to avoid hard-coding font size as much as possible, and not let the user override either font size or font family: we can not support all the possible layout combinations, or guarantee it will all fit; let's focus instead on making sure it looks nice and fit decently with the default system font size. The label in the RYG slice viewports is cropped automatically to something likely too small, and not updated later on when the slice viewport is resized/maximized: to fix.</small><br />
** <small>Ron: Starting with the system default font is a good idea. I have encountered many situations where it is critical to be able to change the font to larger or smaller. Having a keyboard shortcut for situations where the menu is not accessible might be a good idea too: Ctrl + and ctrl - come to mind, like in firefox.</small><br />
<br />
* Progress Bar: the progress bar used while loading data has been removed because it was triggering too many "update idletasks". We still need one though.<br />
** <small>Steve suggests creating an OpenGL progress bar directly inside a small renderwindow. I (Seb) checked VTK's scale/slider interaction widget to see if that would do the trick. To be investigated further with the VTK's widget guru, Will.</small><br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" may be too small for some users, as it gets more and more crowded.<br />
** <small>My (Seb) opinion is that we can't have it resize automatically because who knows how tall it could be, and it would push everything down. Ron is OK to have an option to do it manually, so I plan to add two icon/buttons to increase/decrease the height (numbe of lines) of the tree, say add 15 more lines, and double the size, etc. I wish we could just "drag" the whole tree frame to a new size, like expanding a window, but that's just too hard (or impossible) to implement with this Tk widget.<br>'''[UPDATE]''' vtkKWTreeWithScrollbars has now a ResizeButtonsVisibility flag that is set for the models and MRML tree, and allow for two small resize buttons to be used to resize a tree.</small>[[Image:KWWidgetsExpandTreeButton.png|center|thumb|250px]] <br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" is not as intuitive as the previous UI found in Slicer2; for each model, one could check/uncheck the visibility and change the opacity using controls placed directly next to the model's name (i.e. on the same row). The model name/label itself would use a background color matching the color used to display the model in the 3D view, a nice hint. The tree used in Slicer3 does not do nearly as much, i.e. the user has to select a node then change its visibily using a checkbutton placed in a different frame below the tree (note that the visibility and color can be changed quickly though, by using a popup menu by right-clicking on the tree leaf).<br />
** <small>I (Seb) had several discussion about this item with Alex, and I'm still not sure why this can't be done technically by adding custom widgets next to the label name for each leaf in the tree, but I will have a look at it again.<br>'''[UPDATE]''' Given the size of the testing scene (say, 200 elements), the multicolumn widget would be too slow if each row had a label, a color button, a visibility button, etc., and the indentation would be a ugly hack. The tree widget does support custom widgets per row, but not in separate columns: they would be misaligned (either on the left or right of a leaf label). It seems we need the TkTreeCtrl widget which was added last year when this problem was raised already; Seb to create a C++ class around this monster library and expose only the methods we need for this very specific problem; it will take some time, since TkTreeCtrl is the most complex Tcl/Tk widget to be found in KWWidgets so far.</small></div>Barrehttps://www.slicer.org/w/index.php?title=File:KWWidgetsExpandTreeButton.png&diff=5255File:KWWidgetsExpandTreeButton.png2008-06-26T15:10:52Z<p>Barre: </p>
<hr />
<div></div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/TODO&diff=5254User:Barre/TODO2008-06-26T14:58:38Z<p>Barre: </p>
<hr />
<div>==[[2008 June Workshop Germany |Training Event in Germany]]==<br />
<br />
Notes from a session with Ron, important items to address to improve Slicer3 usability.<br />
<br />
* Save Data: how can one save a data file as a specific/different ITK file format. ITK uses a IO plugin framework to support new file formats: is there a way to find the list of file formats supported by ITK at run-time.<br />
** <small>I (Seb) to check with Luis<br>'''[UPDATE]''' see ImageFileReader<...>::GenerateOutputInformation, BUT every IO file/reader need to expose the list of file extensions it can read and write. Luis is on it, to be added 3.8 end of July. Luis is fast, it's [http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/IO/itkImageIOBase.h?root=Insight&r1=1.48&r2=1.49 in the CVS], and examplified in [http://public.kitware.com/cgi-bin/viewcvs.cgi/Testing/Code/IO/itkImageIOFileNameExtensionsTests.cxx?root=Insight&sortby=date&view=log itkImageIOFileNameExtensionsTests.cxx]</small> <br />
<br />
* Save Data: the "Save" dialog in general is very confusing and buggy. The "Save All" and "Save None" button are mislabelled since they don't perform any save. Saving data to a new file format requires the user to double-click in the file name and manually change the file extension (provided that this extension is known to the user). Changing the data directory does not update the data locations in the multicolumn list (it does if you change the data directory twice). Changing the scene directory has no impact on the data directory.<br />
**<small> I (Seb) suggest that the "Save All/None" should be something like "Mark all for save", "Mark none for save". A button should be placed next to each data filename/location to quickly switch to a new file type (depending on what ITK can save to at run-time). The dialog is large, we have room to put a help string/label that explains a little more how the whole dialog works. Changing the data directory should update the location of each data entry in the multicolumn list correctly. A button should be added to quickly set the data directory to match the scene directory (it should not be automatic though).</small><br />
<br />
* Font Size: the font is definitely too small for the "Modules" menubutton or the filename label in any of the Red/Yellow/Green slice viewports. The "View -> Font Size" menu does not report the current font size. <br />
** <small>My (Seb) opinion is to avoid hard-coding font size as much as possible, and not let the user override either font size or font family: we can not support all the possible layout combinations, or guarantee it will all fit; let's focus instead on making sure it looks nice and fit decently with the default system font size. The label in the RYG slice viewports is cropped automatically to something likely too small, and not updated later on when the slice viewport is resized/maximized: to fix.</small><br />
** <small>Ron: Starting with the system default font is a good idea. I have encountered many situations where it is critical to be able to change the font to larger or smaller. Having a keyboard shortcut for situations where the menu is not accessible might be a good idea too: Ctrl + and ctrl - come to mind, like in firefox.</small><br />
<br />
* Progress Bar: the progress bar used while loading data has been removed because it was triggering too many "update idletasks". We still need one though.<br />
** <small>Steve suggests creating an OpenGL progress bar directly inside a small renderwindow. I (Seb) checked VTK's scale/slider interaction widget to see if that would do the trick. To be investigated further with the VTK's widget guru, Will.</small><br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" may be too small for some users, as it gets more and more crowded.<br />
** <small>My (Seb) opinion is that we can't have it resize automatically because who knows how tall it could be, and it would push everything down. Ron is OK to have an option to do it manually, so I plan to add two icon/buttons to increase/decrease the height (numbe of lines) of the tree, say add 15 more lines, and double the size, etc. I wish we could just "drag" the whole tree frame to a new size, like expanding a window, but that's just too hard (or impossible) to implement with this Tk widget.<br>'''[UPDATE]''' vtkKWTreeWithScrollbars has now a ResizeButtonsVisibility flag that is set for the models and MRML tree, and allow for two small resize buttons to be used to resize a tree.</small> <br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" is not as intuitive as the previous UI found in Slicer2; for each model, one could check/uncheck the visibility and change the opacity using controls placed directly next to the model's name (i.e. on the same row). The model name/label itself would use a background color matching the color used to display the model in the 3D view, a nice hint. The tree used in Slicer3 does not do nearly as much, i.e. the user has to select a node then change its visibily using a checkbutton placed in a different frame below the tree (note that the visibility and color can be changed quickly though, by using a popup menu by right-clicking on the tree leaf).<br />
** <small>I (Seb) had several discussion about this item with Alex, and I'm still not sure why this can't be done technically by adding custom widgets next to the label name for each leaf in the tree, but I will have a look at it again.<br>'''[UPDATE]''' Given the size of the testing scene (say, 200 elements), the multicolumn widget would be too slow if each row had a label, a color button, a visibility button, etc., and the indentation would be a ugly hack. The tree widget does support custom widgets per row, but not in separate columns: they would be misaligned (either on the left or right of a leaf label). It seems we need the TkTreeCtrl widget which was added last year when this problem was raised already; Seb to create a C++ class around this monster library and expose only the methods we need for this very specific problem; it will take some time, since TkTreeCtrl is the most complex Tcl/Tk widget to be found in KWWidgets so far.</small></div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/TODO&diff=5253User:Barre/TODO2008-06-26T14:46:13Z<p>Barre: /* Training Event in Germany */</p>
<hr />
<div>==[[2008 June Workshop Germany |Training Event in Germany]]==<br />
<br />
Notes from a session with Ron, important items to address to improve Slicer3 usability.<br />
<br />
* Save Data: how can one save a data file as a specific/different ITK file format. ITK uses a IO plugin framework to support new file formats: is there a way to find the list of file formats supported by ITK at run-time.<br />
** <small>I (Seb) to check with Luis<br>'''[UPDATE]''' see ImageFileReader<...>::GenerateOutputInformation, BUT every IO file/reader need to expose the list of file extensions it can read and write. Luis is on it, to be added 3.8 end of July. Luis is fast, it's [http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/IO/itkImageIOBase.h?root=Insight&r1=1.48&r2=1.49 in the CVS], and examplified in [http://public.kitware.com/cgi-bin/viewcvs.cgi/Testing/Code/IO/itkImageIOFileNameExtensionsTests.cxx?root=Insight&sortby=date&view=log itkImageIOFileNameExtensionsTests.cxx]</small> <br />
<br />
* Save Data: the "Save" dialog in general is very confusing and buggy. The "Save All" and "Save None" button are mislabelled since they don't perform any save. Saving data to a new file format requires the user to double-click in the file name and manually change the file extension (provided that this extension is known to the user). Changing the data directory does not update the data locations in the multicolumn list (it does if you change the data directory twice). Changing the scene directory has no impact on the data directory.<br />
**<small> I (Seb) suggest that the "Save All/None" should be something like "Mark all for save", "Mark none for save". A button should be placed next to each data filename/location to quickly switch to a new file type (depending on what ITK can save to at run-time). The dialog is large, we have room to put a help string/label that explains a little more how the whole dialog works. Changing the data directory should update the location of each data entry in the multicolumn list correctly. A button should be added to quickly set the data directory to match the scene directory (it should not be automatic though).</small><br />
<br />
* Font Size: the font is definitely too small for the "Modules" menubutton or the filename label in any of the Red/Yellow/Green slice viewports. The "View -> Font Size" menu does not report the current font size. <br />
** <small>My (Seb) opinion is to avoid hard-coding font size as much as possible, and not let the user override either font size or font family: we can not support all the possible layout combinations, or guarantee it will all fit; let's focus instead on making sure it looks nice and fit decently with the default system font size. The label in the RYG slice viewports is cropped automatically to something likely too small, and not updated later on when the slice viewport is resized/maximized: to fix.</small><br />
** <small>Ron: Starting with the system default font is a good idea. I have encountered many situations where it is critical to be able to change the font to larger or smaller. Having a keyboard shortcut for situations where the menu is not accessible might be a good idea too: Ctrl + and ctrl - come to mind, like in firefox.<br />
<br />
* Progress Bar: the progress bar used while loading data has been removed because it was triggering too many "update idletasks". We still need one though.<br />
** <small>Steve suggests creating an OpenGL progress bar directly inside a small renderwindow. I (Seb) checked VTK's scale/slider interaction widget to see if that would do the trick. To be investigated further with the VTK's widget guru, Will.</small><br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" may be too small for some users, as it gets more and more crowded.<br />
** <small>My (Seb) opinion is that we can't have it resize automatically because who knows how tall it could be, and it would push everything down. Ron is OK to have an option to do it manually, so I plan to add two icon/buttons to increase/decrease the height (numbe of lines) of the tree, say add 15 more lines, and double the size, etc. I wish we could just "drag" the whole tree frame to a new size, like expanding a window, but that's just too hard (or impossible) to implement with this Tk widget.<br>'''[UPDATE]''' vtkKWTreeWithScrollbars has now a ResizeButtonsVisibility flag that is set for the models and MRML tree, and allow for two small resize buttons to be used to resize a tree.</small> <br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" is not as intuitive as the previous UI found in Slicer2; for each model, one could check/uncheck the visibility and change the opacity using controls placed directly next to the model's name (i.e. on the same row). The model name/label itself would use a background color matching the color used to display the model in the 3D view, a nice hint. The tree used in Slicer3 does not do nearly as much, i.e. the user has to select a node then change its visibily using a checkbutton placed in a different frame below the tree (note that the visibility and color can be changed quickly though, by using a popup menu by right-clicking on the tree leaf).<br />
** <small>I (Seb) had several discussion about this item with Alex, and I'm still not sure why this can't be done technically by adding custom widgets next to the label name for each leaf in the tree, but I will have a look at it again.<br>'''[UPDATE]''' Given the size of the testing scene (say, 200 elements), the multicolumn widget would be too slow if each row had a label, a color button, a visibility button, etc., and the indentation would be a ugly hack. The tree widget does support custom widgets per row, but not in separate columns: they would be misaligned (either on the left or right of a leaf label). It seems we need the TkTreeCtrl widget which was added last year when this problem was raised already; Seb to create a C++ class around this monster library and expose only the methods we need for this very specific problem; it will take some time, since TkTreeCtrl is the most complex Tcl/Tk widget to be found in KWWidgets so far.</small> <br />
<br />
* Tree: seen while Daniele was doing her tutorial: drag and dropping a leaf to a new parent will trigger an event that would repopulate the whole tree, hence losing the focus of the selection; she had to go down the list, etc etc. Let's make sure the focus is not lost...</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/2008_Summer_Project_Week&diff=5251User:Barre/2008 Summer Project Week2008-06-25T21:26:09Z<p>Barre: </p>
<hr />
<div>* Various user-friendly optimization (see [[User:Barre/TODO|TODO]])<br />
* Steve Aylward: SlicerIGT funding?<br />
* Tuesday<br />
** Ipek Oguz: Help with Offscreen Rendering and making sure it can behave as a command-line program (without a KWW GUI)<br />
** Ragani: Try to convert legacy code, vtkImageResliceST.cxx, based on old vtkImageReslice<br />
** Craig Sharp: Help with Plastimatch; including the CMake code for a CLP was conflicting with his own CMake code. At the end of the day, his library needed to be linked against ITK, as opposed to just his executables; why the CLP CMake code revealed that "problem" is not clear, but in any case that's the way to go in general...<br />
** Luis: discuss the IO formats introspection (see [[User:Barre/TODO|TODO]])<br />
** Cleanup some installation/configuration rules in QdecModule and TumorGrowth<br />
* Wednesday<br />
** Gary Christensen & team: CMake/CPack presentation, help<br />
** Will: build Slicer3 (need to update the Wiki)<br />
** Alex: check the Models tree widget issue, i.e. that it is lacking the usability found in Slicer2 (see [[User:Barre/TODO|TODO]])<br />
** Add option vtkKWTreeWithScrollbars to resize the tree manually (see [[User:Barre/TODO|TODO]])</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/TODO&diff=5250User:Barre/TODO2008-06-25T21:25:04Z<p>Barre: </p>
<hr />
<div>==[[2008 June Workshop Germany |Training Event in Germany]]==<br />
<br />
Notes from a session with Ron, important items to address to improve Slicer3 usability.<br />
<br />
* Save Data: how can one save a data file as a specific/different ITK file format. ITK uses a IO plugin framework to support new file formats: is there a way to find the list of file formats supported by ITK at run-time.<br />
** <small>I (Seb) to check with Luis<br>'''[UPDATE]''' see ImageFileReader<...>::GenerateOutputInformation, BUT every IO file/reader need to expose the list of file extensions it can read and write. Luis is on it, to be added 3.8 end of July.</small> <br />
<br />
* Save Data: the "Save" dialog in general is very confusing and buggy. The "Save All" and "Save None" button are mislabelled since they don't perform any save. Saving data to a new file format requires the user to double-click in the file name and manually change the file extension (provided that this extension is known to the user). Changing the data directory does not update the data locations in the multicolumn list (it does if you change the data directory twice). Changing the scene directory has no impact on the data directory.<br />
**<small> I (Seb) suggest that the "Save All/None" should be something like "Mark all for save", "Mark none for save". A button should be placed next to each data filename/location to quickly switch to a new file type (depending on what ITK can save to at run-time). The dialog is large, we have room to put a help string/label that explains a little more how the whole dialog works. Changing the data directory should update the location of each data entry in the multicolumn list correctly. A button should be added to quickly set the data directory to match the scene directory (it should not be automatic though).</small><br />
<br />
* Font Size: the font is definitely too small for the "Modules" menubutton or the filename label in any of the Red/Yellow/Green slice viewports. The "View -> Font Size" menu does not report the current font size. <br />
** <small>My (Seb) opinion is to avoid hard-coding font size as much as possible, and not let the user override either font size or font family: we can not support all the possible layout combinations, or guarantee it will all fit; let's focus instead on making sure it looks nice and fit decently with the default system font size. The label in the RYG slice viewports is cropped automatically to something likely too small, and not updated later on when the slice viewport is resized/maximized: to fix.</small><br />
<br />
* Progress Bar: the progress bar used while loading data has been removed because it was triggering too many "update idletasks". We still need one though.<br />
** <small>Steve suggests creating an OpenGL progress bar directly inside a small renderwindow. I (Seb) checked VTK's scale/slider interaction widget to see if that would do the trick. To be investigated further with the VTK's widget guru, Will.</small><br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" may be too small for some users, as it gets more and more crowded.<br />
** <small>My (Seb) opinion is that we can't have it resize automatically because who knows how tall it could be, and it would push everything down. Ron is OK to have an option to do it manually, so I plan to add two icon/buttons to increase/decrease the height (numbe of lines) of the tree, say add 15 more lines, and double the size, etc. I wish we could just "drag" the whole tree frame to a new size, like expanding a window, but that's just too hard (or impossible) to implement with this Tk widget.<br>'''[UPDATE]''' vtkKWTreeWithScrollbars has now a ResizeButtonsVisibility flag that is set for the models and MRML tree, and allow for two small resize buttons to be used to resize a tree.</small> <br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" is not as intuitive as the previous UI found in Slicer2; for each model, one could check/uncheck the visibility and change the opacity using controls placed directly next to the model's name (i.e. on the same row). The model name/label itself would use a background color matching the color used to display the model in the 3D view, a nice hint. The tree used in Slicer3 does not do nearly as much, i.e. the user has to select a node then change its visibily using a checkbutton placed in a different frame below the tree (note that the visibility and color can be changed quickly though, by using a popup menu by right-clicking on the tree leaf).<br />
** <small>I (Seb) had several discussion about this item with Alex, and I'm still not sure why this can't be done technically by adding custom widgets next to the label name for each leaf in the tree, but I will have a look at it again.<br>'''[UPDATE]''' Given the size of the testing scene (say, 200 elements), the multicolumn widget would be too slow if each row had a label, a color button, a visibility button, etc., and the indentation would be a ugly hack. The tree widget does support custom widgets per row, but not in separate columns: they would be misaligned (either on the left or right of a leaf label). It seems we need the TkTreeCtrl widget which was added last year when this problem was raised already; Seb to create a C++ class around this monster library and expose only the methods we need for this very specific problem; it will take some time, since TkTreeCtrl is the most complex Tcl/Tk widget to be found in KWWidgets so far.</small> <br />
<br />
* Tree: seen while Daniele was doing her tutorial: drag and dropping a leaf to a new parent will trigger an event that would repopulate the whole tree, hence losing the focus of the selection; she had to go down the list, etc etc. Let's make sure the focus is not lost...</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/TODO&diff=5249User:Barre/TODO2008-06-25T21:06:07Z<p>Barre: </p>
<hr />
<div>==[[2008 June Workshop Germany |Training Event in Germany]]==<br />
<br />
Notes from a session with Ron, important items to address to improve Slicer3 usability.<br />
<br />
* Save Data: how can one save a data file as a specific/different ITK file format. ITK uses a IO plugin framework to support new file formats: is there a way to find the list of file formats supported by ITK at run-time.<br />
** <small>I (Seb) to check with Luis<br>'''[UPDATE]''' see ImageFileReader<...>::GenerateOutputInformation, BUT every IO file/reader need to expose the list of file extensions it can read and write. Luis is on it, to be added 3.8 end of July.</small> <br />
<br />
* Save Data: the "Save" dialog in general is very confusing and buggy. The "Save All" and "Save None" button are mislabelled since they don't perform any save. Saving data to a new file format requires the user to double-click in the file name and manually change the file extension (provided that this extension is known to the user). Changing the data directory does not update the data locations in the multicolumn list (it does if you change the data directory twice). Changing the scene directory has no impact on the data directory.<br />
**<small> I (Seb) suggest that the "Save All/None" should be something like "Mark all for save", "Mark none for save". A button should be placed next to each data filename/location to quickly switch to a new file type (depending on what ITK can save to at run-time). The dialog is large, we have room to put a help string/label that explains a little more how the whole dialog works. Changing the data directory should update the location of each data entry in the multicolumn list correctly. A button should be added to quickly set the data directory to match the scene directory (it should not be automatic though).</small><br />
<br />
* Font Size: the font is definitely too small for the "Modules" menubutton or the filename label in any of the Red/Yellow/Green slice viewports. The "View -> Font Size" menu does not report the current font size. <br />
** <small>My (Seb) opinion is to avoid hard-coding font size as much as possible, and not let the user override either font size or font family: we can not support all the possible layout combinations, or guarantee it will all fit; let's focus instead on making sure it looks nice and fit decently with the default system font size. The label in the RYG slice viewports is cropped automatically to something likely too small, and not updated later on when the slice viewport is resized/maximized: to fix.</small><br />
<br />
* Progress Bar: the progress bar used while loading data has been removed because it was triggering too many "update idletasks". We still need one though.<br />
** <small>Steve suggests creating an OpenGL progress bar directly inside a small renderwindow. I (Seb) checked VTK's scale/slider interaction widget to see if that would do the trick. To be investigated further with the VTK's widget guru, Will.</small><br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" may be too small for some users, as it gets more and more crowded.<br />
** <small>My (Seb) opinion is that we can't have it resize automatically because who knows how tall it could be, and it would push everything down. Ron is OK to have an option to do it manually, so I plan to add two icon/buttons to increase/decrease the height (numbe of lines) of the tree, say add 15 more lines, and double the size, etc. I wish we could just "drag" the whole tree frame to a new size, like expanding a window, but that's just too hard (or impossible) to implement with this Tk widget.<br>'''[UPDATE]''' vtkKWTreeWithScrollbars has now a ResizeButtonsVisibility flag that is set for the models and MRML tree, and allow for two small resize buttons to be used to resize a tree.</small> <br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" is not as intuitive as the previous UI found in Slicer2; for each model, one could check/uncheck the visibility and change the opacity using controls placed directly next to the model's name (i.e. on the same row). The model name/label itself would use a background color matching the color used to display the model in the 3D view, a nice hint. The tree used in Slicer3 does not do nearly as much, i.e. the user has to select a node then change its visibily using a checkbutton placed in a different frame below the tree (note that the visibility and color can be changed quickly though, by using a popup menu by right-clicking on the tree leaf).<br />
** <small>I (Seb) had several discussion about this item with Alex, and I'm still not sure why this can't be done technically by adding custom widgets next to the label name for each leaf in the tree, but I will have a look at it again.</small><br />
<br />
* Tree: seen while Daniele was doing her tutorial: drag and dropping a leaf to a new parent will trigger an event that would repopulate the whole tree, hence losing the focus of the selection; she had to go down the list, etc etc. Let's make sure the focus is not lost...</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/2008_Summer_Project_Week&diff=5248User:Barre/2008 Summer Project Week2008-06-25T21:04:11Z<p>Barre: </p>
<hr />
<div>* Various user-friendly optimization (see [[User:Barre/TODO|TODO]])<br />
* Steve Aylward: SlicerIGT funding?<br />
* Tuesday<br />
** Ipek Oguz: Help with Offscreen Rendering and making sure it can behave as a command-line program (without a KWW GUI)<br />
** Ragani: Try to convert legacy code, vtkImageResliceST.cxx, based on old vtkImageReslice<br />
** Craig Sharp: Help with Plastimatch; including the CMake code for a CLP was conflicting with his own CMake code. At the end of the day, his library needed to be linked against ITK, as opposed to just his executables; why the CLP CMake code revealed that "problem" is not clear, but in any case that's the way to go in general...<br />
** Luis: discuss the IO formats introspection (see [[User:Barre/TODO|TODO]])<br />
** Cleanup some installation/configuration rules in QdecModule and TumorGrowth<br />
* Wednesday<br />
** Gary Christensen & team: CMake/CPack presentation, help<br />
** Will: build Slicer3 (need to update the Wiki)<br />
** Add option vtkKWTreeWithScrollbars to resize the tree manually (see [[User:Barre/TODO|TODO]])</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/2008_Summer_Project_Week&diff=5247User:Barre/2008 Summer Project Week2008-06-25T16:35:00Z<p>Barre: </p>
<hr />
<div>* Various user-friendly optimization (see [[User:Barre/TODO|TODO]])<br />
* Steve Aylward: SlicerIGT funding?<br />
* Tuesday<br />
** Ipek Oguz: Help with Offscreen Rendering and making sure it can behave as a command-line program (without a KWW GUI)<br />
** Ragani: Try to convert legacy code, vtkImageResliceST.cxx, based on old vtkImageReslice<br />
** Craig Sharp: Help with Plastimatch; including the CMake code for a CLP was conflicting with his own CMake code. At the end of the day, his library needed to be linked against ITK, as opposed to just his executables; why the CLP CMake code revealed that "problem" is not clear, but in any case that's the way to go in general...<br />
** Cleanup some installation/configuration rules in QdecModule and TumorGrowth<br />
* Wednesday<br />
** Gary Christensen & team?</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/TODO&diff=5246User:Barre/TODO2008-06-25T13:21:33Z<p>Barre: /* Training Event in Germany */</p>
<hr />
<div>==[[2008 June Workshop Germany |Training Event in Germany]]==<br />
<br />
Notes from a session with Ron, important items to address to improve Slicer3 usability.<br />
<br />
* Save Data: how can one save a data file as a specific/different ITK file format. ITK uses a IO plugin framework to support new file formats: is there a way to find the list of file formats supported by ITK at run-time.<br />
** <small>I (Seb) to check with Luis;<br>'''[UPDATE]''' see ImageFileReader<...>::GenerateOutputInformation, BUT every IO file/reader need to expose the list of file extensions it can read and write. Luis is on it, to be added 3.8 end of July.</small> <br />
<br />
* Save Data: the "Save" dialog in general is very confusing and buggy. The "Save All" and "Save None" button are mislabelled since they don't perform any save. Saving data to a new file format requires the user to double-click in the file name and manually change the file extension (provided that this extension is known to the user). Changing the data directory does not update the data locations in the multicolumn list (it does if you change the data directory twice). Changing the scene directory has no impact on the data directory.<br />
**<small> I (Seb) suggest that the "Save All/None" should be something like "Mark all for save", "Mark none for save". A button should be placed next to each data filename/location to quickly switch to a new file type (depending on what ITK can save to at run-time). The dialog is large, we have room to put a help string/label that explains a little more how the whole dialog works. Changing the data directory should update the location of each data entry in the multicolumn list correctly. A button should be added to quickly set the data directory to match the scene directory (it should not be automatic though).</small><br />
<br />
* Font Size: the font is definitely too small for the "Modules" menubutton or the filename label in any of the Red/Yellow/Green slice viewports. The "View -> Font Size" menu does not report the current font size. <br />
** <small>My (Seb) opinion is to avoid hard-coding font size as much as possible, and not let the user override either font size or font family: we can not support all the possible layout combinations, or guarantee it will all fit; let's focus instead on making sure it looks nice and fit decently with the default system font size. The label in the RYG slice viewports is cropped automatically to something likely too small, and not updated later on when the slice viewport is resized/maximized: to fix.</small><br />
<br />
* Progress Bar: the progress bar used while loading data has been removed because it was triggering too many "update idletasks". We still need one though.<br />
** <small>Steve suggests creating an OpenGL progress bar directly inside a small renderwindow. I (Seb) checked VTK's scale/slider interaction widget to see if that would do the trick. To be investigated further with the VTK's widget guru, Will.</small><br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" may be too small for some users, as it gets more and more crowded.<br />
** <small>My (Seb) opinion is that we can't have it resize automatically because who knows how tall it could be, and it would push everything down. Ron is OK to have an option to do it manually, so I plan to add two icon/buttons to increase/decrease the height (numbe of lines) of the tree, say add 15 more lines, and double the size, etc. I wish we could just "drag" the whole tree frame to a new size, like expanding a window, but that's just too hard (or impossible) to implement with this Tk widget.</small><br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" is not as intuitive as the previous UI found in Slicer2; for each model, one could check/uncheck the visibility and change the opacity using controls placed directly next to the model's name (i.e. on the same row). The model name/label itself would use a background color matching the color used to display the model in the 3D view, a nice hint. The tree used in Slicer3 does not do nearly as much, i.e. the user has to select a node then change its visibily using a checkbutton placed in a different frame below the tree (note that the visibility and color can be changed quickly though, by using a popup menu by right-clicking on the tree leaf).<br />
** <small>I (Seb) had several discussion about this item with Alex, and I'm still not sure why this can't be done technically by adding custom widgets next to the label name for each leaf in the tree, but I will have a look at it again.</small><br />
<br />
* Tree: seen while Daniele was doing her tutorial: drag and dropping a leaf to a new parent will trigger an event that would repopulate the whole tree, hence losing the focus of the selection; she had to go down the list, etc etc. Let's make sure the focus is not lost...</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/2008_Summer_Project_Week&diff=5245User:Barre/2008 Summer Project Week2008-06-25T03:31:35Z<p>Barre: </p>
<hr />
<div>* Various user-friendly optimization (see [[User:Barre/TODO|TODO]])<br />
* Steve Aylward: SlicerIGT funding?<br />
* Tuesday<br />
** Ipek Oguz: Help with Offscreen Rendering and making sure it can behave as a command-line program (without a KWW GUI)<br />
** Ragani: Try to convert legacy code, vtkImageResliceST.cxx, based on old vtkImageReslice<br />
** Craig Sharp: Help with Plastimatch; including the CMake code for a CLP was conflicting with his own CMake code. At the end of the day, his library needed to be linked against ITK, as opposed to just his executables; why the CLP CMake code revealed that "problem" is not clear, but in any case that's the way to go in general...<br />
** Cleanup some installation/configuration rules in QdecModule and TumorGrowth</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/TODO&diff=5244User:Barre/TODO2008-06-24T22:01:59Z<p>Barre: /* Training Event in Germany */</p>
<hr />
<div>==[[2008 June Workshop Germany |Training Event in Germany]]==<br />
<br />
Notes from a session with Ron, important items to address to improve Slicer3 usability.<br />
<br />
* Save Data: how can one save a data file as a specific/different ITK file format. ITK uses a IO plugin framework to support new file formats: is there a way to find the list of file formats supported by ITK at run-time.<br />
** <small>I (Seb) to check with Luis; DONE, see ImageFileReader<...>::GenerateOutputInformation, BUT every IO file/reader need to expose the list of file extensions it can read and write. Luis is on it, to be added 3.8 end of July.</small> <br />
<br />
* Save Data: the "Save" dialog in general is very confusing and buggy. The "Save All" and "Save None" button are mislabelled since they don't perform any save. Saving data to a new file format requires the user to double-click in the file name and manually change the file extension (provided that this extension is known to the user). Changing the data directory does not update the data locations in the multicolumn list (it does if you change the data directory twice). Changing the scene directory has no impact on the data directory.<br />
**<small> I (Seb) suggest that the "Save All/None" should be something like "Mark all for save", "Mark none for save". A button should be placed next to each data filename/location to quickly switch to a new file type (depending on what ITK can save to at run-time). The dialog is large, we have room to put a help string/label that explains a little more how the whole dialog works. Changing the data directory should update the location of each data entry in the multicolumn list correctly. A button should be added to quickly set the data directory to match the scene directory (it should not be automatic though).</small><br />
<br />
* Font Size: the font is definitely too small for the "Modules" menubutton or the filename label in any of the Red/Yellow/Green slice viewports. The "View -> Font Size" menu does not report the current font size. <br />
** <small>My (Seb) opinion is to avoid hard-coding font size as much as possible, and not let the user override either font size or font family: we can not support all the possible layout combinations, or guarantee it will all fit; let's focus instead on making sure it looks nice and fit decently with the default system font size. The label in the RYG slice viewports is cropped automatically to something likely too small, and not updated later on when the slice viewport is resized/maximized: to fix.</small><br />
<br />
* Progress Bar: the progress bar used while loading data has been removed because it was triggering too many "update idletasks". We still need one though.<br />
** <small>Steve suggests creating an OpenGL progress bar directly inside a small renderwindow. I (Seb) checked VTK's scale/slider interaction widget to see if that would do the trick. To be investigated further with the VTK's widget guru, Will.</small><br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" may be too small for some users, as it gets more and more crowded.<br />
** <small>My (Seb) opinion is that we can't have it resize automatically because who knows how tall it could be, and it would push everything down. Ron is OK to have an option to do it manually, so I plan to add two icon/buttons to increase/decrease the height (numbe of lines) of the tree, say add 15 more lines, and double the size, etc. I wish we could just "drag" the whole tree frame to a new size, like expanding a window, but that's just too hard (or impossible) to implement with this Tk widget.</small><br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" is not as intuitive as the previous UI found in Slicer2; for each model, one could check/uncheck the visibility and change the opacity using controls placed directly next to the model's name (i.e. on the same row). The model name/label itself would use a background color matching the color used to display the model in the 3D view, a nice hint. The tree used in Slicer3 does not do nearly as much, i.e. the user has to select a node then change its visibily using a checkbutton placed in a different frame below the tree (note that the visibility and color can be changed quickly though, by using a popup menu by right-clicking on the tree leaf).<br />
** <small>I (Seb) had several discussion about this item with Alex, and I'm still not sure why this can't be done technically by adding custom widgets next to the label name for each leaf in the tree, but I will have a look at it again.</small><br />
<br />
* Tree: seen while Daniele was doing her tutorial: drag and dropping a leaf to a new parent will trigger an event that would repopulate the whole tree, hence losing the focus of the selection; she had to go down the list, etc etc. Let's make sure the focus is not lost...</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/TODO&diff=5243User:Barre/TODO2008-06-24T22:01:17Z<p>Barre: /* Training Event in Germany */</p>
<hr />
<div>==[[2008 June Workshop Germany |Training Event in Germany]]==<br />
<br />
Notes from a session with Ron, important items to address to improve Slicer3 usability.<br />
<br />
* Save Data: how can one save a data file as a specific/different ITK file format. ITK uses a IO plugin framework to support new file formats: is there a way to find the list of file formats supported by ITK at run-time.<br />
** <small>I (Seb) to check with Luis; DONE, see ImageFileReader<...>::GenerateOutputInformation, BUT every IO file/reader need to expose the list of file extensions it can read and write. Luis is on it.</small> <br />
<br />
* Save Data: the "Save" dialog in general is very confusing and buggy. The "Save All" and "Save None" button are mislabelled since they don't perform any save. Saving data to a new file format requires the user to double-click in the file name and manually change the file extension (provided that this extension is known to the user). Changing the data directory does not update the data locations in the multicolumn list (it does if you change the data directory twice). Changing the scene directory has no impact on the data directory.<br />
**<small> I (Seb) suggest that the "Save All/None" should be something like "Mark all for save", "Mark none for save". A button should be placed next to each data filename/location to quickly switch to a new file type (depending on what ITK can save to at run-time). The dialog is large, we have room to put a help string/label that explains a little more how the whole dialog works. Changing the data directory should update the location of each data entry in the multicolumn list correctly. A button should be added to quickly set the data directory to match the scene directory (it should not be automatic though).</small><br />
<br />
* Font Size: the font is definitely too small for the "Modules" menubutton or the filename label in any of the Red/Yellow/Green slice viewports. The "View -> Font Size" menu does not report the current font size. <br />
** <small>My (Seb) opinion is to avoid hard-coding font size as much as possible, and not let the user override either font size or font family: we can not support all the possible layout combinations, or guarantee it will all fit; let's focus instead on making sure it looks nice and fit decently with the default system font size. The label in the RYG slice viewports is cropped automatically to something likely too small, and not updated later on when the slice viewport is resized/maximized: to fix.</small><br />
<br />
* Progress Bar: the progress bar used while loading data has been removed because it was triggering too many "update idletasks". We still need one though.<br />
** <small>Steve suggests creating an OpenGL progress bar directly inside a small renderwindow. I (Seb) checked VTK's scale/slider interaction widget to see if that would do the trick. To be investigated further with the VTK's widget guru, Will.</small><br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" may be too small for some users, as it gets more and more crowded.<br />
** <small>My (Seb) opinion is that we can't have it resize automatically because who knows how tall it could be, and it would push everything down. Ron is OK to have an option to do it manually, so I plan to add two icon/buttons to increase/decrease the height (numbe of lines) of the tree, say add 15 more lines, and double the size, etc. I wish we could just "drag" the whole tree frame to a new size, like expanding a window, but that's just too hard (or impossible) to implement with this Tk widget.</small><br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" is not as intuitive as the previous UI found in Slicer2; for each model, one could check/uncheck the visibility and change the opacity using controls placed directly next to the model's name (i.e. on the same row). The model name/label itself would use a background color matching the color used to display the model in the 3D view, a nice hint. The tree used in Slicer3 does not do nearly as much, i.e. the user has to select a node then change its visibily using a checkbutton placed in a different frame below the tree (note that the visibility and color can be changed quickly though, by using a popup menu by right-clicking on the tree leaf).<br />
** <small>I (Seb) had several discussion about this item with Alex, and I'm still not sure why this can't be done technically by adding custom widgets next to the label name for each leaf in the tree, but I will have a look at it again.</small><br />
<br />
* Tree: seen while Daniele was doing her tutorial: drag and dropping a leaf to a new parent will trigger an event that would repopulate the whole tree, hence losing the focus of the selection; she had to go down the list, etc etc. Let's make sure the focus is not lost...</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/2008_Summer_Project_Week&diff=5242User:Barre/2008 Summer Project Week2008-06-24T21:42:17Z<p>Barre: </p>
<hr />
<div>* Various user-friendly optimization [[User:Barre/TODO|TODO]]<br />
* Steve Aylward: SlicerIGT funding?<br />
* Tuesday<br />
** Ipek Oguz: Help with Offscreen Rendering and making sure it can behave as a command-line program (without a KWW GUI)<br />
** Ragani: Try to convert legacy code, vtkImageResliceST.cxx, based on old vtkImageReslice<br />
** Craig Sharp: Help with Plastimatch; including the CMake code for a CLP was conflicting with his own CMake code. At the end of the day, his library needed to be linked against ITK, as opposed to just his executables; why the CLP CMake code revealed that "problem" is not clear, but in any case that's the way to go in general...</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/2008_Summer_Project_Week&diff=5241User:Barre/2008 Summer Project Week2008-06-24T20:27:31Z<p>Barre: </p>
<hr />
<div>* Various user-friendly optimization [[User:Barre/TODO|TODO]]<br />
* Steve Aylward: SlicerIGT funding?<br />
* Tuesday<br />
** Ipek Oguz: Help with Offscreen Rendering and making sure it can behave as a command-line program (without a KWW GUI)<br />
** Craig Sharp: Help with Plastimatch; including the CMake code for a CLP was conflicting with his own CMake code. At the end of the day, his library needed to be linked against ITK, as opposed to just his executables; why the CLP CMake code revealed that "problem" is not clear, but in any case that's the way to go in general...</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/TODO&diff=5240User:Barre/TODO2008-06-24T18:36:13Z<p>Barre: /* Training Event in Germany */</p>
<hr />
<div>==[[2008 June Workshop Germany |Training Event in Germany]]==<br />
<br />
Notes from a session with Ron, important items to address to improve Slicer3 usability.<br />
<br />
* Save Data: how can one save a data file as a specific/different ITK file format. ITK uses a IO plugin framework to support new file formats: is there a way to find the list of file formats supported by ITK at run-time.<br />
** <small>I (Seb) to check with Luis</small><br />
<br />
* Save Data: the "Save" dialog in general is very confusing and buggy. The "Save All" and "Save None" button are mislabelled since they don't perform any save. Saving data to a new file format requires the user to double-click in the file name and manually change the file extension (provided that this extension is known to the user). Changing the data directory does not update the data locations in the multicolumn list (it does if you change the data directory twice). Changing the scene directory has no impact on the data directory.<br />
**<small> I (Seb) suggest that the "Save All/None" should be something like "Mark all for save", "Mark none for save". A button should be placed next to each data filename/location to quickly switch to a new file type (depending on what ITK can save to at run-time). The dialog is large, we have room to put a help string/label that explains a little more how the whole dialog works. Changing the data directory should update the location of each data entry in the multicolumn list correctly. A button should be added to quickly set the data directory to match the scene directory (it should not be automatic though).</small><br />
<br />
* Font Size: the font is definitely too small for the "Modules" menubutton or the filename label in any of the Red/Yellow/Green slice viewports. The "View -> Font Size" menu does not report the current font size. <br />
** <small>My (Seb) opinion is to avoid hard-coding font size as much as possible, and not let the user override either font size or font family: we can not support all the possible layout combinations, or guarantee it will all fit; let's focus instead on making sure it looks nice and fit decently with the default system font size. The label in the RYG slice viewports is cropped automatically to something likely too small, and not updated later on when the slice viewport is resized/maximized: to fix.</small><br />
<br />
* Progress Bar: the progress bar used while loading data has been removed because it was triggering too many "update idletasks". We still need one though.<br />
** <small>Steve suggests creating an OpenGL progress bar directly inside a small renderwindow. I (Seb) checked VTK's scale/slider interaction widget to see if that would do the trick. To be investigated further with the VTK's widget guru, Will.</small><br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" may be too small for some users, as it gets more and more crowded.<br />
** <small>My (Seb) opinion is that we can't have it resize automatically because who knows how tall it could be, and it would push everything down. Ron is OK to have an option to do it manually, so I plan to add two icon/buttons to increase/decrease the height (numbe of lines) of the tree, say add 15 more lines, and double the size, etc. I wish we could just "drag" the whole tree frame to a new size, like expanding a window, but that's just too hard (or impossible) to implement with this Tk widget.</small><br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" is not as intuitive as the previous UI found in Slicer2; for each model, one could check/uncheck the visibility and change the opacity using controls placed directly next to the model's name (i.e. on the same row). The model name/label itself would use a background color matching the color used to display the model in the 3D view, a nice hint. The tree used in Slicer3 does not do nearly as much, i.e. the user has to select a node then change its visibily using a checkbutton placed in a different frame below the tree (note that the visibility and color can be changed quickly though, by using a popup menu by right-clicking on the tree leaf).<br />
** <small>I (Seb) had several discussion about this item with Alex, and I'm still not sure why this can't be done technically by adding custom widgets next to the label name for each leaf in the tree, but I will have a look at it again.</small><br />
<br />
* Tree: seen while Daniele was doing her tutorial: drag and dropping a leaf to a new parent will trigger an event that would repopulate the whole tree, hence losing the focus of the selection; she had to go down the list, etc etc. Let's make sure the focus is not lost...</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/2008_Summer_Project_Week&diff=5239User:Barre/2008 Summer Project Week2008-06-24T18:20:15Z<p>Barre: </p>
<hr />
<div>* Various user-friendly optimization [[User:Barre/TODO|TODO]]<br />
* Steve Aylward: SlicerIGT funding?<br />
* Tuesday<br />
** Ipek Oguz: ?<br />
** Craig Sharp: Helped with Plastimatch; including the CMake code for a CLP was conflicting with his own CMake code. At the end of the day, his library needed to be linked against ITK, as opposed to just his executables; why the CLP CMake code revealed that "problem" is not clear, but in any case that's the way to go in general...</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/2008_Summer_Project_Week&diff=5238User:Barre/2008 Summer Project Week2008-06-24T18:17:25Z<p>Barre: </p>
<hr />
<div>* Various user-friendly optimization [[User:Barre/TODO|TODO]]<br />
* Tuesday<br />
** Craig Sharp: Helped with Plastimatch; including the CMake code for a CLP was conflicting with his own CMake code. At the end of the day, his library needed to be linked against ITK, as opposed to just his executables; why the CLP CMake code revealed that "problem" is not clear, but in any case that's the way to go in general...</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/2008_Summer_Project_Week&diff=5237User:Barre/2008 Summer Project Week2008-06-24T17:51:37Z<p>Barre: New page: * Various user-friendly optimization TODO * Tuesday ** Helped Craig Sharp with Plastimatch; including the CMakeLists.txt code for a CLP was conflicting with his own C...</p>
<hr />
<div>* Various user-friendly optimization [[User:Barre/TODO|TODO]]<br />
* Tuesday <br />
** Helped Craig Sharp with Plastimatch; including the CMakeLists.txt code for a CLP was conflicting with his own CMake code. At the end of the day, it was just his library that needed to be linked against ITK, as opposed to just his executables...</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre&diff=5236User:Barre2008-06-24T17:47:39Z<p>Barre: </p>
<hr />
<div>* [mailto:sebastien.barre@kitware.com Sebastien Barre]<br />
* Research Engineer<br />
* [http://www.kitware.com Kitware, Inc.]<br />
* [http://www.kitware.com/profile/team/barre.html Profile]<br />
* [[User:Barre/TODO|TODO]]<br />
* [[User:Barre/2008 Summer Project Week|2008 Summer Project Week]]</div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre/TODO&diff=5235User:Barre/TODO2008-06-24T17:46:02Z<p>Barre: New page: ==Training Event in Germany== Notes from a session with Ron, important items to address to improve Slicer3 usability. * Save Data: how can one save a data...</p>
<hr />
<div>==[[2008 June Workshop Germany |Training Event in Germany]]==<br />
<br />
Notes from a session with Ron, important items to address to improve Slicer3 usability.<br />
<br />
* Save Data: how can one save a data file as a specific/different ITK file format. ITK uses a IO plugin framework to support new file formats: is there a way to find the list of file formats supported by ITK at run-time.<br />
** <small>I (Seb) to check with Luis</small><br />
<br />
* Save Data: the "Save" dialog in general is very confusing and buggy. The "Save All" and "Save None" button are mislabelled since they don't perform any save. Saving data to a new file format requires the user to double-click in the file name and manually change the file extension (provided that this extension is known to the user). Changing the data directory does not update the data locations in the multicolumn list (it does if you change the data directory twice). Changing the scene directory has no impact on the data directory.<br />
**<small> I (Seb) suggest that the "Save All/None" should be something like "Mark all for save", "Mark none for save". A button should be placed next to each data filename/location to quickly switch to a new file type (depending on what ITK can save to at run-time). The dialog is large, we have room to put a help string/label that explains a little more how the whole dialog works. Changing the data directory should update the location of each data entry in the multicolumn list correctly. A button should be added to quickly set the data directory to match the scene directory (it should not be automatic though).</small><br />
<br />
* Font Size: the font is definitely too small for the "Modules" menubutton or the filename label in any of the Red/Yellow/Green slice viewports. The "View -> Font Size" menu does not report the current font size. <br />
** <small>My (Seb) opinion is to avoid hard-coding font size as much as possible, and not let the user override either font size or font family: we can not support all the possible layout combinations, or guarantee it will all fit; let's focus instead on making sure it looks nice and fit decently with the default system font size. The label in the RYG slice viewports is cropped automatically to something likely too small, and not updated later on when the slice viewport is resized/maximized: to fix.</small><br />
<br />
* Progress Bar: the progress bar used while loading data has been removed because it was triggering too many "update idletasks". We still need one though.<br />
** <small>Steve suggests creating an OpenGL progress bar directly inside a small renderwindow. I (Seb) checked VTK's scale/slider interaction widget to see if that would do the trick. To be investigated further with the VTK's widget guru, Will.</small><br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" may be too small for some users, as it gets more and more crowded.<br />
** <small>My (Seb) opinion is that we can't have it resize automatically because who knows how tall it could be, and it would push everything down. Ron is OK to have an option to do it manually, so I plan to add two icon/buttons to increase/decrease the height (numbe of lines) of the tree, say add 15 more lines, and double the size, etc. I wish we could just "drag" the whole tree frame to a new size, like expanding a window, but that's just too hard (or impossible) to implement with this Tk widget.</small><br />
<br />
* Models, tree: the tree in "Models -> Hierarchy -> Model Hierarchy" is not as intuitive as the previous UI found in Slicer2; for each model, one could check/uncheck the visibility and change the opacity using controls placed directly next to the model's name (i.e. on the same row). The model name/label itself would use a background color matching the color used to display the model in the 3D view, a nice hint. The tree used in Slicer3 does not do nearly as much, i.e. the user has to select a node then change its visibily using a checkbutton placed in a different frame below the tree (note that the visibility and color can be changed quickly though, by using a popup menu by right-clicking on the tree leaf).<br />
** <small>I (Seb) had several discussion about this item with Alex, and I'm still not sure why this can't be done technically by adding custom widgets next to the label name for each leaf in the tree, but I will have a look at it again.</small></div>Barrehttps://www.slicer.org/w/index.php?title=User:Barre&diff=5234User:Barre2008-06-24T17:45:35Z<p>Barre: New page: * [mailto:sebastien.barre@kitware.com Sebastien Barre] * Research Engineer * [http://www.kitware.com Kitware, Inc.] * [http://www.kitware.com/profile/team/barre.html Profile] * [[User:Barr...</p>
<hr />
<div>* [mailto:sebastien.barre@kitware.com Sebastien Barre]<br />
* Research Engineer<br />
* [http://www.kitware.com Kitware, Inc.]<br />
* [http://www.kitware.com/profile/team/barre.html Profile]<br />
* [[User:Barre/TODO|TODO]]</div>Barre