Input/output file dialog behind window #3775

Closed
colouredmirrorball opened this Issue Sep 6, 2015 · 16 comments

Comments

Projects
None yet
4 participants
@colouredmirrorball

When using selectInput() or selectOutput(), the resulting file dialog window is always at the same location of the sketch' window but behind it. This is very annoying and off-putting since there is almost no visual evidence the dialog has opened, except when one thinks about looking behind the sketch' window. (3.0b5)

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 8, 2015

Member

Code to reproduce? I don't even know what renderer you're using, so there's no way to track this down.

Member

benfry commented Sep 8, 2015

Code to reproduce? I don't even know what renderer you're using, so there's no way to track this down.

@colouredmirrorball

This comment has been minimized.

Show comment
Hide comment
@colouredmirrorball

colouredmirrorball Sep 8, 2015

Sorry. Windows 7 64 bit, Processing 3.0b5:

void setup()
{
  size(500,500, P2D);
  //surface.setLocation(500,500); <- causes crash (unrelated)
}

void draw()
{
}

void mousePressed()
{
  selectInput("test", "test");   //gets placed behind the sketch' window
}

void test(File input)
{
  println(input.getAbsolutePath());
}

Sorry. Windows 7 64 bit, Processing 3.0b5:

void setup()
{
  size(500,500, P2D);
  //surface.setLocation(500,500); <- causes crash (unrelated)
}

void draw()
{
}

void mousePressed()
{
  selectInput("test", "test");   //gets placed behind the sketch' window
}

void test(File input)
{
  println(input.getAbsolutePath());
}
@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 9, 2015

Member

Working fine on OS X. @JakubValtar can you see if this is Windows-specific? I suspect it's also JOGL-specific.

Member

benfry commented Sep 9, 2015

Working fine on OS X. @JakubValtar can you see if this is Windows-specific? I suspect it's also JOGL-specific.

@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Sep 9, 2015

Contributor

Yes, the file picker opens in the background on my Win 8.1 64bit.

Also: In the head version, it takes a few seconds before the picker opens. In beta 5 it opens instantly.

I also have violent flickering in the sketch window, but that's a separate issue. Flickering is fixed in the head version.

Contributor

JakubValtar commented Sep 9, 2015

Yes, the file picker opens in the background on my Win 8.1 64bit.

Also: In the head version, it takes a few seconds before the picker opens. In beta 5 it opens instantly.

I also have violent flickering in the sketch window, but that's a separate issue. Flickering is fixed in the head version.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 9, 2015

Member

Hm, sounds like a JOGL bug, but we own it.

Member

benfry commented Sep 9, 2015

Hm, sounds like a JOGL bug, but we own it.

@benfry benfry added this to the 3.0 final milestone Sep 15, 2015

@benfry benfry added the high label Sep 15, 2015

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Sep 16, 2015

Member

Right now I don't have access to a windows machine, but I wrote a minimal test case that does not depend on Processing, available here, which could be used to report the issue to JOGL. I did similar thing for other upstream bugs (#3401, #3339, #3793) that seem to be caused by bugs in JOGL's NEWT.

Member

codeanticode commented Sep 16, 2015

Right now I don't have access to a windows machine, but I wrote a minimal test case that does not depend on Processing, available here, which could be used to report the issue to JOGL. I did similar thing for other upstream bugs (#3401, #3339, #3793) that seem to be caused by bugs in JOGL's NEWT.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 18, 2015

Member

Looks like we won't have an upstream fix in time for 3.0, so what should we do here?

  1. Put a message in the console saying "check behind this window for your the file dialog"
  2. Minimize the rendering window during file selection
  3. Leave it as-is and continue to annoy people
Member

benfry commented Sep 18, 2015

Looks like we won't have an upstream fix in time for 3.0, so what should we do here?

  1. Put a message in the console saying "check behind this window for your the file dialog"
  2. Minimize the rendering window during file selection
  3. Leave it as-is and continue to annoy people
@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Sep 18, 2015

Member

I would go with 2, and then restoring the rendering window after the file selection dialog is closed.

I just opened a bug in JOGL's tracker (also for the other ones), with the hope to bringing these issues to their attention. I will keep an eye on any updates on JOGL's tracker.

Member

codeanticode commented Sep 18, 2015

