Re: Widget Properties

2020-04-25 Thread J. Landman Gay via use-livecode
Don't despair, not all widgets are duds. I've used several with good 
success: the browser widget, spinner, tree view, switch button, nav bar, 
segmented control and probably some others I can't remember. Since each 
widget is authored by an individual, the properties they support vary but 
like any software, feature requests are considered.


In my case I usually can't wait for a specific feature so I use LC controls 
or groups that emulate the control I need. In my last project I created a 
navigation bar with LC controls but it was recently updated to support a 
feature I needed and now I'm using it again.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On April 25, 2020 9:19:00 AM Graham Samuel via use-livecode 
 wrote:



Thanks Jacque

You’re adding to my gloom about widgets being offered as native controls - 
the only reason they were produced AFAIKS was to produce a superior result 
to whatever else was on offer, and if they don’t, why bother? I have a 
feeling not many people are trying to use them - you don’t for example, and 
so far nobody on this list has come to their defence. Perhaps LC’s widget 
factory is right to put their energies elsewhere.


Graham

On 25 Apr 2020, at 00:03, J. Landman Gay via use-livecode 
 wrote:


My suggestion was just to see what properties are available in the widget. 
But when I just tried it, I see that it doesn't respond in the IDE, what 
you see is just a placeholder. You can search for "ios native button" in 
the dictionary, where I see only two available properties: enabled and label.


If the widget author doesn't support the rest of them, they don't exist. I 
do see that you can resize the rectangle, but since I don't use the native 
buttons I'm not sure if the size will be retained on an iPhone or whether 
it just defaults to the standard native size.


Typically only the properties that the author has supported will appear in 
the property inspector.



On 4/24/20 3:35 PM, Graham Samuel via use-livecode wrote:
Thanks Jacque - info safely stored in my “how to make a mobile app look 
like one” archive!
Thanks for the other info about properties - how would you then refer to a 
property that isn’t shown in the Property Inspector for a widget, such as 
fontColor (or whatever)? I assume the array is just a way of accessing the 
whole collection and not the route to setting an individual property - but 
I’m probably wrong.

Graham
On 24 Apr 2020, at 20:26, J. Landman Gay via use-livecode 
 wrote:


On 4/24/20 3:37 AM, Graham Samuel via use-livecode wrote:
As my app took shape, I noticed how unlike a typical iPhone app it looked, 
mostly because I was using the controls I was familiar with, such as radio 
buttons and ordinary fields. I wondered if my users might find its 
interface unfamiliar. Therefore I have been seeking to make my app’s user 
interface look and feel more like other iPhone apps. I have already had a 
lot of help from this list, but it seems there is no one packaged solution 
to getting an ‘iPhone look and feel’.


You mentioned the iOS native button doesn't look right. If it makes you 
feel better, the Android one doesn't either. So what I did was use a 
round-rect graphic as a button. Set the linesize to 1 and the round radius 
to 8. You can set the border color and the text color.


I use the same graphic for Android. Sometimes Android buttons have a fill 
color, sometimes they are just borderless text. I adjust those properties 
based on platform. IOS buttons use sentence capitalization, Android buttons 
use all-caps. The label can be adjusted the same way based on platform.


It's an easy fix and looks native.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode



--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode






Re: Widget Properties

2020-04-25 Thread Graham Samuel via use-livecode
Thanks Jacque

You’re adding to my gloom about widgets being offered as native controls - the 
only reason they were produced AFAIKS was to produce a superior result to 
whatever else was on offer, and if they don’t, why bother? I have a feeling not 
many people are trying to use them - you don’t for example, and so far nobody 
on this list has come to their defence. Perhaps LC’s widget factory is right to 
put their energies elsewhere.

Graham

> On 25 Apr 2020, at 00:03, J. Landman Gay via use-livecode 
>  wrote:
> 
> My suggestion was just to see what properties are available in the widget. 
> But when I just tried it, I see that it doesn't respond in the IDE, what you 
> see is just a placeholder. You can search for "ios native button" in the 
> dictionary, where I see only two available properties: enabled and label.
> 
> If the widget author doesn't support the rest of them, they don't exist. I do 
> see that you can resize the rectangle, but since I don't use the native 
> buttons I'm not sure if the size will be retained on an iPhone or whether it 
> just defaults to the standard native size.
> 
> Typically only the properties that the author has supported will appear in 
> the property inspector.
> 
> 
> On 4/24/20 3:35 PM, Graham Samuel via use-livecode wrote:
>> Thanks Jacque - info safely stored in my “how to make a mobile app look like 
>> one” archive!
>> Thanks for the other info about properties - how would you then refer to a 
>> property that isn’t shown in the Property Inspector for a widget, such as 
>> fontColor (or whatever)? I assume the array is just a way of accessing the 
>> whole collection and not the route to setting an individual property - but 
>> I’m probably wrong.
>> Graham
>>> On 24 Apr 2020, at 20:26, J. Landman Gay via use-livecode 
>>>  wrote:
>>> 
>>> On 4/24/20 3:37 AM, Graham Samuel via use-livecode wrote:
 As my app took shape, I noticed how unlike a typical iPhone app it looked, 
 mostly because I was using the controls I was familiar with, such as radio 
 buttons and ordinary fields. I wondered if my users might find its 
 interface unfamiliar. Therefore I have been seeking to make my app’s user 
 interface look and feel more like other iPhone apps. I have already had a 
 lot of help from this list, but it seems there is no one packaged solution 
 to getting an ‘iPhone look and feel’.
