Re: Gtk::Builder and item id

[Christian Schoenebeck <schoenebeck linuxsampler org>]

On Dienstag, 7. November 2017 12:31:21 CET Daniel Boles wrote:
> The code in question won't have changed in GTK 3 to 4, though; the link
> just happens to be to master.

Exactly. This issue seems to be around for quite a while.

> The original syntax showed here is for GMenu style menus, which - I get the
> impression - are intended to be static and not change their text at
> runtime, so if I'm right, it would make sense that you can't get at the
> widgets that make up the menu, as that's an implementation detail.

I had the impression that Glib based menu models are the new "recommended" way 
to build up menus with Gtk Builder. And I cannot see any indication that one 
should not supposed to change the elements at runtime. Existing demos already 
change certain things of the Glib menu model at runtime, plus a real world 
application simply needs to be able to modify the model.

Anyway, I just patched the Gtk+ Builder parser so it accepts an "id" for items 
and now I can also query and change the menu items at runtime.

> However, reading
> https://mail.gnome.org/archives/gtk-list/2014-October/msg00036.html did
> make me wonder whether an <attribute> node (not attribute *attribute*) on
> the item might work. I didn't try it, though.

Does not make any sense to me, neither by looking at the Gtk+ builder code 
(which does not support that for items), nor from format design perspective.

The funny thing is that the current builder parser accepts IDs for almost any 
XML element, even for "section" elements, but not for "item" elements.

On Dienstag, 7. November 2017 09:29:18 CET Kjell Ahlstedt wrote:
> The gtk+ demos at https://git.gnome.org/browse/gtk+/tree/demos/gtk-demo
> contains the menus.ui file with <item> elements without ids, and the
> demo.ui file with elements such as
>
> |<object class="GtkMenuItem" id="open_item"> I don't know if that's how
>
> it's supposed to be, i.e. if you have to use GtkMenuItem when you want
> to get a pointer to the menu item from the GtkBuilder. |

You don't need Gtk::MenuItems for that, at least if you patch the Builder 
parser like I did:

        auto menuItemSplit = Glib::RefPtr<Gio::MenuItem>::cast_dynamic(
                uiBuilder->get_object("item-split")
        );
        menuItemSplit->set_label(
                (bSomeCondition) ? _("Some text") : _("An alternative text")
        );

However to be honest, I don't really care whether I use Gtk objects or Glib 
objects to build up menus. As an application developer I just would appreciate 
to see a clear statement in the API docs which one of the two approaches we 
*should* use, which is currently not the case.

Because you know, the main problem for application developers using gtk(mm) is 
that deprecated APIs are completely removed much faster unlike any other UI 
toolkit I know of. So I simply would like to avoid to write gtk(mm) 
replacement code now, which I would have to replace again in couple months.

On Dienstag, 7. November 2017 12:20:26 CET Chris Vine wrote:
> Quite a bit in gtk+-3.92 seems to be broken, which may not be too
> surprising given that it is the current development branch[1].  For
> example I have noticed that GtkPrintOperation doesn't work, which will
> be problematic for any program wanting to offer a print option.
>
> It is probably best to treat gtk+-4 as a work in progress.

Mja, if I knew that before ... I actually downloaded and compiled the entire 
gtkmm chain of libraries from the latest promoted "stable" Gnome release 
branch last week and ported our entire application code base to those newly 
designed APIs. :-/

However I start to think whether it really makes sense to continue with that 
set of library versions at this point. I mean I just fixed this menu issue by 
patching gtk+, but now I have numerous other interesting crashes on gtk+ level 
for actually very simple things.

So far the application window has not popped up on screen once yet. ;-)

CU
Christian