[PATCH] New signal for KKeySequenceWidget

Allen Winter winter at kde.org
Tue Sep 4 14:50:12 BST 2007


On Thursday 23 August 2007 7:31:21 am Olivier Goffart wrote:
> Le mercredi 22 août 2007, Andreas Hartmetz a écrit :
> > First off, minimizing porting work at the cost of API quality is not a
> > priority for me.
> > The safest and most explicit API that I can come up with and that doesn't
> > require subclassing is this:
> >
> > public slots:
> > void denyValidation();
> >
> > signals:
> > validationHook(const QKeySequence &newSeq);
> >
> > It is very straightforward and you don't get tempted to do things you
> > should not be doing - i.e. changing the shortcut in response to the user
> > choosing a different one. Although you can still do exactly this if you
> > need to. Would this API also work in the given use case?
> 
> 
> Other possibilities:  (I'm not saying they are batter ;-) )
> 
> signals:
>  void validationHook(const QKeySequence &newSeq, bool *hook);
> 
> or even
> 
> signals:
>  bool validationHook(const QKeySequence &newSeq);
> 
> Yes, return value of slot is forwarded to the signal, although this is not 
> documented, I don't know why.
> I noticed this issue when porting to Qt4, because a slot did return a type 
> which Qt cannot handle, cosing compile error in the .moc
> 
Was your KKeySequenceWidget patch committed?




More information about the kde-core-devel mailing list