GNOME Bugzilla – Bug 754115
org.gtk.Settings.Debug.enable-inspector-keybinding should default to false
Last modified: 2018-04-15 00:07:38 UTC
Created attachment 310027 [details] Patch changing the enable-inspector-keybinding default to false By default, the enable-inspector-keybinding key in the org.gtk.Settings.Debug schema is set to true. This hijacks Ctrl+Shift+D and Ctrl+Shift+I which is an extremely bad idea. In Firefox Nightly, for example, it means that Ctrl+Shift+I, rather than just opening the Firefox developer tools, opens the GTK+ Inspector as well, which *no one* (for some impressively-close-to-zero value of “no one”) is going to care about. In Inkscape, should it upgrade from GTK+ 2 to 3, I imagine it would mean that Ctrl+Shift+D would start opening a GTK+ Inspector as well as or instead of the Document Settings panel. Again, *no one* (for some not-quite-zero-but-oh-so-all-but value of “no one”) is going to care about that. If someone is wanting to develop and debug GTK applications, let them enable the inspector keybindings themselves, or add "inspect" to the GTK_DEBUG environment variable. Normal people should not have two good keyboard shortcuts which are used by some programs stolen away from them. GTK+ is not just a tool for GTK+ developers (I hope)—Real People want to use GTK+ applications too, and Real People will be utterly confused by things like the GTK+ Inspector, and confusion is bad. The default value of enable-inspector-keybinding should be changed to false. A default of true is a default of confusion, even more angry users, sorrow and poor usability. Workaround: $ gsettings set org.gtk.Settings.Debug enable-inspector-keybinding false I believe this would apply to 3.14.x and later.
It doesn't here, in this firefox 40.0 gtk3 build. If your nightly build behaves differently, then something must have changed for the worse in firefox, and you should go and complain to them.
@Matthias Clasen: it depends slightly on what is focused when you press it. It’s true of all applications, however; I maintain that such a debug keyboard shortcut simply shouldn’t exist for normal people, let alone *two*.
(In reply to Chris Morgan from comment #2) > @Matthias Clasen: it depends slightly on what is focused when you press it. > It’s true of all applications, however; I maintain that such a debug > keyboard shortcut simply shouldn’t exist for normal people, let alone *two*. Not exactly a convincing argument, considering that you complain about exactly such a debug keyboard shortcut not working (firefox's).
It’s a matter of how many people will want to do a thing. GTK+ application debugging is going to be comparatively rare, while web debugging is somewhat more useful and common, though still somewhat restricted in its audience. There’s also the difference in layer; Firefox is an application, while GTK+ is the framework. The framework should not tend to reserve key bindings beyond perhaps standard ones like Ctrl+Q. (I have tended to feel that the keyboard shortcuts should not be enabled in Firefox until someone has enabled it, but as I’ve indicated, I believe it’s a more reasonable thing there than in GTK+. And “they do it, so why shouldn’t we?” is typically a fairly weak argument in itself.) Consider also my example of things like Inkscape. Ctrl+Shift+I and Ctrl+Shift+D are not *enormously* common keyboard shortcuts, but they are both ones which are used, and ones which people may accidentally press, and having such a developer-oriented thing shown to the hapless, unsuspecting user is inherently undesirable.
commit 9326f1a57c52cc991b5756d1811155a25fe6623c Author: Matthias Clasen <mclasen@redhat.com> Date: Mon Aug 31 11:08:25 2015 -0400 Turn off inspector keybindings by default This is a 'developer mode' feature, and it can and does interfere with preexisting key bindings in some applications, so keep it off by default in stable releases, at least.
The inspector is an important feature to show developers. It should be possible for any developer potentially using GTK to open the inspector without first toggling weird settings. In recent times the inspector has in fact been one of the main selling points for why GTK is awesome - many people have used it in forums, on IRC or in real life - and so from a marketing perspective turning off the inspector is one of the worst things we can do if we want to attract new developers. Inkscape would also work fine because Inkscape would register another Ctrl-Shift-D shortcut that would override GTK's. You can easily see that in gnome-terminal, which does do that already. (I just closed my tab, dammit! Now my history is gone!) And I certainly don't buy the differentiation between framework and application because Firefox is a framework for web applications that has happily hijacked all sorts of keybindings, including the developer console. I don't care if it's a keybinding or different way (like a button in the about box or an entry in the window decorations right-click menu) to open the inspector, but I do care ver much that it is available in a running GTK application by default (ie without having to toggle settings elsewhere).
I definitely can see the argument for both. Occasionally I do outreach at universities and meetups and have the unique pleasure of introducing people to GNOME. These are mostly people that have an interest towards becoming a developer or computer engineer of some sort. Showing the inspector is one of the most captivating parts of our interactions. Peoples eyes light up when they have the ability to "dive into the system" and learn how, what they feel is the operating system, works. I do think it is useful to be able to trigger this feature without having to remember GTK_DEBUG=inspector and relaunch the program. On the other hand, I see the desired to not have it conflict with, say FireFox. Can we add API to disable internal keybindings? And then applications using Gtk3 for theming, such as FireFox and perhaps Libre Office can just call that function to disable it?
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new