You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Create a new .NET 8 ConsoleApp (I called mine OpenFileTest)
Import NuGet packages Eto.Forms 2.8.3 and Eto.Platform.Gtk 2.8.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!
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
Run the program from a Linux machine
Wait for the File Open dialog to appear
Either choose a file or cancel out (it does not matter)
Observe the File Open dialog is frozen
Also observe that the program received your file choice (and is continuing to run in the background!)
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
usingEto.Forms;usingEto.GtkSharp.Forms;varapplication=newApplication();varlastDisplayedTime=DateTime.Now.AddSeconds(-10);// While loop to simulate a "game loop" (if we _don't_ have this while loop the bug doesn't reprowhile(true){// Open the file open dialogue every 10 secondsif((DateTime.Now-lastDisplayedTime).TotalSeconds>10){Console.WriteLine($"Select a file:");varopenFileDialog=newOpenFileDialog();varresult=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, :(varcontrol=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
The text was updated successfully, but these errors were encountered:
Preface
Admittedly: I have a weird setup. I'm writing a level editor in MonoGame and really I just want to use
Eto.Forms
'sOpenFileDialog
andSaveFileDialog
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
OpenFileTest
)Eto.Forms 2.8.3
andEto.Platform.Gtk 2.8.3
dotnet publish OpenFileTest -c Release -r linux-x64 /p:PublishReadyToRun=false /p:TieredCompilation=false --self-contained
Code that Demonstrates the Problem
Specifications
The text was updated successfully, but these errors were encountered: