Why is the geometry manager still borked in 2021?!

Anything beyond the basics in using the LiveCode language. Share your handlers, functions and magic here.

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Why is the geometry manager still borked in 2021?!

Post by FourthWorld » Sun Mar 14, 2021 4:37 pm

tetsuo29 wrote:
Sun Mar 14, 2021 2:29 pm
FourthWorld wrote:
Sun Mar 14, 2021 9:49 am
tetsuo29 wrote:
Sun Mar 14, 2021 4:17 am
It was recommended to me (I believe here on these forums) that I not rely on it and instead write code to resize and move widgets.
Sounds like good advice.

What difficulties did you run into writing your own resizeStack handler?
A. Sounds like someone has Stockholm Syndrome when it comes to the geometry manager.
For those who find it unsatisfying but still imagine they must be dependent on it, that's a far harsher metaphor than I would choose, but the underlying sentiment may not be entirely off the mark.
B. It’s a PITA that shouldn’t be required when I should be able to use the built-in feature without issues like this.
No-code tools are available and may be a better fit for those who prefer not to code.


I don't disagree that the GM is unsatisfying. Indeed, that's why neither I nor most devs I know well have ever used it.

We disagree only in the remedy:

Having spent considerable time over the decades exploring the question of generalizing layout handling, I've become most comfortable just writing a few lines of code and moving on to other tasks.

The notion of attempting to write one giant resizeStack handler that attempts to handle all possible layouts doesn't seem a good use of time to me.

So if it were up to me, the remedy would be to have never shipped a GM at all, and focused instead on helping people get the most out of the resizeStack messages provided for that purpose.

And for those seeking to use the resizeStack messages for their intended purpose, I'm happy to help share what I've learned about using them well.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

SparkOut
Posts: 2834
Joined: Sun Sep 23, 2007 4:58 pm

Re: Why is the geometry manager still borked in 2021?!

Post by SparkOut » Sun Mar 14, 2021 4:45 pm

FourthWorld wrote:
Sun Mar 14, 2021 4:37 pm
So if it were up to me, the remedy would be to have never shipped a GM at all, and focused instead on helping people get the most out of the resizeStack messages provided for that purpose.
Well, that's not a remedy, since we can't go back in time and change the decision made in the past - but could the remedy be "to remove the GM from the IDE completely" and instead, provide tutorials on sane layout management?
Is that a realistic proposal for the Development Team?
If so, does that mean there would be a whole slew of unnecessary geometry messages that could be excised from the engine and provide some unexpected performance benefits?

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Why is the geometry manager still borked in 2021?!

Post by FourthWorld » Sun Mar 14, 2021 4:49 pm

bogs wrote:
Sun Mar 14, 2021 4:25 pm
@Richard, we've had these conversations before, so I conclude it is a topic you and I are destined to not agree on among many.
It's a rare day I've written anything you didn't take exception to, so no worries, I've become accustomed to the routine. ;)

If writing one giant resizeStack handler to handle all possible layouts seems easy, I would welcome being wrong by having anyone demonstrate that ease.

In the meantime, I just write code for that and move on to doing the same for DB access and networking and anything else that requires far more diligence yet yields few complaints.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

bogs
Posts: 5435
Joined: Sat Feb 25, 2017 10:45 pm

Re: Why is the geometry manager still borked in 2021?!

Post by bogs » Sun Mar 14, 2021 4:55 pm

FourthWorld wrote:
Sun Mar 14, 2021 4:49 pm
bogs wrote:
Sun Mar 14, 2021 4:25 pm
@Richard, we've had these conversations before, so I conclude it is a topic you and I are destined to not agree on among many.
It's a rare day I've written anything you didn't take exception to, so no worries, I've become accustomed to the routine. ;)
At the risk of sounding like I take exception to the above, heh, I completely agree with you on the statement I quoted ;) as well as a *lot* of things you've said in the past. I just take it for granted there are things we will never see eye to eye on, but I would imagine no one sees eye to eye on everything with everyone anyway :D

Take heart though, a great deal of what I know about this language came from reading your posts here and elsewhere.
Image

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Why is the geometry manager still borked in 2021?!

Post by FourthWorld » Sun Mar 14, 2021 5:00 pm

bogs wrote:
Sun Mar 14, 2021 4:55 pm
FourthWorld wrote:
Sun Mar 14, 2021 4:49 pm
bogs wrote:
Sun Mar 14, 2021 4:25 pm
@Richard, we've had these conversations before, so I conclude it is a topic you and I are destined to not agree on among many.
It's a rare day I've written anything you didn't take exception to, so no worries, I've become accustomed to the routine. ;)
At the risk of sounding like I take exception to the above, heh, I completely agree with you on the statement I quoted ;) as well as a *lot* of things you've said in the past. I just take it for granted there are things we will never see eye to eye on, but I would imagine no one sees eye to eye on everything with everyone anyway :D

