Bug 1223

Is this still true w/ latest builds?

See commit 03909cb24ab6f5648e7fc6e696024ca460b37070

<http://jogamp.org/git/?p=jogl.git;a=commit;h=03909cb24ab6f5648e7fc6e696024ca460b37070>

NEWT Window Maximize: re-gain focus after maximize action (maybe lost on platforms, i.e. OSX)

I just tested with the september 20 release and the issue is still happening.

Thx to this report and hence manual testing on OSX
I found another open issue, see Bug 1188 comment 11,
i.e. commit fa3c55b8176b284752ed14a5a24f7fee36e588a3.

commit fbf14fd09bcc8eccaf819e953a82b3619e6de796:

Analysis
    
TestGearsES2NEWT reacts on key-press 'n', opening another GLWindow.
    
Procedure:
[1] Pressing 'n' (2nd GLWindow) and manual re-focus 1st GLWindow
    
[2] Pressing 'm' (single, alt, shift) on 1st GLWindow maximizes it
    Focus is still on 1st GLWindow!
    
[3] Pressing ctrl-m un-maximizes ..
    Focus is still on 1st GLWindow!

Please re-open this bug if you can produce a detailed 
reproduction test case - and if the issue still exists.

Thank you.

It is still happening, and in fact it is a duplicate of 

https://jogamp.org/bugzilla/show_bug.cgi?id=977

where the bug is better explained. I'm not sure how to reproduce programmatically, but basically what happens is that the application does not receive any mouse events after maximizing the GLWindow, unless clicking on the title bar or switching applications back and forth.

(In reply to ac from comment #6)
> It is still happening, and in fact it is a duplicate of 
> 
> https://jogamp.org/bugzilla/show_bug.cgi?id=977
> 
> where the bug is better explained. I'm not sure how to reproduce
> programmatically, but basically what happens is that the application does
> not receive any mouse events after maximizing the GLWindow, unless clicking
> on the title bar or switching applications back and forth.

you mean 'maximized by pressing the green "plus" button on the window decoration',
and not via our new programmatic way?

TestGearsES2NEWT shows me that mouse events are received
after manually maximizing the NEWT window or doing it programmatic:

java com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT -manual -time 1000000 -traceMouse

OSX 10.10.5
java 1.8.0_60

+++

Further more, if I run your test WindowFocusNEWT:
  java -XstartOnFirstThread com.jogamp.newt.util.MainThread WindowFocusNEWT
or
  java WindowFocusNEWT

... everything works as well.

+++

Maybe it is the OSX or java version ?

*** Bug 977 has been marked as a duplicate of this bug. ***

(In reply to Sven Gothel from comment #8)
> java com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT
> -manual -time 1000000 -traceMouse

that should read (ofc):

java -XstartOnFirstThread com.jogamp.newt.util.MainThread \
com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT \
  -manual -time 1000000 -traceMouse

commit 8790d4a25410c51e747f4cdd7954ef8abbb7a68b:
  Add '-traceMouse' commandline argument to check whether mouse events are still received after manual maximize

Ok, I will run the test command you just mentioned, and will report back.

apologies for my ignorance, but where are you supposed to run the command:

java -XstartOnFirstThread com.jogamp.newt.util.MainThread \
com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT \
  -manual -time 1000000 -traceMouse

from? I tried a couple of places, but was not able to make it work. I get "Error: Could not find or load main class com.jogamp.newt.util.MainThread"

(In reply to ac from comment #13)
> apologies for my ignorance, but where are you supposed to run the command:
> 
> java -XstartOnFirstThread com.jogamp.newt.util.MainThread \
> com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT \
>   -manual -time 1000000 -traceMouse
> 
> from? I tried a couple of places, but was not able to make it work. I get
> "Error: Could not find or load main class com.jogamp.newt.util.MainThread"

cd jogl/make
- edit scripts/tests.sh: enable that one test line only - 
bash scripts/tests-osx-x64.sh -manual -time 10000000 -traceMouse

Thanks for the instructions. 

Now I realize that I was behind a "non-bug", which was simply a result of how windowing toolkits work... 

I was able to reproduce the "bug" by doing the following:

* Move mouse over the green maximize button
* Press on said button, which maximizes the window
* Because the window was not initially placed at the upper left corner of the screen, after maximization the cursor falls inside the drawing area (without moving it)
* Now, moving the mouse inside the drawing area does not generate any EVENT_MOUSE_MOVED
* If I move the mouse outside of the drawing area, and then back in, EVENT_MOUSE_MOVED events are triggered again.

What happens is that the mouse leaves the window by being positioned over the maximize button, and even though after maximization the pointer falls inside the window, it is not registered as entering the window (since it didn't move). Please correct me if I'm wrong (AWT behaves in the same way, by the way)

(In reply to ac from comment #15)
> Thanks for the instructions. 
> 
> Now I realize that I was behind a "non-bug", which was simply a result of
> how windowing toolkits work... 
> 
> I was able to reproduce the "bug" by doing the following:
> 
> * Move mouse over the green maximize button
> * Press on said button, which maximizes the window
> * Because the window was not initially placed at the upper left corner of
> the screen, after maximization the cursor falls inside the drawing area
> (without moving it)
> * Now, moving the mouse inside the drawing area does not generate any
> EVENT_MOUSE_MOVED
> * If I move the mouse outside of the drawing area, and then back in,
> EVENT_MOUSE_MOVED events are triggered again.
> 
> What happens is that the mouse leaves the window by being positioned over
> the maximize button, and even though after maximization the pointer falls
> inside the window, it is not registered as entering the window (since it
> didn't move). Please correct me if I'm wrong (AWT behaves in the same way,
> by the way)

That could be all right - good explanation.

Dun thing though is, that - again - here it works,
i.e. the mouse gets inside again (detected) and hence
mouse move events are arriving.

Maybe some odd setting differences of our machines?

I.e. I would expect OSX cocoa to send us the focus state
and hence we can receive the events. This seems to be not true.

BTW, we propagate EVENT_MOUSE_ENTERED and EVENT_MOUSE_EXITED
from the native NewtView.
Wonder what really happens, but I cannot reproduce it.

If you could produce a full debug log, '-Djogl.newt.debug',
maybe even compile the native NEWT stuff w/ VERBOSE_ON
../src/newt/native/NewtMacWindow.h#41: #define VERBOSE_ON 1

and make pipe a minimal test w/ our test case >& a.log,
7z it .. etc - I may get an idea :)

(In reply to Sven Gothel from comment #16)
> BTW, we propagate EVENT_MOUSE_ENTERED and EVENT_MOUSE_EXITED
> from the native NewtView.
> Wonder what really happens, but I cannot reproduce it.

Further more .. if those enter/exit events are _not_ received,
we synthesize them ourselves.

Created attachment 762 [details]
log file

Hi Sven,

I run the TestGearsES2NEWT test case using the latest changes from the gluegen and jogl repos. I rebuilt jogl using #define VERBOSE_ON 1 in NewtMacWindow.h, and run the following command:

bash scripts/tests-osx-x64.sh -manual -time 10000000 -traceMouse -Djogl.newt.debug >& a.log

The EVENT_MOUSE_MOVED events are no longer generated after maximizing the GLWindow. I have attached the log file. Let me know if you want me to run other tests on my system.

Andres