Gui.cs: UX: Does it make sense to always close Open/Save Dialog when clicking the action button?

[Mgamerz]

Been working a lot with OpenDialog, and noticed that when clicking the 'Open' button, the dialog always closes, regardless of the state of the selector window. Looking at the source for the button, it is hardwired to just say it's not canceled and immediately close the dialog when this button is clicked. As someone who works with users and UX a lot, does this make sense? On these dialogs (open/save) there is two options: Cancel and (Open/Save (I'll call it the action button from here on out). Clicking cancel will immediately close the dialog and say it was canceled. But clicking the action button at any time also will close the dialog, regardless of whether the select item(s) are actually valid.

Does this make sense, from an end user perspective? I get that the developer can check the result of the dialog, to see if it matches what they expect. But from an end user perspective, does this dialog behave like one would expect? In my testing and use of the library, it doesn't seem to feel like it - if I have a file selector for example, I can still click open on a folder that is highlighted. On other platforms (such as Windows) clicking 'Open' when in file chooser mode, when a folder is selected, makes it open the folder (navigate into it). In folder chooser mode on windows, clicking 'Open' on a folder opens that folder, and having none selected opens the current folder (which if I recall is how this library currently behaves in folder mode now).

I know having a button dedicated to closing dialog is good, but that is already handled by the cancel button. I feel like if the user selects the action button, there should be a valid result set on the dialog's variables (FilePath/FilePaths), as part of the API agreement: Open a dialog and get me a valid (filepath/folderpath)(s), OR get me nothing if the user cancels. Right now it is Open a dialog and maybe get me a valid file/folderpaths, OR get me nothing if the user cancels. Maybe this is by design, but it seems weird having a dialog that opens file browser but can return invalid results. I get it is still up to the dev to check the results, because users be users.

I wrote some code to test if the selection was valid, but I did not commit or make a PR for it as I was not sure if this was intended behavior. As I am somewhat of an 'end user' of this library, I think the file selection behavior seems a bit... off, maybe not totally incorrect. In my local code I had, I made a new method that checked if the selection was valid in FileDialog, based on if it was a OpenDialog or a SaveDialog (as it seems the base dialog has no way of knowing what kind it is, I just used a if (this is OpenDialog). I got it to work for single file selection, but I wasn't sure how to handle multi file selection (I don't use this feature so I haven't looked at the code).

Just wondering what thoughts on this behavior are. Sorry for making so many issues, I know you're trying to lock down API changes soon so I'm getting all of them in ;)

[tig]

Hmmm...

First, I'll note that I don't have a ton of confidence in the OpenDialog implementation based on my experience fixing a few bugs in there. I too noted some behavior that didn't seem right, but at the time I didn't choose to dive into it deeply. Frankly, I suspect it has not been used "in anger" very much.

For the behavior of the standard buttons, I think it should work this way:

• If nothing is selected, "Open/Save" should be disabled
• If something is selected, "Open/Save" should be enabled
• There should be a mode where the dialog is in "file mode" (default)
  
  
  
  • If a directory/folder is selected "Open/Save" should navigate to that folder.
  
  
  • If a file is selected, the dialog should close and whatever was selected should be available via the API
  
  
• If in the other mode ("directory mode")
  
  
  
  • Only directories should be displayed
  
  
  • If a directory is selected and "Open/Save" is pressed the dialog should close and whatever was selected should be available via the API
  
  

We'd totally appreciate you taking a swing at fixing this. Please read the contribution guide.

Cheers!

[Mgamerz]

I'll take a look into it. I'm still learning how the library works so I
assume there will be a few revisions needed on my work. I'll let you know
what I come up with.

On Sat, Aug 15, 2020, 11:22 AM Charlie Kindel [e-mail]
wrote:

Hmmm...

First, I'll note that I don't have a ton of confidence in the OpenDialog
implementation based on my experience fixing a few bugs in there. I too
noted some behavior that didn't seem right, but at the time I didn't choose
to dive into it deeply. Frankly, I suspect it has not been used "in anger"
very much.

For the behavior of the standard buttons, I think it should work this way:

• If nothing is selected, "Open/Save" should be disabled
• If something is selected, "Open/Save" should be enabled
• There should be a mode where the dialog is in "file mode" (default)
  
  
  
  • If a directory/folder is selected "Open/Save" should navigate to
    
    that folder.
  
  
  • If a file is selected, the dialog should close and whatever was
    
    selected should be available via the API
  
  
• If in the other mode ("directory mode")
  
  
  
  • Only directories should be displayed
  
  
  • If a directory is selected and "Open/Save" is pressed the dialog
    
    should close and whatever was selected should be available via the API
  
  

We'd totally appreciate you taking a swing at fixing this. Please read the
contribution guide.

Cheers!

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/migueldeicaza/gui.cs/issues/871#issuecomment-674425920,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAU4VFC7J4RZFM23PZ7B7L3SA274RANCNFSM4QALW4RA
.

[tig]

No stress. This is all for fun and learning anyway so @bdisp and I will happily help as you make progress!

[BDisp]

Yes, both can be improved as @tig mentioned, but they don't have to do all the work, but just return what the developer needs for processing. And in this case FilePathsis essential because it returns a list of the selected files / folders. Then the developer has to know how to process them, whether to open or to save. I've made some improvements but all help is always welcome :-)

[Mgamerz]

It may take me a bit to get to this, but I'll try it once I get a bit of time.

[Mgamerz]

I'm finishing up work on the second version of the app and will be coming back to the console UI version so I'll be taking a look at this within the next week or so.