Ali Lloyd wrote:
> Not much has changed since this question was last asked:
> http://lists.runrev.com/pipermail/use-livecode/2015-October/219630.html
So it seems, hence my question. :)
> The question here really is what you want to use the properties
> property for.
My interest this morning came from a property sheet I build some years
ago as an alternative to an inspector. There are many good reasons why
a property sheet is a much better fit for an IDE, but we can save that
for another thread.
Another reason Kevin asked Scott Raney to add "the properties" as a
universal representation of object props back around '00 was for the
rapid things we can do for new object creation.
As an array, the value lends itself particularly well for a wide range
of needs.
For example, taking the delta between two objects gives you a great way
to concisely express what would be needed to reproduce one from the
other. Such conciseness is esp. useful in Internet applications.
Another would be transferable styles. I can make a button or field how
I like it, and then store only the things I care about to represent that
"style". Later I can union that subset with "the properties" of another
object of that type and have them applied in one simple and highly
efficient move.
There may be other reasons this was requested as a universal way of
representing object properties. That's just the short list of things
that come to mind off the top of my head right now.
> It is not correct to say that the properties property is used to
> create the property inspector
I don't know anyone who said that. But imagine how much simpler it
would be to make an Inspector if "the properties" were completed to
handle this new class of objects.
In fact, add that to the use-case list above.
Having one universal means of getting and setting object properties en
masse is very helpful.
And we've had it for more than a decade and a half.
And we have it still, except for one new class of objects, widgets.
If we extend this mechanism to include the data the engine already knows
about properties, widgets will be elevated to first class objects like
anything else.
Isn't having widgets behave more like engine-native controls the reason
we use them over compound groups?
>- that is in fact done from property definition files. There are things
> that are properties that you might not want to present in a property
> inspector, and there are things that you might want to present in the
> property inspector that are not strictly properties. Hence we maintain
> these lists:
>
https://github.com/livecode/livecode-ide/tree/develop/Toolset/resources/supporting_files/property_definitions
I'm familiar with the existing mechanisms, but help me understand: which
scriptable properties would a widget have which would not be of interest
to a scripter?
> Because the 'classic controls' are somewhat multipurpose, the notion
> of control type isn't fine-grained enough to use the properties
> property for a good property inspector.
Agreed. Another good argument for a property sheet, but that's for
another thread.
Either way, it's a settable value which can be scripted.
Scripting them will be simpler and more enjoyable to write with one
consistent mechanism for all object types.
All I'm suggesting is that we remove a limitation that makes widgets
second-class citizens in the LC object world.
And since the information is already available, it would seem a
relatively easy task, at least as far as powerful feature-completeness
requests go, yes?
--
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
