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

List:       kde-core-devel
Subject:    Re: KApplication::cut()....
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2005-09-23 12:59:06
Message-ID: 200509231459.08184.hausmann () kde ! org
[Download RAW message or body]

On Friday 23 September 2005 15:02, Benjamin Meyer wrote:
> On Friday 23 September 2005 8:14 am, Simon Hausmann wrote:
> > On Friday 23 September 2005 14:04, Joseph Wenninger wrote:
> > > Hi !
> > >
> > > I don't think it really belongs to KMainWindow. What about a a
> > > KFramework (find a better name) class, which contains all those
> > > "global" convenience functions ? I guess there will be more of those in
> > > other classes too, which are not really associated with the class they
> > > are in ?
> >
> > Why bother with having those functions public at all? Most of the time
> > you just want to get the action object, and for those it definitely makes
> > sense to bind them to a mainwindow.
> >
> > Simon
>
> What functions something like this:
>
>    /**
>      * If the widget with focus provides a cut() slot, call that slot. 
> Thus for a
>      * simple application cut can be implemented as:
>      * \code
>      * createAutomaticCutAction(actionCollection());
>      * \endcode
>      */
>     KAction *createAutomaticCutAction(KActionCollection *collection) const;
>
>
> KAction *KMainWindow::createAutomaticCutAction(KActionCollection
> *collection) const
> {
>     return KStdAction::cut( this, SLOT( invokeEditSlot( SLOT( cut() ) ) ),
> collection );
> }

One reason against still having public cut()/copy()/paste() methods in 
KMainWindow is that unlike with KApplication people inherit from KMainWindow, 
and this way we always drag methods called cut()/copy()/paste() into their 
(class) namespace.


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