Usability: qtFileItem and multi-selection

Simulation Modeling Toolkit (SMTK) Design
1

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

2

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.
3

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.

4

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.

5

Same as Bob, I would advocate for a separate widget/ItemView with a list view.