[Glade-users] objects properties in a custom catalog

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

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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]