Re: Incorporating changes from bindings [was: Add GtkRadioGroup?]
- From: Philip Chimento <philip chimento gmail com>
- To: Tristan Van Berkom <tristanvb openismus com>
- Cc: gtk-devel-list gnome org
- Subject: Re: Incorporating changes from bindings [was: Add GtkRadioGroup?]
- Date: Wed, 10 Nov 2010 22:11:47 +0100
On Wed, Nov 10, 2010 at 17:49, Tristan Van Berkom
<tristanvb openismus com> wrote:
> On Wed, 2010-11-10 at 17:16 +0100, Philip Chimento wrote:
>> On Sun, Oct 31, 2010 at 11:28, Alexander Larsson <alexl redhat com> wrote:
>> > By the way, are there any other places where the java or C++ bindings do
>> > "cleanup" changes like this? Some may be interesting to push into the
>> > core now that we have the chance.
>>
>> I'd propose adding gtk_builder_get_widget_derived(), based on a method
>> in gtkmm [1]. This would make it much easier to use Glade when
>> subclassing widgets.
>>
>> [1] http://library.gnome.org/devel/gtkmm-tutorial/unstable/sec-builder-using-derived-widgets.html.en
>
> I've been cooking up something that might be close to what that API
> describes (for some months actually a while back, I just need to dust
> off the code and possibly automate the creation of properties which
> refer to child widgets etc)
>
> The general idea is that GtkContainerClass itself allows one to define
> content using an assigned GtkBuilder xml at the class level,
> implementing classes are composite widgets and a project can be
> comprised of several or many composite widgets all defined by
> GtkBuilder xml, reusable, practical etc (i.e. the way IMO
> GtkBuilder should really be used ideally).
>
> I brought it up most recently here:
> http://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00054.html
>
> And I would really like to land this stuff before 3.0 as well.
>
> Does that just about cover the use case ? or have I missed the point
> somehow ?
I think that covers it, although yours takes the concept much farther
than just porting that gtkmm function. I'm thinking of the common use
case of writing a MyAppMainWindow class that derives from GtkWindow.
The way it is now, in my_app_main_window_init() you open the ui file,
get the outermost non-toplevel widget from the builder (i.e. whatever
widget is contained by the window), gtk_container_add() that widget to
the window you're constructing, and then manually set all the
properties of the window that you would otherwise have set in Glade.
I'm not so fond of the gtkmm derived class having to have a certain
constructor either, but maybe this could be circumvented if the
derived class was required to implement GtkBuildable?
--
Philip Chimento
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]