Widget Properties

[Mark Waddingham]

On 2015-10-11 08:11, Monte Goulding wrote:
>> On 11 Oct 2015, at 11:36 am, Peter Haworth <pete at lcsql.com> wrote:
>> 
>> Thanks Monte.  Maybe I should file a QCC report or have you already 
>> done so?
> 
> No I haven’t reported it. I got the impression from the discussion
> that it was never intended to support the properties so it wouldn’t
> happen. I’m about to propose (on the engine forum) a refactor of the
> properties property (which I’ll do if they want me to) that will
> essentially make the properties property self maintaining rather than
> the current situation which means the list of properties for an object
> type needs to be maintained manually. This wasn’t possible before the
> refactor and there’s still a few issues like identifying which synonym
> of a property is the one to use in the properties array and which
> properties should be in the array. The end result will mean the
> properties of a widget will be kind + the standard properties for a
> control + the standard properties for an object.

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.

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).

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.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps