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.

[WickedShell]

Scrollable focus should swap between the favorites section and the current folder depending on which the mouse is over (focus listeners are a pretty straightforward way to do this).

[WickedShell]

Fetching the list of available files in a folder should be done off the GL thread as when referencing filesystems that are over the network or are on removable media the time can be extremely slow to build the list causing a significant and noticeable hitch in the UI (2-15 seconds depending on what I'm accessing of non responsiveness)

[kotcrab]

@WickedShell added async file listing, I'd be grateful if you could test it and tell me how it works

[WickedShell]

Works appropriately, the animation isn't fluid for me, but I suspect that is because I don't have continuous rendering so something has to prompt the system to be repainting while the bar is there. Still has a noticable hitch when loading the final elements for rendering, but I suspect that is just the performance cost of having 5000 items in a folder and that the only way around it would be to reduce the number of elements that are needed for each row, or split the creation over multiple frames and have a timer that limits each round of creation to say 10ms so that it doesn't take so long before showing results.

[kotcrab]

@WickedShell I pushed more IO work to the background thread so the hitch should be less noticeable now. Time spent on UI is nothing compared to time spent on IO operations. Doing UI creation over multiple frames really creates more problem than it solves.

Animation now request rendering so it should be smooth in non-continous mode.

[WickedShell]

@kotcrab been busy traveling this week but got to test that the continuous requests work quite well. I will retest on the slower devices when I get a chance to see if the continuous rendering seems to fix the lag a lot (I suspect it does).

I agree that the overhead of splitting it over multiple frames is almost 100% not worth it, as its non trivial to do and has a lot of corner cases to consider.

[WickedShell]

When the filechooser is finding all the files in a directory and then types in a name (such as a save dialog option) when the files become available (from the background thread) the users input for name is reset which is extremely surprising as they had the opportunity to type/possibly name it entirely while waiting on the background thread)

[WickedShell]

When the user is typing a filename the textfield should accept the enter key as being open/save file and close the bialog and return the name

[WickedShell]

When reusing a dialog box if it had selected files with a nonstandard filter switching back and selecting directories will still show the file name filter selectbox even though we are in file mode (where it clearly doesn't make sense)

[WickedShell]

When the path is longer then fits in the text box at the top, rather then left aligning the path (IE so you can see the "C:" for example, it should be right aligned, as the most interesting part is almost always the last folder or two the user selected.

[WickedShell]

On initial load of the filechooser the scroll focus isn't forced into the scrollpane (even if the mouse was already in the correct position). This means that all scroll events will go to the map rather then the UI. I suspect this is more a fundamental problem with the way scroll focus is assigned in libgdx, but it is a problem :/

[kotcrab]

The whole scroll focus management of scene2d is done in Windows-like way where you have to click to something to move focus to it and to be honest I don't see a way how this can be changed. You could use scroll listener added to stage capturing events and use hit(...) to deliver them to proper actor but hit implementation doesn't guarantee that it will return actor on top so that could cause problem when there are multiple windows on top of each other.

This is a simple cause though, it makes most sense to focus scroll pane automatically when file chooser is shown, I added setting for it and made it default.

[raeleus]

Could you make FileChooserStyle extend WindowStyle and use that in the call to FileChooser.super()? Currently FileChooser uses the "default" or "noborder" styles. This is pretty restrictive to those that want to make their own skins.

[payne911]

Could you allow the client to decide if the hiddenFolders should be displayed or not?

https://github.com/kotcrab/vis-ui/blob/master/ui/src/main/java/com/kotcrab/vis/ui/widget/file/FileChooser.java#L1754

I come from there: libgdx/gdx-liftoff#31

[czyzby]

@payne911 Since you can pass a custom FileFilter to the FileChooser with setFileFilter, I don't think it's a major issue. You can extend the DefaultFileFilter or just add your custom FileFilter implementation tailored to your own needs.

Otherwise you might want to open a PR yourself, as VisUI is in maintenance mode. (Correct me if I'm wrong.)

[kotcrab]

I responded in the linked issue to avoid notifying again all those people back from 2016. I guess it's too late now :)

If you want you can make a PR that will add allow hidden option for DefaultFileFilter.