| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
| |
It worked in 4.5.0, so it should work in 4.5.1 too.
|
| |
|
|
|
|
| |
It seems that Vim or Xcode or whatever I was using to paste these
in messed up and added an extra space. Now we should be consistent with
the .cpp files and I found a file that we missed too.
|
| |
|
|
|
|
|
|
| |
It seems there is a potential for recursion because calling keyDown:
can bubble up to the window which will start the process all over again.
keyDown: will actually call qt_dispatchKeyEvent(), we may as well short
it out here. All the previous cases I tried continue to work and we
don't crash Creator if you are really impatient hitting keys.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In our Cocoa menu we check if we need to send the key event to the
qwidget before the menu has a chance at it, because logically in Qt, the
key event should go to the widget and not the menubar first (a bit
different than what happens on the mac). The way to determine this is to
send a shortcut override event and see if it accepts it. If it does,
that means we should just send it the key event. Previously we were
sending the shortcut override, but not following through on the key
event because we thought (however foolishly). That returning "YES" but
not setting an action would somehow forward the event (it doesn't).
There still seems to be some problems if you have a Dvorak-QWERTY+CWD
layout, but this probably needs to be dealt with at the key mapper
level.
Reviewed-by: Prasanth Ullattil
|
| |
|
|
| |
Someone messed up the whitespace on this comment.
|
| |
|
|
|
|
| |
GCC 4.2 needs to have this extern (and likely every compiler != gcc 4.
Reviewed-by: Trust Me
|
| |
|
