[Ctk-developers] [slicer-devel] new dicom interface

Mon Nov 11 16:11:14 UTC 2013

The vertical layout is good, because we need some width to show all the columns. The problems are that rows very high, thre are unnecessary buttons above/below the widget, and the loadable widget is also below the patient/study/series widget (the loadable widget could be on the right side of the patient/study/series widget instead).

Andras

From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Steve Pieper
Sent: November 11, 2013 11:09 AM
To: Csaba Pinter
Cc: slicer-devel at bwh.harvard.edu; Andriy Fedorov; ctk-developers at commontk.org
Subject: Re: [Ctk-developers] [slicer-devel] new dicom interface

Yes, the feature is still there under the hood but Andreas removed the button to make the interface cleaner.  We can add back a preference if we want to allow configuration of this.  For now you can experiment on the fly with the line below.  I preferred the horizontal layout since it shows more of the columns.  But now that we have the building blocks I think we can make whatever interface we want.

-Steve

>>> slicer.modules.DICOMWidget.detailsPopup.tables.tableOrientation = 1

On Mon, Nov 11, 2013 at 10:55 AM, Csaba Pinter <csaba.pinter at queensu.ca<mailto:csaba.pinter at queensu.ca>> wrote:
Thank you very much for all the work of developing and integrating the new browser!

I remember Andreas showing me a layout switcher feature in the new browser in the spring, which allowed the user to switch from horizontal to vertical view, in which the patient/study/series level are not underneath each other but organized side-by-side. Maybe using the vertical layout would solve the small screen problem. Or at least showing the control if it's still available.

csaba

From: ctk-developers-bounces at commontk.org<mailto:ctk-developers-bounces at commontk.org> [mailto:ctk-developers-bounces at commontk.org<mailto:ctk-developers-bounces at commontk.org>] On Behalf Of Steve Pieper
Sent: November 10, 2013 09:59
To: Andriy Fedorov; ctk-developers at commontk.org<mailto:ctk-developers at commontk.org>
Cc: slicer-devel at bwh.harvard.edu<mailto:slicer-devel at bwh.harvard.edu>
Subject: Re: [Ctk-developers] [slicer-devel] new dicom interface

Thanks for the feedback!  I'm forwarding the thread to the ctk developer list since some ideas relate to the ctk components and some to the slicer integration.

I agree with most of the suggestions and I think they will be pretty straightforward to implement (pull requests welcome!). This is sort of a first-pass with the new layout so we can iterate on some of these issues.  I didn't want to delay implementing the new table display since it was identified as a critical issue for SlicerRT.

-Steve

On Sat, Nov 9, 2013 at 1:08 PM, Andriy Fedorov <fedorov at bwh.harvard.edu<mailto:fedorov at bwh.harvard.edu>> wrote:
I agree configuration is complex and should be in advanced. I was
thinking about list of sources. See attached the way it's done in
syngo.via, would be great to have a similar concept in Slicer, as a
replacement of the directory button.

I also agree with you completely that the way DICOM database button
functions right now (file dialog popup) is very confusing.

On Sat, Nov 9, 2013 at 12:55 PM, Andras Lasso <lasso at queensu.ca<mailto:lasso at queensu.ca>> wrote:
> The main problem with the directory selector is that the users think that it is for importing. I've helped several users with this problem, they all thought that the DICOM import was broken because they used this database directory selector instead of the Import button. Even after finding the Import directory they are still confused what this database directory selection is for and they are not sure if they have to set it to the directory where they store their DICOM files. We just should not show this database directory selector on the main GUI. Showing just a listbox (or checkboxes) with a list of database names (either local filesystem or remote systems) would be also fine.
>
> In general, _setup_ of DICOM hosts/connections, databases are too complex operations for most users (IP addresses, port numbers, AE titles, database directories, ...). However, once they are set up, the query/retrieve, push, etc. operations are easy to use. So, to reduce frustration of users and administrators, the GUI for setup should be clearly separated. GUI for users should be simplified and the GUI for all DICOM configuration settings should be editable in the Slicer Application settings. This applies to the Query/Retrieve GUI. The user should only see a list of data sources and search options; and editing server name, aeitle, address, port, cget flag, add/remove server, etc. should be only displayed in the Application settings.
>
> Andras
>
> -----Original Message-----
> From: Andriy Fedorov [mailto:fedorov at bwh.harvard.edu<mailto:fedorov at bwh.harvard.edu>]
> Sent: November 9, 2013 12:23 PM
> To: Andras Lasso
> Cc: pieper at bwh.harvard.edu<mailto:pieper at bwh.harvard.edu>; slicer-devel at bwh.harvard.edu<mailto:slicer-devel at bwh.harvard.edu>
> Subject: Re: [slicer-devel] [Ctk-developers] new dicom interface
>
> On Sat, Nov 9, 2013 at 10:06 AM, Andras Lasso <lasso at queensu.ca<mailto:lasso at queensu.ca>> wrote:
>> *         On a laptop screen only 3-4 patients, studies, and series are
>> visible - we should see at least about 10 of each. Change the layout
>> (e.g., move the loadables list into a second column; hide the plugin
>> list by default and use a >> button - similar to the one in the
>> Application settings/Modules - to show it), decrease the row height of
>> the patients/studies/series tables (it looks to have about 1.5-2x line
>> spacing and/or larger font)
>>
>
> I had a similar concern. Does it make sense to have Patient/Study/Series panels collapslible? It is currently possible to move the separator all the way down to use all space for one panel, but it requires a lot of mouse interaction.
>
> I like the idea of ">>" for plugins list.
>
>> *         Move "Local database" selector and Make DICOM browser persistent
>> to an advanced options section (in a popup window or hidden by
>> default) to save space and reduce clutter
>>
>
> Here I would suggest not to hide it, but have a drop-down (ideally --
> checkable) list of databases. In the future, it would be great to integrate the remote sources that can be queried into this single drop-down list to provide a unified experience (this is how syngo.via does it). But even without remote sources, the use case is often there may be different databases for different projects, and right now Slicer is not very friendly in supporting more than one database.
>
>
>
>>
>>
>> Other changes to consider:
>>
>> *         We could remove the "Close" button (having the "X" in the window
>> corner and adding an "Esc" button shortcut should be enough)
>>
>> *         View header: make it a right-click accessible option on the
>> loadables list (note that currently if no loadable is selected it's
>> still enabled and shows the latest selected loadable's info) or a
>> small icon next to the series search bar
>>
>> *         Remove: make it a right-click accessible option (now it's so far
>> from all the patient/study/series selector that it's not very
>> intuitive that it refers to them) or a small trashcan icon next to
>> each search bar
>>
>>
>>
>> Andras
>>
>>
>>
>> From: ctk-developers-bounces at commontk.org<mailto:ctk-developers-bounces at commontk.org>
>> [mailto:ctk-developers-bounces at commontk.org<mailto:ctk-developers-bounces at commontk.org>] On Behalf Of Steve Pieper
>> Sent: November 7, 2013 2:49 PM
>> To: slicer-devel at bwh.harvard.edu<mailto:slicer-devel at bwh.harvard.edu>; ctk-developers at commontk.org<mailto:ctk-developers at commontk.org>
>> Subject: [Ctk-developers] new dicom interface
>>
>>
>>
>> Hello from the CTK hackfest in London! [1]
>>
>>
>>
>> For a while now several of groups have been working on improving the
>> dicom browser in CTK (the one used in the Slicer DICOM module) to make
>> it more consistent with clinical systems and to make it easier to
>> customize.  Work really got going at the last hackfest at Queens in
>> Kingston [2] where a design was worked out that would help with a
>> number of longstanding issues faced in SlicerRT [for example, 3] and
>> some issues intrinsic to the way the old DICOM tree view was implemented [4].
>>
>>
>>
>> After a lot of work at the CTK level by Adreas Fetzer and Marco Nolden
>> of DKFZ and Csaba Pinter and Andras Lasso of Queens we now have a new
>> interface to address these issues.  Plus Alireza Mehrtash of BWH has
>> added a DICOM header browser option to address a longstanding missing
>> feature of slicer4 [5].  These have now been integrated into the
>> slicer trunk [6] and the new interface is documented on the nightly section of the wiki [7].
>>
>>
>>
>> Of course this big of a change may take a little time to settle out,
>> so please let us know if you see build or run time issues.
>> Suggestions are welcome too.
>>
>>
>>
>> Cheers from jolly old England,
>>
>> Steve
>>
>>
>>
>>
>>
>> [1] http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013
>>
>>
>>
>> [2]
>> http://www.commontk.org/index.php/CTK-Hackfest-May-2013#DICOM_Database
>> _and_Networking
>>
>>
>>
>> [3] http://na-mic.org/Bug/view.php?id=2828
>>
>>
>>
>> [4] http://na-mic.org/Bug/view.php?id=3106
>>
>>
>>
>> [5] http://na-mic.org/Bug/view.php?id=1838
>>
>>
>>
>> [6]
>> http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=226
>> 89
>>
>> [7]
>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/Modules/D
>> ICOM
>>
>>
>> _______________________________________________
>> slicer-devel mailing list
>> slicer-devel at bwh.harvard.edu<mailto:slicer-devel at bwh.harvard.edu>
>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>> To unsubscribe: send email to
>> slicer-devel-request at massmail.spl.harvard.edu<mailto:slicer-devel-request at massmail.spl.harvard.edu>
>> with unsubscribe as the subject
>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Devel
>> opers/FAQ
>>
>>
>> The information in this e-mail is intended only for the person to whom
>> it is addressed. If you believe this e-mail was sent to you in error
>> and the e-mail contains patient information, please contact the
>> Partners Compliance HelpLine at http://www.partners.org/complianceline
>> . If the e-mail was sent to you in error but does not contain patient
>> information, please contact the sender and properly dispose of the
>> e-mail.
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20131111/15ca18ad/attachment.htm>