User: Password:
Subscribe / Log in / New account

Clasen: Introducing GtkInspector

Clasen: Introducing GtkInspector

Posted May 18, 2014 21:46 UTC (Sun) by HelloWorld (guest, #56129)
In reply to: Clasen: Introducing GtkInspector by rleigh
Parent article: Clasen: Introducing GtkInspector

GObject has become much better in that regard through GObject Introspection. In fact my impression is that Qt (and QObject-based libraries in general) could really use something like that.

(Log in to post comments)

Clasen: Introducing GtkInspector

Posted May 19, 2014 0:48 UTC (Mon) by sandsmark (subscriber, #62172) [Link]

I'm not sure exactly what you're referring to, but are you familiar with QMetaObject?

Clasen: Introducing GtkInspector

Posted May 19, 2014 4:03 UTC (Mon) by tetromino (subscriber, #33846) [Link]

> I'm not sure exactly what you're referring to

GObject introspection generates a description of a GObject-based API from C code comments. The result is output in the form of XML (for ease of parsing) or a binary format (for speed) and is used for automatic language bindings - currently, the main users are vala, python, and javascript. It's much more powerful than the typical ffi setup because it provides not just the C function signature but a vast amount of semantic information. The function's signature would only tell you that argument 1 is a pointer to struct foo, so is the return value, parameter 2 is an integer, and parameter 3 is a function pointer. But GObject introspection would inform you that parameter 1 is an out-parameter in the form of an array of struct foos which must be allocated by the caller (with the number of elements supplied in argument 2) and is filled in by the called function; that parameters 1 and 3 are optional and you can safely pass in NULL if you don't want them; that the return value must not be deallocated by the caller; that parameter 3 is a callback which will be called asynchronously, but only once (at which point resources associated with the callback can be freed); that the function was introduced in library version 1.2, was considered to be unstable API, had been deprecated since 1.16, and in languages which support function overloading, it makes sense to rename it to bar().

Does Qt have some equivalent of this?

Clasen: Introducing GtkInspector

Posted May 19, 2014 8:54 UTC (Mon) by jospoortvliet (subscriber, #33164) [Link]

This has been in Qt forever, from what I understand. See google:

And of course, the SMOKE bindings allow writing a GTK hello world app in Qt:


Clasen: Introducing GtkInspector

Posted May 19, 2014 13:19 UTC (Mon) by kigurai (subscriber, #85475) [Link]

But is there anything in place so that this information can actually be used in an automated fashion?

Currently I can start a Python shell and do

>>> from gi.repository import GtkSource

and now I can natively make calls to the GtkSourceView library using a Pythonic interface.
And the same would go for JS, or any language for which a GObject introspection functionality exists.

When I've looked at programming with Qt, I've gotten the impression that all the Python interfaces are "handcrafted" in some sense. But maybe I'm wrong on this.

Still GIR is a really nice concept that I wish was more common.

Clasen: Introducing GtkInspector

Posted May 19, 2014 13:27 UTC (Mon) by sandsmark (subscriber, #62172) [Link]

Language bindings for KDE libraries (and some other libraries, though it was made by KDE and is therefore most popular there) are made by SMOKE/smokegen automatically. It has been around for a while now. It doesn't require you to do anything at runtime though, as it seems like the GObject introspections does?

Clasen: Introducing GtkInspector

Posted May 19, 2014 13:59 UTC (Mon) by kigurai (subscriber, #85475) [Link]

Hmm, I could not really make sense of the documentation of that page.
But, to met still seemed like you
1) Have to write a lot of SMOKE specific code, and
2) have to do this for every language binding?

But, as I said, the documentation was not really clear to me.

With GIR, the introspection file is created once for each library, and the GIR mechanism is created once per runtime (Python, JS, ...).
And yes, it means doing things at runtime, but I have not noticed any overhead when using the Python GIR module.
For compiled languages I am guessing you would simply call into the C-library anyway?

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds