Open GoogleCodeExporter opened 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
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:
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
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
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
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
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
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
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
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
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
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
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
Original comment by pulkoma...@gmail.com
on 15 Jan 2010 at 7:39
Original comment by pulkoma...@gmail.com
on 16 Jan 2010 at 6:31
Original comment by pulkoma...@gmail.com
on 17 Mar 2010 at 6:00
Original issue reported on code.google.com by
MagerV...@gmail.com
on 12 Jan 2010 at 1:09