edit_line and edit_box swallows keypress events about shoes3 HOT 5 CLOSED

There are shoes_app_keypress() and shoes_app_keydown(). Gtk calls them both for GDK_PRESS event. OSX only calls _shoes_app_keypress().

Some alt-key sequences are legitimately part of Apples text editing - including alt-left and alt-right( ! ) and as long as that edit box has OSX focus, OSX does what OSX does.

from shoes3.

Some alt-key sequences are legitimately part of Apples text editing - including alt-left and alt-right( ! ) and as long as that edit box has OSX focus, OSX does what OSX does.

This is a useful piece of information. A simple test revealed that the whole edit_box and edit_line behaviour, including with the new keypress handling, is actually normal on MacOS X.

TEST SCENARIO

• Open Safari.
• Go to a page, then http://www.google.ca/, than another page.
• cmd-left to go back to http://www.google.ca/.
• Focus on the input box.
• cmd-left or cmd-right to go back or forward.

_ACTUAL RESULT_ cmd-left and cmd-right doesn't work either on Safari.

from shoes3.

Helpful indeed. Fighting Apple's choices for cocoa is not a good practice for us.

from shoes3.

I'm closing this report since it's probably not something we should be doing.

from shoes3.

I'm closing this one. By definition keys for edit_line and edit_blocks belong to the native widget and processed by the Shoes change block - assuming you have one attached to the shoes widget. You can use the 3.3.5 event abilities to get if front of that if you really need that.

from shoes3.