GtkBuilder, docs examples, and glade differences and menuitem actions

I have been playing with Gtk 3 and have found differences in the way the documentation, examples and demos describe the UI if compared to the way glade creates it.

For instance, looking at this menubar.c demo example, it goes like this:

<interface>
  <menu id="menubar">
    <submenu>
      <attribute name="label">File</attribute>
      <section>
        <item>
          <attribute name="label">New</attribute>
          <attribute name="action">app.new</attribute>
        </item>
        <item>
          <attribute name="label">Quit</attribute>
          <attribute name="action">app.quit</attribute>
        </item>
      </section>
    </submenu>

And the glade result from my attempt looks like this:

<child>
  <object class="GtkImageMenuItem" id="mi_quit">
    <property name="label">gtk-quit</property>
    <property name="name">im-quit</property>
    <property name="visible">True</property>
    <property name="can_focus">False</property>
    <property name="right_justified">True</property>
    <property name="use_underline">True</property>
    <property name="use_stock">True</property>
    <property name="accel_group">accelgroup1</property>
    <property name="always_show_image">True</property>
  </object>
</child>

I realize it depends on how I do things in glade, but for this case, I just used a GtkMenuBar, and it created all that by default. Here’s the entire UI description for the window I am creating.

Why is glade generating so different UI description code if compared to the way docs and examples?

With that being said, I am struggling finding the proper way to make the quit menuitem (or any other menuitem) respond to click events.

Because Glade is a project with a long history, and it hasn’t always caught up with GTK when it comes to newer (or best) practices.

Glade generates menu descriptions in terms of GtkMenu and GtkMenuItem widgets; it used to support the (deprecated) GtkUIManager format for describing menus without widgets, but since that API has been deprecated in GTK2 and replaced by GMenu in GTK3, nobody has stepped up to work on making Glade use GMenu.

Using which approach? If you’re using GMenu, then I suggest you read the wiki, if you haven’t already.

Well, I’m not sure what approach I should use (hadn’t even realized there were multiple approaches). I have read lots of docs (and will continue dong that), but I can’t piece everything together as of yet. I’ll read the link you provided.

Other than that, I think I’ll give up Glade and write UI descriptions manually using gtk-builder-tool as you have suggested here.

Thanks a lot.

Using GtkBuilder is always recommended , especially once you start using widget templates and your own composite widget classes.

Well, the original thread is already closed :frowning:

Have just read a bit about these “widget templates”. My feeling is that they are most intended for gtk library authors writing in plain C? Or is support for “widget templates” expected from language bindings, and when yes, which bindings do provide good support? (I have to admit that for the high level Nim bindings I have no idea how I should support it – I assume it may be possible, but may be not easy.)

Generally I really hate the usage of C Macros in GTK. In Gtk – 3.0 it is G_DEFINE_TYPE_WITH_PRIVATE. These macros can make life hard for bindings authors. For the oldgtk3 bindings I tried to provide a few of these macros – I expanded them first, and then recreate them in Nim. Expanding and recreating by library call was not easy, but it was working and was used in my personal Nim editor GitHub - StefanSalewski/NEd: Plain GTK3-Sourceview based Nim editor with nimsuggest support. But oldgtk3 is obsolete now, and for the new gobject-introspection bindings there is no C macro support at all currently.

FernandoBasso, is there some progress on your site: What is the state of Glade, have you found tutorials or documentation. I have really bad memories about glade. But writing XML manually is no fun also.

After working on Nim bindings for 4 years now, I guess it is time to do some real app coding now, maybe convert my old unfinished Ruby tool Homepage of Dr. Stefan Salewski to Nim. So I have to do a decision builder or no builder.

And I wonder if GtkBuilder will work at all for dynamic apps where total number of widgets is not fixed, like GtkNotebook where we can open new pages and the new page has to be populated with new widgets. I assume that each widget from GtkBuilder can be used only once, so a GtkBuilder can never contain enough widgets for a GtkNotebook with basically unlimited pages?

No, widget templates are part of the default functionality of GTK—GTK itself uses them for all its composite widgets. Language bindings can use the provided API to implement support for them. For instance, Python and GJS support them.

Macros are for C developers, and by their own nature, they have to call public API. Language bindings developers typically write their own convenience for their languages, to make the API fit in with the language style and facilities.

The macros for C developers are there precisely because the language doesn’t offer any syntactic facility to make the code more compact or more readable—and they can be ignored entirely if you’re not writing in C. As a language binding developer, though, you must know how to use them, and to what they expand to, because those macros usually contain what the library developers consider to be best practices.

If your GtkNotebook gets populated at run time you should template each page with its own widget class, not the notebook itself. Though I’d contend that notebooks should never be dynamically populated, because after adding a handful of pages they become pointless, and should be replaced by a side bar bound to a stack.

2 Likes

I started the project in Python, didn’t like it very much (for several reasons which I don’t think are worth bringing up here), and rewrote it in C.

I have very little time to work on my Gtk project, and it will probably take long before I can have a more educated opinion about this entire subject and therefore I don’t know what to think of the situation right now. I have been using Linux since 2006, but have always been a full-stack web developer. Never wrote a desktop application before and my Gtk learning has been slow.

After my struggle with Glade vs the examples on the docs and @ebassi answer I decided ti rewrite my UI descriptions by hand. No problems so far, but as hinted, I’m in no position to make assessments about this.

I’ll take this opportunity to thank you all for always helping and answering my questions. Much appreciated!

There are many more options than C and Python for GTK :slight_smile: Indeed people liking C or Python can use Qt, Qt has main language C++, and I was told that Python support is good for Qt. But I am not aware of another language with full Qt support.

For GTK there are many bindings, see https://www.gtk.org/language-bindings.php

I started with Ruby in 2007, as I did really not liked plain C for desktops apps. C is OK for small microcontrollers, for linux kernel and maybe GTK libs. But Ruby support was not that great, slow GTK3 adaption, small outdated tutorial, bugs and no community. And while dynamically typed and interpreted languages like Ruby and Python are OK for small projects with a few hundred lines of code and no requirement for performance, I would not use Python or Ruby again in these days, there are so many better alternatives like Go, Rust, Nim, Julia, maybe D, Crystal, Zig, maybe Vala, but I think Vala is death.

I think D and Rust bindings are not bad. For my Nim bindings I don’t know how good they are already, we have some fine working examples, but not more.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.