Gtk::Builder and item id

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Gtk::Builder and item id

Christian Schoenebeck
Hi

in the course of porting our app to latest GTKMM 3.91.2 API(s), I encountered
some issues where I wonder whether those are GTK(MM) bugs or rather
intentional.

First of all, I replaced Gtk::UIManager code occurrences by Gtk::Builder code.
And for instance a popup menu which was previously constructed with UIManager
like this:

    uiManager = Gtk::UIManager::create();
    uiManager->insert_action_group(actionGroup);
    Glib::ustring ui_info =
        "<ui>"
        "  <popup name='PopupMenuInsideDimRegion'>"
        "    <menuitem action='SplitDimZone'/>"
        "    <menuitem action='DeleteDimZone'/>"
        "  </popup>"
        "</ui>";
    uiManager->add_ui_from_string(ui_info);

    popup_menu_inside_dimregion = dynamic_cast<Gtk::Menu*>(
        uiManager->get_widget("/PopupMenuInsideDimRegion")
    );

with Builder it now looks like this:

    uiBuilder = Gtk::Builder::create();
    Glib::ustring ui_info =
        "<interface>"
        "  <menu id='menu-PopupMenuInsideDimRegion'>"
        "    <section>"
        "      <item id='item-split'>"
        "        <attribute name='label' translatable='yes'>Split Dimension
Zone</attribute>"
        "        <attribute
name='action'>PopupMenuInsideDimRegion.SplitDimZone</attribute>"
        "      </item>"
        "      <item id='item-delete'>"
        "        <attribute name='label' translatable='yes'>Delete Dimension
Zone</attribute>"
        "        <attribute
name='action'>PopupMenuInsideDimRegion.DeleteDimZone</attribute>"
        "      </item>"
        "    </section>"
        "  </menu>"
        "</interface>";
    uiBuilder->add_from_string(ui_info);

    popup_menu_inside_dimregion = new Gtk::Menu(
        Glib::RefPtr<Gio::Menu>::cast_dynamic(
            uiBuilder->get_object("menu-PopupMenuInsideDimRegion")
        )
    );

Now the problem is, that add_from_string() throws the following exception:

        Attribute "id" invalid for element "item"

Is that a bug? If that is intentional, how should it be possible to query an
item object instead? Because we need to query menu items to change their label
at runtime like this:

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

Thanks!

CU
Christian
_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk::Builder and item id

Christian Schoenebeck
On Montag, 6. November 2017 15:38:32 CET Christian Schoenebeck wrote:
>     uiBuilder = Gtk::Builder::create();
>     Glib::ustring ui_info =
>         "<interface>"
>         "  <menu id='menu-PopupMenuInsideDimRegion'>"
>         "    <section>"
>         "      <item id='item-split'>"
[snip]
>         "      </item>"
>         "    </section>"
>         "  </menu>"
>         "</interface>";
>     uiBuilder->add_from_string(ui_info);
[snip]
> Now the problem is, that add_from_string() throws the following exception:
>
> Attribute "id" invalid for element "item"
>
> Is that a bug?

