Widget Properties

[Monte Goulding]

> On 11 Oct 2015, at 8:08 pm, Mark Waddingham <mark at livecode.com> wrote:
> 
> I don't think we have ever had the intention not to update the properties property to make it work for widgets - we just haven't done so yet.
> 
> Part of the reason for this is that 'the properties' property is quite ill-posed. As it stands it is essentially 'the properties needed to recreate the object' (after the work Monte did on it a couple of years ago); however that concept is difficult as it actually requires hard-coded rules in it to ensure that when you set 'the properties' the properties are set in the correct order.

Oh, yeah that was a headache working all that out...
> 
> Widgets complicate matters somewhat. We make no requirement that the state a widget must preserve to recreate itself be directly related to the properties you actually set (this is actually also true of existing engine controls - hence why there is a need for 'hardcoded' rules in the properties property implementation).
> 
> Now, I'm not saying this situation is ideal, there are various things we could do in the future to make widgets easier to write if they follow the rule that 'there should be a set of persistent properties which don't overlap and fully faithfully allow recreation of the object' (for widgets that claim to be this, they wouldn't need an OnSave / OnLoad handler as the engine could synthesise one).

Nice idea
> 
> However, that doesn't change the fact that currently engine controls don't follow that rule and I'd be loathe to put a restriction on all widgets in that fashion as I cannot forsee the widgets people might wish to write.
> 
> Basically there is a bit distinction between:
> 
>  1) The data you need to recreate an object (this is what lcVCS needs).
> 
>  2) The information you need to provide good introspection on created objects (this is what the IDE / inspectors etc. need).
> 
> Right now, I'd be incredibly dubious if a single 'properties' property could be made to handle both these uses - the lengthy thread a couple of years ago on this precise topic made that absolutely clear.
> 
> Moreover, we have worked quite hard in the IDE to provide a mechanism for (2) - it is what the new property inspector is based on - i.e. APIs for returning information and data about objects in the environment.

Yes, 2 is not really my concern. Having said that I’m not really sure why some of the stuff in the manifest (handlers and properties) couldn’t have just been done by introspection. Was it necessary to know all that stuff before loading the extension? I can understand the dependencies, icon, name etc but the handlers and properties seems a missed opportunity as it looks like they are available in the exported definitions.

Re 1 a possibility could be some combination of the properties and the exported array from OnSave. The properties of a widget could be something like:

- kind
- control & object props (rect, visible etc)
- state
	- the stuff in the $state key from the exported array

The only problem here is you can’t just create a blank widget and set the kind like this so its probably not worthwhile having kind in there. The rest could work fine and the widget author is in full control of how the state array is parsed.

However, it may be better to just deprecate the properties and finish the export to array stuff.

Cheers

Monte