[PATCH] New signal for KKeySequenceWidget

Olivier Goffart ogoffart at kde.org
Thu Aug 23 12:31:21 BST 2007


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

-- 
Gof
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070823/0b965de5/attachment.sig>


More information about the kde-core-devel mailing list