MirceaKitsune Posted October 1, 2017 Report Share Posted October 1, 2017 I'm being affected by a strange issue in the latest Git master of DarkRadiant which makes using DR nearly impossible. I've already opened a bug report about it, but since progress is slow for several months I thought I'd also put this here in case anyone sees it and has some extra ideas. http://bugs.thedarkmod.com/view.php?id=4524 DarkRadiant does not sense any keyboard commands. I can however use the mouse and click on buttons just fine. I'm using openSUSE Tumbleweed x64 / KDE desktop.This seems to change if I have a menu opened, which implies it might be a focus detection issue. For instance: If I select a brush then press escape to deselect it, nothing happens... but if I select a brush, click on a toolbar entry such as "File" and leave the menu open, then press escape, the brush does get deselected. I additionally noticed that if I run DarkRadiant from a console, I get the following messages printed which seem to be relevant: (darkradiant:10061): Gtk-CRITICAL **: IA__gtk_check_menu_item_set_active: assertion 'GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed (darkradiant:10061): Gtk-CRITICAL **: IA__gtk_check_menu_item_set_active: assertion 'GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed (darkradiant:10061): Gtk-CRITICAL **: IA__gtk_check_menu_item_set_active: assertion 'GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed (darkradiant:10061): Gtk-CRITICAL **: IA__gtk_check_menu_item_set_active: assertion 'GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed Quote Link to comment Share on other sites More sharing options...
MirceaKitsune Posted October 12, 2017 Author Report Share Posted October 12, 2017 (edited) Any suggestions on what I could try to debug this, please? I'm sorry if I'm being a little insistent: This is being a major issue for me, and the only thing keeping me from using DarkRadiant and working on FM's. What I find interesting is that if a menu is open, DarkRadiant does sense keyboard inputs in the 3D view... whereas if no menu is open, DarkRadiant ignores the keyboard. This leads me to believe that DR is triggering some GTK / wxWidgets error, inverting the verification on whether a menu is open or not: If no menu is open, DR thinks it is so it ignores inputs... whereas if a menu actually is open, DR doesn't see it so it processes inputs instead. Maybe DR is being tricked into seeing a selected menu when it starts up, which throws off (inverts) its ability to keep track of open menus? [EDIT 1] Ran a new test and noticed the following behavior: If I open another window such as the Surface Inspector, then click on that window to select it (any field or its background), keyboard shortcuts (such as the arrow keys to move or esc to deselect) work perfectly. However the moment I click in any of the viewports (2D or 3D) the keys stop working again. I can even hover the mouse cursor over those viewports after clicking the floating window... I just can't close this window or click in a viewport. Could this be a focus detection issue? [EDIT 2] Found a workaround as well as the apparent cause! The problem only happens when "Settings -> Map Files -> Open last map on startup" is enabled. If I tell DarkRadiant to not automatically open the previous map on start, I no longer get the frozen keys issue. Edited October 12, 2017 by MirceaKitsune Quote Link to comment Share on other sites More sharing options...
AluminumHaste Posted October 13, 2017 Report Share Posted October 13, 2017 I can't reproduce this error but I'm also on Windows. Quote I always assumed I'd taste like boot leather. Link to comment Share on other sites More sharing options...
MirceaKitsune Posted October 13, 2017 Author Report Share Posted October 13, 2017 I can't reproduce this error but I'm also on Windows. It likely has to do with the little window that pops up, which lets you know the map is loading and shows a bar of what has loaded so far; If DarkRadiant loads the last map on autostart, this window appears before the main DR window is spawned... if no map is loaded at startup however, the window appears later so it doesn't freeze the inputs. Just my theory at least, likely an issue with GTK for Linux or the KDE desktop. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.