widget properties

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

widget properties

J. Landman Gay via use-livecode
When we query the properties of any object, we get an array that lets us
understand and even reproduce that object easily.

Except with widgets.

When we query the properties of a widget we get only the subset of
properties common to all widgets, but none of the properties unique to
any given widget type.

Should the widget spec be enhanced to map its unique properties to be
included among "the properties" array?

--
  Richard Gaskin
  Fourth World Systems

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: widget properties

J. Landman Gay via use-livecode
Doe this get what you want:
export widget to array arrayVar
On Sat, Feb 24, 2018 at 10:01 AM Richard Gaskin via use-livecode <
[hidden email]> wrote:

> When we query the properties of any object, we get an array that lets us
> understand and even reproduce that object easily.
>
> Except with widgets.
>
> When we query the properties of a widget we get only the subset of
> properties common to all widgets, but none of the properties unique to
> any given widget type.
>
> Should the widget spec be enhanced to map its unique properties to be
> included among "the properties" array?
>
> --
>   Richard Gaskin
>   Fourth World Systems
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: widget properties

J. Landman Gay via use-livecode
I meant “does”
To get what you want (if different than above) would require something
defined within each widget to export the desired internal information.
One other thing that could be done is to extend the export to include
everything that the engine knows about the widget (i.e. add the properties
array to it).

Thanks,
Brian
On Sat, Feb 24, 2018 at 10:12 AM Brian Milby <[hidden email]> wrote:

> Doe this get what you want:
> export widget to array arrayVar
> On Sat, Feb 24, 2018 at 10:01 AM Richard Gaskin via use-livecode <
> [hidden email]> wrote:
>
>> When we query the properties of any object, we get an array that lets us
>> understand and even reproduce that object easily.
>>
>> Except with widgets.
>>
>> When we query the properties of a widget we get only the subset of
>> properties common to all widgets, but none of the properties unique to
>> any given widget type.
>>
>> Should the widget spec be enhanced to map its unique properties to be
>> included among "the properties" array?
>>
>> --
>>   Richard Gaskin
>>   Fourth World Systems
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: widget properties

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
> Richard G. wrote:
> When we query the properties of any object, we get an array that lets us
> understand and even reproduce that object easily.
>
> Except with widgets.
>
> When we query the properties of a widget we get only the subset of
> properties common to all widgets, but none of the properties unique to
> any given widget type.
>
> Should the widget spec be enhanced to map its unique properties to be
> included among "the properties" array?

A widget is not an ordinary "object". It's more like a micro-standalone.
You'll get what the author provides, as with a standalone or an external.

The documentation and property-infos are a *lot* of work and will raise
the price of a widget (if not free), just as with standalones or externals.

> Brian M. wrote:
> One other thing that could be done is to extend the export to include
> everything that the engine knows about the widget (i.e. add the
> properties array to it).

The widget author can already do that by defining a list of persistent
properties. Why should the engine override that?


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: widget properties

J. Landman Gay via use-livecode
> > Brian M. wrote:
> > One other thing that could be done is to extend the export to include
> > everything that the engine knows about the widget (i.e. add the
> > properties array to it).
>
> The widget author can already do that by defining a list of persistent
> properties. Why should the engine override that?


I see this as a unification rather than override.  When a stack is saved it
asks each widget what it wants to save but also includes other properties
too (rect, layer, id, ...).
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: widget properties

J. Landman Gay via use-livecode
Now I’m really confused:

put the properties of widget id 1004 into tA

Results in an empty tA. If I put something into tA[“rect”] and then set the
properties to tA then it does move to that rect. Is that just my 2
computers (Mac and Win10)? I checked 9DP11 and 8.1.7 (will get the latest 8
now though).
On Sat, Feb 24, 2018 at 1:41 PM Brian Milby <[hidden email]> wrote:

> > Brian M. wrote:
>> > One other thing that could be done is to extend the export to include
>> > everything that the engine knows about the widget (i.e. add the
>> > properties array to it).
>>
>> The widget author can already do that by defining a list of persistent
>> properties. Why should the engine override that?
>
>
> I see this as a unification rather than override.  When a stack is saved
> it asks each widget what it wants to save but also includes other
> properties too (rect, layer, id, ...).
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: widget properties

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
Brian Milby wrote:

 >> > Brian M. wrote:
 >> > One other thing that could be done is to extend the export to
 >> > include everything that the engine knows about the widget (i.e.
 >> > add the properties array to it).
 >>
 >> The widget author can already do that by defining a list of
 >> persistent properties. Why should the engine override that?
 >
 > I see this as a unification rather than override.

