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

List:       kde-core-devel
Subject:    RE: KActions...
From:       Simon Hausmann <shaus () helios ! med ! Uni-Magdeburg ! DE>
Date:       2000-03-28 11:52:24
[Download RAW message or body]



On Tue, 28 Mar 2000, David Faure wrote:

> > On Tue, 28 Mar 2000, Simon Hausmann wrote:
> > > On Tue, 28 Mar 2000, Sven Radej wrote:
> > > > On Tue, 28 Mar 2000, Simon Hausmann wrote:
> > > > >On Tue, 28 Mar 2000, Sven Radej wrote:
> > > > >> Hi (Kurt)
> > > > >>
> > > > >> I have multiple [KToggle | KRadio]actions (setA, setB, setC), and I
> > > > >> donīt want to connect each action to its own slot - I want to
> connect
> > > > >> them all to one common slot which knows which action has been
> > > > >> activated, like slotABC(int ID).
> > > > >>
> > > > >> Question 1: How? I guess KActionCollection should also have signal
> > > > >> activated(const char *action_name) or activated (KAction *a).
> > > > >
> > > > >use sender() :-)
> > > >
> > > > Ummm...   shouldnīt there be some other way?
> > >
> > > Hmm, we use sender() quite often in konqueror for this purpose ;-) , and
> I
> > > admit that I like it (it's sooo handy :-)
> > >
> > > (or is it really considered to be a bad hack?)
> > 
> > It's quite dangerous. sender() never gets resetted (can't be 
> > done, because at the time where it could be resetted you could have 
> > already deleted the object (if you do e.g. a 'delete this' in the slot)). 
> > 
> > So if you e.g. call directly a slot and before that this slot 
> > was called by an object via a signal and this object has been already 
> > deleted, sender still points to this already deleted object and
> baaaaaaang!
> 
> Yes - but this doesn't happen here since actions are not deleted (at least
> not
> between the activation of an action and the slot being called - actions are
> only deleted
> when a window (or a part) is deleted). I agree, though, that we should try
> to avoid
> using it.
> 
> Simon, it seems to me that the suggestion above (adding a signal to
> KActionCollection)
> is matching exactly your idea for the highlighted stuff ? Those two signals
> would
> make a consistent solution IMHO.

Yes, I think so, too :)

Ok, so the actioncollection connects to the action's activated() signal,
uses sender() in the slot to determine the action and then emits
actionActivated( KAction *action ); , right?

IMHO we should make this a configurable option (just like with the
highlighting) .

Ciao,
 Simon

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