+1

It shouldn't require recompiling g-t to be able to _somehow_ open the inspector.

At the same time I'm wondering why we don't respect the standard means of opening it (that is, the hotkeys don't work, but we have a menu item that other apps don't).

(In reply to Egmont Koblinger from comment #1)
> At the same time I'm wondering why we don't respect the standard means of
> opening it (that is, the hotkeys don't work, but we have a menu item that
> other apps don't).

Because all key strokes should be passed to the terminal application. See commit 7a3d8e370f312a040544a28525ce149e69243221

Ctrl+letter and Ctrl+Shift+letter always generate the same byte. That's why all the hotkeys (e.g. Ctrl+Shift+N for new window) have this double modifier. So I can't see what's wrong with Ctrl+Shift+D or Ctrl+Shift+I opening the inspector.

When I added the code to disable the keys and install the menu item instead, there was no way to disable the inspector yet (now there's the gsettings key).

Also, I don't think the inspector is something any *user* requires, or even should be enabled to use, so disabling it by default with only a way to get it in a developer build seemed the best way for me.

Note that you can currently still get it if you start g-t-server yourself with the GTK_DEBUG=interactive (iirc) env var set.

I'd be ok with moving the menu item outside of the debug #ifdef and instead showing it iff the gsettings key is enabled.

The last time I tried GTK_DEBUG=interactive it didn't work for me (on non-debug g-t-s). But now it works :)

Oh yeah, I can recall it now.

Starting g-t-s with GTK_DEBUG=interactive does open an inspector window, however, it is useless. It only contains some global entries (a GtkSettings, and a TerminalApp with a GMenu), but nothing for the actual terminal windows.

In order to be able to inspect a window, you need to open the inspector after the terminal window has appeared, which is currently only possible via the menu entry in the debug build.