Re: GtkBuilder status

[Johan Dahlin <johan gnome org>]

Dan Winship wrote:
> Johan Dahlin wrote:
>>> Over the last couple of weeks Henrique Romano and I have been working on
>>> GtkBuilder, a UI constructor intended for inclusion in GTK+.
>>> I'd like to discuss the API and some of the decisions before making the
>>> code available for public review.
>>>   
>> I went ahead and attached the patch to
>> http://bugzilla.gnome.org/show_bug.cgi?id=172535
> 

Thanks for taking time to review the code.

> I think you can avoid needing to special-case "has_focus",
> "has_default", and "visible" at the GtkBuilder level. Change
> gtk_buildable_set_property() so that most of the code is in a default
> implementation of the method rather than in the wrapper function, and
> have implementations of the method fall back to their parent
> set_property() method as needed. Then have GtkWidget implement
> buildable.set_property, and let it do the special-casing for those
> properties there (and fall back to the default impl for all other
> properties). Then you don't need to hope there aren't other properties
> that need that sort of special-casing, because if there are, widget
> implementors can just special-case them themselves.

All three of them are very special:
has_default and has_focus should only be allowed to be set on on widget
per toplevel and they can't be set until the toplevel is created.
The visible property is similar, it should be set as late as possible, after
all the rest of the tree is constructed, but only for GtkWindow subclasses.

GtkBuildable->set_property could be modified to pass in a GtkBuilder
instance, which GtkWindow could implement to make sure visible is set there.
However, has_default and has_focus is trickier.

> The "constructor" property seems like it shouldn't be needed. Can't the
> parser figure out automatically that if the object being constructed
> implements construct_child, that it should use that to construct its
> children? (I might be misinterpreting how it's used...)

The reason I added the construct was to have a way to map
gtk_ui_manager_get_widget to a widget name.
I don't think it'd be trival to modify (I might be wrong, I don't know the
details of GtkUIManager) to expose a complete mapping of all the children.

Even if it does work, a menubar or toolbar constructed by a GtkUIManager
should have an implicit marker saying that they should not be created using
g_object_new.

> gtk_enum_from_string and gtk_flags_from_string seem like they should go
> into glib. (Along with their inverses? A flags_to_string function would
> often be useful when debugging.) Does gtk_flags_from_string() actually
> need to be working in UTF-8 or are those values guaranteed to be ASCII?
> And does it need to work with both flag names and flag nicks?
> (libglade's equivalent function does because glade uses flag.name for
> most properties, but uses flag.nick for table child x_options and
> y_options. But if we're changing the file format, we can fix that.)

These were copied from libglade, and I must admit that I have
not paid too much attention to them.

It's not so important for them to be able to handle utf-8, since an enum
or flag should stay reasonably close to the C language enum/flag.

It'd be great to only support nicks, because they are shorter.
However it would make the conversion scripts much harder to write.

> Does it make sense to pretend that gtk_set_value_from_string() isn't
> completely GtkBuilder-specific? The GtkAdjustment handling doesn't seem
> very general-use. Moving this function into GtkBuilder would solve the
> problem of how to handle GdkPixbuf. And on that topic: one problem with
> using glade files in C# is that you generally want the filenames in
> pixbuf properties to refer to resource objects that have been compiled
> into the exe file, not separate files. So it would be sweet if there was
> some way to override GtkBuilder's default filename->pixbuf resolving method.

It'll be easy to remove of we decide that we're not going to support
custom properties.

I haven't quite decided what to do about GdkPixbufs yet.
A way of resolving them is probably likely, I'll take the image embedded in
an exe file into account.

> Tooltips? Custom widgets?

Ditto for tooltips. If possible, I'd like to avoid the custom hack libglade
does.

Custom widgets is another hack, even so, a very useful one. Perhaps it would
be better to move it to out to a separate object, so we don't have to
special case the "Custom" type in the builder itself.


Johan