Feature: Select Folder type of Dialog

[armand1m]

Feature Request

Currently, when using the Dialog method, we can use the DialogTypeEnum to determine if we want a dialog for:

• Message - a simple message
• Error - an error message
• Open - open a file
• Save - save a file

Well, it turns out that sometimes we want the user to also select a folder instead of a file. So I would like to propose a new DialogType:

• Folder - select a folder

User Story

As a user,
I want to be able to select a folder,
In order to select the destiny of a generated file, for example.

As a developer,
I want to be able to popup a Dialog to request a folder destiny to the user,
In order to get the path I should use as destiny of a generated file, for example.

(I'm no good at writing user stories, but well, I tried)

[armand1m]

Well, it seems to be necessary a pull request for this in https://github.com/parro-it/libui-node and https://github.com/andlabs/libui :/

I've already take a look at the files needed to implement a new method for this in libui, it would be necessary to modify these files:

darwin: https://github.com/andlabs/libui/blob/86c4485578d6d58aff6528b27558bc1ccc6aadbe/darwin/stddialogs.m

windows: https://github.com/andlabs/libui/blob/86c4485578d6d58aff6528b27558bc1ccc6aadbe/windows/stddialogs.cpp

unix: https://github.com/andlabs/libui/blob/86c4485578d6d58aff6528b27558bc1ccc6aadbe/unix/stddialogs.c

Don't know if there is any other needed, probably I may need to expose this somewhere.

[mischnic]

Probably two new types are needed:

• OpenFolder and
• SaveFolder (this would also make it clearer that there are related to their Open/Save counterparts)

because on all platforms, you have to select one type (i.e. NSSavePanel or NSOpenPanel).

[mischnic]

There was already a pull request for openFolder (closed): andlabs/libui#190

[armand1m]

@mischnic nice to know this, maybe I can build a PR up on this, but I didn't found it in the master branch if I can recall (I need to take a look again..). Maybe it was removed later?

EDIT

Sorry, now I see that the PR was rejected. I'll start the discussion again on why this was made.

[andlabs]

I didn't reject the PR. I decided to hold off on merging it, because the current APIs for dialogs isn't ideal. It all has to do with event handling and synchronicity. I'll use pseudocode in JavaScript to explain what I mean (this will probably be easier than explaining it in C in the main repo, to be honest...).

On Windows, the system dialog API only gives me one option:

var selectedItem = runDialog(parentWindow);

You'll notice this function does not return until the dialog is dismissed. You'll notice that a parent window must be specified. Clicking on that window while the dialog is open will cause that window to flash.

Other windows can still be interacted with, but they will NOT respond to things like tab navigation. This is because tab navigation on Windows is intrinsically tied to dialog boxes! Specifically, the IsDialogMessage() function requires you to pass a handle to the top-level window (I'm not sure if it's the dialog box or the parent window), and only handles tab navigation for the window you passed in. libui works around this for the outermost main loop by passing the currently active window into this function, but in the runDialog() function above I have no such control. Likewise, I have no such control over what happens inside the main loop body, so no custom main loops (uiMainSteps()/uiMainStep()).

I could also disable all the windows during the dialog's lifetime, but then clicking on those other windows won't flash the dialog window (and I don't think I have a way to do this myself at all...).

Now I could theoretically use a dialog message hook to try to work around this, but I'm not sure if this solution might be flaky (I would have to write it). I have tried to deduce what the correct programming model on Windows is based on all this information, even going so far as to ask outright, but I can't get an answer out.

Failure to provide a parent window will cause Windows to not flash the dialog window when clicking other windows.

GTK+ is the nicest of the bunch, as I have two options:

var selectedItem = runDialog(parentWindow);

openDialog(parentWindow).then((selectedItem) => {
    // ...
});

The former will prevent interaction with any window during the dialog's lifetime, but in a weird some-of-the-events-still-go-through way. I also can't do any custom main loops with this option.

The latter will let you interact with everything else in the program while the dialog is running. I don't remember if there were caveats, but notice you still need to provide a window to disable while the dialog is running.

In both cases, failure to provide a parent window will do nothing but cause GTK+ to spit the dreaded GtkDialog mapped without a transient parent on stderr.

macOS is only slightly less nice:

var selectedItem = runDialog();

openDialog(parentWindow).then((selectedItem) => {
    // ...
});

In the former case, the dialog is global to the application, and all window interaction is blocked until the dialog is dismissed. I also can't do any custom main loop stuff.

In the latter case, the dialog is modal to to a specific window, and appears as a "sheet" that pulls down from the titlebar. You can still interact just fine with other windows, under certain circumstances. While custom main loops are still possible, this approach probably tells NSApplication to run in a different main loop run mode which might affect things. I need to read more on how NSApplication and sheets work together before I can make a verdict here. Also, you must provide a parent window in this case.

So hopefully that explains the dilemma.

[mischnic]

New issue tracking progress: andlabs/libui#314

[kusti8]

Proton Native V2 is now released! If the issue still occurs in the new update, please open a new issue.