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

List:       kde-core-devel
Subject:    Re: KActionCollection proposal
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2002-01-17 10:03:59
[Download RAW message or body]

On Wed, Jan 16, 2002 at 05:10:08PM -0500, Ellis Whitehead wrote:
> 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").

Good point (removing the 0) , agreed.

> > 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 

Yes, I guess a create( KStdActionType ) method is better than a
hundre of createSelectAllAction, createUndoAction, etc. Might be a
little too verbose. What do others think?

> 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.

Why bound KStdAction to KActionCollection? Aside from internal
implementation details (accel handling, instance handling for icons) 
those classes have nothing to do with each other.

> > 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.

Well, it makes it impossible to use a plain KStdAction object
without a KActionCollection. For example if I don't want all the
xmlgui fuzz but just want to use the plain action concept to build a
small GUI for a small application I might just want to create the
actions, plug them into the GUI and forget about them. It seems odd
to me (just API wise) that KAction objects can only be successfully
be used in combination with a KActionCollection object, a class that
API wise just looks like a plain stupid container. Yes, there are
keyMap and whatever methods in the public API (hmm..) , but no
developer really calls those methods, and the plain class name
stresses the main purpose: A tool class to collect actions together,
simplifying the storage. No need for 100 member variables for each
action when you can just push them into a collection.

Maybe we should split up KActionCollection. I get the impression the
current class does too much (I do feel guilty :( . Currently it
provides some KInstance handling, accelerator stuff and highlighting
(think statusbar text) . I see/agree though that some of that
functionality can't be just pushed into KAction, so it seems KAction
will always depend on some other class for providing all features.
Hmm, hm, need to think about this more in a quiet minute.

What do others think?

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