[Glade-devel] glade & gsettings

[Tristan Van Berkom]

On Tue, Aug 11, 2009 at 10:11 PM, Sam Thursfield<ssssam at gmail.com> wrote:
> 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.

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

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

Right for now that is irrelevant...

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

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