Take heart though, a great deal of what I know about this language came from reading your posts here and elsewhere.
Thank you for the kind words. I learn a great deal from you as well.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Why is the geometry manager still borked in 2021?!

Post by FourthWorld » Sun Mar 14, 2021 5:09 pm

SparkOut wrote:
Sun Mar 14, 2021 4:45 pm
FourthWorld wrote:
Sun Mar 14, 2021 4:37 pm
So if it were up to me, the remedy would be to have never shipped a GM at all, and focused instead on helping people get the most out of the resizeStack messages provided for that purpose.
Well, that's not a remedy, since we can't go back in time and change the decision made in the past - but could the remedy be "to remove the GM from the IDE completely" and instead, provide tutorials on sane layout management?
Is that a realistic proposal for the Development Team?
Deprecation happens in any software from time to time.

The Animation Manager was another ambitious attempt, now deprecated yet still available as a plugin for those who enjoy it. Same with the Application Manager.

But it's not up to me.

My choices are limited to what happens in my own office. And here, I've never felt a need to use the GM.
If so, does that mean there would be a whole slew of unnecessary geometry messages that could be excised from the engine
I see no need for that. The humble resizeStack message applied to well-established size and location properties seems adequate.
and provide some unexpected performance benefits?
It's hard to imagine one giant resizeStack handler attempting all possible layouts performing any better.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

SparkOut
Posts: 2834
Joined: Sun Sep 23, 2007 4:58 pm

Re: Why is the geometry manager still borked in 2021?!

Post by SparkOut » Sun Mar 14, 2021 5:44 pm

I meant, would it be taken seriously as a proposal to the Team to actively remove the GM from the IDE?
In which case the messages relating to geometry (of which there are many) would be unneccessary, and could be purged from the engine. There might be an unexpected benefit to engine performance as well, if the GM was removed. (Although the main benefit would be to stop users having negative experiences of an IDE feature that is sub-par.)

But is it realistic? @Richard, no it's not "up to you" but do you (as well as anyone else) consider that a viable proposal to the developers?

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Why is the geometry manager still borked in 2021?!

Post by FourthWorld » Sun Mar 14, 2021 6:01 pm

SparkOut wrote:
Sun Mar 14, 2021 5:44 pm
I meant, would it be taken seriously as a proposal to the Team to actively remove the GM from the IDE?
Possibly. I spend so little time even thinking about the GM that beyond advising against it when it was in beta I don't recall discussing it with them at all. You may have better luck than I did.
In which case the messages relating to geometry (of which there are many) would be unneccessary, and could be purged from the engine.
Beyond resizeStack and resizeControl, what other system messages does the engine send related to resizing?
There might be an unexpected benefit to engine performance as well, if the GM was removed.
IIRC the only loss with the GM present is a frontscript test to see if the card has GM custom props, and if not the resizeStack message is passed immediately.

But it's been a long time since I've looked into it. Did I miss something?
But is it realistic? @Richard, no it's not "up to you" but do you (as well as anyone else) consider that a viable proposal to the developers?
My only proposal is for the developers here: use what works for you. If the GM does what you need, enjoy it. And if it's frustrating, it's easily ignored.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 9250
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: Why is the geometry manager still borked in 2021?!

Post by richmond62 » Sun Mar 14, 2021 6:04 pm

I honestly wonder why the Geometry manager is still there as it's largely rubbish.

It should either be sorted out or dumped.

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7210
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Why is the geometry manager still borked in 2021?!

Post by jacque » Sun Mar 14, 2021 6:35 pm

I don't use the GM either but several people have said it's valuable as long as you understand how it works. It does need to be one of the last things you set up because, as mentioned, changing the layout requires a redo.

I suspect it would work under any circumstances if you never use positioning relative to other controls and instead always use the card edges as reference points.

I do question Richard's comments about writing "a few lines of code" but I've brought that up before. You will write code for every object. If you only have a handful of controls in a single layout it can indeed be a few lines. In my last two projects, where there are dozens of controls on many cards, we hired Brian to write a library because I couldn't face the task again, after doing it in the past. Brian's library was long and we implemented it as a behavior. Parts of it are generic enough to reuse, though every new layout will need to be integrated into the script, one control at a time.

Whenever possible I use fullscreenmode to do automatic resizing on mobile, just to avoid the tedium of all those placement scripts and handlers.