I would go with 2, and then restoring the rendering window after the file selection dialog is closed.

I just opened a bug in JOGL's tracker (also for the other ones), with the hope to bringing these issues to their attention. I will keep an eye on any updates on JOGL's tracker.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 19, 2015

Member

Sounds good; will you have time to implement or should I take a look?

Member

benfry commented Sep 19, 2015

Sounds good; will you have time to implement or should I take a look?

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Sep 19, 2015

Member

I was looking into this... We would need to add some code inside the select*() functions that checks the renderer is PGraphicsOpenGL and the platform MACOSX, and if that is the case calls surface.setVisible(false) and surface.setVisible(true) after and before selectImpl(). I thought of using setVisible() because GLWindow does not have a function to request minimization. It is not a particularly elegant hack, but would work until the issue is fixed in JOGL. What do you think?

Member

codeanticode commented Sep 19, 2015

I was looking into this... We would need to add some code inside the select*() functions that checks the renderer is PGraphicsOpenGL and the platform MACOSX, and if that is the case calls surface.setVisible(false) and surface.setVisible(true) after and before selectImpl(). I thought of using setVisible() because GLWindow does not have a function to request minimization. It is not a particularly elegant hack, but would work until the issue is fixed in JOGL. What do you think?

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 19, 2015

Member

I think it's worth trying, though I think it's Windows, not OS X, that has the problem.

Member

benfry commented Sep 19, 2015

I think it's worth trying, though I think it's Windows, not OS X, that has the problem.

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Sep 19, 2015

Member

ok, this 8c25523 should do it. Don't have windows machine to test right now, if anyone do please let me know if it works.

Member

codeanticode commented Sep 19, 2015

ok, this 8c25523 should do it. Don't have windows machine to test right now, if anyone do please let me know if it works.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 19, 2015

Member

That looks problematic—you're aware the selectXxx() methods are asynchronous, right? So that'll open the chooser and then immediately re-open the drawing area. Or was that intentional? Maybe it would work. Also better to do these once inside the two selectXxxxImpl functions, rather than in each variant that calls selectXxxxImpl.

Member

benfry commented Sep 19, 2015

That looks problematic—you're aware the selectXxx() methods are asynchronous, right? So that'll open the chooser and then immediately re-open the drawing area. Or was that intentional? Maybe it would work. Also better to do these once inside the two selectXxxxImpl functions, rather than in each variant that calls selectXxxxImpl.

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Sep 19, 2015

Member

you are right, the setVisible() calls should go inside run(). A problem is that we need to look at g to determine if the renderer is PGraphicsOpenGL, but selectXxxxImpl() are static.

Member

codeanticode commented Sep 19, 2015

you are right, the setVisible() calls should go inside run(). A problem is that we need to look at g to determine if the renderer is PGraphicsOpenGL, but selectXxxxImpl() are static.

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Sep 19, 2015

Member

Ok, I added a PApplet argument to selectXxxx() with commit 202bae8, so the check can be done in the thread that launches the dialog and collects the user selection. I noticed these methods are also used in Archiver.java, Welcome.java, and the PreferencesFrame.java.

I run some tests with platform == MACOSX, and the rendering window disappears/appears while selecting the file, and the other functionality in the PDE (preferences, sketchbook folder selection) doesn't seem to be affected. Committed changes use platform == WINDOWS.

Take a look and let me know if this could work as a temp workaround until JOGL fixes the upstream bug.

Member

codeanticode commented Sep 19, 2015

Ok, I added a PApplet argument to selectXxxx() with commit 202bae8, so the check can be done in the thread that launches the dialog and collects the user selection. I noticed these methods are also used in Archiver.java, Welcome.java, and the PreferencesFrame.java.

I run some tests with platform == MACOSX, and the rendering window disappears/appears while selecting the file, and the other functionality in the PDE (preferences, sketchbook folder selection) doesn't seem to be affected. Committed changes use platform == WINDOWS.

Take a look and let me know if this could work as a temp workaround until JOGL fixes the upstream bug.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 19, 2015

Member

Yeah, wow.. what a mess that makes. But it works, so we'll go with it. Opened #3831 to cover the workaround and future fix.

Member

benfry commented Sep 19, 2015

Yeah, wow.. what a mess that makes. But it works, so we'll go with it. Opened #3831 to cover the workaround and future fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment