On Mon, 22 Feb 2010 09:29:22 +0100 daniele_athome <[email protected]> said:
> Hello, I have another use case for this issue I need to implement myself. > > I use the power button in my own applications to do some actions in > them, but I want to do those actions only on short press; on long > press a lock-app should activate. So my idea was something like > delayed action in enlightenment key bindings: > [0.0 forward_to_client][1.0 simplelock] (it's just an example) > > I can handle this thing in many ways: I can send a dbus message from > the wm (very slow I guess), or I might simulate the keypress on the > application, can I do that? unfortunately... you ask asking e to begin a complex input manager. not just grabbing some keys for its own needs (to control the wm) but to become a full input router. routing some things and not others, knowing what it should and should not grab and then route - route to which application? (focused one, another one etc.) and currently - though this would be possible to do, is not a function of e as such. so - it's just not going to do that. no wm will that i know of. wm's tend to keep out of the input pipeline other than grabbing some keys+modifiers and buttons+modifiers so the wm can do its job of managing (providing controls to the user). now - this is possible to be created via modules - but it'd become a non-trivial module as u'd not only define what keys are to be grabbed by e and then either actioned on OR passed to an app, but under what contisions they are to be grabbed or not - are apps to register interest in keys via properties - then how, when will e grab them for apps and then provide the right routing to the desired target (example - normally camera button would run camera app - except when camera app is up.. it wants the button for "take a picture", or play/pause normally play/pause music.. even if music plyer window is not focused - it wants these key presses routed to it all the time focused or not... UNLESS some other app with a higher priority wants to take control of the play/paus etc. buttons - for video player for example or maybe incoming call or... who knows). but in the end you guys are entering the can of worms that is input routing. you are coming up with simple cases that dont work and are just beyond the very simplistic view of input that almost all wm's have. you want to open that can of worms.. you will have to deal with the above too - not just "use it or pass it on" but deciding when to pass it on (long, short, double press etc. etc.), what app is focused - what does it want to get, what non-focused apps exist and what do they say they want - what are their priorities for input grabbing like this etc. and based on all of these and some rules - decide how to forward and to who - if to forward at all (basically send a fake key event will do the job of forwarding). you could write a stand-alone process to do this - or it could be put into the wm u already have as a module (leaner than another process). but.. you do open this pandoras box. it can be done. it just isn't - so either you just dont try and do things that trigger the need for complex input routing and keep your designs/desires simpler ... or ... you attack the beast. :) this has come up before and i've made a mental note of this, but i've never gotten around to doing anything about it as i'm busy enough. but i have a rough idea of the kind of design needed etc. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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