>>> 
>>> You mentioned the iOS native button doesn't look right. If it makes you 
>>> feel better, the Android one doesn't either. So what I did was use a 
>>> round-rect graphic as a button. Set the linesize to 1 and the round radius 
>>> to 8. You can set the border color and the text color.
>>> 
>>> I use the same graphic for Android. Sometimes Android buttons have a fill 
>>> color, sometimes they are just borderless text. I adjust those properties 
>>> based on platform. IOS buttons use sentence capitalization, Android buttons 
>>> use all-caps. The label can be adjusted the same way based on platform.
>>> 
>>> It's an easy fix and looks native.
>>> 
>>> -- 
>>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>>> HyperActive Software   | http://www.hyperactivesw.com
>>> 
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: Widget Properties

2020-04-24 Thread J. Landman Gay via use-livecode
My suggestion was just to see what properties are available in the widget. But when I just 
tried it, I see that it doesn't respond in the IDE, what you see is just a placeholder. You can 
search for "ios native button" in the dictionary, where I see only two available properties: 
enabled and label.


If the widget author doesn't support the rest of them, they don't exist. I do see that you can 
resize the rectangle, but since I don't use the native buttons I'm not sure if the size will be 
retained on an iPhone or whether it just defaults to the standard native size.


Typically only the properties that the author has supported will appear in the 
property inspector.


On 4/24/20 3:35 PM, Graham Samuel via use-livecode wrote:

Thanks Jacque - info safely stored in my “how to make a mobile app look like 
one” archive!

Thanks for the other info about properties - how would you then refer to a 
property that isn’t shown in the Property Inspector for a widget, such as 
fontColor (or whatever)? I assume the array is just a way of accessing the 
whole collection and not the route to setting an individual property - but I’m 
probably wrong.

Graham


On 24 Apr 2020, at 20:26, J. Landman Gay via use-livecode 
 wrote:

On 4/24/20 3:37 AM, Graham Samuel via use-livecode wrote:

As my app took shape, I noticed how unlike a typical iPhone app it looked, 
mostly because I was using the controls I was familiar with, such as radio 
buttons and ordinary fields. I wondered if my users might find its interface 
unfamiliar. Therefore I have been seeking to make my app’s user interface look 
and feel more like other iPhone apps. I have already had a lot of help from 
this list, but it seems there is no one packaged solution to getting an ‘iPhone 
look and feel’.


You mentioned the iOS native button doesn't look right. If it makes you feel 
better, the Android one doesn't either. So what I did was use a round-rect 
graphic as a button. Set the linesize to 1 and the round radius to 8. You can 
set the border color and the text color.

I use the same graphic for Android. Sometimes Android buttons have a fill 
color, sometimes they are just borderless text. I adjust those properties based 
on platform. IOS buttons use sentence capitalization, Android buttons use 
all-caps. The label can be adjusted the same way based on platform.

It's an easy fix and looks native.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode




--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: Widget Properties

2020-04-24 Thread Graham Samuel via use-livecode
Thanks Jacque - info safely stored in my “how to make a mobile app look like 
one” archive!

Thanks for the other info about properties - how would you then refer to a 
property that isn’t shown in the Property Inspector for a widget, such as 
fontColor (or whatever)? I assume the array is just a way of accessing the 
whole collection and not the route to setting an individual property - but I’m 
probably wrong.

Graham

> On 24 Apr 2020, at 20:26, J. Landman Gay via use-livecode 
>  wrote:
> 
> On 4/24/20 3:37 AM, Graham Samuel via use-livecode wrote:
>> As my app took shape, I noticed how unlike a typical iPhone app it looked, 
>> mostly because I was using the controls I was familiar with, such as radio 
>> buttons and ordinary fields. I wondered if my users might find its interface 
>> unfamiliar. Therefore I have been seeking to make my app’s user interface 
>> look and feel more like other iPhone apps. I have already had a lot of help 
>> from this list, but it seems there is no one packaged solution to getting an 
>> ‘iPhone look and feel’.
> 
> You mentioned the iOS native button doesn't look right. If it makes you feel 
> better, the Android one doesn't either. So what I did was use a round-rect 
> graphic as a button. Set the linesize to 1 and the round radius to 8. You can 
> set the border color and the text color.
> 
> I use the same graphic for Android. Sometimes Android buttons have a fill 
> color, sometimes they are just borderless text. I adjust those properties 
> based on platform. IOS buttons use sentence capitalization, Android buttons 
> use all-caps. The label can be adjusted the same way based on platform.
> 
> It's an easy fix and looks native.
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: Widget Properties

2020-04-24 Thread Richard Gaskin via use-livecode

J. Landman Gay wrote:

> So what I did was use a round-rect graphic as a button. Set the
> linesize to 1 and the round radius to 8. You can set the border color
> and the text color.

Using the graphic is a much better choice than a roundRect button, 
because the button uses an older non-antialiased corner.


If any of the C programmers here have a few minutes, we could enjoy all 
the benefits roundRect button with appearances as good as a roundRect 
graphic with what Monte describes as a fairly minor bit of work:


   This is possibly a good user contribution. It's just wrapping
   the drawroundrect call with `dc -> setquality(QUALITY_SMOOTH);
   ` & `dc -> setquality(QUALITY_DEFAULT);`

https://quality.livecode.com/show_bug.cgi?id=21118

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: Widget Properties

2020-04-24 Thread J. Landman Gay via use-livecode

On 4/23/20 11:41 AM, Graham Samuel via use-livecode wrote:

  Hoping that other properties were just not showing up, I tried

   put the properties of widget “myWidget”

in the message box and got nothing, so I don’t know how to proceed.


