FileChooser improvements

[kotcrab]

• Make 'unsafe' classes optional and extract them to vis-ui-contrib
  • FileChooserWinService not worth it
  • JNAFileDeleter
• Add Refresh in popup menu
• Different view modes
• Display suggestions when typing file name
• FileTypeFilter
  • Automatically append extension
• Update wiki (FileChooser.setDefaultPrefsName())
• File list sorting options
• Show file modified date when using details view
• When using DIRECTORIES selection mode, filter out files from list (don't forget setSelectionMode must rebuild file list)
• Drag and drop (maybe post 1.1.0 though)
• Allow to use FileWatcher from NIO instead of pooling
• File detail / preview view mode (see comments below)
• Automatic scroll focus shift (see FileChooser improvements #176 (comment))
• List directory contents on separate thread (see FileChooser improvements #176 (comment))

[raeleus]

May I suggest that when a user types a name with no extension (or the wrong extension) into a FileChooser using Mode.SAVE and using a type filter, that the type filter's extension would be appended to the selected file path? This is typical behavior of all save dialogs that I have used. Sure this can be implemented manually in the FileChooserListener.selected(), but this will still trip the "Overwrite File?" dialog if you happen to have a file that matches the incorrect file extension in the directory.

For example, if I have a type filter for "png" and I have the following file in my directory "atlas" with no extension. If the user types "atlas" as the file name, it will prompt the user to overwrite this file and save the image as "atlas" with no extension. Instead, the file should have been automatically been named "atlas.png".

[kotcrab]

Good idea, I have one concern though. What if they are multiple file extensions added to single rule? I think in that case chooser should display suggestion popup with possible list of extensions.

[raeleus]

A curious predicament indeed! Most software avoid this situation in save dialogs by only allowing one extension per rule so it won't be ambiguous. Supposing a programmer still wants to implement multiple extensions in one rule this way, the suggestions would be great but should fall back to the first added extension if the user just clicks through.

[kotcrab]

@raeleus I've added this feature. When wrong extensions is typed or there is no extensions then first extension from type filter rule will be used. If that file already exist choser shows overwrite dialog. Additionally if user types something like filename. chooser will show suggestions with possible file extensions using rule extension list.

[raeleus]

That's perfect! Thanks for being so responsive.

[mbrlabs]

Something that would drastically improve the UX would be image previews.
I don't mean little thumbnails, but rather a dedicated area, which displays the image once you have selected one. Firefox has this feature, when you select an image for upload.

I might try this out it over the weekend, so you can have a look.

[kotcrab]

Standard thumbnails are already supported, see https://github.com/kotcrab/vis-ui-contrib/wiki/Adding-thumbnails-to-VisUI-FileChooser.

This isn't Firefox feature. Firefox is using native OS file chooser. In case of Windows 7, chooser doesn't have this feature enabled by default. GIMP would be better example here, it uses GTK file chooser which has it but on the other hand it doesn't have standard thumbnails.

I don't see many benefits of doing this to be honest, to me thumbnails seems like a much better solution. Even in terms of UX, you don't have to click file to see its preview - you see all of them at once.

This is how standard thumbnails look:

[mbrlabs]

Yeah, firefox was probably a bad example. Thanks for the hint, i am going to check that out. Well, an advantage of the dedicated area is, that the file list remains compact, while you can still see a preview of the image before you finally select it.
Anyway, thats just a nice-to-have, the thumbnails will do just fine.

[czyzby]

Live preview seems like a good candidate for another view type. I think it might be even more useful than thumbnails in case of folders with multiple images, especially if they are similar. Mixing list view with a dedicated spot for an enlarged icon (or image preview) of the file with some additional data (size, modification time and so on) seems like a great idea.

[kotcrab]

Showing additional file details is actually pretty good benefit since current view modes doesn't support it. Also since it only requires to load 1 image, it should work without need to scale image and without including any other library. I added this feature to the list.

I don't agree however that new view mode should be added. Something like button on the top bar that opens preview panel would be better in my opinion. New view mode would be limited to single file arrangement (either list or detail). With separate panel you can use any view mode and still be able to see detailed preview.

[mbrlabs]

Nice. I also think it's better to have a toggle button instead of a separate view type.