View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0007163 | ardour | bugs | public | 2016-12-09 07:54 | 2020-09-28 16:08 |
Reporter | ventosus | Assigned To | |||
Priority | high | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 5.5 | ||||
Summary | 0007163: KeyRelease events destined to embedded LV2 X11 plugins are eaten by Ardour (and suil) | ||||
Description | KeyRelease events destined to embedded LV2 X11 plugins are eaten by Ardour. Toggling the fancy button on the top right makes no difference (apart from letting some additional KeyPress events through, e.g. space). This makes plugin UIs needing to be notified about KeyRelease of special keys (e.g. Shift, Control, ....) totally unusable. E.g. imagine a rudimentary text editor which enters selection mode after writing a capital letter and can never exit selection mode again :( There are actually at least two bugs involved here. One I've already found and reported in suil (http://dev.drobilla.net/ticket/1149). My patch for suil fixes the issue in jalv.gtk* (which is having the the very same problem for X11 UIs embedded in GTK). In Ardour the problem persits, though, it therefore seems to drop KeyRelease events at an earlier point (even before vanilla suil will drop it itself) | ||||
Steps To Reproduce | * Apply referenced patch to suil * Listen for KeyPress and KeyRelease events in an embeddable LV2 X11 plugin UI and you'll see that KeyPress will reach the UI but not a single KeyRelease will ever reach the plugin UI. | ||||
Tags | No tags attached. | ||||
|
0001_fix_missing_key_release_x11_lv2_ui.patch (1,257 bytes)
diff --git a/gtk2_ardour/ardour_ui.cc b/gtk2_ardour/ardour_ui.cc index 783510977..d5f8cfaf5 100644 --- a/gtk2_ardour/ardour_ui.cc +++ b/gtk2_ardour/ardour_ui.cc @@ -5536,15 +5536,14 @@ ARDOUR_UI::key_event_handler (GdkEventKey* ev, Gtk::Window* event_window) Gtkmm2ext::Bindings* bindings = 0; Gtk::Window* window = 0; - /* until we get ardour bindings working, we are not handling key - * releases yet. - */ - - if (ev->type != GDK_KEY_PRESS) { - return false; - } - if (event_window == &_main_window) { + /* until we get ardour bindings working, we are not handling key + * releases yet. + */ + + if (ev->type != GDK_KEY_PRESS) { + return false; + } window = event_window; diff --git a/gtk2_ardour/plugin_ui.cc b/gtk2_ardour/plugin_ui.cc index 15600772e..d243ea66c 100644 --- a/gtk2_ardour/plugin_ui.cc +++ b/gtk2_ardour/plugin_ui.cc @@ -425,17 +425,7 @@ PluginUIWindow::on_key_press_event (GdkEventKey* event) bool PluginUIWindow::on_key_release_event (GdkEventKey *event) { - if (_keyboard_focused) { - if (_pluginui) { - if (_pluginui->non_gtk_gui()) { - _pluginui->forward_key_event (event); - } - return true; - } - return false; - } else { - return true; - } + return on_key_press_event(event); } void |
|
I've tried to find the spot where KeyRelease events are gone missing in Ardour. The attached patch fixes the issue for me. It may well break other things as I don't know the code. At least it should give a potential developer a heads up where to look... My moony plugin [1] can be used as test case. It embeds a simple code editor which is useless without proper KeyRelease events for e.g. Shift and Control. Write a single capital letter and the editor will be stuck in selection mode forever (it supports Shift + Arrow keys for keyboard-only selections). [1] https://dl.open-music-kontrollers.ch/moony.lv2/unstable/ |
|
seems fixed, sorry, totally forgot about it. |
Date Modified | Username | Field | Change |
---|---|---|---|
2016-12-09 07:54 | ventosus | New Issue | |
2016-12-19 20:39 | ventosus | File Added: 0001_fix_missing_key_release_x11_lv2_ui.patch | |
2016-12-19 20:43 | ventosus | Note Added: 0019175 | |
2020-09-28 16:08 | ventosus | Status | new => closed |
2020-09-28 16:08 | ventosus | Resolution | open => fixed |
2020-09-28 16:08 | ventosus | Note Added: 0025072 |