On Mon, Feb 22, 2010 at 10:04 AM, Gustavo Sverzut Barbieri <[email protected]> wrote: > On 2/21/10, Brian Wang <[email protected]> wrote: >> On Sun, Feb 14, 2010 at 9:20 AM, Carsten Haitzler <[email protected]> >> wrote: >>> On Fri, 12 Feb 2010 16:18:21 +0800 Brian Wang <[email protected]> >>> said: >>> >>>> Hello all, >>>> >>>> Here comes another newbie's question: >>>> How can I grab a key event if the key binding is already set in >>>> enlightenment? >>>> >>>> Thanks in advance. >>> >>> once a wm grabs a key - it is gone for application input. event gets >>> delivered >>> to the wm, not the app with the focus. same with any x client grabbing a >>> key. >>> it'd generally be bad to pass it on as now you end up with the same event >>> being >>> reacted to twice. this would need care. but as such - e uses the key to >>> flip >>> desktops or close a window etc. etc. so it makes no sense to pass them on >>> in >>> general as the event is acted on already. >> >> The use case I'm thinking of is that the application may want to >> handle this key event differently. For example, the application may >> want to display the volume differently (visually) to suit its >> interface. If wm takes away the event, the application would have to >> poll and display the volume. The UI may become less responsive this >> way. >> >> Since it's the way right now, I'll have to come up with an alternative. >> However, it's still quite surprising to me that the application cannot >> register a callback handler of the key events to the wm. >> >> Thanks for the insight. :-) > > do u have a better real use case than volume case? it is a very > unfortunate example for a number of reasons, the biggest being lack of > consistency... and you have easy cases to be informed without any > polling (timed polling)
How about the lock key? On a portable gadget, the power button is often used as a lock button. Here is the scenario: * WM handles the POWER button, which is configured to call a lock app. * POWER button is pressed -> lock-app starts up, brings down the LCM, and scales the cpu frequency down just enough to handle the background task (music playback, for instance) * POWER button is pressed (while the LCM is powered down) -> another lock-app instance (which will check for the existence of another lock-app) will be launched by the WM 5 seconds after the button is pressed. Yes, I've tested this on my board... This is bad in terms of responsiveness. I thought if there's some way the app can handle this key itself, the latency may be minimized. Maybe I'm wrong. But since it is not possible for the app to snatch the key event from wm, I don't know if it's just CPU too busy to handle the key or the WM delivers the event too late. Or this is just plain wrong to handle the POWER button this way? > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: [email protected] > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > -- brian ------------------ Cool-Karaoke - The smallest recording studio, in your palm, open-sourced http://cool-idea.com.tw/ iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
