Re: Counting unique items in a file

2020-04-28 Thread Jim Lambert via use-livecode
function getUniqueNames inData,pColumn
split inData by column

split inData[pColumn] by return and return

combine inData[pColumn] by return and space

return inData[pColumn]

end getUniqueNames


Jim Lambert
___
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: Three very simple questions

2020-04-28 Thread dunbarx--- via use-livecode
The user guide?
It certainly is searchable. I do it all the time.
Craig


-Original Message-
From: Graham Samuel via use-livecode 
To: How to use LiveCode 
Cc: Graham Samuel 
Sent: Tue, Apr 28, 2020 3:44 pm
Subject: Re: Three very simple questions

Bill, I think you’re right about the Guide not being searchable. I was going to 
point it out myself, but I began to think that I had used up my grumbling 
allowance, or at least I had not much left and needed to use it for other 
things.

Of course the Giude should be searchable!

Graham

Re grumbling - I have always been delighted by the way people on this list come 
to each other’s aid. This ‘invisible college’ is a really essential part of the 
LiveCode experience, I believe. I hope I say ‘thank you’ enough.



> On 26 Apr 2020, at 23:52, prothero--- via use-livecode 
>  wrote:
> 
> Folks:
> I think Graham is doing LiveCode a favor by pointing out some of the ways a 
> newby (even though he isn’t) might get messed up when learning LiveCode. We 
> all get used to various approaches and newbies (even tho Graham isn’t) alert 
> us to impediments for that very vital population of potential or new users.
> 
> One thing that has bugged me is that when I click on the dictionary, I get a 
> nice display of commands, etc, searchable. But when I click on the “Guide” 
> tab, I get what looks like a very informative document. However, if I’m 
> looking for a particular task and want to do a search, there is none. So, it 
> seems to me like a very valuable newby document is crippled by the omission 
> of a very basic feature.
> 
> Or have I just missed something?
> 
> Best,
> Bill
> 
> William A. Prothero
> Santa Barbara, CA. 93105
> http://earthlearningsolutions.org/
> 
>> On Apr 26, 2020, at 12:23 PM, Mark Wieder via use-livecode 
>>  wrote:
>> 
>> On 4/26/20 12:09 PM, Sannyasin Brahmanathaswami via use-livecode wrote:
>>> "globals are evil"
>>> But we use  one array
>>> Global gConfigA
>>> and we stuff it with all manner of "things" including another arrays
>>> it turns about to quite useful
>> 
>> Yes, I do what you and Jacque do as a workaround, of course. I recently 
>> implemented a feature management infrastructure the same way, given the lack 
>> of globally available constants.
>> 
>> on preOpenStack
>> global gFeatures
>> put "feature1,feature2,feature3" into gFeatures
>> end preOpenStack
>> 
>> ...some other stack
>> 
>> global gfeatures
>> if "feature2" is among the items of gfeatures then
>> ...
>> 
>> on closeStackRequest
>> delete variable gFeatures
>> end closestackRequest
>> 
>> great for A/B testing, rolling out new features without messing with 
>> existing code, being able to roll back unwanted or not-working features 
>> after beta testing... and would be so much cleaner if we didn't have to 
>> resort to global variables and remember to put a reference to them in each 
>> place they're referenced...
>> 
>> -- 
>> 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
> 
> ___
> 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: Three very simple questions

2020-04-28 Thread Brian Milby via use-livecode
Correct about the guide.  A PDF is included which can be searched (help... user 
guide).  There is a bug about the guide search.  It is probably going to take 
JavaScript though.

