widget properties

[Ali Lloyd]

>
> 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 applicationsL


These seem to me to be perfect examples of why export <obj> to tVar would
be useful to extend to all objects.


> 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.
>
>
You did, in your earlier email ;-)

> 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.

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.
>

Unless you meant 'the properties' abstractly. If that's the case then there
is such a function - it is in the IDE library and the IDE does use it on
all object types to generate the property inspector.


> 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?
>
>
I'm not trying to argue that we shouldn't extend the properties property -
actually efficiency may indeed be one of the best reasons in terms of being
able to set a bunch of properties in one go. I'm just trying to gather
information to figure out the priority of such a thing.


>  >- 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?
>

I didn't say they aren't of interest to the scripter, I said you might not
want to present them in a property inspector. And it's not just widgets,
all objects have properties that are not really relevant to the property
inspector. Most obviously, the properties property. Others are, for
example, the noncontiguousHilites of a standard text field, or the
menuHistory of a default button. Many widgets have other properties that
overlap, for example the itemArray of the navigation bar, which overlaps
with (in fact subsumes) the itemLabels, itemIcons, itemSelectedIcons etc.
See the navigation bar's itemArray editor in the PI - in my view this is
much nicer than a set of fields. Another type would be transient properties
of mobile native objects - eg the 'focused' property of the android native
field which is not saved with the object. It is completely unuseful to set
this property via PI in the IDE, but still needs to be a property so you
can set it from script. As the existence of such properties is subject to
the whims of the widget author, they could crop up anywhere, hence the
desire to make the ones that *should* show up part of the metadata.


>
 > 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.
>

I don't understand how that's an argument for a property sheet - surely
that just means you get a property sheet where some of the things do
nothing or something you didn't expect. But yes, 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?
>
>
Again, I am not arguing that there shouldn't be a properties property
extended to widgets. I see that efficiency and property sheets are
reasonable use-cases for it. The trick is to ensure that the VCS use-case
can be extricated. If we have export for all object types, there's no
reason (other than backwards compatibility) that the properties property
couldn't return the value of every single gettable property of an object
type.

I wonder if the properties of <obj> should actually be a function, to avoid
there always being a property that (for obvious reasons) cannot be returned
by a properties property.