# Usability: qtFileItem and multi-selection
**URL:** https://discourse.kitware.com/t/usability-qtfileitem-and-multi-selection/404
**Category:** Design
**Created:** [January 31, 2020, 10:17pm UTC](https://discourse.kitware.com/t/usability-qtfileitem-and-multi-selection/404 "2020-01-31T22:17:02Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [January 31, 2020, 10:17pm UTC](https://discourse.kitware.com/t/usability-qtfileitem-and-multi-selection/404/1 "2020-01-31T22:17:02Z")
We have run into some usability issues with qtFileItem. We have an import operation that should allow multiple files to be imported into the same (new) resource.
Without multi-selection in the browser dialog, it is very awkward to resize the attribute::FileItem with the qtFileItem’s “+” button and then browse to each file individually (i.e., bring up the browser N times and select a single file instead of using the browser once to select N files).
We can enable multi-selection in the file browser dialog, by changing `qtFileItem::onLaunchFileBrowser` (in `smtk/extension/qt/qtFileItem.cxx`) so that Qt’s FileMode and AcceptMode match the item’s definition (Extensible and ShouldExist, respectively). However, what is unclear is how the GUI should respond in a few cases:
- The user selects N files in the browser and clicks OK. Should the qtFileItem expand to show 5 values?
- What if M items were shown before and the user had clicked the “Browse” button next to one of them – would the result be M + N - 1 values, or should we replace the contents of the entire FileItem each time the user browses?
- Should there be a single “Browse” button for the item or one per value?
- If we switch to a single “Browse” button for the item and replace the item’s existing values with the selection, how can users select multiple files in different directories? Is that a use case we want to support?
@Bob_Obara @johnt
---
### Author:  [@Bob\_Obara](https://discourse.kitware.com/u/Bob_Obara)
#### Post date: [February 1, 2020, 10:05pm UTC](https://discourse.kitware.com/t/usability-qtfileitem-and-multi-selection/404/2 "2020-02-01T22:05:07Z")
So I assume that the FileItem in question is extensible correct?
If that is the case how does this interaction model sound for extensible FileSystemItems?
- There is a single Browse button for the entire Item not one for each file.
- The browser is put in multi-selection mode for the sole purpose of selecting additional files/directories
- The selection is then added to the Item (values that already exist in the Item are ignored)
- The values are presented as a list to the user where unwanted values are removed by selecting them and pressing delete.
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [February 1, 2020, 10:12pm UTC](https://discourse.kitware.com/t/usability-qtfileitem-and-multi-selection/404/3 "2020-02-01T22:12:50Z")
I think the “browsing always adds” model sounds good. We’ll have to figure out how to behave when the user selects too many entries in the file browser.
---
### Author:  [@Bob\_Obara](https://discourse.kitware.com/u/Bob_Obara)
#### Post date: [February 1, 2020, 10:21pm UTC](https://discourse.kitware.com/t/usability-qtfileitem-and-multi-selection/404/4 "2020-02-01T22:21:00Z")
We could in this case follow your model - mark the item as invalid but have the widget hold all the values but not set the item until a valid number is reached. Unfortunately if the user switches tabs or forces the GUI to redraw the widget would revert back to the original values of the item.
---
### Author:  [@johnt](https://discourse.kitware.com/u/johnt)
#### Post date: [February 2, 2020, 3:51pm UTC](https://discourse.kitware.com/t/usability-qtfileitem-and-multi-selection/404/5 "2020-02-02T15:51:36Z")
Same as Bob, I would advocate for a separate widget/ItemView with a list view.