glade & gsettings

[Sam Thursfield]

Hello!
I've been doing some more hacking on putting gsettings into GLADE.
I've got to one of the thorny areas - preventing conflicts when you
bind say a GtkRadioButton::active to a gsetting, and also set a
related action on it.

Here is what I've thought should happen:
* when you set a related action and the 'active' property is bound to
a setting: the binding needs to move to the action's 'active' property
(which would be done from the relevant GladeCommand). This could be
confusing to the user - I thought that if this happens it should open
the bindings window for the action to show what has gone on.
* when you set bind a widget's active property but a related action
is set: either: 1. don't allow it - the 'connect to setting' context
menu item should be disabled with a tooltip to say why. or, 2. bind
the action's property instead (and select the action in GLADE so that
it's obvious what has gone on.)

Any comments on this? Especially for the second case, I prefer
approach #2 I think because it saves a tiny bit of effort for the user
- but either is workable. I'll be implementing this in a day or two
(before the gsoc deadline :).
Thanks
Sam
_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Tristan Van Berkom]

Post by Sam Thursfield
Hello!
I've been doing some more hacking on putting gsettings into GLADE.
I've got to one of the thorny areas - preventing conflicts when you
bind say a GtkRadioButton::active to a gsetting, and also set a
related action on it.

Hi,
Great to hear that you are making progress ;-)

First off, I like the dialog per widget approach, it will give us
the flexibility we need.

One important detail is that you should expose the widget
not as a dialog, but as a widget proper (possibly could come
with a utility function to fire a dialog, but that could be coded
into the core).

This is so that we continue to offer a proper and flexible api
both to IDEs and to our own frontend (for instance, in the
future if and when we collapse the properties into one
more comprehensible tab then we might easily add the
binding editor widget to a "bindings" tab).

Post by Sam Thursfield
 * when you set a related action and the 'active' property is bound to
a setting: the binding needs to move to the action's 'active' property
(which would be done from the relevant GladeCommand). This could be
confusing to the user - I thought that if this happens it should open
the bindings window for the action to show what has gone on.
 * when you set bind a widget's active property but a related action
is set: either: 1. don't allow it - the 'connect to setting' context
menu item should be disabled with a tooltip to say why. or, 2. bind
the action's property instead (and select the action in GLADE so that
it's obvious what has gone on.)

I think we should keep unexpected results to a minimum.

Currently the only places where Glade clears properties are
from custom editors which feature radio buttons that control
various modes in which you can setup a widget (i.e. use stock
or custom images in buttons etc), this I think is quite clear.

I would prefer:
- Setting a related-action clears properties, and also clears bound
properties.
(this starts to be unclear because it starts modifying/clearing
properties that
are not on the editor page itself, I suggest solving this by
firing a dialog from
the activatable editor in the case that the widget already has
bound properties,
telling the user the properties will be cleared and asking if he
is sure etc).

- In the binding editor:
- properties that are insensitive/disabled cannot be bound; a
text or tooltip
explaining why it cannot be bound should show up (this text
is generically
accessible on GladeProperty instances)
- properties that are invisible should not even show up.
- properties that are in the future from the target project
version should
show a warning icon/text (also generically accessible).

Its also important to note that glade_project_verify() codepaths still need to
produce expectable results - that means when saving a project that binds
properties outside of the target toolkit version range - the error explaining
why should still popup.

Also, now that a GladeProperty can be bindable, I suppose this adds api
to GladeProperty (and then similar api to GladeCommand), how is the binding
data to be saved (as a new attribute to the <property> tag) ?

In an abstract way, lets say that this changes the nature of GladeProperty
from a single state object, to a concurrent state object, this may present some
problems in the core, we have to brainstorm a little together about how this is
going to fit in...

Consider that from the POV of the plugin, a GladeProperty represents the
value assigned to a property - this property is not serialized if its
at the default
value (unless specified as "save-always") - a property can also have
i18n metadata
on it, but that data is useless when the property is default (i.e. we
dont save empty
strings just to say that they are translatable and give context), so
you can safely
say that a default property is unset and meaningless.

So,... you can bet that the plugin already makes assumptions in a few places
about a property being default or not, as specially at load time to decide
configuration modes of buttons and images etc, at the same time changing
the behavior and return value of glade_property_orig_default() should be out
of the question.

It would be possible to split up the data or maintain a separate list on
the GladeWidget that points to the bound properties - but I think I would
at this point rather live with some minor api breakage than the convoluted
complex code that may result in separating those datum.

Well anyway, Im eager to hear your thoughts about how to address this
area, it might help if you came up with the new apis for GladeProperty
or GladeWidget and proposed them here for discussion.

Cheers,
-Tristan
_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Sam Thursfield]

On Tue, Aug 11, 2009 at 8:13 PM, Tristan Van

Post by Tristan Van Berkom
One important detail is that you should expose the widget
not as a dialog, but as a widget proper (possibly could come
with a utility function to fire a dialog, but that could be coded
into the core).

Will do.

...
the binding editor at the moment is just a treeview in a dialog with a
'remove' button. properties are added to the treeview when you go
"connect to setting" from a context menu on the property in the
inspector.

Post by Tristan Van Berkom
        - properties that are insensitive/disabled cannot be bound; a
text or tooltip
          explaining why it cannot be bound should show up (this text
is generically
          accessible on GladeProperty instances)

okay, i already don't allow binding packing props for example

Post by Tristan Van Berkom
        - properties that are invisible should not even show up.

i don't think is is relevant given the fact that properties only
appear in the editor when first bound

Post by Tristan Van Berkom
        - properties that are in the future from the target project
version should
          show a warning icon/text (also generically accessible).

i'm not sure what you mean here .. :(

Post by Tristan Van Berkom
Its also important to note that glade_project_verify() codepaths still need to
produce expectable results - that means when saving a project that binds
properties outside of the target toolkit version range - the error explaining
why should still popup.

will look into this.

Post by Tristan Van Berkom
Also, now that a GladeProperty can be bindable, I suppose this adds api
to GladeProperty (and then similar api to GladeCommand), how is the binding
data to be saved (as a new attribute to the <property> tag) ?

yes it does. the bindings will be saved (this isn't implemented in
glade but is in gtkbuilder) as a "setting" attribute on the <property>
tag. The top of the .ui file has a declaration such as <settings
schema="org.gnome.foo" path="/apps/frobozz/" /> which I just realised
will also need to be exposed in GLADE somewhere .. I guess in the
project settings, since this is a global thing.

Post by Tristan Van Berkom
In an abstract way, lets say that this changes the nature of GladeProperty
from a single state object, to a concurrent state object, this may present some
problems in the core, we have to brainstorm a little together about how this is
going to fit in...
Consider that from the POV of the plugin, a GladeProperty represents the
value assigned to a property - this property is not serialized if its
at the default
value (unless specified as "save-always") - a property can also have
i18n metadata
on it, but that data is useless when the property is default (i.e. we
dont save empty
strings just to say that they are translatable and give context), so
you can safely
say that a default property is unset and meaningless.
So,... you can bet that the plugin already makes assumptions in a few places
about a property being default or not, as specially at load time to decide
configuration modes of buttons and images etc, at the same time changing
the behavior and return value of glade_property_orig_default() should be out
of the question.
It would be possible to split up the data or maintain a separate list on
the GladeWidget that points to the bound properties - but I think I would
at this point rather live with some minor api breakage than the convoluted
complex code that may result in separating those datum.

I don't really understand the problem here. The value of a property
inside GLADE is unaffected by whether it's bound to a setting or not,
surely? sorry if I'm missing the point totally but I can't quite get
my head around this :)

Post by Tristan Van Berkom
Well anyway, Im eager to hear your thoughts about how to address this
area, it might help if you came up with the new apis for GladeProperty
or GladeWidget and proposed them here for discussion.

will post these tomorrow (tired now :)

sam
_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Tristan Van Berkom]

Post by Sam Thursfield
On Tue, Aug 11, 2009 at 8:13 PM, Tristan Van

Post by Tristan Van Berkom
One important detail is that you should expose the widget
not as a dialog, but as a widget proper (possibly could come
with a utility function to fire a dialog, but that could be coded
into the core).

Will do.
...
the binding editor at the moment is just a treeview in a dialog with a
'remove' button. properties are added to the treeview when you go
"connect to setting" from a context menu on the property in the
inspector.

Understood, ideally it would be great if you could also bind properties
in that treeview, similar to how we add columns to liststores (by
using an editable "<add binding>" row with a completion of bindable
properties)... but if thats not there for now it doesnt break anything...

Post by Sam Thursfield

Post by Tristan Van Berkom
        - properties that are insensitive/disabled cannot be bound; a
text or tooltip
          explaining why it cannot be bound should show up (this text
is generically
          accessible on GladeProperty instances)

okay, i already don't allow binding packing props for example

Post by Tristan Van Berkom
        - properties that are invisible should not even show up.

i don't think is is relevant given the fact that properties only
appear in the editor when first bound

Right for now that is irrelevant...

Post by Sam Thursfield

Post by Tristan Van Berkom
        - properties that are in the future from the target project
version should
          show a warning icon/text (also generically accessible).

i'm not sure what you mean here .. :(

Properties have metadata on them dictating in what version
of their toolkit it was introduced, the project preferences dialog
lets you select the target version for your project (usually you
only see the target for GTK+, while other plugins generally dont
use the versioning, its still there).

Anyway the point is that if you use a new property from GTK+ 2.18
and you are targetting GTK+ 2.14 for instance, you get a warning icon
in the UI with a tooltip explaining the version conflict, you also get
a warning when trying to save a property that mismatches the target
version (i.e. saving with that property at any value other than its default).

Post by Sam Thursfield

Post by Tristan Van Berkom
Its also important to note that glade_project_verify() codepaths still need to
produce expectable results - that means when saving a project that binds
properties outside of the target toolkit version range - the error explaining
why should still popup.

will look into this.

Post by Tristan Van Berkom
Also, now that a GladeProperty can be bindable, I suppose this adds api
to GladeProperty (and then similar api to GladeCommand), how is the binding
data to be saved (as a new attribute to the <property> tag) ?

yes it does. the bindings will be saved (this isn't implemented in
glade but is in gtkbuilder) as a "setting" attribute on the <property>
tag. The top of the .ui file has a declaration such as <settings
schema="org.gnome.foo" path="/apps/frobozz/" /> which I just realised
will also need to be exposed in GLADE somewhere .. I guess in the
project settings, since this is a global thing.

[...]

Post by Sam Thursfield
I don't really understand the problem here. The value of a property
inside GLADE is unaffected by whether it's bound to a setting or not,
surely? sorry if I'm missing the point totally but I can't quite get
my head around this :)

Well currently if a property is at its default value it is not saved,
period - this
policy will have to change obviously with bindings.

Next, I guess the right thing to do is to make the binding and the setting
of a property mutually exclusive, right ? or can the value be used for
something ?

Finally, when we load classes like GtkButton for instance we are going
to check a bunch of default values of properties, so:
a.) if a child widget is found, then we set the virtual edit-mode
property to "custom button content"
b.) if the "use-stock" property is set, then we set editing to "stock button"
c.) finally resort to "label with optional image"

A better example is now in GtkEntry we do:
a.) if "primary-icon-name" is non-default, then we edit the primary
entry icon from the icon theme
b.) if "primary-icon-pixbuf" is not default, then we use the pixbuf edit mode
c.) then resort to stock-id mode for the primary icon.

So what edit mode do I get for my GtkEntry when I want to bind the
entry's "primary-icon-name" property to a setting ? it *should* continue
to be the icon mode.

A quick search through the GTK+ plugin for
glade_widget_property_original_default()
or through the sources in general for glade_property_orig_default()
etc will give you
a better picture of the voidness of an "unset" property.

Basically an unset property will now suddenly and quite unexpectedly
become useful in
cases where its auxiliary settings metadata counterpart is
non-null/setup (this is in my
opinion right, but it will break a good portion of existing code that
assumes otherwise...)

Cheers,
-Tristan
_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel