[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