Open Sawuare opened 4 years ago
I disagree w/ this issue. Will post a proper explanation when I have time to type it out.
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?)
Some arguments in favour of this issue:
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?
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)
I strongly disagree with having both, it's just pointless complexity having to maintain two effectively identical systems.
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:
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.#ifndef
/#include
hell.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:
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.
QFileDialog
.Now the pros:
AppImage
s are self-contained though, so for Linux users it would be advantageous to get LMMS from their package manager to prevent duplicate dependenciesI 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.
For reference, this is what the dialog could look like (this screenshot is from KDEnlive, which uses KF5 and therefore the KF5 file dialog)
I think the additional dependency is not a problem if we can set it as optional in CMake and then use #ifdef
s to use or not use it?
Update: this is the class I think we want it to inherit from:
https://api.kde.org/frameworks/kio/html/classKFileCustomDialog.html
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!!
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:
FileDialog
class.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 );
}
}
}
Mainly for consistency with the rest of the interface, we currently use themed file dialogs everywhere, instead of native, but unlike native, they
@Wallacoloo once wrote:
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: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. :thought_balloon:
Related: #3792, specifically: https://github.com/LMMS/lmms/issues/3792#issuecomment-439078098.