The properties are an array so they won't display in the message box. I usually write a tiny 
one-line handler and put a breakpoint in so I can see the array in the variable pane.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: Widget Properties

2020-04-24 Thread J. Landman Gay via use-livecode

On 4/24/20 3:37 AM, Graham Samuel via use-livecode wrote:

As my app took shape, I noticed how unlike a typical iPhone app it looked, 
mostly because I was using the controls I was familiar with, such as radio 
buttons and ordinary fields. I wondered if my users might find its interface 
unfamiliar. Therefore I have been seeking to make my app’s user interface look 
and feel more like other iPhone apps. I have already had a lot of help from 
this list, but it seems there is no one packaged solution to getting an ‘iPhone 
look and feel’.


You mentioned the iOS native button doesn't look right. If it makes you feel better, the 
Android one doesn't either. So what I did was use a round-rect graphic as a button. Set the 
linesize to 1 and the round radius to 8. You can set the border color and the text color.


I use the same graphic for Android. Sometimes Android buttons have a fill color, sometimes they 
are just borderless text. I adjust those properties based on platform. IOS buttons use sentence 
capitalization, Android buttons use all-caps. The label can be adjusted the same way based on 
platform.


It's an easy fix and looks native.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: Widget Properties

2020-04-24 Thread Graham Samuel via use-livecode
Hello Scott

Just to keep you in the loop, I have been trying to produce a mobile app (right 
now it’s iPhone — Android may come later). I’m trying to do this as rapidly as 
possible (it is connected in a minor way to the lockdown measures for the 
pandemic).  I have lots of experience of LiveCode development but almost zero 
for mobile. 

As my app took shape, I noticed how unlike a typical iPhone app it looked, 
mostly because I was using the controls I was familiar with, such as radio 
buttons and ordinary fields. I wondered if my users might find its interface 
unfamiliar. Therefore I have been seeking to make my app’s user interface look 
and feel more like other iPhone apps. I have already had a lot of help from 
this list, but it seems there is no one packaged solution to getting an ‘iPhone 
look and feel’. As LC offers some ‘native’ controls, I tried to use the maximum 
of these - I even paid for a pack of native widgets. That’s why I was using the 
button widget.

So far the results have been disappointing in the widget line, although other 
features like mobilePick and the choice of soft keyboards have worked well. On 
the whole up to now, the widget solutions have only been marginally helpful. 

Hope that explains it - probably more than you want to know!

Graham

> On 23 Apr 2020, at 22:32, scott--- via use-livecode 
>  wrote:
> 
> Hello Graham,
> 
> Sorry if I missed this earlier but, what made you go with a button widget 
> rather than just using a standard LiveCode button?
> 
> —
> Scott
> 
>> On Apr 23, 2020, at 9:41 AM, Graham Samuel via use-livecode 
>>  wrote:
>> 
>> I am getting rather fed up with the widgets I’ve been trying to use for my 
>> mobile app. For example, the iOS button widget (a press button, not a 
>> switch) has so few properties that you can’t change the colour of the text 
>> in any way I could see and sometimes mine turn out blue or red for no 
>> apparent reason. Hoping that other properties were just not showing up, I 
>> tried
>> 
>> put the properties of widget “myWidget”
>> 
>> in the message box and got nothing, so I don’t know how to proceed. 
>> 
>> I also hate that the object doesn’t have a label separate from its name. I 
>> would never recommend anyone to put spaces in names of objects for 
>> scripting, but of course they’re essential for many kinds of label seen by a 
>> user, so the two different strings which work in normal LC are essential, in 
>> my opinion.
>> 
>> Oh dear, this has some danger of becoming a rant…
>> 
>> Graham
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: Widget Properties

2020-04-23 Thread scott--- via use-livecode
Hello Graham,

Sorry if I missed this earlier but, what made you go with a button widget 
rather than just using a standard LiveCode button?

—
Scott

> On Apr 23, 2020, at 9:41 AM, Graham Samuel via use-livecode 
>  wrote:
> 
> I am getting rather fed up with the widgets I’ve been trying to use for my 
> mobile app. For example, the iOS button widget (a press button, not a switch) 
> has so few properties that you can’t change the colour of the text in any way 
> I could see and sometimes mine turn out blue or red for no apparent reason. 
> Hoping that other properties were just not showing up, I tried
> 
>  put the properties of widget “myWidget”
> 
> in the message box and got nothing, so I don’t know how to proceed. 
> 
> I also hate that the object doesn’t have a label separate from its name. I 
> would never recommend anyone to put spaces in names of objects for scripting, 
> but of course they’re essential for many kinds of label seen by a user, so 
> the two different strings which work in normal LC are essential, in my 
> opinion.
> 
> Oh dear, this has some danger of becoming a rant…
> 
> Graham
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Widget Properties

2020-04-23 Thread Graham Samuel via use-livecode
I am getting rather fed up with the widgets I’ve been trying to use for my 
mobile app. For example, the iOS button widget (a press button, not a switch) 
has so few properties that you can’t change the colour of the text in any way I 
could see and sometimes mine turn out blue or red for no apparent reason. 
Hoping that other properties were just not showing up, I tried

  put the properties of widget “myWidget”

in the message box and got nothing, so I don’t know how to proceed. 

I also hate that the object doesn’t have a label separate from its name. I 
would never recommend anyone to put spaces in names of objects for scripting, 
but of course they’re essential for many kinds of label seen by a user, so the 
two different strings which work in normal LC are essential, in my opinion.

Oh dear, this has some danger of becoming a rant…

Graham
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-27 Thread Bob Sneidar via use-livecode
+1 Sounds like a good idea. The only bugaboo I see is if the properties of a 
widget were in some other format than an LC string, but I don't know that. 

