gitea-mirror commented

Owner

Originally created by @armand1m on GitHub (Mar 5, 2018).
Original GitHub issue: https://github.com/kusti8/proton-native/issues/47

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)

Originally created by @armand1m on GitHub (Mar 5, 2018). Original GitHub issue: https://github.com/kusti8/proton-native/issues/47 # 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)_

gitea-mirror

2026-05-05 11:28:34 -06:00

closed this issue
added the
wait for libui implementation
label

gitea-mirror commented

2026-05-05 11:28:44 -06:00

Author

Owner

@armand1m commented on GitHub (Mar 5, 2018):

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: 86c4485578/darwin/stddialogs.m

windows: 86c4485578/windows/stddialogs.cpp

unix: 86c4485578/unix/stddialogs.c

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

@armand1m commented on GitHub (Mar 5, 2018): 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.

gitea-mirror commented

2026-05-05 11:28:48 -06:00

Author

Owner

@mischnic commented on GitHub (Mar 6, 2018):

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 commented on GitHub (Mar 6, 2018): 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`).

gitea-mirror commented

2026-05-05 11:28:52 -06:00

Author

Owner

@mischnic commented on GitHub (Mar 11, 2018):

There was already a pull request for openFolder (closed): https://github.com/andlabs/libui/pull/190

@mischnic commented on GitHub (Mar 11, 2018): There was already a pull request for openFolder (closed): https://github.com/andlabs/libui/pull/190

gitea-mirror commented

2026-05-05 11:28:55 -06:00

Author

Owner

@armand1m commented on GitHub (Mar 12, 2018):

@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.

@armand1m commented on GitHub (Mar 12, 2018): @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.

gitea-mirror commented

2026-05-05 11:28:58 -06:00

Author

Owner

@andlabs commented on GitHub (Mar 14, 2018):

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.

@andlabs commented on GitHub (Mar 14, 2018): 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: ```js 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: ```js 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: ```js 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.

gitea-mirror commented

2026-05-05 11:29:00 -06:00

Author

Owner

@mischnic commented on GitHub (Apr 3, 2018):

New issue tracking progress: https://github.com/andlabs/libui/issues/314

@mischnic commented on GitHub (Apr 3, 2018): New issue tracking progress: https://github.com/andlabs/libui/issues/314

gitea-mirror commented

2026-05-05 11:29:02 -06:00

Author

Owner

@kusti8 commented on GitHub (Jan 19, 2020):

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

@kusti8 commented on GitHub (Jan 19, 2020): Proton Native V2 is now released! If the issue still occurs in the new update, please open a new issue.

gitea-mirror referenced this issue

2026-05-05 11:56:11 -06:00

[PR #27] [MERGED] Consistency in features list #229

Rows
Columns

[GH-ISSUE #47] Feature: Select Folder type of Dialog #27

Feature Request

User Story

EDIT