widget properties

[Richard Gaskin]

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