Testing Glade files

I often edit Glom’s .glade files by hand instead of using Glade (though that should get better now that we have a GtkSourceView catalog for Glade, and that Openismus is paying Tristan to do a little cleanup in Glade). But I often make mistakes, so I added some tests. These run when doing “make check”, for instance during “make distcheck”, thanks to the autotools’ lovely built-in features.

Here are links to the two tests, in case it’s useful to anybody else. Maybe other people have other useful tests?

  • Check the glade files for validity (a Glade DTD would make this even better if someone can finish it)
  • Check instantiation: Check that all top-level windows and dialogs can be instantiated and check that none have visible=true.?
    This is C++, with libxml++ and gtkmm, but it’s simple.
    It would need slightly cleverer code to get secondary top-level objects such as GtkAdjustments and GtkTreeBuffers, because gtk_builder_add_objects_from_file() fails unless you specify secondary objects explicitly. But we avoid using these in Glom, because it’s easy to break the code at runtime when one is added to the .glade file, and it’s less of a problem now that Glade doesn’t create them when the default values would be acceptable. Another workaround is to put all windows in their own .glade file, but that makes it hard to work with them all together in Glade.

3 thoughts on “Testing Glade files

  1. Hey,

    May I ask a question to a glade expert ?
    Is it possible with Gtk(Builder) to instanciate the same Glade-generated window multiple times?
    I can’t manage to do it since every window since to be uniquely identified, but I may have missed

    1. > Is it possible with Gtk(Builder) to instanciate the same Glade-generated window multiple times?

      Yes, though instantiation happens when you create the GtkBuilder object, or use gtk_builder_add_objects_from_file() on it. get_object() just gets the already-instantiated widget, and of course returns the same one if called again.

      I guess that should be explicitly stated in the documentation:

Comments are closed.