Thanks,
Brian
On Apr 28, 2020, 3:44 PM -0400, Graham Samuel via use-livecode 
, wrote:
> Bill, I think you’re right about the Guide not being searchable. I was going 
> to point it out myself, but I began to think that I had used up my grumbling 
> allowance, or at least I had not much left and needed to use it for other 
> things.
>
> Of course the Giude should be searchable!
>
> Graham
>
> Re grumbling - I have always been delighted by the way people on this list 
> come to each other’s aid. This ‘invisible college’ is a really essential part 
> of the LiveCode experience, I believe. I hope I say ‘thank you’ enough.
>
>
>
> > On 26 Apr 2020, at 23:52, prothero--- via use-livecode 
> >  wrote:
> >
> > Folks:
> > I think Graham is doing LiveCode a favor by pointing out some of the ways a 
> > newby (even though he isn’t) might get messed up when learning LiveCode. We 
> > all get used to various approaches and newbies (even tho Graham isn’t) 
> > alert us to impediments for that very vital population of potential or new 
> > users.
> >
> > One thing that has bugged me is that when I click on the dictionary, I get 
> > a nice display of commands, etc, searchable. But when I click on the 
> > “Guide” tab, I get what looks like a very informative document. However, if 
> > I’m looking for a particular task and want to do a search, there is none. 
> > So, it seems to me like a very valuable newby document is crippled by the 
> > omission of a very basic feature.
> >
> > Or have I just missed something?
> >
> > Best,
> > Bill
> >
> > William A. Prothero
> > Santa Barbara, CA. 93105
> > http://earthlearningsolutions.org/
> >
> > > On Apr 26, 2020, at 12:23 PM, Mark Wieder via use-livecode 
> > >  wrote:
> > >
> > > On 4/26/20 12:09 PM, Sannyasin Brahmanathaswami via use-livecode wrote:
> > > > "globals are evil"
> > > > But we use one array
> > > > Global gConfigA
> > > > and we stuff it with all manner of "things" including another arrays
> > > > it turns about to quite useful
> > >
> > > Yes, I do what you and Jacque do as a workaround, of course. I recently 
> > > implemented a feature management infrastructure the same way, given the 
> > > lack of globally available constants.
> > >
> > > on preOpenStack
> > > global gFeatures
> > > put "feature1,feature2,feature3" into gFeatures
> > > end preOpenStack
> > >
> > > ...some other stack
> > >
> > > global gfeatures
> > > if "feature2" is among the items of gfeatures then
> > > ...
> > >
> > > on closeStackRequest
> > > delete variable gFeatures
> > > end closestackRequest
> > >
> > > great for A/B testing, rolling out new features without messing with 
> > > existing code, being able to roll back unwanted or not-working features 
> > > after beta testing... and would be so much cleaner if we didn't have to 
> > > resort to global variables and remember to put a reference to them in 
> > > each place they're referenced...
> > >
> > > --
> > > 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
> >
> > ___
> > 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: Three very simple questions

2020-04-28 Thread Graham Samuel via use-livecode
Bill, I think you’re right about the Guide not being searchable. I was going to 
point it out myself, but I began to think that I had used up my grumbling 
allowance, or at least I had not much left and needed to use it for other 
things.

Of course the Giude should be searchable!

Graham

Re grumbling - I have always been delighted by the way people on this list come 
to each other’s aid. This ‘invisible college’ is a really essential part of the 
LiveCode experience, I believe. I hope I say ‘thank you’ enough.



> On 26 Apr 2020, at 23:52, prothero--- via use-livecode 
>  wrote:
> 
> Folks:
> I think Graham is doing LiveCode a favor by pointing out some of the ways a 
> newby (even though he isn’t) might get messed up when learning LiveCode. We 
> all get used to various approaches and newbies (even tho Graham isn’t) alert 
> us to impediments for that very vital population of potential or new users.
> 
> One thing that has bugged me is that when I click on the dictionary, I get a 
> nice display of commands, etc, searchable. But when I click on the “Guide” 
> tab, I get what looks like a very informative document. However, if I’m 
> looking for a particular task and want to do a search, there is none. So, it 
> seems to me like a very valuable newby document is crippled by the omission 
> of a very basic feature.
> 
> Or have I just missed something?
> 
> Best,
> Bill
> 
> William A. Prothero
> Santa Barbara, CA. 93105
> http://earthlearningsolutions.org/
> 
>> On Apr 26, 2020, at 12:23 PM, Mark Wieder via use-livecode 
>>  wrote:
>> 
>> On 4/26/20 12:09 PM, Sannyasin Brahmanathaswami via use-livecode wrote:
>>> "globals are evil"
>>> But we use  one array
>>> Global gConfigA
>>> and we stuff it with all manner of "things" including another arrays
>>> it turns about to quite useful
>> 
>> Yes, I do what you and Jacque do as a workaround, of course. I recently 
>> implemented a feature management infrastructure the same way, given the lack 
>> of globally available constants.
>> 
>> on preOpenStack
>> global gFeatures
>> put "feature1,feature2,feature3" into gFeatures
>> end preOpenStack
>> 
>> ...some other stack
>> 
>> global gfeatures
>> if "feature2" is among the items of gfeatures then
>> ...
>> 
>> on closeStackRequest
>> delete variable gFeatures
>> end closestackRequest
>> 
>> great for A/B testing, rolling out new features without messing with 
>> existing code, being able to roll back unwanted or not-working features 
>> after beta testing... and would be so much cleaner if we didn't have to 
>> resort to global variables and remember to put a reference to them in each 
>> place they're referenced...
>> 
>> -- 
>> 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
> 
> ___
> 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: Another widget grumble

2020-04-28 Thread Niggemann, Bernd via use-livecode


