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