Usability: qtFileItem and multi-selection

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

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.

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.

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.

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