Re: glade & gsettings

On Tue, Aug 11, 2009 at 1:00 PM, Sam Thursfield<[email protected]> wrote:
> 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).

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

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  -  [email protected]
http://lists.ximian.com/mailman/listinfo/glade-devel