Exactly.  My request is almost exactly as you worded it, but in reverse:
  rather than adding the info obtainable from the universally-supported
"the properties" to something widget-specific, I'm suggesting the engine
have an enhancement to add the widget-specific info to the
universally-supported "the properties" info.

This suggestion would seem to address hh's concern as well:
 > The documentation and property-infos are a *lot* of work and will
 > raise the price of a widget (if not free), just as with standalones
 > or externals.

By having an engine-level enhancement to include the values already
supplied by the widget per the widget spec included in the existing "the
properties" function, we would then have one universal array to work
with which would adequately describe any object with no additional work
needed from any widget developer.

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.

If the engine included the widget-specific info in "the properties", the
Inspector need only query one place to obtain all relevant info about an
object.

And given that "the properties" was introduced to provide a universal
way of obtaining object info, and that widgets were introduced as a way
to provide native-like objects without requiring engine-level
implementation, honoring the purpose of "the properties" by extending it
to include widget-specific info would seem every bit as useful as having
"the properties" has been until the introduction of widgets.

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

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: widget properties

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
> Richard G. wrote:
> I'm suggesting the engine have an enhancement to add the widget-specific info
> to the  universally-supported "the properties" info.

It would be possible to simply add all the info that the property inspector
can display. But that can also easily be scripted by the user of the widget.
Or use the demo-stacks of the widget's author (I usually provide these) which
contain (parts of) setter and getter scripts.
[You can set the settable properties to an array. So you can get in just the same
way an array of gettable properties. This needs only a list of gettable/settable
properties in the dictionary.]

> Brian M. wrote:
> Now I’m really confused:
>
> put the properties of widget id 1004 into tA
>
> Results in an empty tA. If I put something into tA[“rect”] and then set the
> properties to tA then it does move to that rect.

That's correct(*). Setting tA is just an array of (valid) properties to set,
needed also when using a widget as popup.
The properties returns the widget property "properties" which is usually empty.

(*) "rect" is a LCS property of the widget, the widget author can currently set
such properties only by posting to the widget's script object.
From that it is a bug, all gettable/settable LCS properties of the widget
(see https://livecode.com/topic/accessing-livecode-control-properties/)
should populate the "the properties"-array (this list is missing "rect").


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: widget properties

J. Landman Gay via use-livecode
hh wrote:

 >> Richard G. wrote:
 >> I'm suggesting the engine have an enhancement to add
 >> the widget-specific info to the  universally-supported
 >> "the properties" info.
 >
 > It would be possible to simply add all the info that the property
 > inspector can display. But that can also easily be scripted by the
 > user of the widget.
 > Or use the demo-stacks of the widget's author (I usually provide
 > these) which contain (parts of) setter and getter scripts.

Exactly.  There are many workarounds available.

What's missing is support for the universal method by which we can
obtain property info, "the properties" function.

Given that the engine is apparently already able to obtain that info,
adding it to the universal mechanism for this should seem short work, no?

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

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: widget properties

J. Landman Gay via use-livecode
Not much has changed since this question was last asked:
http://lists.runrev.com/pipermail/use-livecode/2015-October/219630.html

The question here really is what you want to use the properties property
for. It is not correct to say that the properties property is used to
create the property inspector - 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

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. In the property definition files, they are split
up into control types (more like how widgets should be, i.e. one widget
kind per distinct functionality)

