1===== 2Goals 3===== 4 5The introspection project has two major goals, and a variety of more minor 6ones. 7 8 9Two level applications - C and <your favorite runtime> 10------------------------------------------------------ 11 12It makes sense to build many kinds of applications using (at least) two 13different levels and languages — one for the low level elements, interfacing 14with the OS and/or the hardware; and one for the high level application logic. 15C is good for graphics, multimedia, and lower level systems work. However, 16writing complex software in C is difficult and error-prone. A managed runtime 17such as `JavaScript <https://wiki.gnome.org/JavaScript>`__, Python, Perl, 18Java, Lua, .NET, Scheme etc. makes a lot of sense for non-fast-path 19application logic such as configuration, layout, dialogs, etc. 20 21 22.. note:: 23 24 To achieve this goal you need to write your code using GObject convention. 25 For more information about that, see the `GObject tutorial 26 <https://developer-old.gnome.org/gobject/stable/pt02.html>`__ 27 28Thus, one of the major goals of the GObject introspection project is to be a 29convenient bridge between these two worlds, and allow you to choose the right 30tool for the job, rather than being limited inside one or the other. With the 31introspection project, you can write for example a ClutterActor or GtkWidget 32subclass in C, and then without any additional work use that class inside the 33high level language of your choice. 34 35 36Sharing binding infrastructure work, and making the platform even more binding-friendly 37--------------------------------------------------------------------------------------- 38 39Historically in GNOME, the core platform has been relatively binding-friendly, 40but there are several details not captured in the C+GObject layer that 41bindings have needed. For example, reference counting semantics and the item 42type inside GList's. Up until now various language bindings such as Python, 43Mono, java-gnome etc. had duplicated copies of hand-maintained metadata, and 44this led to a situation where bindings tended to lag behind until these manual 45fixups were done, or were simply wrong, and your application would crash when 46calling a more obscure function. 47 48The introspection project solves this by putting all of the metadata inside 49the GObject library itself, using annotations in the comments. This will lead 50to less duplicate work from binding authors, and a more reliable experience 51for binding consumers. 52 53Additionally, because the introspection build process will occur inside the 54GObject libraries themselves, a goal is to encourage GObject authors to 55consider shaping their APIs to be more binding friendly from the start, rather 56than as an afterthought. 57 58 59Additional goals and uses 60------------------------- 61 62* API verification - Sometimes the API of a library in our stack changes by 63 accident. Usually by a less experienced developer making a change without 64 realizing it will break applications. Introspecting the available API in 65 each release of the library and comparing it to the last one makes it easy 66 to see what changed 67* Documentation tools - The tools written inside of the GObjectIntrospection 68 can easily be reused to improve that problem. Essentially; replacing 69 gtk-doc. We want to document what we export so it makes sense to glue this 70 together with API verification mentioned above 71* UI Designer infrastructure 72* Serialization/RPC/DBus 73