Ticket #1589 (closed defect: fixed)
can not make Lock screen when option menu poping up During connecting a call
| Reported by: | regina_kim | Owned by: | zecke |
|---|---|---|---|
| Priority: | normal | Milestone: | Om2008.8 |
| Component: | Qtopia | Version: | |
| Severity: | normal | Keywords: | |
| Cc: | raster@… | Blocked By: | |
| Blocking: | Estimated Completion (week): | ||
| HasPatchForReview: | PatchReviewResult: | ||
| Reproducible: |
Description
kernel : 20080705-asu.stable-uImage.bin
rootfs : 20080708-asu.stable-rootfs.jffs2
summary : can not make Lock screen when option menu poping up During connecting a call
step :
- incoming a call
- answer call
- press option
- press AUX button
current result : when press AUX key will works for select menu
expected result : it should shows lock screen.
Change History
comment:3 Changed 5 years ago by raster
aaaah hmmm. well.. i can tell you exactly what is happening and why... and why it can't be fixed.
background:
- aux is an x key. power is also a key in x (like a key on a keyboard).
- e uses passive key grabs (x's mechanism to bind keys - eg alt+tab for switching windows) to grab a key (or key combination) so whenever it is pressed e gets the event
- when it gets this event for this bound key, e reacts by looking up what actions are bound to it and then "running" those actions.
background 2:
- when you press "option" qtopia (qt) pops up a MENU.
- MENUS in ALL widget sets GRAB the keyboard. that means they grab the entire set of keys in x and all passive keygrabs are "disabled" as ALL key presses go to the client that grabbed. this is to allow key navigation of menus without affecting the focus policy of x and focus returns automaticaly in x when a grab is released.
- the menu grabs the keyboard thus stopping e from getting its bindings presses - it nver gets the event so it can never respond.
this is just how it "works". the only solution is disabling key grabs for menus in qt/qtopia - i am unsure of the repercussions within qt/qtopia of this. but as such it will break "key navigation" for menus in qtopia.
i'm tempted to say its "invalid" as actually this is intended behavior and design of qt (and gtk and every other toolkit) and x11. this is just how it works, either that or "wontfix". since we have no numberpad/keypad, disabling keygrabs MAY work for the freerunner - but for future devices that may have a keypad... this would then break so we're breaking a widget set for 1 specific device.
comment:4 Changed 5 years ago by will
regina, let's take a look at this tomorrow.
i don't really get whats going on here.
comment:5 Changed 5 years ago by will
- Status changed from new to in_testing
last time we checked this was working.
