Widget properties

[Richard Gaskin]

Monte Goulding wrote:

 > It seems a stretch to imply the lack of support for a property that
 > has little to no use case outside the IDE means the company doesn’t
 > take widgets seriously but I’m not going to argue with you about that.

A reasonable choice, given that "seriously" is a colloquialism with no 
specific quantifiable meaning.

Here I used it to try to elicit LC's vision for widgets.  I had the 
(quite possibly mistaken) notion that widgets were a way to craft 
reusable controls that would look and feel like engine objects, but with 
the advantage that they could be created from a scripting language.

We see many queries here about messages common to all other controls not 
working with widgets, and now and then we see queries about properties 
and functions too.

"The properties" is just the latest of these, and your view of that here 
is helpful:

 > I will say there’s two main use cases for `the properties` and neither
 > of them it serves very well:
 >
 > - Getting the properties of an object to apply to recreate the object
 > elsewhere. export widget does a much better job of this and was
 > designed specifically for that use case.

Can you help me understand how it's better than "the properties", and 
why this superior method isn't used for engine controls?


 > - Introspecting what properties an object has in order to create an
 > editor without maintaining your own lists of properties. It has never
 > been good at this. It doesn’t tell you anything about acceptable
 > values for those properties, it doesn’t tell you the importance of
 > the property, it doesn’t tell you about alternative object properties
 > that may be more useful to edit (text, styledText, htmlText, rtfText
 > etc) or whether it’s potentially risky to present a UI that can edit
 > it. Really this use case is served best by a well documented library
 > that covers all objects. Currently you would need to dig the details
 > out of the IDE scripts

That seems to answer the first question, though while the metadata about 
types and options is useful for some things, it would still be useful to 
get just the name-value pairs as "the properties" does.

That the company has such a narrowly specific view of the applicability 
of "the properties" is indeed helpful. Thank you for chiming in.

I use "the properties" in a great many things, even outside the IDE 
tools, though those are about half of everything I've been doing as one 
of the few people outside the company working full-time with LC for as 
long as I have.

Much of what I do is bespoke authoring systems, and frequently they're 
implemented as plugins.  This is something I love about xTalks, and the 
SC/MC/LC philosophy that's driven the post-HC world. SC's Bill Appleton 
summed it up well when he once said:

     "HyperCard is a multimedia authoring system. SuperCard is a tool
      you can use to build multimedia authoring systems."

For myself, and a good many others I know, the value of making tools is 
not limited to the IDE team, but a core value and key differentiator of 
choosing LiveCode.

I have lot of ways to make software. But few of them let me redefine the 
workflow as flexibly as an xTalk. And no xTalk has been as flexible as 
LiveCode.

It's like the difference between a drawing program and a scriptable 
drawing program, or between Wordpress and Drupal, or between a sculpture 
and modeling clay.

I appreciate your team making an IDE, but for most of us who make our 
living with it it's only part of the toolset we use.


On the more consumer-facing side which may better fit a view in which 
tooling is seen as for the engine team only, consider styling:

When we set "the properties" of an object, it affects only the keys 
present, leaving everything else alone.

This means we can make arrays with any subset of relevant attributes we 
want, and apply them almost like style sheets with just one line.  We 
can even save these prop subsets to disk as LSON files if we like, so we 
can reuse them, mixing and matching from screen to screen and project to 
project as we like.

In fact, using "the properties" has become such a habit across so much 
of what I do I have to admit that I need to think about it to list them 
all, in the way a fish struggles to define water.


Arrays are a great foundational data type, and being able to express 
controls with them efficiently and uniformly is a godsend.

 From my perspective, perhaps no less limited than someone who works all 
day on the IDE but coming at it from a different angle, the question 
seems less interesting as "Why is this useful?" than "How could it not be?"


Let me simplify the question:

How hard would it be for the team to map the existing means of 
extracting widget properties to "the properties"?

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com