glade & gsettings
|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
 |
glade & gsettings
by Sam Thursfield
::
Rate this Message:
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-devel@... http://lists.ximian.com/mailman/listinfo/glade-devel |
|
|
Re: glade & gsettings
by Tristan Van Berkom-2
::
Rate this Message:
On Tue, Aug 11, 2009 at 1:00 PM, Sam Thursfield<ssssam@...> 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 - Glade-devel@... http://lists.ximian.com/mailman/listinfo/glade-devel |
|
|
|
|
|
Re: glade & gsettings
by Tristan Van Berkom-2
::
Rate this Message:
On Tue, Aug 11, 2009 at 10:11 PM, Sam Thursfield<ssssam@...> wrote:
> On Tue, Aug 11, 2009 at 8:13 PM, Tristan Van > Berkom<tristan.van.berkom@...> 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 _______________________________________________ Glade-devel maillist - Glade-devel@... http://lists.ximian.com/mailman/listinfo/glade-devel |
| Free embeddable forum powered by Nabble | Forum Help |
