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

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 Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to