> Alex Tweedly wrote:
> How do you tell whether a widget is "part of the main product" ?
> Or, conversely, how do you find out what other source it came from ?

If you look at a widget in the Properties Inspector in the "basic" pane you 
will find its name and then "Kind"

for the Cock widget:
name: clock 
kind: com.livecode.widget.clock

 com.livecode.widget tells you that it is a, well, livecode widget.

Kind regards
Bernd
___
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: Mobile screen sizes - another naive question

2020-04-28 Thread Richard Gaskin via use-livecode
You never need an excuse with me. On the contrary, having an adventurous 
mind hardly needs an excuse at all.


In fact, where you're headed is a potentially exciting place.

I have a need for something tangentially related for a web production 
tool, where I need to reproduce in an LC lib some of the key benefits of 
CSS Grid.


Having thought about this for some time, FWIW I would suggest considering:

- Both FlexBox and Grid merit attention for design inspiration,
  but between the two it seems most designers find Grid more
  generally applicable, so where they differ consider how Grid
  does things, at least for a first pass.

- Allowing Grid to serve as more than just inspiration, but an actual
  model in terms of properties and how setting those adjusts behavior
  would seem very useful for two reasons:

  - The design work for something like that is the hard part, and
 Grid's design process was thorough, its result very good.

  - A lot of us do both native and web apps, so being able to transfer
knowledge from one domain to another simplifies adoption.


When I think of adaptation of web methods for native apps in LC, my mind 
often returns to the excellent work of Ralf Bitter with his revIgniter 
framework.  Inspired by the popular PHP-based webIgniter, his 
implementation carries forward the best of what that offers, enhanced in 
ways that make very good sense for LC devs.


Our community could benefit from more things like that, popular ideas 
from other parts of the world re-envisioned in LC-savvy implementations.


If the parts I need for my web production tool become generally useful 
I'll happily contribute them to any more generalized effort toward a CSS 
Grid-like lib for LC.


--
 Richard Gaskin
 Fourth World Systems



Alex Tweedly wrote:

> Richard,
>
> it wasn't that you over-wrote it - the problem was I over-thought it.
>
> My excuse is that I have been thinking quite a bit this last week
> about whether there was a (simple enough) approach to layout that
> would allow "rows & columns" semi-flow layout to be nearly automatic,
> and be possible to provide a UI that would make it practical (and
> quick) to provide extra guidance to such a system.
>
> You message just happened to fit into that thought exercise - causing
> me to over-complicate things.
>
> So my apologies. I think what you wrote was perfectly clear, it just
> didn't happen to be the same as I was working on :-)
>
> Alex.


___
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: Which git service suits a LiveCoder best?

2020-04-28 Thread Trevor DeVore via use-livecode
On Tue, Apr 28, 2020 at 8:50 AM Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I wouldn't say it's using levure as intended.
> trevor, in his videos, anyway, does not export every script to an SOS, only
> ones that are a certain length.  if you do it that way, then scriptTracker
> could be valuable.
> I choose to put every script in SOS's, so scriptTracker isn't particularly
> useful for me.


To clarify, my guide wasn’t really script length. It was scripts in buttons
that only called a handler in the group, card, or stack script (which would
be SOS). So something like this:

on mouseUp pBtnNum
  if pBtnNum is 1 then
uiDoSomething
  end if
end mouseUp

It seemed counter productive to have SOS stacks for every button.

After a couple of rounds of refactoring I’ve changed my approach. I only
use SublimeText to work on code and when searching for handlers the ones
stored as part of the stack wouldn’t show up. In the above example I now
leave the button script empty and move the mouseUp to the group the button
is in. The mouseUp in the group branches based on the target.

This approach allows me to do a search and replace in all code within
SublimeText if I need to. Since I organize the UI into groups of controls
with their own behavior scripts no single mouseUp handler becomes too
unwieldy. It isn’t like there is one script that is branching for every
possible button click on the card.

Regarding the question of whether or not you would want to use Script
Tracker with Levure - Levure doesn’t really care :-) Levure has excellent
support for workflows that use script-only stacks. If you choose to it can
encrypt all of them when packing up a standalone. But it doesn’t require it
at all. Levure will happily work with any sort of stack file you add.

For example, one could add their existing stacks to a Levure app and start
leveraging the available Helpers (spell check, notary, auto update,
installer builders, etc.) without extracting any scripts to script-only
stacks.

- -
Trevor DeVore
ScreenSteps

>
___
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: Another widget grumble

2020-04-28 Thread Brian Milby via use-livecode
Anything you can find here can be updated by the community (either via PR,
or compiled and used in your own project):