Ok, after reviewing the relevant Gtk+ code, the current Gtk Builder XML parser
clearly does not accept an "id" attribute for "item" elements:

        https://github.com/GNOME/gtk/blob/master/gtk/gtkbuilder-menus.c
        (Line 107) :

        if (COLLECT (G_MARKUP_COLLECT_INVALID, NULL))

 which contradicts to both, what the Gtk+ docs say, quote:

         "Objects may be given a name with the “id” attribute, which allows the
        application to retrieve them from the builder with
        gtk_builder_get_object()."
        ( https://developer.gnome.org/gtk3/stable/GtkBuilder.html )

as well as contradicts to the format's schema file:

        https://github.com/GNOME/gtk/blob/master/gtk/gtkbuilder.rnc
        (Line 58) :

        item = element item {
  attribute id { xsd:ID } ?,
                 (attribute_ | link) *
        }

But I guess I have to move this issue over to the Gtk+ list.

However I wonder if I am really the first one encountering this issue. I mean
it should be quite common to retrieve menu items at runtime. Or does that mean
other people are using a different approach by assembling menus with

        <object class="GtkMenuItem" id="foo">

format instead?

CU
Christian
_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk::Builder and item id

Kjell Ahlstedt-2
Den 2017-11-07 kl. 00:07, skrev Christian Schoenebeck:

But I guess I have to move this issue over to the Gtk+ list.
Yes, that's a good idea.
However I wonder if I am really the first one encountering this issue. I mean 
it should be quite common to retrieve menu items at runtime. Or does that mean 
other people are using a different approach by assembling menus with

	<object class="GtkMenuItem" id="foo">

format instead?
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.
CU
Christian



_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk::Builder and item id

Chris Vine-3
On Tue, 7 Nov 2017 09:29:18 +0100
Kjell Ahlstedt <[hidden email]> wrote:

> Den 2017-11-07 kl. 00:07, skrev Christian Schoenebeck:
> >
> > But I guess I have to move this issue over to the Gtk+ list.  
> Yes, that's a good idea.
> > However I wonder if I am really the first one encountering this
> > issue. I mean it should be quite common to retrieve menu items at
> > runtime. Or does that mean other people are using a different
> > approach by assembling menus with
> >
> > <object class="GtkMenuItem" id="foo">
> >
> > format instead?  
> 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. |

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.

Chris

[1] When gtk+-3.22 was frozen it was the stated hope that gnome
projects would switch to the unstable API leaving gtk+-3 for other
applications.  That hasn't happened - nothing in gnome-3.26 and (as far
as I can tell) gnome-3.27 uses the gtk+-4 branch.
_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk::Builder and item id

Daniel Boles
The code in question won't have changed in GTK 3 to 4, though; the link just happens to be to master.

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.

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.



_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk::Builder and item id

Christian Schoenebeck
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
_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk::Builder and item id

Daniel Boles


On 7 November 2017 at 14:52, Christian Schoenebeck <[hidden email]> wrote:

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. :-/

Well, 3 is the stable branch. I'm not sure GTK+ 4 was ever really on-topic here.



_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk::Builder and item id

Christian Schoenebeck
On Dienstag, 7. November 2017 14:59:05 CET Daniel Boles wrote:
> > 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. :-/
>
> Well, 3 is the stable branch. I'm not sure GTK+ 4 was ever really on-topic
> here.

Ok, I will revert my libraries back to an older version.

Just to get this really right this time; is the following set of library
versions considered to be the latest stable branch of gtk(mm) ?

http://ftp.gnome.org/pub/GNOME/teams/releng/3.22.2/gnome-suites-core-deps-3.22.2.modules

It sais i.e. gtk+ 3.22.3 and gtkmm 3.22.0.

I hope I can safe at least some work by only replacing gtk+ and
gtkmm, while retaining all other lib versions.

CU
Christian
_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk::Builder and item id

Daniel Boles
My point was that if you got GTK+/gtkmm from any official sources talking about a "stable" release, it would definitely have been talking about GTK+ 3 and not 4.

Perhaps the confusion is the chosen numbering for the GTK+ 4 development branch, which is currently being prereleased with version numbers of 3.9x.

Yes, 3.22 is the LTS version of GTK+ 3, i.e. the current stable version, and the last minor release within that.

See https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/

_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk::Builder and item id

Christian Schoenebeck
On Dienstag, 7. November 2017 15:42:09 CET Daniel Boles wrote:
> Perhaps the confusion is the chosen numbering for the GTK+ 4 development
> branch, which is currently being prereleased with version numbers of 3.9x.

That was exactly the cause! I was downloading all source files manually
(including all dependencies) from Gnome sources, which was exactly this
one:

        http://ftp.acc.umu.se/pub/GNOME/teams/releng/3.26.1/gnome-suites-core-deps-3.26.1.modules

And from there I saw no indication, neither that this was the new Gtk4 branch,
nor that it is (as far as I can see it now) completely unusable yet.

I had to download the tarballs manually because I decided to package all
libraries altogether (currently 25 libraries) as an Xcode framework, which
nobody had done before it seems. That allows you to simply drag that framework
into an gtkmm application project, and the entire chain of gtk(mm) libraries
compiles entirely from source in just 2 minutes, and if there is a bug in one
of the libraries, you can fix them within seconds, plus other advantages.

> Yes, 3.22 is the LTS version of GTK+ 3, i.e. the current stable version,
> and the last minor release within that.
>
> See
> https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-i
> n-gtk/

Ok, good to know, thanks! :)

CU
Christian
_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list