Re: Counting unique items in a file
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
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
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
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
> 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
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?
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
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
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=33989=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
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
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
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=33989=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?
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
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=33989=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
Re: Another widget grumble
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
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
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=33989=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:
> - Subject
