Brian Milby wrote:
>> > Brian M. wrote:
>> > One other thing that could be done is to extend the export to
>> > include everything that the engine knows about the widget (i.e.
>> > add the properties array to it).
>> The widget author can already do that by defining a list of
>> persistent properties. Why should the engine override that?
> I see this as a unification rather than override.
Exactly. My request is almost exactly as you worded it, but in reverse:
rather than adding the info obtainable from the universally-supported
"the properties" to something widget-specific, I'm suggesting the engine
have an enhancement to add the widget-specific info to the
universally-supported "the properties" info.
This suggestion would seem to address hh's concern as well:
> The documentation and property-infos are a *lot* of work and will
> raise the price of a widget (if not free), just as with standalones
> or externals.
By having an engine-level enhancement to include the values already
supplied by the widget per the widget spec included in the existing "the
properties" function, we would then have one universal array to work
with which would adequately describe any object with no additional work
needed from any widget developer.
Consider the LC IDE's Inspector: to populate its controls it obtains
"the properties" from all LC-native objects, and "the properties" +
widget-specific info from widgets.
If the engine included the widget-specific info in "the properties", the
Inspector need only query one place to obtain all relevant info about an
And given that "the properties" was introduced to provide a universal
way of obtaining object info, and that widgets were introduced as a way
to provide native-like objects without requiring engine-level
implementation, honoring the purpose of "the properties" by extending it
to include widget-specific info would seem every bit as useful as having
"the properties" has been until the introduction of widgets.
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription