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

List:       kde-core-devel
Subject:    RE: KActions...
From:       David Faure <David.Faure () cramersystems ! com>
Date:       2000-03-28 12:38:41
[Download RAW message or body]

> On Tue, 28 Mar 2000, David Faure wrote:
> 
> > Simon wrote:
> > > 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?
> > 
> > Well, this still uses sender() :-)))
> > What about doing it like you said for the highlight ?
> > Connecting to the container's signal (the one that gives an id)
> > and looking up the action of that id (using an intdict) ?
> 
> Well, the big problem is that the ids aren't unique within the
> application. They are unique in case of QMenuData, but this 
> clashes with
> KToolBar, because way KAction "calculated" IDs for KToolBar items is
> *exactly* the same as in QMenuData ( get_seq_id() ).

No no, I was thinking of container + id, not just id. Just like
we said for the highlight stuff - or was it a clone of you that forgot
to relay the information to the other clones ? :)

I don't understand why you want to treat activate() and highlight()
differently about this.

> I don't know, but perhaps the solution here is to use the
> getToolButtonId() method in kaction.cpp for both cases, when 
> plugging an action into a QPopupMenu and when plugging into a KToolBar.
> 
> That way we could rely on the fact that the id is unique and use a
> QIntDict for the highlighting and for the additional 
> activated signal of the actioncollection.

Unique ids would definitely help, that's for sure.
I'd rename the method though, so that it becomes the one and unique
method for getting a new id in the XMLGUI. Like getNextID.
But then we have to make sure we never use Qt's automatic ids.

> > > IMHO we should make this a configurable option (just like with the
> > > highlighting) .
> > Yes - but start thinking about a name for it, that's not an 
> > easy one. ;-)
> 
> You have good ideas? :-)

No :)

David.

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