Bob S


> On Feb 24, 2018, at 12:19 , Richard Gaskin via use-livecode 
>  wrote:
> 
> [This message was identified as a phishing scam. Learn about phishing at 
> http://aka.ms/LearnAboutPhishing]
> 
> 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
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-26 Thread Richard Gaskin via use-livecode

Ali Lloyd wrote:

> Essentially my point of view is that a properties property should
> return all properties. Otherwise it can't really work with widgets.

Would it simplify things if what is needed for widgets is done for 
widgets, and the current data derived from engine-native objects remains 
as-is?


--
 Richard Gaskin
 Fourth World Systems

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-25 Thread Ali Lloyd via use-livecode
You didn't misunderstand, that is (almost) exactly what I'm suggesting
(once we had import/export for all objects), although I think the way set
works should probably be tweaked so that we *don't* do any manual fettling
- we just document that setting certain groups of properties via the
properties is undefined behavior. If you want to set *all* the properties
of an object to the same as another, don't do it like that, use
export/import instead.

Essentially my point of view is that a properties property should return
all properties. Otherwise it can't really work with widgets. The manual
fettling for the order of properties to set isn't really compatible with
the fact that widget authors can define properties in innumerable ways that
we don't know in advance, unless we force widget authors to provide the
equivalent of the engine's s_preprocess_props.

I just realised though that you can't set if it's a function, so it would
have to be a property, and then you couldn't include the properties
property :-(

On Mon, Feb 26, 2018 at 3:20 AM Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> I must have misunderstood. I thought you were proposing adding all
> gettable properties to the properties and not changing the way set works
> (i.e. iterating all elements and setting them one at a time).
>
> Cheers
>
> Monte
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-25 Thread Brian Milby via use-livecode
Looking at the source, when a stack is saved, here is the general flow for
an individual widget (widget.cpp):

OnSave called to get internal widget state (array)
Write uint1 OT_WIDGET to indicate a widget
Save the object state
Save the widget kind
Save the internal widget state
Save the property sets

Suggestion is to add the object state ($object) and property sets ($props)
to the existing export array.

Once the object state function was in place, most of the work to add other
classic controls would already be done.

The couple of OnLoad handlers that I’ve looked into seem to handle extra
data fine since it is just ignored. It gets lost on save though. This is
some of the things that came to light when vertical was added to the
segmented control. This should not have any impact to this idea.
On Sun, Feb 25, 2018 at 10:10 PM Brian Milby  wrote:

> I’m not sure I follow.  The proposal I’m making is no different than what
> the engine does today, just allowing the same information to be saved to an
> array.  The internal state of the widget is the same as what would be used
> on export/import.  It just adds the other properties (rect, ...) to the
> array.
>
> I’ll need to look again, but I think that export uses OnSave to get the
> array.  Import uses OnLoad.  This would save the step of setting the other
> properties.
>
> On Sun, Feb 25, 2018 at 10:02 PM hh via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> > Brian M. wrote:
>> > My 0.02 is that export should mirror what the engine saves to the stack
>> > file such that import could exactly recreate an object (with some logic
>> on
>> > how to handle ID collisions - overwrite, throw error, assign new ID...)
>>
>> If you are developing and testing a widget this would make you crazy.
>> What I want are some persistent properties from "OnSave" and "OnLoad" but
>> NOT the saved state of a probable buggy widget.
>>
>> And if I open a stack half a year later while the widget was updated,
>> then I want, as it is currently, the new version without deleting and
>> reinstalling all widgets of that kind (think of a stack that has a lot of
>> svg-icon-widgets).
>>
>>
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: widget properties

2018-02-25 Thread Brian Milby via use-livecode
I’m not sure I follow.  The proposal I’m making is no different than what
the engine does today, just allowing the same information to be saved to an
array.  The internal state of the widget is the same as what would be used
on export/import.  It just adds the other properties (rect, ...) to the
array.

I’ll need to look again, but I think that export uses OnSave to get the
array.  Import uses OnLoad.  This would save the step of setting the other
properties.

On Sun, Feb 25, 2018 at 10:02 PM hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

> > Brian M. wrote:
> > My 0.02 is that export should mirror what the engine saves to the stack
> > file such that import could exactly recreate an object (with some logic
> on
> > how to handle ID collisions - overwrite, throw error, assign new ID...)
>
> If you are developing and testing a widget this would make you crazy.
> What I want are some persistent properties from "OnSave" and "OnLoad" but
> NOT the saved state of a probable buggy widget.
>
> And if I open a stack half a year later while the widget was updated,
> then I want, as it is currently, the new version without deleting and
> reinstalling all widgets of that kind (think of a stack that has a lot of
> svg-icon-widgets).
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: widget properties

2018-02-25 Thread Brian Milby via use-livecode
Exactly... that would be the overwrite option I was thinking about.

import object from array tMyArray [with OverwriteID]
import object from array tMyArray [with AutoID]

If neither option specified and the ID exists, an error would be thrown.
On Sun, Feb 25, 2018 at 9:52 PM Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
>
> > On 26 Feb 2018, at 2:47 pm, Brian Milby  wrote:
> >
> > My 0.02 is that export should mirror what the engine saves to the stack
> file such that import could exactly recreate an object (with some logic on
> how to handle ID collisions - overwrite, throw error, assign new ID...)
>
> Yes that makes sense. It would also be nice if we could somehow apply that
> exported data to an existing object.
>
> Cheers
>
> Monte
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-25 Thread hh via use-livecode
> Brian M. wrote:
> My 0.02 is that export should mirror what the engine saves to the stack
> file such that import could exactly recreate an object (with some logic on
> how to handle ID collisions - overwrite, throw error, assign new ID...)

If you are developing and testing a widget this would make you crazy.
What I want are some persistent properties from "OnSave" and "OnLoad" but
NOT the saved state of a probable buggy widget.

And if I open a stack half a year later while the widget was updated,
then I want, as it is currently, the new version without deleting and
reinstalling all widgets of that kind (think of a stack that has a lot of
svg-icon-widgets).


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-25 Thread Monte Goulding via use-livecode


> On 26 Feb 2018, at 2:47 pm, Brian Milby  wrote:
> 
> My 0.02 is that export should mirror what the engine saves to the stack file 
> such that import could exactly recreate an object (with some logic on how to 
> handle ID collisions - overwrite, throw error, assign new ID...)

Yes that makes sense. It would also be nice if we could somehow apply that 
exported data to an existing object.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-25 Thread Brian Milby via use-livecode
My 0.02 is that export should mirror what the engine saves to the stack
file such that import could exactly recreate an object (with some logic on
how to handle ID collisions - overwrite, throw error, assign new ID...)
On Sun, Feb 25, 2018 at 9:21 PM Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
>
> > On 26 Feb 2018, at 9:45 am, Ali Lloyd via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> >> 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.
>
> I must have misunderstood. I thought you were proposing adding all
> gettable properties to the properties and not changing the way set works
> (i.e. iterating all elements and setting them one at a time).
>
> Cheers
>
> Monte
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-25 Thread Monte Goulding via use-livecode


> On 26 Feb 2018, at 9:45 am, Ali Lloyd via use-livecode 
>  wrote:
> 
>> 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.

I must have misunderstood. I thought you were proposing adding all gettable 
properties to the properties and not changing the way set works (i.e. iterating 
all elements and setting them one at a time).

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-25 Thread Ali Lloyd 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-25 Thread Richard Gaskin 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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-25 Thread Monte Goulding via use-livecode


> On 26 Feb 2018, at 2:57 am, Ali Lloyd via use-livecode 
>  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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: widget properties

2018-02-25 Thread Richard Gaskin 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  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" ).  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  should actually be a function, to
> avoid there always being a property that (for obvious reasons) 

Re: widget properties

2018-02-25 Thread Ali Lloyd 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  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 

Re: widget properties

2018-02-24 Thread Mark Wieder 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
-- tPropertyNametValue

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
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-24 Thread Richard Gaskin 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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-24 Thread Richard Gaskin 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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-24 Thread Brian Milby 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: widget properties

2018-02-24 Thread hh 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-24 Thread Ali Lloyd 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 <
use-livecode@lists.runrev.com> 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
>   
>   ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-24 Thread Richard Gaskin 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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-24 Thread hh 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: widget properties

2018-02-24 Thread Richard Gaskin 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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-24 Thread Brian Milby 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  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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: widget properties

2018-02-24 Thread Brian Milby 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-24 Thread hh 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: widget properties

2018-02-24 Thread Brian Milby 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  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 <
> use-livecode@lists.runrev.com> 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
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: widget properties

2018-02-24 Thread Brian Milby 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 <
use-livecode@lists.runrev.com> 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
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


widget properties

2018-02-24 Thread Richard Gaskin 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: Widget properties

2017-10-23 Thread Bob Sneidar via use-livecode
The answer to that question may be academic. But the best answer I can come up 
with is that mobile devices are fundamentally different than desktop devices. 
It's already an amazing thing to get a single layout to display in the various 
desktop operating systems in a consistent manner, and Windows/Mac/Unix/Linux 
are similar enough for that. iOS and Android are vastly different interfaces, 
so to look and behave "natively" on these requires in many instances a 
different kind of object. 

It is not a big chore, but you can create your own "scalable" radio buttons 
from regular buttons and some reasonably high resolution images, or even just 
the images themselves. That is one of the great things about livecode. You can 
with some ingenuity create your own custom controls. 

Bob S


> On Oct 22, 2017, at 05:35 , Pyyhtiä Christer via use-livecode 
>  wrote:
> 
> When fixing a problem with non-scaling radio buttons one solution was to use 
> widget switch button, which can be scaled.
> 
> Now it appears that those buttons do not retain the setup theme, but you need 
> to redo it at every stack startup.  Why not.
> 
> Actually the first question is why can't the LiveCode team make the radio 
> buttons scalable?  Using those on a mobile device you hardly see what the 
> hilite status is.
> 
> 
> Christer Pyyhtiä
> chris...@mindcrea.com
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Widget properties

2017-10-22 Thread Pyyhtiä Christer via use-livecode
When fixing a problem with non-scaling radio buttons one solution was to use 
widget switch button, which can be scaled.

Now it appears that those buttons do not retain the setup theme, but you need 
to redo it at every stack startup.  Why not.

Actually the first question is why can't the LiveCode team make the radio 
buttons scalable?  Using those on a mobile device you hardly see what the 
hilite status is.


Christer Pyyhtiä
chris...@mindcrea.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Widget Properties

2015-10-11 Thread Mark Waddingham

On 2015-10-11 02:18, Monte Goulding wrote:

Yes this is an odd one which I’ve queried before. You can now use
export widget to array to get the widget defined properties as they
will be saved. I don’t think this includes the base object properties
like visible, rect, disabled etc though. This is one of the things I
need to investigate if I ever have time to get lcVCS working on LC 8…


Well I added a minimal 'export widget to array' command precisely for 
use by lcVCS (as well as the 'is really a ' operators).


As it stands it returns a standard array structure which encodes the 
internal state required by a widget to reconstruct it's portion of 
things. The eventual aim is that the command will work on any object to 
return its internal structure in a similar way.


The 'parent' properties aren't currently there because none of the 
engine object classes (apart from Widget) currently implement an 
appropriate 'export to array' mechanism; and I figured it would be easy 
enough for you to leverage existing lcVCS code to fetch the small set of 
base properties that also need to be saved.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Widget Properties

2015-10-11 Thread Mark Wieder

On 10/10/2015 11:11 PM, Monte Goulding wrote:


No I haven’t reported it. I got the impression from the discussion that it was 
never intended to support the properties so it wouldn’t happen. I’m about to 
propose (on the engine forum) a refactor of the properties property (which I’ll 
do if they want me to) that will essentially make the properties property self 
maintaining rather than the current situation which means the list of 
properties for an object type needs to be maintained manually. This wasn’t 
possible before the refactor and there’s still a few issues like identifying 
which synonym of a property is the one to use in the properties array and which 
properties should be in the array. The end result will mean the properties of a 
widget will be kind + the standard properties for a control + the standard 
properties for an object.


Oh, please do. I hate that manual updating thing.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Widget Properties

2015-10-11 Thread Monte Goulding

> On 11 Oct 2015, at 5:26 pm, Mark Wieder  wrote:
> 
> On 10/10/2015 11:11 PM, Monte Goulding wrote:
> 
>> No I haven’t reported it. I got the impression from the discussion that it 
>> was never intended to support the properties so it wouldn’t happen. I’m 
>> about to propose (on the engine forum) a refactor of the properties property 
>> (which I’ll do if they want me to) that will essentially make the properties 
>> property self maintaining rather than the current situation which means the 
>> list of properties for an object type needs to be maintained manually. This 
>> wasn’t possible before the refactor and there’s still a few issues like 
>> identifying which synonym of a property is the one to use in the properties 
>> array and which properties should be in the array. The end result will mean 
>> the properties of a widget will be kind + the standard properties for a 
>> control + the standard properties for an object.
> 
> Oh, please do. I hate that manual updating thing.

Here’s what I’m thinking:

http://forums.livecode.com/viewtopic.php?f=66=25563 


If I get the go ahead there’s going to be bucket loads trivial changes and 
stuff like identifying which token is a synonym and which is the official 
token. Things like rect and rectangle are curly because just about nobody uses 
rectangle yet obviously rect is the synonym and has been used in the properties 
property for as long as it has existed...

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Widget Properties

2015-10-11 Thread Monte Goulding

> On 11 Oct 2015, at 8:08 pm, Mark Waddingham  wrote:
> 
> I don't think we have ever had the intention not to update the properties 
> property to make it work for widgets - we just haven't done so yet.
> 
> Part of the reason for this is that 'the properties' property is quite 
> ill-posed. As it stands it is essentially 'the properties needed to recreate 
> the object' (after the work Monte did on it a couple of years ago); however 
> that concept is difficult as it actually requires hard-coded rules in it to 
> ensure that when you set 'the properties' the properties are set in the 
> correct order.

Oh, yeah that was a headache working all that out...
> 
> Widgets complicate matters somewhat. We make no requirement that the state a 
> widget must preserve to recreate itself be directly related to the properties 
> you actually set (this is actually also true of existing engine controls - 
> hence why there is a need for 'hardcoded' rules in the properties property 
> implementation).
> 
> Now, I'm not saying this situation is ideal, there are various things we 
> could do in the future to make widgets easier to write if they follow the 
> rule that 'there should be a set of persistent properties which don't overlap 
> and fully faithfully allow recreation of the object' (for widgets that claim 
> to be this, they wouldn't need an OnSave / OnLoad handler as the engine could 
> synthesise one).

Nice idea
> 
> However, that doesn't change the fact that currently engine controls don't 
> follow that rule and I'd be loathe to put a restriction on all widgets in 
> that fashion as I cannot forsee the widgets people might wish to write.
> 
> Basically there is a bit distinction between:
> 
>  1) The data you need to recreate an object (this is what lcVCS needs).
> 
>  2) The information you need to provide good introspection on created objects 
> (this is what the IDE / inspectors etc. need).
> 
> Right now, I'd be incredibly dubious if a single 'properties' property could 
> be made to handle both these uses - the lengthy thread a couple of years ago 
> on this precise topic made that absolutely clear.
> 
> Moreover, we have worked quite hard in the IDE to provide a mechanism for (2) 
> - it is what the new property inspector is based on - i.e. APIs for returning 
> information and data about objects in the environment.