https://github.com/livecode/livecode/tree/develop/extensions/widgets


On Tue, Apr 28, 2020 at 11:26 AM Alex Tweedly via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> On 28/04/2020 13:38, Brian Milby via use-livecode wrote:
> > For any that are part of the main product, a PR to add that feature
> would not be very difficult.  If I get some time I will take a look.  I do
> agree that a distinct label would be a good idea for native control widgets.
>
> How do you tell whether a widget is "part of the main product" ?
>
> Or, conversely, how do you find out what other source it came from ?
>
> I don't see anything in the dictionary about owner/source of the widgets.
>
> Alex.
>
>
> ___
> 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: Mobile screen sizes - another naive question

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

Thank you for your feedback, Graham.

If it takes more than a quick skim to get to the "a ha!" of using groups 
well to reduce scripting, I'll bet I can revise that to be clearer.


Help me understand something - anyone, please chime in:

Resizable windows have been around since the dawn of GUI OSes, and 
putting things where we want them by setting the rect and loc of objects 
has been central to all xTalk dialects since HC 1.0.


What parts of putting objects where you want them have been challenging?

Have most LC devs been delivering fixed-size windows all this time?

My aim with that brief tutorial is to encourage folks to use the object 
placement commands they already know to deliver UIs that behave like the 
other apps they use.


Setting loc and rect gets us there, and using groups well gets us there 
with a fraction of the code.


FullScreenMode is easy, but when you look at the apps on your phone 
you'll see very few that do anything like it.  In most other tools 
designers put things where they want them in ways that make optimal use 
of the screen, at any size screen, any ratio, in either orientation.


We can do this in LC at least as easily.  And groups make short work of 
much of it.


Why is it our community often makes apps that don't have the look and 
feel of most others with regard to object placement?


We share this level of interest in the appearance of individual 
controls, with much discussion about getting every detail as nice as we 
can make it to meet user expectations.  Heck, we even have at least five 
ways to make a simple button so we can be sure to get the exact look we 
want.


But somehow when it comes to how those controls work together to respond 
to changes in screen/window size, the interest wanes.  I'm not sure why.


--
 Richard Gaskin
 Fourth World Systems



Graham Samuel wrote:

> Richard, thanks for these valuable insights. I am doing my best to
> absorb them as quick as I can, meanwhile making use of FullScreen mode
> just to get my app running before it becomes redundant. You are right,
> it has been very difficult to gather comprehensive info on the topic
> until now.
>
> Graham
>
>> On 27 Apr 2020, at 22:29, Richard Gaskin wrote:
>>
>> Graham (and Brahmanathaswami may enjoy this too):
>>
>> I've been itching to write a tutorial on using specific object
>> placement ("Responsive Design", as the kids call it) to compliment
>> the Lesson we've had for years on the other mobile layout option,
>> FullScreenMode.
>>
>> I had a few minutes over the weekend, and a discussion with a new
>> developer prompted me to craft a simple example of how groups can
>> be used to handle common design patterns with little code.
>>
>> This may be fleshed out more fully in the future, but for now at
>> least it's more than the zero tutorials we've had on it thus far:
>>
>> https://forums.livecode.com/viewtopic.php?f=53&t=33989&start=15#p190927
>>
>> --
>> 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: Mobile screen sizes - another naive question

2020-04-28 Thread Alex Tweedly via use-livecode

Richard,

it wasn't that you over-wrote it - the problem was I over-thought it.

My excuse is that I have been thinking quite a bit this last week about 
whether there was a (simple enough) approach to layout that would allow 
"rows & columns" semi-flow layout to be nearly automatic, and be 
possible to provide a UI that would make it practical (and quick) to 
provide extra guidance to such a system.


You message just happened to fit into that thought exercise - causing me 
to over-complicate things.


So my apologies. I think what you wrote was perfectly clear, it just 
didn't happen to be the same as I was working on :-)


Alex.

On 28/04/2020 16:22, Richard Gaskin via use-livecode wrote:

Very good thoughts there, Alex.

The assumptions you list would be important to keep in mind if one 
were aiming to generalize basic layout handling, with libraries that 
have nicely-designed APIs, or even further with virtual props that 
would lend themselves well to reducing things further to simple 
point-and-click authoring.


But in this exercise I'm making no assumptions at all; I'm just 
looking at the UI and writing purpose-built code to make it do what I 
want.


And with only a dozen lines, why not?

There's good value in generalizing app development.  Data binding is 
ripe with unexplored opportunities, as are field entry validation, 
window management, menu management, exception handling and reporting, 
socket comms, and many other things we write.


Sometimes we make tools or libraries to reduce the scripting we would 
use to deliver those.


Sometimes we generalize far enough to reduce it further to assigning 
the desired behavior with property settings which would then lend 
themselves to a point-and-click development workflow.


But often we just write a few lines of script to do what we want to do 
for the case at hand and be done with it.


The draft Lesson I posted serves only as a reminder that placing 
objects where we want them isn't all that deep, and if we use groups 
well we can reduce that scripting even farther.


That this wasn't clear in the writing suggests the draft is possibly 
too long.  "Set the loc of  to " doesn't really require a 
whole page.


Different apps require different code. Layout is the least of it. 
LiveCode is a scripting language.  We script.


And when we look at the apps we use from others, regardless what tool 
they're written in, we see those authors do the same thing: they look 
at their layout, consider what they want to communicate to the user, 
and put things where they want them to support that.


What I had tried to convey was that putting things where you want them 
is neither mysterious nor difficult in a nice language like LC.  
Clearly I overwrote.




___
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: Another widget grumble

2020-04-28 Thread Alex Tweedly via use-livecode


On 28/04/2020 13:38, Brian Milby via use-livecode wrote:

For any that are part of the main product, a PR to add that feature would not 
be very difficult.  If I get some time I will take a look.  I do agree that a 
distinct label would be a good idea for native control widgets.


How do you tell whether a widget is "part of the main product" ?

Or, conversely, how do you find out what other source it came from ?

I don't see anything in the dictionary about owner/source of the widgets.

Alex.


___
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: Mobile screen sizes - another naive question

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

Very good thoughts there, Alex.

The assumptions you list would be important to keep in mind if one were 
aiming to generalize basic layout handling, with libraries that have 
nicely-designed APIs, or even further with virtual props that would lend 
themselves well to reducing things further to simple point-and-click 
authoring.


But in this exercise I'm making no assumptions at all; I'm just looking 
at the UI and writing purpose-built code to make it do what I want.


And with only a dozen lines, why not?

There's good value in generalizing app development.  Data binding is 
ripe with unexplored opportunities, as are field entry validation, 
window management, menu management, exception handling and reporting, 
socket comms, and many other things we write.


Sometimes we make tools or libraries to reduce the scripting we would 
use to deliver those.


Sometimes we generalize far enough to reduce it further to assigning the 
desired behavior with property settings which would then lend themselves 
to a point-and-click development workflow.


But often we just write a few lines of script to do what we want to do 
for the case at hand and be done with it.


The draft Lesson I posted serves only as a reminder that placing objects 
where we want them isn't all that deep, and if we use groups well we can 
reduce that scripting even farther.


That this wasn't clear in the writing suggests the draft is possibly too 
long.  "Set the loc of  to " doesn't really require a whole 
page.


Different apps require different code. Layout is the least of it. 
LiveCode is a scripting language.  We script.


And when we look at the apps we use from others, regardless what tool 
they're written in, we see those authors do the same thing: they look at 
their layout, consider what they want to communicate to the user, and 
put things where they want them to support that.


What I had tried to convey was that putting things where you want them 
is neither mysterious nor difficult in a nice language like LC.  Clearly 
I overwrote.


--
 Richard Gaskin
 Fourth World Systems



Alex Tweedly wrote:

On 27/04/2020 21:29, Richard Gaskin via use-livecode wrote:


I've been itching to write a tutorial on using specific object 
placement ("Responsive Design", as the kids call it) to compliment the 
Lesson we've had for years on the other mobile layout option, 
FullScreenMode.


I had a few minutes over the weekend, and a discussion with a new 
developer prompted me to craft a simple example of how groups can be 
used to handle common design patterns with little code.


This may be fleshed out more fully in the future, but for now at least 
it's more than the zero tutorials we've had on it thus far:


https://forums.livecode.com/viewtopic.php?f=53&t=33989&start=15#p190927

Interesting, and as you say, a good start can be made easily. But it has 
many built-in assumption that may come back to bite you 


on resizeControl -- Allow the user to enjoy whichever orientation -- 
they prefer with responsive design: -- put item 1 of the loc of me 
into tMidX put item 2 of the loc of me into tMidY -- if the width of 
this cd < the height of this cd then -- Portrait: set the loc of grp 
"UserInfo" to \ tMidX, tMidY - (the formattedHeight of grp "UserInfo" 
div 2) set the loc of grp "MembershipInfo" to \ tMidX, tMidY + (the 
formattedHeight of grp "MembershipInfo" div 2) else -- Landscape: set 
the loc of grp "UserInfo" to \ tMidX - (the formattedWidth of grp 
"UserInfo" div 2), tMidY set the loc of grp "MembershipInfo" to \ 
tMidX + (the formattedWidth of grp "MembershipInfo" div 2), tMidY end 
if -- end resizeControl
In Portrait mode, this assumes that the two groups are the same height 
(or nearly so). If they're not, one or other of them will finish up 
bumping against the top (or bottom) of the card.


