[Glade-users] objects properties in a custom catalog

[tristan.van.berkom at gmail.com (Tristan Van Berkom)]

On Thu, Aug 6, 2009 at 1:15 PM, Alexey
Kurochkin<alexey.kurochkin at pathfinderlwd.com> wrote:
> I'm trying to create a catalog with my custom widgets and have couple of
> questions:
>
> 1. I have some objects which have a property called "name". Glade does
> not show that property, although it saves it. Is there a way to force
> the "name" property to be shown somewhere?

Interesting, Glade handles "name" as a special case for GtkWidgets and
ties that into the widget id (and the parser equally treats this as a special
case).

Im not sure why the "name" property is not showing up for you in the
property editor, but you should still have a "name" entry in the the property
editor to set the actual object name (this is not a property) (I would consider
it a bug, and would have to look deeper to figure out exactly why...).

I think it would probably be best if you handled the "notify::name" signal
on the GladeWidget wrapper created for your custom widget (connect
to that signal from post_create()), and then always call
glade_widget_property_set()
on your own hidden "name" property to always match the object id.

This would ofcourse only be satisfactory if its ok that your objects
all receive a unique "name" value; otherwise feel free to file a bug
about why we are not picking up the "name" property...

> 2. Some properties are dependent on other properties, so changing one
> changes the other. I have appropriate calls to g_object_notify() in the
> code, but Glade seems to ignore them. Is there a way to tell Glade that
> the property value has to be updated?

Yes you can do that; there are 2 levels at which that can be done:

  a.) what you probably want is to handle the adaptor->set_property()
       for your custom object, from there you can call
glade_widget_property_set()
       on other properties; it will modify the project data and update
the UI accordingly.

       In this scenario the object just "reacts" to property settings,
and will react again
       in the case of an "undo" or such, you will obviously want to be
careful to avoid
       the possibility of infinite recursion.

  b.) sometimes setting the property in the UI makes other properties already
       set not make sense anymore, for instance we reset some properties on
       GtkActivatable widgets when the :use-action-appearance property changes.

       In this scenario you would have to implement
->create_editable() to return
       a customized editor for the class, from the editor code you can listen to
       the "commit" signal on the editor property and morph the commands into
       grouped commands (i.e. from the editor you always call
glade_command_set_property()
       which is an undoable statement, and commands can be grouped allowing for
       more complex undoable commands).

The former is most probably what you're after.

Cheers,
            -Tristan