Yes, 2 is not really my concern. Having said that I’m not really sure why some 
of the stuff in the manifest (handlers and properties) couldn’t have just been 
done by introspection. Was it necessary to know all that stuff before loading 
the extension? I can understand the dependencies, icon, name etc but the 
handlers and properties seems a missed opportunity as it looks like they are 
available in the exported definitions.

Re 1 a possibility could be some combination of the properties and the exported 
array from OnSave. The properties of a widget could be something like:

- kind
- control & object props (rect, visible etc)
- state
- the stuff in the $state key from the exported array

The only problem here is you can’t just create a blank widget and set the kind 
like this so its probably not worthwhile having kind in there. The rest could 
work fine and the widget author is in full control of how the state array is 
parsed.

However, it may be better to just deprecate the properties and finish the 
export to array stuff.

Cheers

Monte

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Widget Properties

2015-10-11 Thread Mark Waddingham

On 2015-10-11 12:31, Monte Goulding wrote:

Yes, 2 is not really my concern. Having said that I’m not really sure
why some of the stuff in the manifest (handlers and properties)
couldn’t have just been done by introspection. Was it necessary to
know all that stuff before loading the extension? I can understand the
dependencies, icon, name etc but the handlers and properties seems a
missed opportunity as it looks like they are available in the exported
definitions.