Similarly, in Landscape, it assumes they are same-ish width, otherwise 
one of them will stick out the side.
*AND* it assumes they are the same height, otherwise the tops will be 
mis-aligned and potentially ugly.

( you could add lines like
put the min(top of grp "MembershipInfo", the top of grp "Userinfo") into 
temp if temp < the top of me + 10 then put the top of me + 10 into temp 
set the top of grp "MembershipInfo" to temp set the top of grp 
"UserInfo" to temp


to the end of the Landscape case).

And there are other assumptions

1. the fields are sized suitable to fit in the width of the narrowest 
device. If a narrow device is small enough, maybe the labels should 
slide around to above its field, rather than be beside it.


2. assumes that you don't want to widen the fields on not-very-narrow 
devices - whether stretching the fields, or increasing spacing between them.


3. In landscape, there may well not be enough width to allow the two 
groups side-by-side (say, on a phone), and you would really prefer to 
have the stacked vertically, even though in Landscape.


4. (perhaps the hardest) if you have text areas (i.e. multi-line 

Re: Which git service suits a LiveCoder best?

2020-04-28 Thread Mike Kerner via use-livecode
I wouldn't say it's using levure as intended.
trevor, in his videos, anyway, does not export every script to an SOS, only
ones that are a certain length.  if you do it that way, then scriptTracker
could be valuable.
I choose to put every script in SOS's, so scriptTracker isn't particularly
useful for me.


On Mon, Apr 27, 2020 at 4:23 PM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

> ScriptTracker isn’t necessarily incompatible with Levure, but if using
> that framework as intended then all of the scripts would be in script only
> stacks as behaviors which would make it unnecessary.
>
> I have thought about setting up a hybrid project as a test but never have
> gotten around to playing with it.
>
> Thanks,
> Brian
> On Apr 27, 2020, 3:53 PM -0400, Andreas Bergendal via use-livecode <
> use-livecode@lists.runrev.com>, wrote:
> > As to the ’how’, I planned to move into script-only stacks more anyway,
> and will also test the Levure framework, and/or Script Tracker.
> > I’m not sure if those two are compatible though? I mean, if I use Levure
> framework I can’t (needn’t?) use Script Tracker as well, right?
> >
> > Anyway, with the help of a good free tutorial I’ve set up a GitHub
> account and done the necessary local stuff, including doing basic command
> line actions (yeah, wasn’t that scary after all…), so I’m progressing one
> step at a time… :)
> >
> > Andreas
> > ___
> > 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
>


-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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: Mobile screen sizes - another naive question

2020-04-28 Thread Brian Milby via use-livecode
On the MobileDemo stack, there are a couple scripts that would be useful.
https://github.com/bwmilby/mobileDemo/tree/master/mobileDemo_Scripts
stack_MobileDemo_button_id_1024
stack_MobileDemo_card_id_1002

The button script is a behavior applied to 2 groups on the card.  There are
6 buttons that will change how they are laid out depending on the width of
the screen (2 rows for narrow, 1 row for wide).

The card script has the resizeStack handler that positions the 2 groups.
It will adjust the second one based on the first (so if the buttons unwrap,
then it moves up).

This will show an example of handling a couple of the issues brought up.

(I jump through some hoops in other pieces of code trying to handle the
arbitrary change of fullScreenMode which would not be necessary in a real
application since you would normally pick a mode and stick with it.)

Thanks,
Brian

