GNOME Bugzilla – Bug 740983
Allow plugins for Gtk Inspector
Last modified: 2014-12-09 21:54:10 UTC
I wrote a gjs based interactive tab for the Gtk Inspector: https://github.com/alexlarsson/gjs-inspector This can't be part of Gtk+ for natural reasons, so i made it possible to extend GtkInspector using GIOModules.
Created attachment 291891 [details] [review] Inspector: Support extending the inspector using GIOModules This allows external modules to add a page to the Gtk Inspector.
personally, I prefer a module loading approach to a direct dependency. linking GTK+ with mozjs via gjs would make GTK+ builds suddenly fairly sizable — definitely unsuitable for minimal environments, and adding a configure switch would imply we tested the reduced build, which I don't believe will happen. we would also need to avoid the indirect dependency on libstdc++ — basically, wrapping the C++ entry points of mozjs in GJS, and using the C linker. I did that for the Xapian (a C++ library) GLib bindings, and Behdad did that for harfbuzz, but it's not really trivial, and would require more maintenance efforts spent in the direction of GJS. the interaction of a GJS-powered inspector running against an application written using Python/Perl/whatever is also a sizable unknown.
We could still keep the gjs-inspector module in the gtk tree, I guess, just not link it into libgtk.
Matthias: Isn't that a circular dependency though? Gjs has an (optional) dependency on gtk.
Another alternative is to ship the gjs-inspector module with GJs.
yeah, you'd have to have a --disable-gjs configure flag and use it to break the cycle for bootstrapping
Just a few things I wonder. Imagine somebody implements the same extension point for an interactive python repl. Do we expect them both to show up in the UI ? will they both be called "Interactive" ? Do we need a way to disable or choose individual extensions ? When trying this, I get a few warnings like <interactive>:1:strict warning: reference to undefined property imports.gi resource:///org/gnome/gjs/modules/overrides/GLib.js:258:strict warning: reference to undefined property this.Variant It would be really helpful to have completion in the entry. Do you think a box full of labels is the best way to represent history ? Wouldn't a text view be more natural ? You could select and copy the whole thing then, not just individual lines...
Yeah, not sure about the multiple extensions. It would depend on what they did. Having several repl would be kind of weird, and also problematic (due to the at-most-one-toggle-ref issue). We could have a specifically named extension for that where we only pick one repl i guess. I'm not sure we would actually get multiple repls though. For apps written in e.g. python i'd think you get a python repl some other way than the inspector. The warnings seem to be from gjs itself, not sure about the exact reason, or why they don't show up in other gjs code. Completion is tricky, you would have to parse the js code and figure out what to expand to. Christian, you did some research into this, right? As for the history, yeah, you might be right. And additionally, we should probably show the commands that you typed in the history list too.
(In reply to comment #8) > Completion is tricky, you would have to parse the js code and figure out what > to expand to. Christian, you did some research into this, right? The kind of completion I would expect is for existing properties / functions of objects - no need to parse js for that , I hope ? isn't that what introspection was invented for ?
(In reply to comment #8) > The warnings seem to be from gjs itself, not sure about the exact reason, or > why they don't show up in other gjs code. Are you seeing the same warnings ?
Completion with JS is tricky for two major reasons. 1) When you need to complete something, you almost definitely do not have a valid parse tree. 2) You have to guess scoping and use conventions to determine what types things are (based on previous parse tree's due to 1). That said, https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Parser_API seems useful. We can try to guess gobject introspection information based on imports and assignments. Probably easier for a REPL than for a full blown text editor where you write OO styled code.
I mean something in the style of the completion you get in gnome-shell's looking glass.
I switched master to use a GtkTextView. I also imported the gnome-shell completion. Its not great, but it completes some stuff at least. I think the problem is that all the introspection data is resolved lazily, so completion only lists whats been used so far, or something.
And yes, i see the warnings too. I hacked around it in master.
Comment on attachment 291891 [details] [review] Inspector: Support extending the inspector using GIOModules Attachment 291891 [details] pushed as 2d6ae59 - Inspector: Support extending the inspector using GIOModules
pushed this, since I think it is pretty cool. A few things would make it even cooler: - Make the picker button visible on the interactive tab, and inject the picked object into the entry - Allow backrefences to the previously evaluated expressions, like looking glass does with r(n)
may not be super-easy to do with the extension point approach, unless you make the extension point provide the header bar button, I guess
Latest gjs-inspector has picker injection and backreferences
cool