It's not about needing to know it before the extension is loaded, it is 
more about where the appropriate information is stored.


The widget module file stores all the code / embedding related things 
(so compiled bytecode, public handler definitions, property definitions 
etc.) but it doesn't contain anything that might be called 'metadata' - 
things like the name of the editor widget to use for a particular 
property (which is not necessarily related to its type).


Therefore, the manifest file stores all the metadata which is not 
related to the actually running of the widget as well as the exported 
public definitions in an easy to access way. (Basically, we needed 
sideline information which wasn't suitable for inclusion in the actual 
module format, and thus it seemed sensible to put the other information 
the IDE would need in the manifest too rather than it having to both 
interrogate an XML file *and* introspect on the loaded module).


At some point the metadata expressed in widget lcb files might well get 
put into the compiled module blob - but it seemed more expedient whilst 
developing the ideas to keep it separate as it is easier to change the 
XML format that is emitted and read than it is the compiled module blob 
format.



Re 1 a possibility could be some combination of the properties and the
exported array from OnSave. The properties of a widget could be
something like:

- kind
- control & object props (rect, visible etc)
- state
- the stuff in the $state key from the exported array

The only problem here is you can’t just create a blank widget and set
the kind like this so its probably not worthwhile having kind in
there. The rest could work fine and the widget author is in full
control of how the state array is parsed.


