Thanks Richard, for that typically useful reply! I have indeed written many a resize handler, but getting back into this stuff I was struck by how messy it can get. Right now I don’t even know if say a field with 12 point type in it has to be changed to a smaller or larger rectangle with smaller or larger type in it, but obviously as soon as I can start doing simulations (I have a totally different problem there!) I can experiment. I do like the idea of sending resizeControl to groups - I have used similar techniques for other purposes in the past. Powerful and encapsulated.
As to graphics, I can presumably start with the highest possible resolution and resize at startup according to the actual screen size, or do what I said before, have a little library of different versions tweaked for different screen sizes. Or possibly use SVG, but I have not yet made that work - I know almost nothing about SVG, although I have seen some sexy examples that look almost like photos etc. Wouldn’t work for say a Google Maps image though - again I need to see what happens if the grid of pixels available to display a map varies by a factor of say three. Well, I am trying to learn, and I am grateful for all that you’ve said. Graham > On 9 Apr 2020, at 18:47, Richard Gaskin via use-livecode > <use-livecode@lists.runrev.com> wrote: > > 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 > Software Design and Development for the Desktop, Mobile, and the Web > ____________________________________________________________________ > ambassa...@fourthworld.com http://www.FourthWorld.com > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
