Jump to content


Photo

DarkRadiant won't sense any keyboard inputs

bug keyboard darkradiant input issue

  • Please log in to reply
3 replies to this topic

#1 MirceaKitsune

MirceaKitsune

    Advanced Member

  • Member
  • PipPipPip
  • 653 posts

Posted 01 October 2017 - 06:14 PM

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.thedarkm...iew.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


#2 MirceaKitsune

MirceaKitsune

    Advanced Member

  • Member
  • PipPipPip
  • 653 posts

Posted 12 October 2017 - 08:32 AM

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 by MirceaKitsune, 12 October 2017 - 09:28 AM.


#3 AluminumHaste

AluminumHaste

    Darkmod Contributor

  • Development Role
  • PipPipPipPipPip
  • 5886 posts

Posted 13 October 2017 - 04:56 PM

I can't reproduce this error but I'm also on Windows.

I always assumed I'd taste like boot leather.

 

#4 MirceaKitsune

MirceaKitsune

    Advanced Member

  • Member
  • PipPipPip
  • 653 posts

Posted 13 October 2017 - 06:21 PM

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.







Also tagged with one or more of these keywords: bug, keyboard, darkradiant, input, issue

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users