Hi, Let me see if I understand this correctly:
1. The Keys attached object supports _any_ key through the generic pressed and released signals and the event parameter that comes with them. 2. There are a couple of convenience signals for commonly used keys. You would like to add private API to allow for custom convenience signals to be added? I'll be honest: I don't like the idea of adding private API that isn't needed internally. I think the existing code could be be cleaned up a little bit and with a little bit of trickery I suppose any Qt::Key could have a convenience signal, of we create a dynamic meta object at library startup time. However I'm not sure how is worth the cost, unless we find a way to do it lazily. Simon From: Dmitry Volosnykh Sent: Friday, May 1, 2015 02:55 To: development@qt-project.org Subject: [Development] RFC: QtQuick. Custom keys support proposal. 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?
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