On Tue, Apr 28, 2020 at 8:07 AM Graham Samuel via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Richard, thanks for these valuable insights. I am doing my best to absorb
> them as quick as I can, meanwhile making use of FullScreen mode just to get
> my app running before it becomes redundant. You are right, it has been very
> difficult to gather comprehensive info on the topic until now.
>
> Graham
>
> > On 27 Apr 2020, at 22:29, Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Graham (and Brahmanathaswami may enjoy this too):
> >
> > I've been itching to write a tutorial on using specific object placement
> ("Responsive Design", as the kids call it) to compliment the Lesson we've
> had for years on the other mobile layout option, FullScreenMode.
> >
> > I had a few minutes over the weekend, and a discussion with a new
> developer prompted me to craft a simple example of how groups can be used
> to handle common design patterns with little code.
> >
> > This may be fleshed out more fully in the future, but for now at least
> it's more than the zero tutorials we've had on it thus far:
> >
> > https://forums.livecode.com/viewtopic.php?f=53&t=33989&start=15#p190927
> >
> > --
> > Richard Gaskin
> > Fourth World Systems
> >
> >
> >
> > -- original post from 9 April -
> >
> > Graham Samuel wrote:
> >
> > > Folks, yet again I don’t know where to look for an answer in the LC
> > > documentation.
> > >
> > > The issue is the enormous variety of screen sizes on smart phones.
> > > For example the iPhone XS Max has 1242 pixels width, the iPhone 5 has
> > > 640. And there are many many more before we even get to tablets…
> > >
> > > The question is, how do most of you tackle this, and does LC help?
> > > Obviously an object taking up a fixed number of pixels on one phone
> > > will look absurdly large or small on another one, or of course may not
> > > fit on the screen at all. Not all objects can be vector drawings, and
> > > the ones that are still have to be resized according to device
> > >
> > > Is there anything better than the obvious trick of resizing everything
> > > in sight when the app is being initialised, including substituting the
> > > more sensitive graphics from a library of appropriate sizes? Seems
> > > tedious.
> >
> > Is it all that tedious?
> >
> > Computers have had resizable windows since Mac 1.0, and even HyperCard
> > stacks could be resize after its first version.
> >
> > True, in the very olden days we all enjoyed the simplicity of knowing we
> > never had to accommodate any screen size other than 512x342.  Ah, those
> > were the days! :)
> >
> > But 640x480 came along not long after, and it caused much concern among
> > developers. Suddenly we had to become aware of screen metrics, and
> > rearrange our layouts to make good use of the available space.
> >
> > Then 1024x768 came along, and then we had THREE(!) screen sizes to
> > contend with. Oh the humanity! :)
> >
> > Then by the early 90s we got over it.  Anticipating multiple screen
> > sizes became the norm, new tools like SuperCard, OMO, and MetaCard came
> > along offering true resizable windows, and we learned to respond to
> > notification that the window had resized so we can adjust our interior
> > contents nicely.
> >
> > Flash forward to 2010: iPhone comes out, with the presumption that one
> > size will satisfy all tastes.  That didn't last long.  History doesn't
> > always repeat itself, but it often rhymes. :)
> >
> > 
> >
> > As with desktop software, I find it instructive to observe how the best
> > apps on mobile behave, and then - because those establish user
> > expectations - do what they do.
> >
> > And what we see is not all that different from how designers handle
> > resizable windows on the desktop: some objects stay where they are,
> > those that make sense to enlarge enlarge, those that make sense to
> > remain adjacent to something next to them remain adjacent to something
> > next to them, etc.
> >
> > If you've written resizeStack handlers at any point in the last 2

Re: Another widget grumble

2020-04-28 Thread Brian Milby via use-livecode
For any that are part of the main product, a PR to add that feature would not 
be very difficult.  If I get some time I will take a look.  I do agree that a 
distinct label would be a good idea for native control widgets.

Thanks,
Brian
On Apr 28, 2020, 8:23 AM -0400, Graham Samuel via use-livecode 
, wrote:
> I’m still trying to use the ‘mobile native’ style of widget. Previously I’ve 
> objected to the idea of an object that displays its name and has no label or 
> alias. My objection was mostly that names that the user sees often have 
> spaces in them (“Stop Now” or whatever), whereas names with spaces in them 
> are dangerous to refer to in scripts because it’s so easy to put two in 
> instead of one, and is either illegal or deprecated in almost all computer 
> languages.
>
> Today I came across an even more annoying aspect of this, when I added a 
> facility to my app to change the language of the display. So a button in 
> English displaying “Cancel” gets changed to “Annuler”. So if I need to refer 
> to the button in script, the simplest way is to use its ID and not its name. 
> The ID is a fine thing, but it doesn’t make for readable code!
>
> Seriously, is there any chance of these widgets being improved by somebody? 
> They just need more properties really.
>
> 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


Another widget grumble

2020-04-28 Thread Graham Samuel via use-livecode
I’m still trying to use the ‘mobile native’ style of widget. Previously I’ve 
objected to the idea of an object that displays its name and has no label or 
alias. My objection was mostly that names that the user sees often have spaces 
in them (“Stop Now” or whatever), whereas names with spaces in them are 
dangerous to refer to in scripts because it’s so easy to put two in instead of 
one, and is either illegal or deprecated in almost all computer languages.

Today I came across an even more annoying aspect of this, when I added a 
facility to my app to change the language of the display. So a button in 
English displaying “Cancel” gets changed to “Annuler”. So if I need to refer to 
the button in script, the simplest way is to use its ID and not its name. The 
ID is a fine thing, but it doesn’t make for readable code!

