mirror of
https://github.com/TomHarte/CLK.git
synced 2024-11-25 16:31:42 +00:00
Provide current thoughts on Qt and the keyboard.
This commit is contained in:
parent
24b03f733f
commit
abe1e7f244
@ -768,10 +768,40 @@ void MainWindow::keyReleaseEvent(QKeyEvent *event) {
|
||||
bool MainWindow::processEvent(QKeyEvent *event) {
|
||||
if(!machine) return true;
|
||||
|
||||
// First version: support keyboard input only.
|
||||
const auto keyboardMachine = machine->keyboard_machine();
|
||||
if(!keyboardMachine) return true;
|
||||
|
||||
// Qt is the worst.
|
||||
//
|
||||
// Assume your keyboard has a key labelled both . and >, as they do on US and UK keyboards. Call it the dot key.
|
||||
// Perform the following:
|
||||
// 1. press dot key;
|
||||
// 2. press shift key;
|
||||
// 3. release dot key;
|
||||
// 4. release shift key.
|
||||
//
|
||||
// Per empirical testing, and key repeat aside, on both macOS and Ubuntu 19.04 that sequence will result in
|
||||
// _three_ keypress events, but only _two_ key release events. You'll get presses for Qt::Key_Period, Qt::Key_Greater
|
||||
// and Qt::Key_Shift. You'll get releases only for Qt::Key_Greater and Qt::Key_Shift.
|
||||
//
|
||||
// How can you detect at runtime that Key_Greater and Key_Period are the same physical key?
|
||||
//
|
||||
// You can't. On Ubuntu they have the same values for QKeyEvent::nativeScanCode(), which are unique to the key,
|
||||
// but they have different ::nativeVirtualKey()s.
|
||||
//
|
||||
// On macOS they have the same ::nativeScanCode() only because on macOS [almost] all keys have the same
|
||||
// ::nativeScanCode(). So that's not usable. They have the same ::nativeVirtualKey()s, but since that isn't true
|
||||
// on Ubuntu, that's also not usable.
|
||||
//
|
||||
// So how can you track the physical keys on a keyboard via Qt?
|
||||
//
|
||||
// You can't. Qt is the worst. SDL doesn't have this problem, including in X11, so this seems to be a problem
|
||||
// Qt has invented for itself.
|
||||
//
|
||||
// TODO: find a workaround. Platform-specific use of either nativeScanCode() or nativeVirtualKey() maybe,
|
||||
// but if so, how to interpret the meaning?
|
||||
|
||||
|
||||
#define BIND2(qtKey, clkKey) case Qt::qtKey: key = Inputs::Keyboard::Key::clkKey; break;
|
||||
#define BIND(key) BIND2(Key_##key, key)
|
||||
|
||||
@ -779,10 +809,6 @@ bool MainWindow::processEvent(QKeyEvent *event) {
|
||||
switch(event->key()) {
|
||||
default: return true;
|
||||
|
||||
// TODO: Qt factors in modifiers when deciding which key to declare has been pressed.
|
||||
// E.g. on my keyboard a shifted Key_Comma produces a Key_Less, not a Key_Comma and a shift.
|
||||
// Find a way to disable that, or else work around it here.
|
||||
|
||||
BIND(Escape);
|
||||
BIND(F1); BIND(F2); BIND(F3); BIND(F4); BIND(F5); BIND(F6);
|
||||
BIND(F7); BIND(F8); BIND(F9); BIND(F10); BIND(F11); BIND(F12);
|
||||
|
@ -4,7 +4,7 @@ Clock Signal ('CLK') is an emulator for tourists that seeks to be invisible. Use
|
||||
|
||||
[Releases](https://github.com/TomHarte/CLK/releases) are hosted on GitHub.
|
||||
|
||||
On the Mac it is a native Cocoa application; under Linux, BSD and other UNIXes and UNIX-alikes it can be built either with Qt or with SDL.
|
||||
On the Mac it is a native Cocoa application; under Linux, BSD and other UNIXes and UNIX-alikes it can be built either with Qt or with SDL; the Qt build should be considered preliminary, pending a sustainable workaround for its keyboard handling.
|
||||
|
||||
So its aims are:
|
||||
* single-click load of any piece of source media for any supported platform;
|
||||
|
Loading…
Reference in New Issue
Block a user