Openmoko Bug #1589: can not make Lock screen when option menu poping up During connecting a call

Openmoko Public Trac bugs at docs.openmoko.org
Wed Jul 16 15:02:24 CEST 2008


#1589: can not make Lock screen when option menu poping up During connecting a
call
------------------------+---------------------------------------------------
 Reporter:  regina_kim  |        Owner:  zecke
     Type:  defect      |       Status:  new  
 Priority:  normal      |    Milestone:  ASU  
Component:  Qtopia      |      Version:       
 Severity:  normal      |   Resolution:       
 Keywords:              |     Blocking:       
Blockedby:              |  
------------------------+---------------------------------------------------

Comment(by raster):

 aaaah hmmm. well.. i can tell you exactly what is happening and why... and
 why it can't be fixed.

 background:

 1. aux is an x key. power is also a key in x (like a key on a keyboard).
 2. 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
 3. 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:

 1. when you press "option" qtopia (qt) pops up a MENU.
 2. 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.
 3. 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.

-- 
Ticket URL: <https://docs.openmoko.org/trac/ticket/1589#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac


More information about the buglog mailing list