Re: [Glade-devel] gsettings and glade

[Tristan Van Berkom <tvb gnome org>]

On Sun, Jun 14, 2009 at 2:23 PM, Sam Thursfield<ssssam gmail com> wrote:
> Hello!
> I'm doing Summer of code work integrating Gtk+ and the awesome
> gsettings. This includes adding a bunch of stuff to GLADE to make
> binding widgets to settings easy. This can already be done in code
> using g_settings_bind, but nobody likes writing code when the computer
> could do it for us!

Great that somebody is doing something for this feature :)
(Ive been following it a bit in bugzilla...)

Im cross-posting this to GTK+ because I think in this early stage
of development we should all get a look (this project also will
effect GTK+ as much if not more than Glade) and I have some
comments I would like to be reviewed by the GTK+ team...

Pushing the strictly Glade related stuff to the bottom...

>
> * for properties you would actually want to bind to, like
> GtkEntry::text and GtkToggleButton::active, add a GtkEntry under the
> property editor widget to enter a gsettings key name to bind to.

I was thinking, does it make sense to tie this bindings stuff up to actions ?

Does it make sense to just say "any action property is bindable" and
that you should just bind your actions to the settings keys and
bind widgets to the action states ?

This would encourage use of actions in a very interesting way,
and it would also resolve the question of which properties we want to
show the user as "bindable" from the Glade UI.

The drawbacks of this would be, currently we are missing a proper
GtkScalarAction for GtkScales and such, ofcourse people can implement
thier own actions and compensate where we are lacking....

> * schemas will be generated from the .ui file at compile time, using
> the widget's state in the GtkBuilder file as the default key value

Note also, the problem of having multiple widgets registered
to a single gsettings key, would be resolved by forcing the user
to use a single GtkAction per setting...

> * enums and flags I haven't really considered yet. It would be nice to
> make say, a set of radio buttons automatically tied to an enum
> definition, and then bind the radio group to a settings key. I guess
> this isn't really a gsettings-specific issue. It would still be nice
> for GLADE to have this though. I guess you would need to associate a
> glib-mkenums input file with the .ui file.
>
> Comments on this are very welcome. I might not have explained this
> stuff very well either I am happy to clarify. Also, I only started
> working on this stuff yesterday so it's all changable if some better
> ideas come up.

Again, great that you are working on it, come see us on irc if you
need help understanding the internals of Glade (or keep writing our
lists too), thanks :)

[...]
> Here is an exciting bullet list of my plans
> * add a 'bindings' tab based on the 'signals' tab which can bind any
> properties that it makes any sense to (things that aren't
> construct-only, or read-only, or virtual).
>
> This is flexible but most of the properties are still things you
> wouldn't bind a settings key to in a hundred years. This also makes
> the inspector's notebook very wide. I wonder if it would be worth
> hiding the bindings tab by default and having a sort of 'advanced...'
> checkbox to show it

Ok I would like to avoid adding extra UI where we can, lets see if and
how we can add this at the GladeEditorProperty level.

i.e., in Glade, every widget class constructs a GladeEditor on Glades
behalf (widget classes are defines via the plugin backend, or falls back
to default implementations in the core).

With the exception of the signal editor, all the tabs in the editor
load lists of GladeEditorProperty objects which handle properties
individually.

So, this way we have a few options:
  - Add context menu options to GladeEditorProperty to bind a property
    (not very obvious, but we already have "read docs" and "reset" in this
    context menu)
  - Add an icon in the property area to spawn a dialog (like the i18n dialog
    for translatable text entries); I like this idea better, except it takes up
    precious screen realestate, until we write up a canvas based editor
    (because I'll refuse boring treeviews), the editor risks looking cluttered
    (it already does).

    With this UI in mind, we can lighten the load also by:
      o Adding an option in the view menu "show/hide property bindings"
      o Add metadata in the plugin definition: "bindable";
         only properties that were mentioned as "bindable" in the plugin
         will ever show the icon to set the binding key.

Anyway thats it for today, think about these wacky ideas
a bit :)

Cheers,
         -Tristan