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

List:       kde-games-devel
Subject:    Re: [Kde-games-devel] Porting, KAccel
From:       thomas.friedrichsmeier () ruhr-uni-bochum ! de
Date:       2002-04-16 21:38:11
[Download RAW message or body]

To anwer my own question (partially): You can simply keep a QMap of keys 
to meanings, that is updated every time the keys get configured.
(Other than KAccel::findKey (...), currentKey (...) still works).
What I'm wondering though, is whether the developers of the kde-libs are 
aware that deprecating/removing the insertItem-method will pose a problem 
to some games (and probably only to games - all other types of app will 
likely be happy with using slots or actions). I know KAsteroids is using the 
same mechanism (I originally copied from there) and it looks like they still 
use insertItem (...), too.
Has anybody been following the discussions on the KAccel-changes, did the 
problem get mentioned?

> Possibly some other people have run into the same problem:
> I've been using KAccel for keyboard-input (i.e. movements), so the keys are
> configurable:
> 
>  accel->insertItem(i18n("Accelerate Leftwards"), "Left", Qt::Key_Left);
> 
> and then in key(Press|Release)Event (QKeyEvent *e):
> 
>  QString id = accel->findKey(e->key());
> 
> Now when porting to KDE 3, I found out that
> a) insertItem (..) is now deprecated and the porting-guide suggests to use
> insert (...) instead, which would force me to specify a SLOT to connect the item
> to, which obviously isn't what I want. b) the findKey (...) thing does not work
> anymore, all I ever get is an empty string. That of course renders the whole
> game unplayable.
> 
> Did anybody find a good solution to this problem, yet?
> 
> Thomas

_______________________________________________
kde-games-devel mailing list
kde-games-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-games-devel
[prev in list] [next in list] [prev in thread] [next in thread]