widget properties

[Richard Gaskin]

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
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com