That was essentially what I was envisaging.

You shouldn't think of a 'widget' as being something which can change 
its kind. A widget takes on its kind when it is created, so the 'kind' 
property falls into the same class as 'button' or 'field'. So you create 
a widget of a given kind *then* set its state.



However, it may be better to just deprecate the properties and finish
the export to array stuff.


The export to array stuff is the best (future) basis for things such as 
lcVCS. Indeed eventually, if it was rolled out across all engine 
objects, the stackfile format would become 
arrayEncode(stackExportedToArray("my stack")) - although that would 
require a much more efficient arrayEncode format (something which has 
been at the back of my mind for ages - but nothing I've had time to put 
into action).


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Widget Properties

2015-10-11 Thread Mark Waddingham

On 2015-10-11 08:11, Monte Goulding wrote:

On 11 Oct 2015, at 11:36 am, Peter Haworth  wrote:

Thanks Monte.  Maybe I should file a QCC report or have you already 
done so?


No I haven’t reported it. I got the impression from the discussion
that it was never intended to support the properties so it wouldn’t
happen. I’m about to propose (on the engine forum) a refactor of the
properties property (which I’ll do if they want me to) that will
essentially make the properties property self maintaining rather than
the current situation which means the list of properties for an object
type needs to be maintained manually. This wasn’t possible before the
refactor and there’s still a few issues like identifying which synonym
of a property is the one to use in the properties array and which
properties should be in the array. The end result will mean the
properties of a widget will be kind + the standard properties for a
control + the standard properties for an object.


I don't think we have ever had the intention not to update the 
properties property to make it work for widgets - we just haven't done 
so yet.


Part of the reason for this is that 'the properties' property is quite 
ill-posed. As it stands it is essentially 'the properties needed to 
recreate the object' (after the work Monte did on it a couple of years 
ago); however that concept is difficult as it actually requires 
hard-coded rules in it to ensure that when you set 'the properties' the 
properties are set in the correct order.


Widgets complicate matters somewhat. We make no requirement that the 
state a widget must preserve to recreate itself be directly related to 
the properties you actually set (this is actually also true of existing 
engine controls - hence why there is a need for 'hardcoded' rules in the 
properties property implementation).


Now, I'm not saying this situation is ideal, there are various things we 
could do in the future to make widgets easier to write if they follow 
the rule that 'there should be a set of persistent properties which 
don't overlap and fully faithfully allow recreation of the object' (for 
widgets that claim to be this, they wouldn't need an OnSave / OnLoad 
handler as the engine could synthesise one).


However, that doesn't change the fact that currently engine controls 
don't follow that rule and I'd be loathe to put a restriction on all 
widgets in that fashion as I cannot forsee the widgets people might wish 
to write.


Basically there is a bit distinction between:

  1) The data you need to recreate an object (this is what lcVCS needs).

  2) The information you need to provide good introspection on created 
objects (this is what the IDE / inspectors etc. need).


Right now, I'd be incredibly dubious if a single 'properties' property 
could be made to handle both these uses - the lengthy thread a couple of 
years ago on this precise topic made that absolutely clear.


Moreover, we have worked quite hard in the IDE to provide a mechanism 
for (2) - it is what the new property inspector is based on - i.e. APIs 
for returning information and data about objects in the environment.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Widget Properties

2015-10-11 Thread Monte Goulding

> On 11 Oct 2015, at 11:36 am, Peter Haworth  wrote:
> 
> Thanks Monte.  Maybe I should file a QCC report or have you already done so?

No I haven’t reported it. I got the impression from the discussion that it was 
never intended to support the properties so it wouldn’t happen. I’m about to 
propose (on the engine forum) a refactor of the properties property (which I’ll 
do if they want me to) that will essentially make the properties property self 
maintaining rather than the current situation which means the list of 
properties for an object type needs to be maintained manually. This wasn’t 
possible before the refactor and there’s still a few issues like identifying 
which synonym of a property is the one to use in the properties array and which 
properties should be in the array. The end result will mean the properties of a 
widget will be kind + the standard properties for a control + the standard 
properties for an object. 

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Widget Properties

