Ali Lloyd wrote:

> Richard wrote:
>> 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.

Whether we use what we've been using for all types, or add all types to the newer currently-widget-specific syntax, is fine by me.

It's encouraging that you share an interest in this. Whatever syntax you prefer would be fine by me.

>>  > 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 ;-)

If I did say that it does rather than that it could, I'll trust your memory on that. I have been prone to optimism.

In the conversation we're having I didn't, because I've recently poked around in the IDE enough to have a sense of how the Inspector works.

Chipp, Geoff, Ken, Pete, I, and others use "the properties" for our respective prop viewing/editing tools. This may be why revNavigator's prop sheet doesn't support widgets; Chipp's doesn't either, and discovering that my own doesn't is what prompted this thread.

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

Yes, as I wrote to hh yesterday this isn't a show-stopper by any means. LC is a very flexible language, and there's little we can't script.

My request here to treat widgets like first-class objects using the same long-standing mechanism we enjoy for all other objects is more akin to the recent extension of the "files" and "folders" functions:

It never killed any of us to have to write our own custom functions to get the working directory, change to the one we're interested in, get the files/folders, and restore the working directory to what it was, and then return the list. But it's oh so very convenient to have that functionality built into the engine now.

Same with obtaining a prop array: those of us who make good use of "the properties" won't fall over dead if we have to add additional code to support one newer object class. It would just be oh so very convenient to have that built into the engine.

If it were, all tools and libraries written to use "the properties" would work for widgets as well.

As it is, widgets are unsupported by all of them, until every author gets around to adding the additional code needed for that one object type.

For those invested in promoting widget adoption, the choice would seem clear.

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

Your interest is much appreciated.

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

Of course (though it does conjure amusing ideas of recursion; "It's properties all the way down" <g>). And the script property as well, handled separately given its special role. I'm fine with continuing that.

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

Thank you, those are very good examples.

The completeness of "the properties" does not oblige any toolmaker to present information in ways that aren't useful.

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

For me personally, it doesn't matter much if we use what we've been using or use something new.

But anyone invested in promoting widgets may want to give weight to existing syntax, to allow existing tools and libraries to support widgets immediately.

There's always a more perfect way to do anything. But as they say, perfect is the enemy of results.

On this, as someone who would like to see widgets thrive, I would favor anything that offers even just incremental advantage, making the most of every opportunity to promote widgets as viable first-class objects.

 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