[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-16 19:51:30
[Download RAW message or body]

On Wed, Jan 16, 2002 at 04:22:33AM -0500, Ellis Whitehead wrote:
> 2) Correspondingly, rename KActionCollection to KActions (with a typdef 
> KActions KActionCollection, for now)

I don't like that at all. KActions looks IMHO much too simliar to
KAction, making it unnecessarily hard to read code. It's called
QStringList and not QStrings either. And aside from that most modern
editors offer buffer completion ;)

> 3) Since KAction objects have to belong to an action collection in order to 
> function properly (so that they don't throw their key bindings into all the 
> wrong places), and since a KAction should be in one collection only, we 
> should use the accelerator method of inserting actions into a collection.
> 
> I.e., instead of:
> KStdAction::selectAll(viewManager, SLOT(slotSelectAll()), actionCollection());
> prefer:
> actions().insert(KStdAction::SelectAll, viewManager, SLOT(slotSelectAll());
> 
> The advantages of this include assuring proper usage by the application 
> programmer and simplifying the code to be maintained.

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

> 4) Depricate KStdAccel and KStdAction and all its functions.  Move the enums 
> to KAccel or KActionCollection and use a single insertion function rather 
> than using an individual function to create each action type.  This makes the 
> code centralized, smaller, easier to maintain, and avoids the evil of 
> copy&paste programming in KStdAccel/KStdAction.

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


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