Seriously, is there any chance of these widgets being improved by somebody? 
They just need more properties really.

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: Mobile screen sizes - another naive question

2020-04-28 Thread Graham Samuel via use-livecode
Richard, thanks for these valuable insights. I am doing my best to absorb them 
as quick as I can, meanwhile making use of FullScreen mode just to get my app 
running before it becomes redundant. You are right, it has been very difficult 
to gather comprehensive info on the topic until now.

Graham

> On 27 Apr 2020, at 22:29, Richard Gaskin via use-livecode 
>  wrote:
> 
> Graham (and Brahmanathaswami may enjoy this too):
> 
> I've been itching to write a tutorial on using specific object placement 
> ("Responsive Design", as the kids call it) to compliment the Lesson we've had 
> for years on the other mobile layout option, FullScreenMode.
> 
> I had a few minutes over the weekend, and a discussion with a new developer 
> prompted me to craft a simple example of how groups can be used to handle 
> common design patterns with little code.
> 
> This may be fleshed out more fully in the future, but for now at least it's 
> more than the zero tutorials we've had on it thus far:
> 
> https://forums.livecode.com/viewtopic.php?f=53&t=33989&start=15#p190927
> 
> --
> Richard Gaskin
> Fourth World Systems
> 
> 
> 
> -- original post from 9 April -
> 
> Graham Samuel wrote:
> 
> > Folks, yet again I don’t know where to look for an answer in the LC
> > documentation.
> >
> > The issue is the enormous variety of screen sizes on smart phones.
> > For example the iPhone XS Max has 1242 pixels width, the iPhone 5 has
> > 640. And there are many many more before we even get to tablets…
> >
> > The question is, how do most of you tackle this, and does LC help?
> > Obviously an object taking up a fixed number of pixels on one phone
> > will look absurdly large or small on another one, or of course may not
> > fit on the screen at all. Not all objects can be vector drawings, and
> > the ones that are still have to be resized according to device
> >
> > Is there anything better than the obvious trick of resizing everything
> > in sight when the app is being initialised, including substituting the
> > more sensitive graphics from a library of appropriate sizes? Seems
> > tedious.
> 
> Is it all that tedious?
> 
> Computers have had resizable windows since Mac 1.0, and even HyperCard
> stacks could be resize after its first version.
> 
> True, in the very olden days we all enjoyed the simplicity of knowing we
> never had to accommodate any screen size other than 512x342.  Ah, those
> were the days! :)
> 
> But 640x480 came along not long after, and it caused much concern among
> developers. Suddenly we had to become aware of screen metrics, and
> rearrange our layouts to make good use of the available space.
> 
> Then 1024x768 came along, and then we had THREE(!) screen sizes to
> contend with. Oh the humanity! :)
> 
> Then by the early 90s we got over it.  Anticipating multiple screen
> sizes became the norm, new tools like SuperCard, OMO, and MetaCard came
> along offering true resizable windows, and we learned to respond to
> notification that the window had resized so we can adjust our interior
> contents nicely.
> 
> Flash forward to 2010: iPhone comes out, with the presumption that one
> size will satisfy all tastes.  That didn't last long.  History doesn't
> always repeat itself, but it often rhymes. :)
> 
> 
> 
> As with desktop software, I find it instructive to observe how the best
> apps on mobile behave, and then - because those establish user
> expectations - do what they do.
> 
> And what we see is not all that different from how designers handle
> resizable windows on the desktop: some objects stay where they are,
> those that make sense to enlarge enlarge, those that make sense to
> remain adjacent to something next to them remain adjacent to something
> next to them, etc.
> 
> If you've written resizeStack handlers at any point in the last 28 years
> since MC premiered, you've already learned most of what you need to know
> to handle a resizeStack message on a mobile device.
> 
> The specifics of how this plays out in your layout will of course depend
> entirely on your layout.  But I have found a few things that have
> greatly simplified my UI work, chiefly:
> 
> - Use Groups Smartly
> 
> Relatively recently (a few years ago) the engine now sends a
> resizeControl message to groups whenever they're resized by any means,
> either user interaction with the pointer tool (as had always been the
> case) or via script (the new addition).
> 
> This allows us to work with our UIs very cleanly, recognizing that an
> app is ultimately a set of rows, and that some rows are divided into
> blocks.  When we group controls by their location/purpose logically, we
> get to take advantage of a wonderfully simplifying cascading effect with
> regard to resizing, which allows us to keep control adjustments local to
> their containing group.
> 
> Imagine a simple message form, where the rows are:
> 
> - Icons for navigating to different screens
> 
> - Message, which includes three rows:
>   - S