2015-10-11 Thread Peter Haworth
On Sun, Oct 11, 2015 at 2:08 AM, Mark Waddingham <m...@livecode.com> wrote:

> Moreover, we have worked quite hard in the IDE to provide a mechanism for
> (2) - it is what the new property inspector is based on - i.e. APIs for
> returning information and data about objects in the environment.
>

Hi Mark,
The PI for a widget includes some of the non-widget properties such as ink,
blendlevel, size and position info, text info, and a few others.  Is there
an API to get a list of which non-widget properties are available or are
they hard coded into the PI?

Thanks,

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: Widget Properties

2015-10-11 Thread Peter Haworth
You have my vote to go ahead with that and thanks for proposing it.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Sat, Oct 10, 2015 at 11:44 PM, Monte Goulding <
mo...@sweattechnologies.com> wrote:

>
> > On 11 Oct 2015, at 5:26 pm, Mark Wieder  wrote:
> >
> > On 10/10/2015 11:11 PM, Monte Goulding wrote:
> >
> >> No I haven’t reported it. I got the impression from the discussion that
> it was never intended to support the properties so it wouldn’t happen. I’m
> about to propose (on the engine forum) a refactor of the properties
> property (which I’ll do if they want me to) that will essentially make the
> properties property self maintaining rather than the current situation
> which means the list of properties for an object type needs to be
> maintained manually. This wasn’t possible before the refactor and there’s
> still a few issues like identifying which synonym of a property is the one
> to use in the properties array and which properties should be in the array.
> The end result will mean the properties of a widget will be kind + the
> standard properties for a control + the standard properties for an object.
> >
> > Oh, please do. I hate that manual updating thing.
>
> Here’s what I’m thinking:
>
> http://forums.livecode.com/viewtopic.php?f=66=25563 <
> http://forums.livecode.com/viewtopic.php?f=66=25563>
>
> If I get the go ahead there’s going to be bucket loads trivial changes and
> stuff like identifying which token is a synonym and which is the official
> token. Things like rect and rectangle are curly because just about nobody
> uses rectangle yet obviously rect is the synonym and has been used in the
> properties property for as long as it has existed...
>
> Cheers
>
> Monte
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Widget Properties

2015-10-11 Thread Monte Goulding

> On 11 Oct 2015, at 10:10 pm, Mark Waddingham  wrote:
> 
> Basically, we needed sideline information which wasn't suitable for inclusion 
> in the actual module format, and thus it seemed sensible to put the other 
> information the IDE would need in the manifest too rather than it having to 
> both interrogate an XML file *and* introspect on the loaded module).

Ah, forgot about stuff like property editors being in there.
> 
> At some point the metadata expressed in widget lcb files might well get put 
> into the compiled module blob - but it seemed more expedient whilst 
> developing the ideas to keep it separate as it is easier to change the XML 
> format that is emitted and read than it is the compiled module blob format.

Fair enough

> The export to array stuff is the best (future) basis for things such as 
> lcVCS. Indeed eventually, if it was rolled out across all engine objects, the 
> stackfile format would become arrayEncode(stackExportedToArray("my stack")) - 
> although that would require a much more efficient arrayEncode format 
> (something which has been at the back of my mind for ages - but nothing I've 
> had time to put into action).

Wouldn’t it also bloat the file format considerably with array keys? I guess 
the advantages will probably outweigh the disadvantages though. You would never 
need to worry about file format changes again unless you had to change the 
arrayEncode format.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Widget Properties

2015-10-10 Thread Monte Goulding

> On 11 Oct 2015, at 11:06 am, Peter Haworth  wrote:
> 
> I assume widgets can have standard LC built-in properties as well as their
> own specific properties?
> 
> For example if I set the disabled of a widget, it no longer reacts to mouse
> clicks, but if I get its properties, they are empty.
> 
> I know widgets have their own property definitions but I would have thought
> any of the standard built-in properties would have been returned by their
> properties property.

Yes this is an odd one which I’ve queried before. You can now use export widget 
to array to get the widget defined properties as they will be saved. I don’t 
think this includes the base object properties like visible, rect, disabled etc 
though. This is one of the things I need to investigate if I ever have time to 
get lcVCS working on LC 8…

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Widget Properties

2015-10-10 Thread Peter Haworth
Thanks Monte.  Maybe I should file a QCC report or have you already done so?

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Sat, Oct 10, 2015 at 5:18 PM, Monte Goulding  wrote:

>
> > On 11 Oct 2015, at 11:06 am, Peter Haworth  wrote:
> >
> > I assume widgets can have standard LC built-in properties as well as
> their
> > own specific properties?
> >
> > For example if I set the disabled of a widget, it no longer reacts to
> mouse
> > clicks, but if I get its properties, they are empty.
> >
> > I know widgets have their own property definitions but I would have
> thought
> > any of the standard built-in properties would have been returned by their
> > properties property.
>
> Yes this is an odd one which I’ve queried before. You can now use export
> widget to array to get the widget defined properties as they will be saved.
> I don’t think this includes the base object properties like visible, rect,
> disabled etc though. This is one of the things I need to investigate if I
> ever have time to get lcVCS working on LC 8…
>
> Cheers
>
> Monte
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Widget Properties

2015-10-10 Thread Peter Haworth
I assume widgets can have standard LC built-in properties as well as their
own specific properties?

For example if I set the disabled of a widget, it no longer reacts to mouse
clicks, but if I get its properties, they are empty.

I know widgets have their own property definitions but I would have thought
any of the standard built-in properties would have been returned by their
properties property.


Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode