> On 11 Oct 2015, at 8:08 pm, Mark Waddingham <m...@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
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
