Ali Lloyd wrote:

> Not much has changed since this question was last asked:

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:

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

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to