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 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 field > > - Body field > > - Send button > > > > With that, our card script need only bother itself with the general > > placement of the two main goups: > > > > on resizeStack x,y > > set the rect of grp "Nav" to 0,0,x,40 > > set the rect of grp "Message" to 0,40,x,y > > end resizeStack > > > > And because the groups will get a resizeControl message when that card > > script adjust them, each can contain its own handler to take care of its > > interior contents. This might be the script for the Message group: > > > > on resizeControl > > set the rect of fld "Subject" to the left of me, the top of me, \ > > the right of me, the top of me + 40 > > set the rect of fld "Body" to the left of me, 40, the right of me, \ > > the bottom of me - 60 > > set the bottomRight of btn "Send" to x-20, y-10 > > end resizeControl > > > > > > Encapsulating resizing within the group not only keeps the logic simple > > and tidy, but by using the group bounds as its basis rather than the > > card (e.g., "the left of me") the group is maintainable and even > > portable - the card script that sets its rect can change at any time, > > and the group's resizeControl handler will continue to work well. > > > > > > There are probably other tips and tricks worth considering, but none > > have radically streamlined the process of delivering the UI I want my > > user to enjoy as much as using groups as containers for > > logically/geometrically related controls. > > > > As you explore these and other ideas in the crafting of your UI, drop > > back in here with questions. There are always many ways to skin cats in > > LC, and the diversity of experience on this list can help solve anything. > > > > -- > > Richard Gaskin > > Fourth World Systems > > > > > > _______________________________________________ > > use-livecode mailing list > > use-livecode@lists.runrev.com > > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > > http://lists.runrev.com/mailman/listinfo/use-livecode > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ 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