Widget Properties

[Mark Waddingham]

On 2015-10-11 12:31, Monte Goulding wrote:
> 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.

It's not about needing to know it before the extension is loaded, it is 
more about where the appropriate information is stored.

The widget module file stores all the code / embedding related things 
(so compiled bytecode, public handler definitions, property definitions 
etc.) but it doesn't contain anything that might be called 'metadata' - 
things like the name of the editor widget to use for a particular 
property (which is not necessarily related to its type).

Therefore, the manifest file stores all the metadata which is not 
related to the actually running of the widget as well as the exported 
public definitions in an easy to access way. (Basically, we needed 
sideline information which wasn't suitable for inclusion in the actual 
module format, and thus it seemed sensible to put the other information 
the IDE would need in the manifest too rather than it having to both 
interrogate an XML file *and* introspect on the loaded module).

At some point the metadata expressed in widget lcb files might well get 
put into the compiled module blob - but it seemed more expedient whilst 
developing the ideas to keep it separate as it is easier to change the 
XML format that is emitted and read than it is the compiled module blob 
format.

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

That was essentially what I was envisaging.

You shouldn't think of a 'widget' as being something which can change 
its kind. A widget takes on its kind when it is created, so the 'kind' 
property falls into the same class as 'button' or 'field'. So you create 
a widget of a given kind *then* set its state.

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

The export to array stuff is the best (future) basis for things such as 
lcVCS. Indeed eventually, if it was rolled out across all engine 
objects, the stackfile format would become 
arrayEncode(stackExportedToArray("my stack")) - although that would 
require a much more efficient arrayEncode format (something which has 
been at the back of my mind for ages - but nothing I've had time to put 
into action).

Warmest Regards,

Mark.

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