[Glade-devel] glade & gsettings

[Sam Thursfield]

On Tue, Aug 11, 2009 at 8:13 PM, Tristan Van
Berkom<tristan.van.berkom at gmail.com> wrote:
> 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.

...
>   - In the binding editor:

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.

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

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

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

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

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

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

> 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