KActionCollection: it's a jungle

David Faure faure at kde.org
Mon Mar 19 09:24:30 GMT 2007


On Monday 19 March 2007, Andreas Hartmetz wrote:
> Am Montag, 19. März 2007 00:16:51 schrieb David Faure:
> > On Sunday 18 March 2007, Andreas Hartmetz wrote:
> > > Some are really amusing, like addDocCollection() whose documentation goes
> > > like that:
> > > "Doc/View model. This lets you add the action collection of a document to
> > > a view's action collection."
> >
> > Ellis started in that direction after getting requests from the KOffice
> > developers in particular, for support for the following use case (in kde3)
> > :
> >
> > In KOffice each a document can potentially have N views. Common design.
> > The document itself being a KParts::ReadOnlyPart, it has an action
> > collection. For instance, the undo/redo actions are (well, were) part of
> > the document. But an action wanted to know about one widget which would
> > receive keystrokes for that action, so having one action potentially
> > plugged into N mainwindows was troublesome. This is why Ellis added
> > addDocCollection, but I'm not sure the support for that was ever finished,
> > and in any case it was never used by koffice.
> >
> > All this being said, I indeed think it can be removed now, since Qt [and
> > kdeui] solve the undo/redo action issue differently (one can now create one
> > undo action per view, for the same undo history). Just providing some
> > context to explain why things are as they are ;)
> 
> You didn' read the whole thread, did you? :)
Well, I did, but I thought "why bugfix a feature if we don't need it".

However now that I think about it again, this sort of thing (the need to 
put all actions in the view) is quite limiting in the design of an app, so if
we can make it work it would be nice to have indeed.

> The current state of affairs is that it will be named "addOverlayCollection", 
> because that describes the actual service this function offers. 
"Overlay" reads strange to me. Sounds like transparency stuff ;)

> I can see the  
> use of this, even though it won't work right when the collection is added to 
> a KKeyChooser/KKeyDialog (which I'm working on ATM, so I know). If you  think 
> that the function will probably go unused, let's pull it. I don't care one 
> way or another.
> 
> [ ] keep
> [ ] pull

if (kkeychooser_bug->isFixable())
  keep()
else
  pull()

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).




More information about the kde-core-devel mailing list