[PATCH] New signal for KKeySequenceWidget

[Andreas Hartmetz]

On Thursday 23 August 2007 13:31:21 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 guess that is because a signal can possibly have many recipients - it is not 
*exactly* the same thing as a callback.
In this case could have several validators each with the possibility to "veto" 
a change.
Both problems and advantages of return values for signals are unclear, so I 
don't really care.