The VCS-related use case for an expanded properties property still exists
though, as far as I can tell, although 'properties' is kind of a bad name
for it. Actually I think it might be better to add 'export' syntax for
classic controls. The nice thing about the export syntax is that you get
exactly the distinct pieces of information required to reconstruct the
widget (according to the widget author's implementation). It might actually
be a completely distinct representation of the widget state than that
provided by a list of properties and their values (although in practice,
it's usually a subset of the properties).



On Sat, Feb 24, 2018 at 10:11 PM Richard Gaskin via use-livecode <
[hidden email]> wrote:

> hh wrote:
>
>  >> Richard G. wrote:
>  >> I'm suggesting the engine have an enhancement to add
>  >> the widget-specific info to the  universally-supported
>  >> "the properties" info.
>  >
>  > It would be possible to simply add all the info that the property
>  > inspector can display. But that can also easily be scripted by the
>  > user of the widget.
>  > Or use the demo-stacks of the widget's author (I usually provide
>  > these) which contain (parts of) setter and getter scripts.
>
> Exactly.  There are many workarounds available.
>
> What's missing is support for the universal method by which we can
> obtain property info, "the properties" function.
>
> Given that the engine is apparently already able to obtain that info,
> adding it to the universal mechanism for this should seem short work, no?
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   ____________________________________________________________________
>   [hidden email]                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: widget properties

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
> Richard G. wrote:
> What's missing is support for the universal method by which we can
> obtain property info, "the properties" function.

In order to work with a widget you have to know what the single properties
do. I can't see what should be the purpose of such a "full list".

> Given that the engine is apparently already able to obtain that info,
> adding it to the universal mechanism for this should seem short work, no?

Yes, this last part. Using "the properties" you can get what's implemented
for use in the property inspector, but NO short work for the author's part:

(a) The LCS-LCB conversions are not simple, e.g.
= Number-Text conversions (for lists),
= LCB hast true lists, LCS not,
= LCS has arrays with numbers as keys, LCB not.
The widget's author has to implement all such conversions.

(b) The property inspector has not enough (appropriate) tabs for a widget
with a lot of properties.

With my first widgets the properties-part needed up to 70% of work and
code lines. I have it down to 10% now and I will reduce that for new and
updated widgets to a short list (which is not a property).
Will introduce preferences files instead.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: widget properties

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
@Ali... I’ve been mulling over the very idea of extending the export
mechanism. What I would propose is to add an $object key that would contain
the engine related things required to recreate the widget. The same could
be done for any LC object (using $kind to identify the classic
control/object type or possibly just “classic control”). Possibly more than
one additional key. In theory, you could export a whole stack as an array
this way.

The export code currently just processes widgets, but a modification there
would not be that difficult. The functions used to load/save an object
would need mirror functions to load/return an array. Once that is done,
things higher up would need similar treatment (card/stack). I just have not
had the time to sit down and try to implement my thoughts.


> The VCS-related use case for an expanded properties property still exists
> though, as far as I can tell, although 'properties' is kind of a bad name
> for it. Actually I think it might be better to add 'export' syntax for
> classic controls. The nice thing about the export syntax is that you get
> exactly the distinct pieces of information required to reconstruct the
> widget (according to the widget author's implementation). It might actually
> be a completely distinct representation of the widget state than that
> provided by a list of properties and their values (although in practice,
> it's usually a subset of the properties).
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: widget properties

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
Ali Lloyd wrote:

 > Not much has changed since this question was last asked:
 > http://lists.runrev.com/pipermail/use-livecode/2015-October/219630.html

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


 > 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
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: widget properties

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
hh wrote:

 >> Richard G. wrote:
 >> What's missing is support for the universal method by which we can
 >> obtain property info, "the properties" function.
 >
 > In order to work with a widget you have to know what the single
 > properties do.

That is true of all objects of all properties.


 > I can't see what should be the purpose of such a "full list".

Consider the list I included in my reply to Ali, and spend some time
experimenting.  LC's associative arrays are very powerful and very
flexible.  With union and intersect, even more so.  All sorts of rapid
object styling, replication, serializing for transport, and so much more
becomes trivial and fun.


Sure, I could write my own functions to do this.  And if I'm the only
one who's interested it wouldn't take me long.

But the ease and power of this way of working with "the properties" has
become second nature to me because many years ago Kevin had the insight
to request that array from the then-engine-maintainer.  If he hadn't
asked for that, I might still be stuck in the ancient xTalk way of doing
these things, manually maintaining lists of properties and slavishly
applying them one at a time in line after line of long blocks of code.

So I'm good either way.  I'm just thinking about the next generation of
LiveCode scripters.

If we abandon "the properties" as the universal array representation for
all types, we either lose the value of that function by making it into a
"sometimes" thing, or reduce the value of widgets by not treating them
as "real" objects.

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

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: widget properties

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
On 02/24/2018 03:08 PM, Ali Lloyd via use-livecode wrote:

> The VCS-related use case for an expanded properties property still exists
> though, as far as I can tell, although 'properties' is kind of a bad name
> for it. Actually I think it might be better to add 'export' syntax for
> classic controls. The nice thing about the export syntax is that you get
> exactly the distinct pieces of information required to reconstruct the
> widget (according to the widget author's implementation). It might actually
> be a completely distinct representation of the widget state than that
> provided by a list of properties and their values (although in practice,
> it's usually a subset of the properties).

I've always found the property lists in the engine clumsy and hard to
maintain, in addition to them not being accessible outside the engine
other than getting a subset through "the properties".

It's actually very easy to reconstruct objects with a property list that
may contain non-settable entries. I do this with preference files all
the time to stay out of trouble...

local tList -- contains the cr-separated properties as
-- tPropertyName<tab>tValue

local tObject -- the object whose properties we're setting
local tProperty, tValue
repeat for each line tLine in tList
   put item 1 of tLine into tProperty
   put item 2 of tLine into tValue
   try
     set the tProperty of tObject to tValue
   end try
end repeat

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: widget properties

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
>
> 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.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: widget properties

J. Landman Gay via use-livecode
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
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: widget properties

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode


> On 26 Feb 2018, at 2:57 am, Ali Lloyd via use-livecode <[hidden email]> wrote:
>
> The trick is to ensure that the VCS use-case
> can be extricated.

I think probably the VCS use-case is a non-issue right now. I’m not sure if anyone is still using lcVCS but script only stacks + stackFiles with no scripts is significantly simpler to deal with. Either way export object covers that better.

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

Yes there is. If we include all the different forms of text for example (htmlText, text, rtfText, styledText) then we have to have even more complicated precedence rules than we currently do when setting.

I would suggest if we can look at all the metadata we need in the IDE about an object property and provide a way to access as much of that as possible by introspecting the object most people would be happy regardless of whether we provide an array prop to get and set it in one hit. Just about all the data is there already in the property tables.

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: widget properties

J. Landman Gay via use-livecode
Monte wrote:

 > I think probably the VCS use-case is a non-issue right now.

Agreed.


 >> 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.
 >
 > Yes there is. If we include all the different forms of text for
 > example (htmlText, text, rtfText, styledText) then we have to have
 > even more complicated precedence rules than we currently do when
 > setting.

FWIW, if it keeps things simpler I wouldn't change anything at all in
"the properties" beyond adding the export info for widgets.

Below I've copied the list of keys from getting "the properties" of a
field. Neither rtfText nor even text are there, because both are
permutations of the one form that covers what's needed to reproduce
field contents, htmlText.

Apparently a fair bit of thought went into "the properties".  Unless
there's a show-stopping need to alter it, I'd leave it as-is, add the
widget info, and move on to other tasks.

If something more complete or somehow different is needed in the future,
the future would be a good time to address it. :)  That is, maintain
what we have, and take your time thinking through a new form of this
sort of array representation of an object as that need becomes defined.
As much as I appreciate the interest in this, my own needs are modest,
and I know that you folks have quite a queue filled with other things.


altId
autoHilite
autoTab
backColor
backPattern
behavior
blendLevel
borderColor
borderPattern
borderWidth
bottomColor
bottomPattern
cantSelect
colorOverlay
cursorMovement
disabled
dontSearch
dontWrap
dropShadow
firstIndent
fixedLineHeight
focusColor
focusPattern
foreColor
forePattern
hGrid
hiliteColor
hilitedLines
hilitePattern
hScroll
hScrollbar
htmlText
id
ink
innerGlow
innerShadow
layer
layerMode
listBehavior
lockLoc
lockText
margins
multipleHilites
name
noncontiguousHilites
opaque
outerGlow
rect
scrollbarWidth
shadow
shadowColor
shadowOffset
shadowPattern
sharedText
showBorder
showFocusBorder
showLines
style
tabStops
textAlign
textDirection
textFont
textHeight
textSize
textStyle
threeD
threeDHilite
toggleHilites
toolTip
topColor
topPattern
traversalOn
vGrid
visible
vScroll
vScrollbar

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

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: widget properties

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
>
>
> > 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.
>
> Yes there is. If we include all the different forms of text for example
> (htmlText, text, rtfText, styledText) then we have to have even more
> complicated precedence rules than we currently do when setting.
>
> No there isn't, because if you aren't using it to completely import an
object (i.e. set the properties of obj1 to the properties of obj2) it's
your lookout what properties you include in the array to set - so just
don't include all the forms of text.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12