On Tue, Aug 11, 2009 at 8:13 PM, Tristan Van Berkom<[email protected]> 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 _______________________________________________ Glade-devel maillist - [email protected] http://lists.ximian.com/mailman/listinfo/glade-devel
