[PATCH] New signal for KKeySequenceWidget

[Andreas Hartmetz]

On Tuesday 21 August 2007 17:42:11 Thomas McGuire wrote:
> Hi,
>
> On Tuesday 21 August 2007, Andreas Hartmetz wrote:
> > On Monday 20 August 2007 22:43:42 Thomas McGuire wrote:
> > > attached a patch which adds a new signal to KKeySequenceWidget. This
> > > signal is like the existing keySequenceChanged() signal, just with more
> > > parameters.
> >
> > I'd rather have a virtual validate() function that can be reimplemented,
> > see http://doc.trolltech.com/qq/qq13-apis.html#staticpolymorphism.
> > OTOH it could be argued that breaking static polymorphism (interesting
> > term) is worth it if not breaking it means too much of a hassle for API
> > users. Either side has a valid argument, so - anybody else want to
> > comment?
>
> I'd say the validate method is too much hassle for API users. That would
> mean to create a new class that inherits KKeySequenceWidget every time I
> use it. Furthermore, there is one place where KKeySequenceWidget is used
> inside an UI file, changing that would be even more inconvenient.
>
> So I vote for the new signal, because it minimizes porting work.
>

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?