[Glade-users] custom property setter not fired on commit
- From: domfe at tiscali.it (Domenico Ferrari)
- Subject: [Glade-users] custom property setter not fired on commit
- Date: Mon, 17 Mar 2014 15:06:15 +0100
Ok. But how can I get the GladeEditorProperty object to connect to?
In my editor I call glade_gtk_store_create_editable and I have no
access to the property editor, I can only get the GladeProperty with
glade_widget_get_property.
Dome
2014-03-17 13:12 GMT+01:00 Tristan Van Berkom <tristan at upstairslabs.com>:
On Mon, 2014-03-17 at 12:39 +0100, Domenico Ferrari wrote:
Hi Tristan and thank you. Works like a charm.
Now I want to synchronize two properties in my GtkListStore object:
one is the original "columns" property, the other is my own property.
Hi,
Commands should never be issued in a set-property function, this will
probably cause some madness to occur (probably some ugly recursion).
What you want to do instead is connect to the "pre-commit" and
"post-commit" signals on a GladePropertyShell object that you
would declare in a custom editor for your object.
For example, like we do in the about dialog editor code[0]
and ui definition[1].
Notice what we do in this editor:
o glade-gtk-window.c creates a GladeAboutDialogEditor for
the "General" tab for any about dialog[2] (yeah that's
messy, it should be done in the glade-gtk-about-dialog.c
subclass...)
o The GladeAboutDialogEditor declares a GladePropertyShell
which will automatically create an editor for the "license-type"
property, that's in it's own Glade file (as described at [1])
o The GladeAboutDialogEditor surrounds the commits that the
property editor for the "license-type" property will make,
by pushing a group in "pre-commit" and popping it in "post-commit".
In short, if you want to do what you are trying, you need to catch
the commit from the source - when the property editor itself makes
the commit - while the GladeWidgetAdaptor->set_property() method is
only meant to apply a value from Glade's data model onto a runtime
object in the work space (note that even though ->set_property() is
called as a consequence of changing a property value, it is *also*
called when any change is made via Undo/Redo).
Make sense ?
Cheers,
-Tristan
[0]:https://git.gnome.org/browse/glade/tree/plugins/gtk
+/glade-about-dialog-editor.c#n129
[1]:https://git.gnome.org/browse/glade/tree/plugins/gtk
+/glade-about-dialog-editor.ui#n123
[2]:https://git.gnome.org/browse/glade/tree/plugins/gtk
+/glade-gtk-window.c#n156
E.g.
columns prop (type, name values)
gint, intcol
gchar, charcol
my columns prop (name, note values)
intcol, "note on intcol"
charcol, "i'm a note"
Note: on "my columns" prop the user can change only the note value, no
change on the number of columns or the names, they are taken from the
original "columns" prop.
Now, I want to keep my property synchronized to the main property.
My coding behave as expected if I use glade_property_set but I have a
problem with the undo/redo stack... again :(
I tried a change in my code but with no success.
Here's a snippet of my set-property function that overrides the
original GtkListStore call.
if(strcmp(property_name, "columns")==0)
{
...
gwidget=glade_widget_get_from_gobject(object);
property = glade_widget_get_property(gwidget, "my-columns");
glade_property_get(property, &colfmts);
... change colfmt to reflect "columns"
glade_command_push_group("Setting columns on %s",
glade_widget_get_name(gwidget));
g_value_init (&newvalue, MY_TYPE_COLUMN_FORMAT_LIST);
g_value_take_boxed (&newvalue, colfmts);
glade_editor_property_commit (eprop, &newvalue);
g_value_unset (&newvalue);
/* Chain Up */
glade_gtk_store_set_property(adaptor, object, property_name, value);
glade_command_pop_group ();
}
Thank you. Cheers,
Dome
2014-03-15 6:10 GMT+01:00 Tristan Van Berkom <tristan.van.berkom at gmail.com>:
If your custom property is of some unknown GType, like a boxed type
you introduced for example, you will need to provide a
GladeStringFromValue function[0] in your widget adaptor definition.
The string it generates must be unique per possible value that your
GType can have, without this Glade has no way to compare your value
with another value and cannot tell if the value actually changed or
not (and thus needs to be updated in the workspace).
As with all other GladeWidgetAdaptor methods, the string_from_value()
method should chain up to the adaptor implementing the parent widget
type if that is appropriate, here is an example of how we handle it
for the custom "items" property of GtkComboBoxText[1], GtkListStore[2]
also does this for the "columns" property.
Cheers,
-Tristan
[0]:https://developer.gnome.org/gladeui/unstable/gladeui-glade-widget-adaptor.html#GladeStringFromValueFunc
[1]:https://git.gnome.org/browse/glade/tree/plugins/gtk+/glade-gtk-combo-box-text.c#n82
[2]:https://git.gnome.org/browse/glade/tree/plugins/gtk+/glade-gtk-list-store.c#n243
On Fri, Mar 14, 2014 at 11:12 PM, Domenico Ferrari <domfe at tiscali.it> wrote:
Hi.
I'm doing a new plugin for my widget...
It has a property editable with a TreeView, like "columns" on
GtkListStore object.
In my callback function on "edited" signal I have the following code
g_value_init (&value, MY_TYPE_COLUMN_FORMAT_LIST);
g_value_take_boxed (&value, colfmt);
glade_editor_property_commit (eprop, &value);
but my custom property setter is not fired. If I use
glade_property_set it is correctly called but I miss the undo/redo
stack.
Can I have some help?
Thanks!
_______________________________________________
Glade-users maillist - Glade-users at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-users
_______________________________________________
Glade-users maillist - Glade-users at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-users
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]