I just finished a private tool for my own use that has only one layout with 5 controls. That was indeed "a few lines of code" and quickly completed.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Why is the geometry manager still borked in 2021?!

Post by FourthWorld » Sun Mar 14, 2021 7:09 pm

jacque wrote:
Sun Mar 14, 2021 6:35 pm
I don't use the GM either...
...
I do question Richard's comments about writing "a few lines of code"
If the GM isn't up to the task but scripting is somehow too onerous, where does that leave us?

Resizable windows have been a part of the GUI experience since MacOS 1.0. The first xTalk that with support for handling resizing was SuperCard in 1989.

A lot of software has shipped over these many years. In each case, as with every web page as well, the designer considered the goals for adjusting to a change in window size and used instructions to handle it.

Whether one click click clicks or type type types isn't the hard part. Deciding what you want is the hard part. Once you decide that, you can architect with that in mind, and if you write your own code to do that you'll avoid the pitfalls of attempting generalization which led to this thread.

If writing a resizeStack handler is seen as prohibitive, what would that make the Mother of All ResizeStack Handlers that attempts to handle all possible layouts?

Even tedious scripting seems better delivering only fixed-sized windows.
You will write code for every object.
It is possible, but rare. Some controls don't need to be moved. Others can be grouped, and moving the group suffices. It's not possible to describe how to handle a given layout without seeing it, but in my on work I rarely spend more than an hour scripting layouts, often just minutes.
In my last two projects, where there are dozens of controls on many cards, we hired Brian to write a library because I couldn't face the task again, after doing it in the past. Brian's library was long and we implemented it as a behavior. Parts of it are generic enough to reuse, though every new layout will need to be integrated into the script, one control at a time.
Retrofitting is always more expensive, whether adding earthquake reinforcements to older buildings or adding resizing support to a layout constructed without resizing in mind.

I'm sorry you had that experience on two of the great many apps you've made. Those two cases, uncommon even among your own work, seem to have influenced of lot of decisions regarding other layouts. We should chat about that sometime when I can see the layout and how it was constructed.

In 100% of all cases where you and I have had the opportunity to see a layout, we've never disagreed on the best method for the task at hand.
Whenever possible I use fullscreenmode to do automatic resizing on mobile
I believe the OP is making a desktop app, where fullScreenMode is not a viable option.

On mobile, fullScreenMode can sometimes be the best choice. As with anything else, when making any design decisions the best place to start is to look at apps of the sort we want to make, and do what they do.

The easiest way to assess how those apps respond to different ratios is to introduce a ratio change in the simplest way possible: rotate your phone. See how the app responds to that. Do what they do.

Where fullScreenMode does what you're looking for, enjoy it.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7210
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Why is the geometry manager still borked in 2021?!

Post by jacque » Sun Mar 14, 2021 9:12 pm

I actually started writing resizing scripts about 15 years ago with Casey's Solitaire, where there were hundreds of objects to position and scripting was the only way to do it. It took me a couple of weeks, there were four layouts for the main card, and two each for preferences, high score card, and a couple of other cards. Then there was GuruDeva with I don't know how many layouts (dozens) for which I used fullScreenMode, until Brian implemented scripted resizing. I also wrote resizing code for other projects in between, and now my two latest projects.

I am not saying we have other choices for precise positioning because we don't. I only object to making too light of it because it is almost always more than a few lines of code unless you mean "per control." It isn't particularly difficult, it's just tedious. Really, really tedious. And there's often math to calculate per control: ratios, pixel calculations, relative positioning. I've done it, I still do it, and I don't like it.

Kevin told me some years ago that the team uses the GM all the time and it works. Brian explored it and said it works. Chipp (remember Chipp?) also praised it after he got a personal walkthrough at a conference. Maybe there's something we don't know.

But I agree with you that there's not much difference beween typing something for each object and clicking something for each one instead. If I were to wish for anything at all, I'd vote for fullscreenmode everywhere, with a few tweaks for the bits that currently are a little off. When LC implemented fullscreenmode I rejoiced, it addressed my most disliked part of app building.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Why is the geometry manager still borked in 2021?!

Post by FourthWorld » 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?

As for "every object", do you write code to place menus?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7210
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Why is the geometry manager still borked in 2021?!

Post by jacque » 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.
As for "every object", do you write code to place menus?
You know what I mean. 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.

It's like you said; use what works. I shouldn't have picked on your terminology though. It would be just as cumbersome to resize that one card no matter what method was used. And I have dozens more like it.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Why is the geometry manager still borked in 2021?!

Post by FourthWorld » Sun Mar 14, 2021 10:50 pm

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):
Resize.png
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.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

Post Reply

Return to “Talking LiveCode”