+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.
Bob S > On Feb 24, 2018, at 12:19 , Richard Gaskin via use-livecode > <use-livecode@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 > object. > > 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 > ____________________________________________________________________ > ambassa...@fourthworld.com http://www.FourthWorld.com > > _______________________________________________ > 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 _______________________________________________ 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