Use native file dialogs everywhere

[Sawuare]

Mainly for consistency with the rest of the interface, we currently use themed file dialogs everywhere, instead of native, but unlike native, they

• are slower
• aren't familiar to users,
• don't have bookmarks and quick access,
• don't have thumbnails,
• require more code (4 files & 413 SLOC).

@Wallacoloo once wrote:

we should use OS-native dialogs instead of custom-themed ones (because, say, the gtk file chooser includes previews for image types whereas custom dialogs don't, or because OS-native file choosers include user-bookmarked locations, whereas custom dialogs don't, ...).

That being said, switching to native file dialogs everywhere has some implications.
Class VersionedSaveDialog has some added features that can't be implemented in native file dialogs:

1. Increment/Decrement version number
2. Save options

No. 1 is useless, as users just manually change the filename, so it should be removed.
I don't know what to do about No. 2, though. 💭

---

Related: #3792, specifically: #3792 (comment).

[Spekular]

I disagree w/ this issue. Will post a proper explanation when I have time to type it out.

[Spekular]

• Some native file dialogues are awful. Every time I have to use this browser I die a little inside.
• I don't know if it's possible for us to list our LMMS specific default locations in a native dialogue. If we can't list the working dir and stuff like that, the native dialogue is a downgrade.
• I wouldn't consider increment/decrement "useless" at all, it certainly seems more convenient than manually changing the number.
• A native dialogue reduces consistency between OSes. This fragments the userbase's experience, for example it makes tutorials/guides look different for different OSes.

The save dialogue's looks match the rest of LMMS, which I quite like. Blender does themed load/save as well to great effect, with custom functionality (like super easy custom format filtering, import options, etc.). Not to mention, it lists system bookmarks (which, as far as i can remember, LMMS already does for me too?)

[DomClark]

Some arguments in favour of this issue:

• Qt's non-native file dialogs are really slow. This is difficult to measure precisely, but the native Windows file dialog can be many times faster for folders not currently in the disk cache. I've had LMMS hang for nearly 30 seconds navigating to my downloads folder, which is not an issue I've run into with any other application.

• Some native file dialogues are awful. Every time I have to use this browser I die a little inside.

  Perhaps so, but I don't think it's our responsibility as the application to work around perceived bad UI/UX of the operating system.

• I wouldn't consider increment/decrement "useless" at all, it certainly seems more convenient than manually changing the number.

  It would certainly seem so, but I recall discussion on Discord that suggested that a lot of people either don't use these or haven't even noticed them.

• A native dialogue reduces consistency between OSes. This fragments the userbase's experience, for example it makes tutorials/guides look different for different OSes.

  It increases consistency within each OS though. I think it's more likely that users are using LMMS along with other programs on a single OS, rather than using LMMS on multiple OSes. Regarding tutorials/guides, can't we assume some basic computer literacy, that users can navigate their own OS's file browser?

[superpaik]

I've been thinking about this for a while (before reading this PR).
To me the OS file dialogs are more functional (speeder -yes, open the downloads folder is like forever-, the ability to change directory by cut-and-paste, the recent folders in the drop-down directory list, etc.) but certainly the themed file dialogs can have some positive features, keep consistency between OSes, look-and-feel following LMMS theme, etc.
How about a configuration setting in which the user can decide between OS or themed file dialog? In the same way that we have one with "Plugin Embeding"? So, let the user decide which one is best for her/him. And for the "added features" it can be explained in the manual that those can be lost if changed to the OS file dialog (I've never noticed the + - buttons -I've been using LMMS for two years now- and, in windows at least, the "save option" is not visible)

[enp2s0]

I strongly disagree with having both, it's just pointless complexity having to maintain two effectively identical systems.

[ifndefJOSH]

I know this issue may be "stale" at this point, but I hope I can put my two-cents in. I disagree with having native dialogs but I do think that the VersionedSaveDialog is problematic for a couple of reasons:

• It's based on FileDialog, which is based on QFileDialog, and the basic version of QFileDialog that ships with most versions of Qt (and therefore LMMS) is fairly limiting based on the issues that @Sawuare mentioned. No copy/pasting of a filepath, no breadcrumb menu, etc.
• Unfamiliar to users, and no icons.
• Extra code
  However, native dialogs have their own problems:
• Cannot add elements to them without preprocessor and #ifndef/#include hell.
• Harder to make consistent cross platform
• No custom theming
• As @Spekular mentioned, the GTK+ file dialog (native in Gnome, XFCE, etc.) is hideous. I also die inside whenever I have to use it (off topic, but I figured out how to disable it in firefox, but that's neither here nor there)

However, I think there may be a happy medium: there is a far better file dialog the FileDialog class can inherit from in KF5 (kf5::kio). I feel the code changes would be minimal as I'm pretty sure it also inherits from QFileDialog and I know for a fact it inherits from QWidget (KF5 is built on top of Qt). It is not without its cons tho.

I'll list the cons first:

1. Additional dependency: kf5::kio--although it should be a fairly small dependency, it is still a dependency. This is the biggest argument against this in my opinion.
   • It is a dependency that is built on top of a library LMMS already depends on (Qt).
2. May need to change the existing LMMS code to fit it rather than the more generic QFileDialog.
3. KDE isn't known for writing minimalist code.

Now the pros:

1. Because it's built in Qt and inherits from a lot of the existing Qt infrastructure, the code change on the part of LMMS would be fairly minimal
2. Respects the LMMS theming quite easily
3. Copy/pasting paths
4. Easier navigation and (in my opinion) more user friendly than the existing dialog
5. Dependency is already installed on KDE systems, as well as any system that uses any KF5 software (Krita, KDEnlive, Kate Editor etc.)
   • Note that AppImages are self-contained though, so for Linux users it would be advantageous to get LMMS from their package manager to prevent duplicate dependencies

I think it comes down to a balancing act: how much work do we want to do for something that users may find insignificant overall?

EDIT: KF5's file dialog does not have a breadcrumb menu from what I can see...it's just a textbox/combobox where you can paste paths or select from recent/suggested file paths.

[ifndefJOSH]

For reference, this is what the dialog could look like (this screenshot is from KDEnlive, which uses KF5 and therefore the KF5 file dialog)

[JohannesLorenz]

I think the additional dependency is not a problem if we can set it as optional in CMake and then use #ifdefs to use or not use it?

[ifndefJOSH]

Update: this is the class I think we want it to inherit from:

https://api.kde.org/frameworks/kio/html/classKFileCustomDialog.html

[jmfergeau]

Please do it. I can't properly use LMMS because any access to the file dialog takes ages to react. Just single-clicking a file takes around 40-50 seconds to react!!

[michaelgregorius]

I agree with @superpaik that the simplest option for now would be to let the users choose via the preference. It could be a simple checkbox with the text "Use native file dialogs".

The implementation would likely be something like an interface for all the file operations with the following implementations:

• LMMS dialogs via the FileDialog class.
• Native dialogs via QFileDialog (see here). With regards to the additional options the native dialog would just have to use sane defaults, e.g. to not discard MIDI connections. This should be sane because as much information as possible is kept and LMMS must be able to deal with MIDI connections that cannot be reinstated anyway.

Using QFileDialog has several advantages. It does not introduce any new dependencies. People can use the file dialogs that they are used to. For example I am using KDE and on my system it therefore opens a dialog that looks quite KDE-ish:

If somebody wants to experiment with this, e.g. on Windows, here's how to adjust the open file code:

void MainWindow::openProject()
{
	if( mayChangeProject(false) )
	{
		auto fileName = QFileDialog::getOpenFileName(this, tr("Open Project"),
    			ConfigManager::inst()->userProjectsDir(), tr("LMMS (*.mmp *.mmpz)"));
		
		if (!fileName.isNull())
		{
			Song *song = Engine::getSong();

			song->stop();
			setCursor( Qt::WaitCursor );
			song->loadProject(fileName);
			setCursor( Qt::ArrowCursor );
		}
	}
}