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

List:       kde-core-devel
Subject:    Re: PATCH: Re: kdelibs/kdeui
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2002-01-31 9:27:04
[Download RAW message or body]

On Wed, Jan 30, 2002 at 12:03:31PM -0500, Ellis Whitehead wrote:
> There was a discussion in early November (while I was at the ALS conference 
> and not keeping up on the list), but in the end the only reason stated 
> against calling unplugAll() from ~KAction() was about not needing to make 
> those calls during shut-down. 
> http://lists.kde.org/?l=kde-core-devel&m=95846925315076&w=2
> 
> The safety and convenience is worth it, though, so that actions from a dynamic 
> widget can be used by a different persistent widget.  Without the unplugAll() 
> call in ~KAction(), attempts to handle this are very hacky.

The problem I see is rather that it's an imcomplete feature, that
can't be implemented the way it should be, ideally. The feature
makes people think that they don't have to worry about calling
unplug() anymore because the KAction destructor does it
automatically for them. And this is the point, it's wrong. So we
provide a feature that works only in the case that the raw KAction
can handle a certain container. It will not work in all other cases
(unless we duplicate code, and people writing own actions would have
to, too) . And even this very case (that the original KAction knows
how to deal with a certain container) is completely hidden to the
user of the action object, the one calling plug (after all that's
the whole point about the action concept :) .

In other words: There is no way for a user of KAction to figure out
when he needs to call unplugAll() on his own and when he can rely on
~KAction doing some work. Unlike QAction (which provides this
feature) in KDE there are quite a few classes derived from KAction.
Most of them even being in kaction.cpp :)


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