[Glade-users] objects properties in a custom catalog

[Alexey Kurochkin]

On Thu, 2009-08-06 at 14:16 -0400, Tristan Van Berkom wrote:
> 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).

In my case these objects ain't GtkWidgets. They are simple GObjects. 

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

The "Name" entry (which is actually id) is there and works as expected.
It's the actual "name" property I want to be able to edit independently.

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

That's exactly what I do not want. That "name" property is used for
different purpose by these objects, not unique and completely
independent from 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...

I understand that it probably was not a good idea to name the property
"name", but on the other hand I don't really get it why GtkWidgets are
treated differently from any other GObject and their "name" property is
being bounded to the id, when all other objects survive perfectly fine
without even having that property. According to the docs the purpose of
the "name" property is to apply certain style from gtkrc to the widget,
which implies that it does not have to be unique, rather otherwise. Now
GtkBuilder for no particular reason hijacks the property forcing it to
be set to the unique id, completely defeating the purpose. I'm afraid
this rather unfortunate bug has to be filed against gtk. Correct me if
my logic is flawed.

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

I'll try that, thanks for the info.

> 
> Cheers,
>             -Tristan
>