Difference between revisions of "Developer Meetings/20130730"
From Slicer Wiki
m (Created page with '__TOC__ == To discuss ==') |
m |
||
Line 2: | Line 2: | ||
== To discuss == | == To discuss == | ||
+ | |||
+ | * dimensionality | ||
+ | <pre> | ||
+ | Julien: | ||
+ | |||
+ | The first part of the "dimensionality" problem (#1694, #2973, #2480...) is already part of Slicer 4.3: | ||
+ | As of now possible to control (via settings) the default number of decimals for "length" aware widgets. Moreover | ||
+ | the number of decimals is dynamic in a sense that it adapts to best fit the input value. The user is also able to | ||
+ | edit that precision on each widget individually. | ||
+ | |||
+ | The second part is to be able to change the order of magnitude of the values displayed to the user. This second part | ||
+ | is soon to be ready to be merged into Slicer. It is however still a bit experimental. | ||
+ | |||
+ | According to the release schedule (see [1]) , to the value of the feature and to the potential impact on the code | ||
+ | base, is it something that can still go in the release. Or should we wait the next release ? | ||
+ | |||
+ | Note that if the user does not play with the units, it should not bring too much regression (part #2 comes primarily | ||
+ | from CTK and is not really MRML related). | ||
+ | </pre> | ||
+ | |||
+ | <pre> | ||
+ | Jc: | ||
+ | |||
+ | I think we should remain conservative and focus on the issue currently targeted for 4.3. | ||
+ | |||
+ | To help us take a final decision, few questions / remarks: | ||
+ | |||
+ | - Better management of units and dimensionality for 4.3 would be great | ||
+ | |||
+ | - Could you share topic(s) illustrating the extent of the changes ? | ||
+ | |||
+ | CTK: https://github.com/finetjul/CTK/commits/ctkvalueproxy | ||
+ | Slicer: https://github.com/finetjul/Slicer/commits/ProxyValueForUnits | ||
+ | |||
+ | - Can you confirm that this new set of commit will behave as expected after the work of Nicole related | ||
+ | to "Markups" module will be integrated ? | ||
+ | It will still works fine with the Annotations, however, it might require some minor work to work with | ||
+ | the markups module | ||
+ | |||
+ | - Can you confirm that it build on MacOSX/ Linux / Windows ... doing Experimental builds on the factory | ||
+ | could be used to confirm this. | ||
+ | Have tried Linux and Windows, not macosx yet | ||
+ | |||
+ | - Any impact on existing extensions ? | ||
+ | It should not impact extensions. | ||
+ | </pre> | ||
+ | |||
+ | [1] http://massmail.spl.harvard.edu/public-archives/slicer-devel/2013/013114.html |
Revision as of 16:03, 30 July 2013
Home < Developer Meetings < 20130730Contents
To discuss
- dimensionality
Julien: The first part of the "dimensionality" problem (#1694, #2973, #2480...) is already part of Slicer 4.3: As of now possible to control (via settings) the default number of decimals for "length" aware widgets. Moreover the number of decimals is dynamic in a sense that it adapts to best fit the input value. The user is also able to edit that precision on each widget individually. The second part is to be able to change the order of magnitude of the values displayed to the user. This second part is soon to be ready to be merged into Slicer. It is however still a bit experimental. According to the release schedule (see [1]) , to the value of the feature and to the potential impact on the code base, is it something that can still go in the release. Or should we wait the next release ? Note that if the user does not play with the units, it should not bring too much regression (part #2 comes primarily from CTK and is not really MRML related).
Jc: I think we should remain conservative and focus on the issue currently targeted for 4.3. To help us take a final decision, few questions / remarks: - Better management of units and dimensionality for 4.3 would be great - Could you share topic(s) illustrating the extent of the changes ? CTK: https://github.com/finetjul/CTK/commits/ctkvalueproxy Slicer: https://github.com/finetjul/Slicer/commits/ProxyValueForUnits - Can you confirm that this new set of commit will behave as expected after the work of Nicole related to "Markups" module will be integrated ? It will still works fine with the Annotations, however, it might require some minor work to work with the markups module - Can you confirm that it build on MacOSX/ Linux / Windows ... doing Experimental builds on the factory could be used to confirm this. Have tried Linux and Windows, not macosx yet - Any impact on existing extensions ? It should not impact extensions.
[1] http://massmail.spl.harvard.edu/public-archives/slicer-devel/2013/013114.html