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

List:       kde-core-devel
Subject:    Re: KActionCollection proposal
From:       Ellis Whitehead <kde () ellisw ! net>
Date:       2002-01-16 22:10:08
[Download RAW message or body]

On Wednesday 16 January 2002 14:51, Simon Hausmann wrote:
> [snip]
> > I.e., instead of:
> > KStdAction::selectAll(viewManager, SLOT(slotSelectAll()),
> > actionCollection()); prefer:
> > actions().insert(KStdAction::SelectAll, viewManager,
> > SLOT(slotSelectAll());
>
> I like the current mechanism more because it feels consistent with
> the normal way of memory management of QObjects (specify a parent
> upon creation and don't bother anymore) . 

True.  For consistency with Qt, it may well be better to use the 'new 
K*Action(...)' approach -- as long as the parent is specified on creation 
(i.e., we change the "*parent = 0" parameter to "*parent").

> I aggree though that the
> current mechanism of writing KStdAction::selectAll feels strange
> because the method name contains no verb. It's a hidden factory, and
> IMHO factories should be explicit.

I find it strange too.  I added a 'KStdAction::create(...)' method which makes 
it explicit.  Is that the sort of thing you mean?  A recurring issue here 
though is that we could do away with KStdAction ultimately, and just put the 
'enum StdAction' into KActionCollection.  In which case, we're back to the 
insert() method, like the one in KAccel for standard accelerators.

> I think it should still be possible to instantiate a standard action
> without binding it to a KActionCollection. Forcing those two
> together creates an IMHO unnatural limitation. (QAction isn't bound
> to QActionGroup either...)

Could you explain?  I haven't seen any instances of where this would be a 
limitation.

Regards,
Ellis

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