[Development] RFC: QtQuick. Custom keys support proposal.

[Dmitry Volosnykh]

There are some cases when non-standard keys should be handled. Remote
control units with custom key codes are the primary example. Existing Keys
QML type provides a handy means of processing specific key events only for
a small subset of Qt::Key enum, and that is true only for presses, not
release events.

Here I suggest patch that allows to extend the default set of key codes. It
heavily depends on newly added Q_ENUM macro which allows to completely drop
then need to keep internal table sigMap up to date. Unfortunately, there
seems to be no way to generate signal so that all the keys are provided
with specific handlers. So, we will still have to add them manually.
Getting the full list of signals should be a matter of playing with regular
expressions, though.

Another plus is that now implementations of keyPressed/Released handlers of
QQuickKeysAttached are merged into one auxiliary private function.

Adding new set of supported keys is a matter of inheriting
QQuickKeysAttached with Q_ENUM of custom keys declared which should be
registered with a protected member function provided for this purpose.
Next, a set of wanted specific signal should be listed under 'signals'
section of the class.

As for drawbacks, in order to let users inherit from QQuickKeysAttached we
need to mark it with Q_QUICK_PRIVATE_EXPORT -- this will break ABI as far
as I understand. QQuickKeyNavigationAttached is marked this way, already.
So there seems to be no contradiction. And, of course, it is required to
list private modules as your project dependencies.

Unfortunately, should have user chosen to use custom key handlers there is
no way to disable default Keys QML type. Even that it is discouraged to mix
both classes, this should not be a big problem which could be addressed via
documentation on this topic.

Since newly registered set of keys is searched for key in question prior to
the default keys from Qt namespace we can override default signals in
QQuickKeysAttached class thus effectively renaming a key. This feature may
come handy in some cases when RCU has domain specific buttons.

Diff of the patch and example of CustomKeys QML attached type may be viewed
here: https://gist.github.com/dvolosnykh/65819bca1693b0e82058

In case this change is welcomed, what branch should I target?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150501/2832fed4/attachment.html>