Re: Template Widgets inside another GtkBuilder file

[Victor Aurélio Santos <victoraur santos gmail com>]

I compiled now with gmodule-export-2.0.pc the symbols get exported:

nm -g build/src/ajami | grep '_get_type'
[...]
0000000000429b30 T hv_meter_get_type

but when I try to launch I get the same error:
(ajami:30289): Gtk-CRITICAL **: Error building template class
'AjamiMainWindow' for an instance of type 'AjamiMainWindow': Invalid
object type 'HVMeter' on line 2

Thanks ;)

2015-10-04 6:56 GMT-03:00 Tristan Van Berkom <tristan upstairslabs com>:
> On Sat, Oct 3, 2015 at 10:14 AM, Victor Aurélio Santos
> <victoraur santos gmail com> wrote:
> > How can I do that ?
> > Just build all together results in this warning:
> >
> > >  (ajami:3475): Gtk-CRITICAL **: Error building template class
> > > 'AjamiMainWindow' for an instance of type 'AjamiMainWindow': Invalid object
> > > type 'HVMeter' on line 2
> >
> >
> > I've asked on SO[1] and got only one answer.
> >
> > I stick at "_get_type" workaround/hack but I didn't like it and I
> > can't do the same thing in Vala (I've not found how to do the same
> > thing).
>
>
>
> Hello Victor,
>
> The regular way to do this is in fact to compile your app with
> gmodule-export-2.0.pc
>
> I.e. adding `pkg-config --libs gmodule-export-2.0` to your link stage (using
> autotools you
> would just add gmodule-export-2.0 to your regular pkg-config m4 macro
> invocations).
>
> This indeed makes your applications global symbols visible so that they can
> be found using dlsym() on unices and other methods on other platforms.
>
> Regarding the comment on the SO post, the deriving of the _get_type()
> function by the type name is not considered a heuristic but rather it is a
> standard, which is at least enforced in any code written in the last decade
> or so by way of the G_DEFINE_TYPE() macros (vala generated types will also
> comply with this standard). So, if you have a type which is named FooBar,
> and it's low level GType accessor is not correctly named foo_bar_get_type(),
> it is in fact the application/library code declaring the type which is at
> fault for not complying with this.
>
> Granted, one can argument that documentation in this area is weak. Any other
> methods provided in GtkBuilder (such as overridable get_type_from_name()
> virtual methods) are specifically targeted at language bindings which need
> to resolve the type in other ways.
>
> With all that said, it could be plausible to create some tooling perhaps
> which parses your builder files at compile time, perhaps generating a
> resource to be compiled into your app which could be automatically inspected
> at gtk_init() time, to automate the process of initializing the required
> types - and removing the requirement of exporting your symbols in the
> regular way - that's one approach I can imagine anyway, perhaps there are
> others, there would have to be interest and someone would of course have to
> write that code :)
>
> I hope this clarifies the situation a bit more for you.
>
> Best,
>    -Tristan



-- 
Victor Aurélio Santos