[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: kmix and shortcut keys
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2004-02-20 12:31:41
Message-ID: 200402201331.41530.l.lunak () suse ! cz
[Download RAW message or body]

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/

["a.cpp" (text/x-c++src)]

#include <kcmdlineargs.h>
#include <kapplication.h>
#include <kdebug.h>
#include <kkeynative.h>

#include <X11/Xlib.h>
#include <X11/extensions/XTest.h>

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 );
    }


>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]