[PATCH] New signal for KKeySequenceWidget

[Thomas McGuire]

Hi,

On Wednesday 22 August 2007, Andreas Hartmetz wrote:
> On Tuesday 21 August 2007 17:42:11 Thomas McGuire wrote:
> > 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?
Yes, that looks like it would work.
Only thing that is needed is that validationHook() should only be emitted when 
the shortcut is changed by the user, not when it is changed programmatically 
by using setKeySequence(). Or add a "bool programmatically" to the signal.
The reason is that in KMail, we don't want to show the validation dialog if 
the shortcut has been set programmatically.

OK, I'm awaiting the implementation now so I can port the KMail code.

Thanks,
Thomas