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 <object> to <loc>" 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
fields), how do you decide whether to expand vertically depending on the
height of the card, versus simply allowing vertical scroll bars within
the field.
In summary - I absolutely agree that LC has everything needed to provide
responsive layouts, and that with even a modicum of effort (which might
seem tedious the first few times :-), it can produce layouts which are
MUCH more responsive than a typical web page/app. But there is a danger
of thinking it is too easy, and producing semi-responsive designs which
are not quite good enough.
Things that would help:
1. either a widget or a compound-control for labelled field which wold
allow the encapsulation for the sizing options for label+field; and
would allow for labelling above or beside the field depending on
context, space available and kind of field.
And there are others -library functions or behaviours that will help
with the common cases - more thought on that tomorrow.
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