bobsneidar at iotecdigital.com
Tue Feb 27 16:40:58 EST 2018
+1 Sounds like a good idea. The only bugaboo I see is if the properties of a widget were in some other format than an LC string, but I don't know that.
> On Feb 24, 2018, at 12:19 , Richard Gaskin via use-livecode <use-livecode at lists.runrev.com> wrote:
> [This message was identified as a phishing scam. Learn about phishing at http://aka.ms/LearnAboutPhishing]
> 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.
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> Ambassador at FourthWorld.com http://www.FourthWorld.com
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the Use-livecode