<div dir="ltr">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.<div><br></div><div>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. </div>
<div><br></div><div>-Steve</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Nov 9, 2013 at 1:08 PM, Andriy Fedorov <span dir="ltr"><<a href="mailto:fedorov@bwh.harvard.edu" target="_blank">fedorov@bwh.harvard.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree configuration is complex and should be in advanced. I was<br>
thinking about list of sources. See attached the way it's done in<br>
syngo.via, would be great to have a similar concept in Slicer, as a<br>
replacement of the directory button.<br>
<br>
I also agree with you completely that the way DICOM database button<br>
functions right now (file dialog popup) is very confusing.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Sat, Nov 9, 2013 at 12:55 PM, Andras Lasso <<a href="mailto:lasso@queensu.ca">lasso@queensu.ca</a>> wrote:<br>
> 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.<br>
><br>
> 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.<br>
><br>
> Andras<br>
><br>
> -----Original Message-----<br>
> From: Andriy Fedorov [mailto:<a href="mailto:fedorov@bwh.harvard.edu">fedorov@bwh.harvard.edu</a>]<br>
> Sent: November 9, 2013 12:23 PM<br>
> To: Andras Lasso<br>
> Cc: <a href="mailto:pieper@bwh.harvard.edu">pieper@bwh.harvard.edu</a>; <a href="mailto:slicer-devel@bwh.harvard.edu">slicer-devel@bwh.harvard.edu</a><br>
> Subject: Re: [slicer-devel] [Ctk-developers] new dicom interface<br>
><br>
> On Sat, Nov 9, 2013 at 10:06 AM, Andras Lasso <<a href="mailto:lasso@queensu.ca">lasso@queensu.ca</a>> wrote:<br>
>> · On a laptop screen only 3-4 patients, studies, and series are<br>
>> visible – we should see at least about 10 of each. Change the layout<br>
>> (e.g., move the loadables list into a second column; hide the plugin<br>
>> list by default and use a >> button – similar to the one in the<br>
>> Application settings/Modules – to show it), decrease the row height of<br>
>> the patients/studies/series tables (it looks to have about 1.5-2x line<br>
>> spacing and/or larger font)<br>
>><br>
><br>
> 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.<br>
><br>
> I like the idea of ">>" for plugins list.<br>
><br>
>> · Move “Local database” selector and Make DICOM browser persistent<br>
>> to an advanced options section (in a popup window or hidden by<br>
>> default) to save space and reduce clutter<br>
>><br>
><br>
> Here I would suggest not to hide it, but have a drop-down (ideally --<br>
> 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.<br>
><br>
><br>
><br>
>><br>
>><br>
>> Other changes to consider:<br>
>><br>
>> · We could remove the “Close” button (having the “X” in the window<br>
>> corner and adding an “Esc” button shortcut should be enough)<br>
>><br>
>> · View header: make it a right-click accessible option on the<br>
>> loadables list (note that currently if no loadable is selected it’s<br>
>> still enabled and shows the latest selected loadable’s info) or a<br>
>> small icon next to the series search bar<br>
>><br>
>> · Remove: make it a right-click accessible option (now it’s so far<br>
>> from all the patient/study/series selector that it’s not very<br>
>> intuitive that it refers to them) or a small trashcan icon next to<br>
>> each search bar<br>
>><br>
>><br>
>><br>
>> Andras<br>
>><br>
>><br>
>><br>
>> From: <a href="mailto:ctk-developers-bounces@commontk.org">ctk-developers-bounces@commontk.org</a><br>
>> [mailto:<a href="mailto:ctk-developers-bounces@commontk.org">ctk-developers-bounces@commontk.org</a>] On Behalf Of Steve Pieper<br>
>> Sent: November 7, 2013 2:49 PM<br>
>> To: <a href="mailto:slicer-devel@bwh.harvard.edu">slicer-devel@bwh.harvard.edu</a>; <a href="mailto:ctk-developers@commontk.org">ctk-developers@commontk.org</a><br>
>> Subject: [Ctk-developers] new dicom interface<br>
>><br>
>><br>
>><br>
>> Hello from the CTK hackfest in London! [1]<br>
>><br>
>><br>
>><br>
>> For a while now several of groups have been working on improving the<br>
>> dicom browser in CTK (the one used in the Slicer DICOM module) to make<br>
>> it more consistent with clinical systems and to make it easier to<br>
>> customize. Work really got going at the last hackfest at Queens in<br>
>> Kingston [2] where a design was worked out that would help with a<br>
>> number of longstanding issues faced in SlicerRT [for example, 3] and<br>
>> some issues intrinsic to the way the old DICOM tree view was implemented [4].<br>
>><br>
>><br>
>><br>
>> After a lot of work at the CTK level by Adreas Fetzer and Marco Nolden<br>
>> of DKFZ and Csaba Pinter and Andras Lasso of Queens we now have a new<br>
>> interface to address these issues. Plus Alireza Mehrtash of BWH has<br>
>> added a DICOM header browser option to address a longstanding missing<br>
>> feature of slicer4 [5]. These have now been integrated into the<br>
>> slicer trunk [6] and the new interface is documented on the nightly section of the wiki [7].<br>
>><br>
>><br>
>><br>
>> Of course this big of a change may take a little time to settle out,<br>
>> so please let us know if you see build or run time issues.<br>
>> Suggestions are welcome too.<br>
>><br>
>><br>
>><br>
>> Cheers from jolly old England,<br>
>><br>
>> Steve<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> [1] <a href="http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013" target="_blank">http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013</a><br>
>><br>
>><br>
>><br>
>> [2]<br>
>> <a href="http://www.commontk.org/index.php/CTK-Hackfest-May-2013#DICOM_Database" target="_blank">http://www.commontk.org/index.php/CTK-Hackfest-May-2013#DICOM_Database</a><br>
>> _and_Networking<br>
>><br>
>><br>
>><br>
>> [3] <a href="http://na-mic.org/Bug/view.php?id=2828" target="_blank">http://na-mic.org/Bug/view.php?id=2828</a><br>
>><br>
>><br>
>><br>
>> [4] <a href="http://na-mic.org/Bug/view.php?id=3106" target="_blank">http://na-mic.org/Bug/view.php?id=3106</a><br>
>><br>
>><br>
>><br>
>> [5] <a href="http://na-mic.org/Bug/view.php?id=1838" target="_blank">http://na-mic.org/Bug/view.php?id=1838</a><br>
>><br>
>><br>
>><br>
>> [6]<br>
>> <a href="http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=226" target="_blank">http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=226</a><br>
>> 89<br>
>><br>
>> [7]<br>
>> <a href="http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/Modules/D" target="_blank">http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/Modules/D</a><br>
>> ICOM<br>
>><br>
>><br>
>> _______________________________________________<br>
>> slicer-devel mailing list<br>
>> <a href="mailto:slicer-devel@bwh.harvard.edu">slicer-devel@bwh.harvard.edu</a><br>
>> <a href="http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel" target="_blank">http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel</a><br>
>> To unsubscribe: send email to<br>
>> <a href="mailto:slicer-devel-request@massmail.spl.harvard.edu">slicer-devel-request@massmail.spl.harvard.edu</a><br>
>> with unsubscribe as the subject<br>
>> <a href="http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Devel" target="_blank">http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Devel</a><br>
>> opers/FAQ<br>
>><br>
>><br>
>> The information in this e-mail is intended only for the person to whom<br>
>> it is addressed. If you believe this e-mail was sent to you in error<br>
>> and the e-mail contains patient information, please contact the<br>
>> Partners Compliance HelpLine at <a href="http://www.partners.org/complianceline" target="_blank">http://www.partners.org/complianceline</a><br>
>> . If the e-mail was sent to you in error but does not contain patient<br>
>> information, please contact the sender and properly dispose of the<br>
>> e-mail.<br>
>><br>
</div></div></blockquote></div><br></div>