jacque wrote: ↑Sun Mar 14, 2021 10:22 pm
FourthWorld wrote: ↑Sun Mar 14, 2021 9:17 pm
If the GM is a satisfying solution, why do you use fullScreenMode, and why did you hire Brian?
I didn't say the GM was satisfying, I have the same problem with it as others. But a few people have said it works, and I wonder if I've missed something.
Can't say. I don't use it either. I just observe that those who do often create threads like this one.
As for "every object", do you write code to place menus?
You know what I mean.
I do, but only because I know both you and LC well. Do newcomers know what you mean?
A lot of this comes down to the type of app we're building. Here's a basic example, but fairly representative of a lot of types of apps out there (picked it at random looking for a screenshot of a basic text editor):
There's a lot going on there, and if we try to handle each of them separately it'll get tedious quickly. Thankfully, few designs require that.
Most apps have controls that are grouped into sections. Even better, most sections are rows. Desktop or mobile, when we step back and see the groupings lots of solutions become clear that may not have been clear when we look at the collection of controls as a whole. And desktop or mobile, most of the groupings are rows, which simplifies things further, since the left and right don't need to take anything into account except the edges of the card.
I've added labels to that screen shot to draw attention to the groupings, with four functional areas: Menubar, Toolbar, UserContent, and Footer. Variations of this pattern make up a lot of the apps we use, so it's a reasonably useful example to start with.
Let's see how we can handle a resizeStack message there:
We can start at the top, with the Menubar. LC does a good job of applying the Windows theme to the menu bar, provided we make our menu in a group. And because the menus will remain flush-left, we don't need to move them at all. We might be tempted to use one line of code to resize the group so it fits the window, but we don't really need to do that as long as the group extends beyond the right-hand edge. So we'll just make it really wide. Done.
Now let's move on the the Toolbar. There we have 24 button objects and 7 divider graphics in a group. But again, being flush left and in a position that doesn't change vertically, If we make it wide enough we don't need to do anything to handle it. Done.
The UserContent region has only one object, a field. Simple enough, but since it has to fill the entire space between the bottom of the Toolbar and the top of the Footer, it'll be easier if we handle the Footer first.
The Footer has five fields, each flush left. We could move them all individually, but if we put them in a group we can turn those five placement statements into one.
And once the Footer is where we want it, setting the rect of the field in the UserContent area is simple enough.
Here's how it all comes together:
Code: Select all
on resizeStack x,y
set the bottomLeft of group "Footer" to 0,y
set the rect of fld "UserContent" to 0, the bottom of group "Toolbar", x, the top of grp "Footer"
end resizeStack
Nearly 40 objects, handled with 2 statements.
Not every layout will afford an opportunity for such a low object/code ratio. But almost everything is far below one-to-one. Far below. Five-to-one is low for the apps I've done, 10-to-one more common, but of course it depends on the specifics. Seeing a 20-to-one solution like this example isn't very rare.
The unique challenge you faced with the archeaology app is definitely an exception to the sorts of things any app designer usually comes across:
In one of the modules in my courseware project, just the archaeology dig card alone has 833 controls, which is one of 47 cards, about half of which have unique layouts. The entire course has 55 stacks and that's just for the Archaeology course. Fortunately we don't resize the desktop app, but when moving this to mobile I can't imagine what I'd do without fullscreenmode. And the GM wouldn't be any more useful here either.
I remember the meeting we had about that layout. Given where it came from and where it was going (tablet only, so a small range of screen sizes with no need to support Portrait), we both agreed that was a excellent example of where fullScreenMode can be a good fit.
But unless I misunderstand, I think this thread is about desktop apps. FullScreenMode isn't even an option there, so helping people understand how to respond to the resizeStack message seems useful.