Window.isMinimized() and Window.isCloseRequest()

[psiegel]

After a lot of testing, I've discovered that these two methods don't quite behave as I would expect.  Here's the skinny:

Minimzied

Window.isMinimized() returns true whenever the window doesn't have focus, regardless of wether it's on the screen or not.  So if I'm in windowed mode and simply click on another window, even if both windows are small enough that they can co-occupy the screen without overlapping, Window.isMinimized() still returns true.  This is whack.  You might correctly rename this method Window.isMinimizedOrLostFocus().  Personally, I'd much rather see it split into two methods: Window.isMinimized() and Window.hasFocus().

Close Request

When I press the little x button native to the window, Window.isCloseRequest() returns true.  I suspect (or rather, hope) that it would also return true if the system told the window close due to going down for reboot or other such cases.  However, regardless of how I react to this, Window.isCloseRequest() will now forever more return true.  So if I put up an "are you sure" screen and the user pressed "no", there's no way for me to clear that flag.  It seems that the expected behavior is that once this method returns true, my app will shut down.  That's not great.

I think this could be fixed with a simple method called Window.closeRequestHandled().  This would clear the flag, and allow subsequent presses of the 'x' button or possibly other system events set it again and my app to detect such.  Then if I'm in my "are you sure" screen and I press the 'x' button again, I can just take this as a "yes" reply and really shut down the app.

Paul

[princec]

Both good ideas.

Cas

[psiegel]

So, what's the current status of lwjgl?  Last I heard there was some kind of concerted push being organized to get to 0.7.  Is there a time frame for that?  Has it stalled on something specific?

Perhaps it's time I just joined the dev team so I can make these changes instead of just bitching about them.

Paul

[Matzon]

according to plan, 0.7 is due tonight...

[bedelf]

according to plan, 0.7 is due tonight...

Tease.

[Matzon]

Tease.

:twisted:

we just need to make gl entirely static, fix some eax bugs and - if time permits, fix a ati/ogl bug, relating to wglMakeCurrent and fullscreen. The latter proving to be rather hairy!

btw, tonight being 13 july  - and it is now 12:07 here - lots of time

psiegel

This is whack. You might correctly rename this method Window.isMinimizedOrLostFocus(). Personally, I'd much rather see it split into two methods: Window.isMinimized() and Window.hasFocus().

Isn't the purpose that we need to monitor when we're not "active" ? - so though I completely agree with you, couldn't we just call it isActive() ? - and then state that an app is active when it has focus and not minimized?

This is whack. You might correctly rename this method Window.isMinimizedOrLostFocus(). Personally, I'd much rather see it split into two methods: Window.isMinimized() and Window.hasFocus().

Again, can't this be solved by doing some internal stuff - so that we avoid method bloat. Currently the flag is set whenever a user pushes the X button. If we however delay that flag untill gl.tick() is called, and clear it on next round, it would solve it all, yes?

food for thought...

Regarding helping out - you're more than welcome to join! - the more the merrier - either send me or Cas a mail, or join #lwjgl on the freenode IRC network

[Matzon]

just talked to Cas about this and:
renaming to isActive
calling isCloseRequested will also clear the flag

simple aint it ?

[psiegel]

Isn't the purpose that we need to monitor when we're not "active" ? - so though I completely agree with you, couldn't we just call it isActive() ? - and then state that an app is active when it has focus and not minimized?

Consider a game where pausing gives an unfair advantage.  This could be pretty much any kind of time-based game.   Assume that we don't want to pause the game, as the player could just study the game in its paused state to figure out how to beat the level.

Now, let's say the user minimizes the game.  In this case, it's safe to pause the game, as the user can't see it.  There's no screen for him to study so no unfair advantage.  And we can save processing cycles by simply not running the game loop or render loop.

Now, say he simply switches focus to another window.  In this case it's unsafe to pause.  He can still see the game, so it should still be running, even though he's not providing any input.  

So, currently I'm solving this problem by alway pausing the main loop during isMinimized(), but continuing to render a "Game Paused" message to the screen, so no unfair advantage can happen.  However, in the minimized case this isn't very efficient, as we're wasting processor power rendering a screen that's never shown.   And it's not great in the lost focus case either, as we'd much rather have the game simply continue to run.

As you can see, the ideal situation would be a method to tell whether the game is minimized or has lost focus.  Since clearly I want to do two different things in each case.

Again, can't this be solved by doing some internal stuff - so that we avoid method bloat. Currently the flag is set whenever a user pushes the X button. If we however delay that flag untill gl.tick() is called, and clear it on next round, it would solve it all, yes?

I assume you meant to quote something out of the second part of my original mesage about close request, instead of the same quote about minimized?

Anyway, I think your approach for the close request thing is just fine.  I don't really know how the underlying native code works here, so I'd be wary of cases such as the user holding down the 'x' button for a very long period of time.  But perhaps the close request message doesn't actually come through until mouse up?

Regarding helping out - you're more than welcome to join! - the more the merrier icon_biggrin.gif - either send me or Cas a mail, or join #lwjgl on the freenode IRC network

I may have to wait a week or two on this, as I'm working towards a solid deadline of July 25th on my own project right now.  But once we're past that I'll probably have some free time, and would be more than happy to dive into some lwjgl code.  So expect some e-mail from me around the end of July.

Paul

[Matzon]

argh, 0.7 will be a delayed. We have an issue to clear first - sorry...

I see the point for both a isMinimized and isFocused - but typically I actually render the "pause" screen in both cases, since it in some way means the same thing, yes?

reagarding closing, a button click event is _always_ fired on button up - if not, it's an error.

[psiegel]

I noticed something interesting yesterday.  The problem with isMinimized() as I describe above is only an issue in Windows.  When running in Linux, it appears that isMinimized() only returns true if the window is actually minimized and off screen.  Simply switching focus to another window does not cause this method to return true.

So it seems that the Linux version of the code operates as I would expect, while the Windows version does not.  Simply changing the name of the method to isActive() would simply invert the problem, making Windows operate as expected and the Linux version not.

Paul

[Matzon]

So it seems that the Linux version of the code operates as I would expect, while the Windows version does not. Simply changing the name of the method to isActive() would simply invert the problem, making Windows operate as expected and the Linux version not.

This can be fixed
The question is:
do we need both isMinimized isFocused or can we suffice with isActive? - I'd only need the latter - don't know about the rest of you though...

[elias]

I'm definitely with psiegel here, isMinimized is the only state you need to knwo about, so you can save CPU cycles. When the window is inactive, it still needs to be rendered.

Whether people needs isActive() is another question - I don't see the use for it personally.

- elias

[cfmdobbie]

Ever played xboing?  Swung your mouse from side to side to hit the ball, and accidentally clicked on another window?

God I wish that game would pause when it lost focus...

[psiegel]

Yeah, personally I'd much rather have two methods: is Minimized() and hasFocus().  Ok, I suppose hasFocus() could be called isActive().  But I think the term "focus" is generally accepted as the term for which window is currently on top.

Anyway, I won't quibble about method names.  But I would really like to see both methods exist.  Then it's up to the developer to use or not use them.

Paul