Hi,
when having adding some of the diffusion-related extension to the favorites toolbar I see that all have the same default icon used for extensions, which makes it difficult to recognize them.
What is the appropriate way to add an icon to each in the corresponding repository (SlicerDMRI I assume in this case)?
Thanks.
They may be CLI modules. A CLI module is a simple executable that does not provide an icon, therefore only a generic icon is used. Since these modules are usually low-level data processing modules, lack of a recognizable icon is generally not a problem.
What are those diffusion-related modules that you are adding to the toolbar?
What are those diffusion-related modules that you are adding to the toolbar?
DiffusionTensorScalarMaps, TractographyDisplay, which both have a user interface, to name two of them.
These are the CLI modules (which right now cannot provide their module icon): https://github.com/SlicerDMRI/SlicerDMRI/tree/master/Modules/CLI
It would be very easy to add an icon for any other modules, someone would just need to design those icons.
I am interested in these CLI modules; designing or adding a self-created image would not be a problem, but if they cannot provide their own module icon, then there is nothing I can do.
@jcfr @pieper what do you think about adding a new field to the CLI module description that would specify relative path of an extension icon in he (such as <icon>ACPCTransform.png</icon>) in the executable element?
For example:
<?xml version="1.0" encoding="UTF-8"?>
<executable>
<category>Registration.Specialized</category>
<title>ACPC Transform</title>
<icon>ACPCTransform.png</icon>
<index>1</index>
<description><![CDATA[<p>Calculate a transformation that aligns brain images to <a href="https://en.wikipedia.org/wiki/Talairach_coordinates">Talairach coordinate system</a> (also known as stereotaxic or ACPC coordinate system) based on anatomical landmarks.</p><p>The ACPC line extends between two points, one at the anterior commissure and one at the posterior commissure. The resulting transform will bring the line connecting the two points horizontal to the AP axis.</p><p>The midline is a series of points (at least 3) defining the division between the hemispheres of the brain (the mid sagittal plane). The resulting transform will result in the output volume having the mid sagittal plane lined up with the AS plane.</p><p>Use <b>Resample Scalar/Vector/DWI Volume</b> to apply the transformation to a volume.</p>]]></description>
<version>1.0</version>
<documentation-url>https://slicer.readthedocs.io/en/latest/user_guide/modules/acpctransform.html</documentation-url>
<license>slicer3</license>
<contributor>Nicole Aucoin (SPL, BWH), Ron Kikinis (SPL, BWH)</contributor>
<acknowledgements><![CDATA[This work is part of the National Alliance for Medical Image Computing (NAMIC), funded by the National Institutes of Health through the NIH Roadmap for Medical Research, Grant U54 EB005149.]]></acknowledgements>
<parameters>
...
</parameters>
</executable>
I think that’s a great idea, no reason not to that I can see.
Thanks Andras. Let me know when things are ready to support this, and I will add an icon for the diffusion/tractography CLIs that are of interest to me.
I had a closer look and CLI modules actually can already store icons, but they provide it on their standard output when the CLI module is launched with the --logo argument. It would be very inefficient to simply start using this feature, as it would mean running 50 executables at each Slicer startup to just get the CLI module icons. We would need to do something like that is done for the module description .xml files cache the icon files in the module folder so that the application can load them directly. Even then, loading 50 icon files may have add some perceivable delay at application startup. Maybe adding the icon to the .xml file would be faster (as we already load the .xml files at startup)? Another complication is that it is not trivial to bundle the icon file into the executable file (embedding binary resources into an executable is different on each compiler).
Exploring all the options and implement something that does not slow down application startup and remains compatible with the existing CLI module infrastructure would be quite significant work. Since the benefits are quite small, I don’t think this will be worked on soon. Anyway, this issue tracks this task:
As you outlined, we already have a mechanism to associate icons with CLIs.
To move forward, we could expand the XML description file with the <logo> element[1].
It could accept the following:
data:image/png;base64,iVBORw0KG....
qrc:///path/to/image.png
file://relative/path/to/image.png
where:
data URI scheme may be used to specify a base64 encoded image. See hereqrc URI scheme may be used to specify an icon expected to be provided through the Qt resource systemfile URI scheme allows to specify a (relative) path for looking up the icon. To support the build and installed case, the path should be relative and the same in both cases.Using logo would be consistent with the current CLI parameter --logo and associated CMake macro argument LOGO_HEADER. ↩︎
Not sure if I follow the rationale of the icon resources needing to be loaded being prohibitive in terms of time; there are other modules (CLIs or not; I am still not that familiar with these in the context of Slicer) that have a non-negligible number of icons in their panels. But my knowledge about the underlying mechanisms is very limited, so my reasoning may not be accurate enough.
To me, being able to identify a tool is essential in an application, and as a user, I expect any application to offer this capability for the sake of usability.
I grant that if an application is too slow to start, this can bother some users in some contexts or deter them from using an application; but being slow at start is a one-time event, whereas being unable to identify an icon or needing to constantly navigate through a hierarchy of menus is a recurrent event within one session.
Maybe the feature is not straightforward to implement given the current constraints, but I do believe that it can make a difference in usability.
Thanks for your work Andras, JC.
Loadable modules use the Qt resource system to efficiently load icons. It is a very much optimized system for both minimizing storage requirements and loading time. Since CLI modules are just standalone console applications that don’t depend on Qt, they cannot use the Qt resource system.
The cross-platform resource embedding mechanism that is currently implemented for CLI modules is quite slow and complicated to use, so we would need to revamp that before we can use it to load all CLI module icons at each startup.
Lack of icons for CLI modules is usually not a problem because CLI modules implement computational algorithms that users typically do not interact with directly, but via more convenient higher-level interactive “loadable” modules (which all have icons and nicer GUI).