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

List:       kde-core-devel
Subject:    RE: More KActions...
From:       Sven Radej <sven () lisa ! exp ! univie ! ac ! at>
Date:       2000-03-28 13:50:56
[Download RAW message or body]

On Tue, 28 Mar 2000, David Faure wrote:
>> Should KAction have virtual members void setChecked(bool)  
>> and bool checked()
>> 
>> Look at this:
>>    actionCollection()->action("show_all_fields")->setChecked(true);
>> 
>> I get compiler error about no method setChecked in KAction.
>> actionCollection::action(...)  returns "KAction *".  I know 
>> that this is really
>> KToggleAction. But compiler doesnīt and I have to use cast, 
>> which I donīt like.
>> 
>> so 
>>    virtual void setChecked(bool);
>>    virtual bool checked();
>> in kaction.h, and
>> 
>>    void KAction::setChecked(bool)  {};
>>    bool KAction::checked()  {return false;};
>> in kaction.cpp would help.
>> What do you think?
>
>Well, I wanted to point this out, from your earlier posts: you seem to do 
>everything using the lookup-by-name method, whereas the apps I know 
>(konqy, koffice...) keep member variable with pointers to the actions 
>they need to modify, e.g. the KToggleActions.

I donīt have any other method of lookup. Having ton of K*Action* pointers 
isnīt nice (kmail has bazilion of private data already).

>I don't know what is to prefer - pointers take memory, lookups take time...
>But the member variable solution definitely doesn't have this problem.
I am converting an old style app. It used IDs for checkable options. Creating
actions and reading config  are two different methods, plus at least one method
more which checks/unchecks them. Now I donīt have IDs any more -  I just have
names. Oh, well Iīll go with pointers... only 12 ToggleActions...  :-(

>BTW, I think setChecked() in KAction is wrong design, somehow...
Donīt know - KToggleAction and KRadioAction inherit KAction; default
implemntation would do nothing/return false.

I think lookups are handy. By ID or by name.

-- 
Sven Radej      radej@kde.org
KDE developer   Visit http://www.kde.org

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