Bug in KAction::initPrivate

[Ellis Whitehead]

Hi Simon,

On Wednesday 25 September 2002 00:47, Simon Hausmann wrote:
> ...
> IMHO this is a case of a too-magic API. The only similar case that I
> can think of is QSignal, which does a similar matching for an
> integer signature in the slot, but it is not bound to another
> completely unrelated property, like KAction is with the object name.
>
> (ah, I just see that this is apparently a change that is new to KDE
> 3.1, so we could still revert it if we find a better solution, or?)
>
> Looking at the code I actually don't see a reason for it. I might be
> missing something (please correct me if wrong), but isn't the
> functionality that KAction tries to do in magic (and apparently
> fails under certain conditions) exactly what QSignalMapper solves as
> separate class, even more flexible (allows mapping using a string in
> addition to the int mapping) and well-documented?
>
> I mean, just from reading code it's more obvious to me what
>
> QSignalMapper *desktopNumberMapper = new QSignalMapper( this );
>
> connect( desktopNumberMapper, SIGNAL( mapped( int ) ),
>          this, SLOT( moveToDesktop( int ) ) );
>
> moveToDesktopAction = new KAction( .., desktopNumberMapper, SLOT( map() ),
>                                    actionCollection() );
>
> desktopNumberMapper->setMapping( moveToDesktopAction, 1 );
>
> does, than
>
> foob = new KAction( ..., this, SLOT( sendToDesktop( int ),
>                     actionCollection(), "sendToDesktop{1}" )
>
> Yes, the first example is more lines of code, but it's more readable
> IMHO and it's easier to analyze if you see the code for the first
> time. Especially as QSignalMapper has been introduced to exactly to
> solve problems like these, so the developer might already know about
> it. Whereas with the second example one has to read in the
> kaction.cpp sources that a special signature with an encoded number
> does the magic thing if provided in the Qt object name (something
> that is completely unrelated to the activation of actions) .
>
> Unless I completely miss the point I vote for reverting the change
> to the KDE 3.0 API. I'd be happy to take those steps and fix the
> applications relying on the magic object-name{42} behaviour, in case
> there is an agreement.

Had I been aware of QSignalMapper, I would have suggested that to the games 
coders originally instead of the current solution.  (It doesn't fail under 
any circumstances where the previous kaction would have worked, though.)  
I've CC'd this to one of the game developers so that he can give his input.

Cheers,
Ellis