--Boundary-00=_t4fNAK3rFGuWk6/ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Friday 20 of February 2004 00:04, Jonathan Riddell wrote: > On Mon, Feb 02, 2004 at 09:44:34PM +0100, Lubos Lunak wrote: [snip] > > IMHO the right solution would be to drop the KMilo KGlobalAccel-based > > plugin for the multimedia keys and set up default actions in KMix and > > KMixApplet, which is where they belong (and won't cause such strange > > effects like KMix suddenly started). > > > > For keyboards which need KMilo's special support for the keys, I think > > KMilo could act as a proxy for them - it e.g. detects the volume up key > > being pressed/released, and uses XTest to simulate XF86VolumeUp > > keypress/keyrelease (which in turn activates KMix). > > > > Would there be any problem with that? > > That does seem to make sense although I'm not sure how to program > XTest See the attached test app. Simulate keypress after detecting keypresses of the special keys, the same for release (I think KMilo already does in some other module for the wheel, i.e. mouse buttons). > and what happens if KMix/KMixapplet arn't loaded? Well, I think it could be argued that people who want to control the volume run some kind of mixer application, and those who don't won't be able to. The way I see KMilo is that it's just a proxy for all that weird hardware that wouldn't work otherwise. So I think it's sufficient if KMilo just converts the hardware specific events to normal events, and doesn't care anymore who handles those. But maybe KMilo tries to be more that just that, as it has also all those brightness etc. indicators. In which case I'd like if we decided on who's responsible for what, as there's some overlap between the functionality of KMilo, KMix, KHotKeys[*], KLaptopDaemon and maybe more. Currently e.g. KMilo handles the multimedia volume keys even though I'd expect that to be handled in KMix(Applet) and handles the battery status which I'd expect to be in KLaptopDaemon. [*] For KHotKeys I can say that it's purpose is to react on events, usually keypresses or mouse gestures, but it can react also on new windows and it shouldn't be hard to add new triggers, and if certain conditions are met, it performs various actions like starting apps, doing DCOP calls etc. Adding new triggers and actions should be quite simple, so it could e.g. also provide feedback on certain events, but there's no plugin architecture. -- Lubos Lunak KDE developer --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: l.lunak@suse.cz , l.lunak@kde.org Drahobejlova 27 tel: +420 2 9654 2373 190 00 Praha 9 fax: +420 2 9654 2374 Czech Republic http://www.suse.cz/ --Boundary-00=_t4fNAK3rFGuWk6/ Content-Type: text/x-c++src; charset="iso-8859-1"; name="a.cpp" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="a.cpp" #include #include #include #include #include #include bool send_keysym( unsigned int keysym, bool press, bool release ) { KeyCode keycode = XKeysymToKeycode( qt_xdisplay(), keysym ); if( keycode == NoSymbol ) return false; XTestGrabControl( qt_xdisplay(), True ); if( press ) XTestFakeKeyEvent( qt_xdisplay(), keycode, True, CurrentTime ); if( release ) XTestFakeKeyEvent( qt_xdisplay(), keycode, False, CurrentTime ); XFlush( qt_xdisplay()); XTestGrabControl( qt_xdisplay(), False ); return true; } bool send_key( unsigned int key, bool press, bool release ) { unsigned int keysym = KKeyNative( KKey( key )).sym(); return send_keysym( keysym, press, release ); } int main( int argc, char* argv[] ) { KCmdLineArgs::init( argc, argv, "a", "b", "c", "d" ); KApplication app; send_key( Qt::Key_VolumeUp, true, true ); } --Boundary-00=_t4fNAK3rFGuWk6/ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << --Boundary-00=_t4fNAK3rFGuWk6/--