GNOME Bugzilla – Bug 646734
Add gobject-introspection catalog generation
Last modified: 2018-03-26 15:19:21 UTC
This is the firt (public) iteration of a patch adding introspected library support to glade editor. Basically, GtkWidgets from introspected libraries are usable in Glade "for free". To tryout GIR catalog generation, add your typelibs directory to glade catalog search path, ex. : GLADE_CATALOG_PATH=/usr/lib64/girepository-1.0 glade Gtk namespace is ignored by default, as we use a XML catalog for it. This patch is rougth around the edge: g_prints, memory handling and indent might need some work. Also, the XML parsing codepath was modified, so regressions must be hunted. Questions arrised: - caching ? - priorization ? XML over GIR ? - what icons to use ? Generating from offscreen pixmaps ?
Created attachment 185132 [details] [review] Add gobject-introspection catalog generation This patch add the support for multiple GladeCatalog parsers. The existing XML parsing code was isolated in GladeCatalogsXmlParser. A parser using gobject-introspection data was added. This provides a catalog entry for each introspected library declarating a GtkWidget instanciatable subclass. Introspected widgets libraries will be usable from Glade editor "for free". Add GladeCatalogsLoader class, responsible for iteration over the catalogs search path and invoking the right parser for each file. Add GladeCatalogsParser interface: base interface for catalogs' parser Add GladeCatalogsXmlParser: parser responsible for XML catalog parsing. Reuse refactored existing code. Add GladeCatalogGirParser: parser responsible for the creation of GladeCatalog instances from gobject-introspection data.
Hi. Your patch seems to touch many files that it probably should not. Is your patch properly based off of master when generating the diff ? Anyway... we've been interested for some time to generate catalogs from girs, most particularly... we are interested in updating current catalogs from girs. The most important feature here is that we should have a program 'glade-catalog-update' or such that can be used for the following cases: a.) Most importantly, the program should be able to take an updated gir and assign all the 'since="3.0"' portions for signals, properties and widgets b.) It should have command line options so that only versions will be updated and new widget classes wont randomly be showing up in the catalog (and an option that generates the new entries is fine, but will probably be seldom used). c.) It can also be used to generate a whole catalog for end users for their own widget catalogs that they want included in Glade, for this it should also take command line arguments, such as what object classes should be included in the resulting Glade catalog. For the record, Glade will not load objects into the palette by reading a gir, implementing a dual standard in Glade to load widget adaptors from girs AND from XML is a dual standard that I cannot afford to maintain. If anything, some trick can be played to generate the xml from the gir at Glade's startup time and then Glade use that generated xml to load catalogs as normal. Thanks for opening a bug and looking into this.
(In reply to comment #2) Hi Tristan, Thanks for your feedback ! > Hi. > > Your patch seems to touch many files that it probably should not. Definitely this patch modifies a lot of files, not sure those arent required. Lets be specific, here is the detail, feel free to comment. configure.ac | 1 + Add gir pkg-config check gladeui/Makefile.am | 4 + Add the new sources gladeui/glade-app.c | 53 ++- Makes GladeApp instanciate the catalog loader and register parsers. Also the catalog search path parsing was moved there. gladeui/glade-catalog.c | 690 +++++----------- gladeui/glade-catalog.h | 55 +- Extract the XML parsing logic, add some setters to be able to modify its state from the parsers. gladeui/glade-catalogs-gir-parser.c | 314 +++++++ gladeui/glade-catalogs-gir-parser.h | 72 ++ New files, GIR parsing logic gladeui/glade-catalogs-loader.c | 343 ++++++++ gladeui/glade-catalogs-loader.h | 79 ++ New files, iterate over the seach path entry, and call the right parser for each file. gladeui/glade-catalogs-parser.c | 56 ++ gladeui/glade-catalogs-parser.h | 60 ++ New files, base interface for catalog parsers. Should be renamed GladeCatalogParser. gladeui/glade-catalogs-xml-parser.c | 1645 +++++++++++++++++++++++++++++++++++ gladeui/glade-catalogs-xml-parser.h | 74 ++ New files, contain all catalog XML parsing logic extracted elswhere. gladeui/glade-project.c | 47 +- Modified due to a change making the catalog property of an adaptor a reference to a GladeCatalog object instead of a copy of its string name. This change is unrelated to the current bug, and will be absent in the next revision of the patch. gladeui/glade-property-class.c | 811 +++++++---------- gladeui/glade-property-class.h | 59 ++- Extract the XML parsing logic, add some setters to be able to modifiy its state from the parsers. Rework of the gtype intropected and parsed properties merging process. gladeui/glade-signal-class.c | 80 ++- gladeui/glade-signal-class.h | 16 +- Extract the XML parsing logic, add some setters to be able to modifiy its state from the parsers.Rework of the gtype intropected and parsed signals merging process. gladeui/glade-widget-adaptor.c | 1420 ++++++++++-------------------- gladeui/glade-widget-adaptor.h | 63 ++- Extract the XML parsing logic, add some setters to be able to modifiy its state from the parsers. So yeah, glade-project shouldn't have been changed. Will fix that. > Is your patch properly based off of master when generating the diff ? No sure I rebase to master since last week, will fix that too. > > Anyway... we've been interested for some time to generate catalogs from > girs, most particularly... we are interested in updating current catalogs > from girs. That would indeed be an handy tool. I'll give that a try when I'll have some free time. But IMHO its purpose is orthogonal to the proposed patch and is a first step toward making gir the common ground for GObject development. > > The most important feature here is that we should have a program > 'glade-catalog-update' or such that can be used for the following > cases: > > a.) Most importantly, the program should be able to take an updated > gir and assign all the 'since="3.0"' portions for signals, properties > and widgets > > b.) It should have command line options so that only versions will be > updated and new widget classes wont randomly be showing up in the > catalog (and an option that generates the new entries is fine, but > will probably be seldom used). > > c.) It can also be used to generate a whole catalog for end users for > their own widget catalogs that they want included in Glade, for this > it should also take command line arguments, such as what object classes > should be included in the resulting Glade catalog. Regarding c), the propsed patch offer a solution not requiring intervention, nor from widget devs, nor from glade devs and nor from the user. > > For the record, Glade will not load objects into the palette by reading a gir, Sounds like a definite answer, I hope I might convince you sometime :) Loading from gir has many many advantages: For Glade devs: - lower the maintaining cost by removing the need to keep the xml catalogs in-sync - certitude that the loaded widgets are actually installed on the system => removal of the logic checking for "missing" widgets - support new widgets/signals/properties for free: profit.Honestly, I dont see many widgets libraries offering xml catalogs. For Widgets developers: - support of its widgets with additional work. For the user: - no more "missing" widgets - installed libraries widgets appear "magically" in its palette. This patch uses typelibs, not gir, but that a detail, the only difference being that the user do no need to install the -devel package for its widgets libraries. > implementing a dual standard in Glade to load widget adaptors from girs AND > from XML is a dual standard that I cannot afford to maintain. My employer, Igalia, is interested in having webkit-gtk WebView present in the glade palette, so I am pretty sure they are fine with me maintaining the gir parser, if that might help. To avoid the "double standard" you refer to, a common ground can be found: - making the GIR loading the default, then augmenting the widgets/properties/signals/default values/packing defaults/ from what can be found in the XML catalog if an entry matches. or - letting plugins register CatalogParser implementations, and make CatalogGirParser a plugin, maintained outside the glade tree. > If anything, some trick can be played to generate the xml from the gir at > Glade's startup time and then Glade use that generated xml to load catalogs > as normal. Sounds a bit hacky, and the gir (xml) arent always installed on the user system. Opinions ? Thanks for your answer, happy coding, Alexandre
-- 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/85.