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

List:       kde-devel
Subject:    Re: KKeyDialog and KAccel
From:       Andreas Beckermann <b_mann () gmx ! de>
Date:       2002-05-02 13:37:15
[Download RAW message or body]

On Thursday 02 May 2002 14:16, Ellis Whitehead wrote:
> > The only solutions I can found by now:
> > 1. implement all accels as KActions (*really* ugly in a game!)
>
> This is what you'll have to do.  Why do you find it ugly?

Ok, so I'll look into this further...
Some reasons why I find it ugly:
- I need to provide a KActionCollection object, which is unaccessible from my 
central widget.
I could do something like
setCentralWidget(widget);
widget->initKeys(actionCollection());
and then add the KAction objects there, but it looks like a workaround (if 
it's the way to go then its no problem though...)
- when I use QWidget::key[Press|Release]Event() it's hard to find out which 
action was used. Best solution seems to be a QMap or a Q*List which store the 
actions in the widget - beside the KMainWindow. Since I can't access 
actionCollection() I can't iterate the accels either.

> > Simply adding KKeyDialog::insert(KAccel*) seems to work, btw.
>
> The long-term idea is to move away from KAccel usage for all but
> specialized uses.  For KDE 4.0 I intend to completely remove
> configurability for KAccel objects, because there is a lot of code and
> memory duplication between KAccel and KAction that is inelegant and a pain
> to maintain.  I know KAccel is used a lot in kdegames, but I don't want to
> add code for what is in principle a deprecated class usage.

Ok, it's good to know that KAccel should not be used. Once I find a good 
solution for the above problems (the initKeys(actionCollection()) seems to be 
the way to go) I'll port some games in kdegames to use KAction instead.

> Regards,
> Ellis

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