jiayouxjh / grafx2

Automatically exported from code.google.com/p/grafx2
0 stars 0 forks source link

Keyboard ignored after hiding application #282

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Start Grafx2
Press m to toggle zoom
Hide application with CMD-H
Show application again by clicking on icon in dock
Press m, and nothing happens
Keyboard still works in Load/Save dialog

I'm using the 2.2wip experimental build for OS X from bug 188.

Original issue reported on code.google.com by MagerV...@gmail.com on 12 Jan 2010 at 1:09

GoogleCodeExporter commented 9 years ago
I've never used a Mac, but normally, does clicking an icon in the dock give the
application "keyboard focus" ? I'm asking, because the symptoms look a lot like 
what
I could do on Windows : Grafx2/win would still react to the hovering mouse, but
doesn't receive any key input. Clicking inside the window, clicking on the 
border,
and "switching to" Grafx2 (Alt+Tab) automatically give keyboard focus.

If it's not that : You can check if Grafx2 receives any key at all. Go in Help
screens, and start changing any keyboard shortcut. While it's asking "press a 
key",
do the test: CMD-H, click icon in dock, then press M.
You'll see the reaction from grafx2: either accept and recognize 'm', or accept 
an
unexpected key (it will show the name and shift/alt/meta modifiers), or 
'nothing'
(still waiting).

Original comment by yrizoud on 12 Jan 2010 at 5:54

GoogleCodeExporter commented 9 years ago
On Tue, Jan 12, 2010 at 6:55 PM,  <grafx2@googlecode.com> wrote:
> I've never used a Mac, but normally, does clicking an icon in the dock give
> the application "keyboard focus" ?

Yes, if the application brought to front has an open window, it gets focus 
(including
keyboard).

> I'm asking, because the symptoms look a lot
> like what I could do on Windows : Grafx2/win would still react to the hovering
> mouse, but doesn't receive any key input. Clicking inside the window, 
clicking on
> the border, and "switching to" Grafx2 (Alt+Tab) automatically give keyboard 
focus.

Clicking does not help - I can draw, but no keys work.

However, the help dialog handily tells us what the problem is: Gfx2 still 
thinks the
CMD modifier is pressed. If I press m, the application interprets it as CMD-m.
Tapping on CMD a few times doesn't help, nor does holding down CMD (so it's not
inverted).

Attached a screenshot of me just pressing the Up arrow.

Original comment by MagerV...@gmail.com on 12 Jan 2010 at 6:48

Attachments:

GoogleCodeExporter commented 9 years ago
It should be noted that CMD-Tab works fine, but CMD-m (iconify window to dock)
triggers the same bug as CMD-h. Clicking the yellow iconify widget works 
however.

Original comment by MagerV...@gmail.com on 12 Jan 2010 at 6:50

GoogleCodeExporter commented 9 years ago
We don't seem to do anything special with this key...
Unless the key release and "repeatable" shortcut system is misbehaving ?

Original comment by pulkoma...@gmail.com on 12 Jan 2010 at 7:11

GoogleCodeExporter commented 9 years ago
I suspected it : SDL bug. All these fancy "event-driven" keyboard handlers 
cannot
query the current state of the keyboard, they have to wait for the system to 
send
"key pressed" and "key released". In this case, OSX does NOT send the release 
event
of this key, because the application doesn't have the focus. So, when the 
application
is back, you press 'm', and Grafx2 asks SDL "are there any modifiers with 
that?" and
SDL replies "Oh yessir, last time I looked, Meta was pressed."

Original comment by yrizoud on 12 Jan 2010 at 7:58

GoogleCodeExporter commented 9 years ago
It's strange that it doesn't go away when pressing the key again, however.

Original comment by pulkoma...@gmail.com on 12 Jan 2010 at 8:02

GoogleCodeExporter commented 9 years ago
Indeed, that particular problem typically goes away if you tap CMD. I don't see 
this
problem with other SDL apps.

Original comment by MagerV...@gmail.com on 12 Jan 2010 at 9:45

GoogleCodeExporter commented 9 years ago
Can you try to change a line in keyboard.c that reads:
   mod=Key_modifiers(SDL_GetModState());
into
   mod=Key_modifiers(keysym.mod);

With some luck (a lot of luck IMO) the event flags are ok, even though the 
query isn't.
This change would only affect actual keypresses, not the mouse wheel for 
example - So
you'll still have the problem with shortcuts on Mouse3/WheelUp/joystick, they 
will
get "CMD+".

I still need a dynamic call of SDL_GetModState() for Windows at least, to 
sidestep a
different issue: press shift, press a key, release shift: the shortcut that gets
repeated is the one with Shift.

Original comment by yrizoud on 12 Jan 2010 at 11:09

GoogleCodeExporter commented 9 years ago
Waiting on bug 188 and bug 285 as I can't do a test build right now...

Original comment by MagerV...@gmail.com on 13 Jan 2010 at 8:26

GoogleCodeExporter commented 9 years ago
Using keysym.mod didn't help.

I added a little debug output, and the problem is actually a little weird than I
originally though. Pressing *any* CMD+key combination triggers the problem, not 
just
CMD+h and CMD+m. I added a few debug printfs, and this is what I get:

// m, zoom on
Handle_key_press, sym = 006d, mod = 0000
key_code = 006d, mod = 0000, smod = 0000
Handle_key_release, sym = 006d, mod = 0000
key_code = 006d, mod = 0000, smod = 0000

// m, zoom off
Handle_key_press, sym = 006d, mod = 0000
key_code = 006d, mod = 0000, smod = 0000
Handle_key_release, sym = 006d, mod = 0000
key_code = 006d, mod = 0000, smod = 0000

// LCMD, no effect
Handle_key_press, sym = 0136, mod = 0000
Handle_key_release, sym = 0136, mod = 0000

// RCMD, no effect
Handle_key_press, sym = 0135, mod = 0000
Handle_key_release, sym = 0135, mod = 0000

// RCMD, keep holding
Handle_key_press, sym = 0135, mod = 0000
// l, nothing bound to CMD+l, error beep
Handle_key_press, sym = 006c, mod = 0800
key_code = 006c, mod = 8000, smod = 0c00
Handle_key_release, sym = 006c, mod = 0c00
key_code = 006c, mod = 8000, smod = 0c00
Handle_key_release, sym = 0135, mod = 0400

// m, error beep since it's interpreted as CMD+m
Handle_key_press, sym = 006d, mod = 0400
key_code = 006d, mod = 8000, smod = 0400
Handle_key_release, sym = 006d, mod = 0400
key_code = 006d, mod = 8000, smod = 0400

sym and mod are the raw values from event.keysym.sym/mod.
smod is the return value from SDL_GetModState(), mod is the value from 
Key_modifiers().

Original comment by MagerV...@gmail.com on 15 Jan 2010 at 9:30

GoogleCodeExporter commented 9 years ago
Weird indeed. The keypress event contains KMOD_LMETA (left CMD) but 
SDL_GetModState()
already reports KMOD_LMETA + KMOD_RMETA.

We could get similar result if Grafx2 accidentally called 
SDL_SetModState(KMOD_META),
but in our code I can only see this appear when handling Joystick events.

I looked a bit at SDL sourcecode, but I don't know what to think : If I'm 
looking at
the right version of the right file (SDL_macevents.c), MacOS should not even 
make a
difference between the two CMD keys, so I don't see how you can get two 
different syms.

Original comment by yrizoud on 15 Jan 2010 at 12:57

GoogleCodeExporter commented 9 years ago
OK, I found the bug. Commenting out KMOD_META in SDLMain.m, line 85 fixes the 
problem:

- (void)sendEvent:(NSEvent *)anEvent {
    if (NSKeyDown == [anEvent type] || NSKeyUp == [anEvent type]) {
        if ([anEvent modifierFlags] & NSCommandKeyMask)
        {
            SDL_SetModState(SDL_GetModState()/* | KMOD_META*/);
            [super sendEvent: anEvent];
        }
    } else
    {
        [super sendEvent: anEvent];
    }
}

This was apparently from an attempt to fix bug 160

http://code.google.com/p/grafx2/source/diff?spec=svn1248&r=804&format=side&path=
/trunk/SDLMain.m&old_path=/trunk/SDLMain.m&old=264

Original comment by MagerV...@gmail.com on 15 Jan 2010 at 1:10

GoogleCodeExporter commented 9 years ago
Sorry I hadn't noticed, I missed the .m when I searched in sources :(
KMOD_META contains 2 bits for the two CMD keys. This piece of code doesn't seem 
to
work well with what happens on key release, as SDL unsets only the bit for the 
CMD
key you actually release.

Original comment by yrizoud on 15 Jan 2010 at 3:45

GoogleCodeExporter commented 9 years ago

Original comment by pulkoma...@gmail.com on 15 Jan 2010 at 7:39

GoogleCodeExporter commented 9 years ago

Original comment by pulkoma...@gmail.com on 16 Jan 2010 at 6:31

GoogleCodeExporter commented 9 years ago

Original comment by pulkoma...@gmail.com on 17 Mar 2010 at 6:00