GNOME Bugzilla – Bug 698255
Request for GIR support
Last modified: 2018-03-26 15:29:06 UTC
Glade use an XML file to get access to widgets provided from other libraries based on GObject. In order to help others to get inmedate access to Glade pallete, Glade could gain access to GIR XML file from GObjectIntrospection, that file includes most of the information to access widgets defined in a library, including the reference to the library it self. Glade could scan GIR file to find objects derived from GtkWidget for example or any other one. The widget could be added using defaults and adding some custom xml files (or metadata a la Vala bindings) for get fine integration. Python plugin could be used to this. By reading the GIR file in the python plugin to iterate in all defined objects, you can use a Type check to find widgets to be added to Glade, because GObject Introspection / GIR objects can be loaded from python with no extra effort. Widgets could gain a "get_icon" method to help Glade to find the correct one, or just use default name location built-in feature in Glade (widget-CATALOG-GENERICNAME.png) installed in glade/pixmaps. Library developers can install required icons but not generated/update manually XML files for Glade when a new widget is added, just needs to generate GIR files and done (well add an icon to represent the widget is useful for pallet use).
Hi Daniel. First, yes we've wanted to support loading GIRs for a long time, but as you pointed out GIR is not by any means a replacement for our XML catalog, but rather a subset of the data we need to load widgets (and in many cases for third party widget collections, it's indeed enough). What we're mostly interested in for now, is a catalog updater tool that uses GIR, in other words, we would like to have a tool to update our GTK+ catalog for new versions of GTK+ automatically. It would have to: a.) Add the deprecated=True attributes to any newly deprecated classes, properties or signals b.) Add the since="$major.$minor" attributes for any newly introduced classes, properties or signals in the catalog xml c.) Add new widget class definitions to the catalog. Also, it's important to note that the Glade catalog xml is a sort of replacement for good bindings to Glade's GladeWidgetAdaptor model (actually, every <glade-widget-class> effectively subclasses and registers a new GladeWidgetAdaptor type, deriving from the appropriate adaptor for it's parent adaptor type). What would be nicer is if we could have: a.) No catalog files, but instead a collection of vala or javascript implementations of GladeWidgetAdaptor in the plugin directory b.) Load gir's as a detail of those adaptors, pulling out any relevant versioning information and deprecation information.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glade/issues/126.