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

List:       kde-devel
Subject:    Re: KKeyDialog and KAccel
From:       thomas.friedrichsmeier () ruhr-uni-bochum ! de
Date:       2002-05-02 22:39:29
[Download RAW message or body]

>Hmm...  I see your point.  Global shortcuts _are_ able to pass integers back
>to a slot based on the action's name.  I.e., "Switch to Desktop 1" sends 1,
>and "Switch to Desktop 2" sends 2.

>I could try to do something similar for program shortcuts:

>new KAction( i18n("Exchange Card 1"), CTRL+Key_1,
>this, SLOT(slotHeld(int)),
>pCollection, "exchange {1}" );

>If this would work or if you think of a better way, let me know and I'll see
>about implementing it.  Supporting dynamic actions would be a good thing.

>Cheers,
>Ellis

Andreas informed me about this thread on kde-devel and told me to speak 
up, if I am still unhappy with this solution.
Well, I don't think it's all that much of a problem, but this solution will not 
work for my game or generally arcade/action-type games. For those you 
generally want to assure some action is done at a constant rate (meaning 
you don't want to rely on the normal key-repeat) as long as the key is 
pressed, e.g. in KAsteroids you want the ship to accelerate as long as the 
player presses the up-key, and similarly in my game ( 
http://taxipilot.sourceforge.net ) I'm using a combination of keyPressEvent 
and keyReleaseEvent to keep informed about the current state of the key. 
I'm not using or planning to use any slots for this purpose.
I'm quite aware, that this means misusing KAccel (or KAction), but that's 
simply the easiest and nicest way I know to be able to use the key-
configuration dialog. When I brought up the issue on kde-games-devel, my 
problems were that KAccel::findKey (...) did not work as expected anymore, 
and that insertItem (...) is now deprecated (I use insertItem, since I don't 
need any slots). The first is easy to work around by keeping an own map of 
keys to meanings that gets updated everytime the keys get configured. The 
latter should be solvable by using a dummy slot or by inserting this kind of 
action only for the key-configuration dialog and removing them again right 
away (I have not tried this yet, though).
Either way, for my application, it would be most comfortable to be able to 
simply insert some arbitrary actions without slots into the key-configuration-
dialog, which do not get handled as regular KAccels/KActions. Quite likely 
this is a too uncommon situation to add that kind of functionality in kdelibs, 
and I can live with a workaround - I just wanted to point this out and possibly 
you have some better workarounds to offer than those I can think of.

Thomas
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]