Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gtk: OpenFileDialog / SaveFileDialog do not automatically close in some scenarios #2695

Open
notexplosive opened this issue Oct 23, 2024 · 0 comments

Comments

@notexplosive
Copy link

notexplosive commented Oct 23, 2024

Preface

Admittedly: I have a weird setup. I'm writing a level editor in MonoGame and really I just want to use Eto.Forms's OpenFileDialog and SaveFileDialog to give users a good experience saving and opening files on all platforms. For Windows it's been working great! But my friend on Linux (Pop_OS, although I suspect this is not a unique Distro problem) said that the open/save dialogues were behaving kind of funny. I've since been able to reproduce the behavior in a VM.

Expected Behavior

The OpenFileDialog / SaveFileDialog should close itself when the user has selected a file (or has canceled their selection).

Actual Behavior

After choosing a file, the program continues with the returned file path, but the Dialog sticks around in an unresponsive state.

Steps to Reproduce the Problem

  1. Create a new .NET 8 ConsoleApp (I called mine OpenFileTest)
  2. Import NuGet packages Eto.Forms 2.8.3 and Eto.Platform.Gtk 2.8.3
  3. Create a while loop that runs forever that invokes the file open dialogue every 10 seconds (see code sample)
    • The while loop is important because it's simulating (more or less) what MonoGame is doing. I found if you don't have this while loop the bug doesn't repro, so it's definitely related!
  4. Build the application with this command: dotnet publish OpenFileTest -c Release -r linux-x64 /p:PublishReadyToRun=false /p:TieredCompilation=false --self-contained
    • You probably don't NEED to run this exact command, I'm just being thorough in my repro steps
    • If you want to recreate my environment EXACTLY: I'm building from Windows 10 targeting Linux, not building on Linux directly
  5. Run the program from a Linux machine
  6. Wait for the File Open dialog to appear
  7. Either choose a file or cancel out (it does not matter)
  8. Observe the File Open dialog is frozen
  9. Also observe that the program received your file choice (and is continuing to run in the background!)
  10. 10 seconds later, the file open dialogue will finally close itself, but only because a new one was requested in its place, which immediately appears.

Code that Demonstrates the Problem

using Eto.Forms;
using Eto.GtkSharp.Forms;

var application = new Application();
var lastDisplayedTime = DateTime.Now.AddSeconds(-10);

// While loop to simulate a "game loop" (if we _don't_ have this while loop the bug doesn't repro
while (true)
{
    // Open the file open dialogue every 10 seconds
    if ((DateTime.Now - lastDisplayedTime).TotalSeconds > 10)
    {
        Console.WriteLine($"Select a file:");
        var openFileDialog = new OpenFileDialog();
        var result = openFileDialog.ShowDialog(null);

        if (result == DialogResult.Ok)
        {
            Console.WriteLine($"You have selected: {openFileDialog.FileName}");
        }
        else
        {
            Console.WriteLine($"No file selected");
        }
        
        // Optimistically, I hoped one of these would work, :(
        var control = OpenFileDialogHandler.GetControl(openFileDialog);
        control.Destroy();
        control.Hide();
        
        lastDisplayedTime = DateTime.Now;
    }
}

Specifications

  • Version: Eto.Forms 2.8.3 and Eto.Platform.Gtk 2.8.3
  • Platform(s): Confirmed on Gtk, notably the Windows Platform does NOT have this problem
  • Operating System(s): Confirmed repro on a fresh install of Pop_OS 22.04, repros in a VM and on real hardware
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant