Why is the geometry manager still borked in 2021?!

[tetsuo29]

I need to vent here for a minute.

I started dabbling with LC back in like 2004. One of the first things I discovered was that the geometry manager (I think that's what it's called) had serious issues. 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. Fast forward to now, 17 years later, and little has improved in this regard. It's embarrassingly bad. I had a card with like 8 widgets on it. I set some of them to move or resize when the user resizes the window. Great. Easy. Exactly as it should be.

Then... I made the mistake of adding some more buttons. I resized the window and all hell broke loose. Widgets grew to insane proportions and others moved far out of view. I had to open the project browser and start bringing up properties for each item and from there and entering numbers in order to get things back where I could see them and reposition them. Some of them even required me to turn off and turn back on the positioning or sizing constraints they need before they would resize or move properly again.

You should be able to add new elements to a card without the geometry manager going insane. Seriously.

LC should be ashamed of how bad this is and the fact that they have not fixed it in almost 20 years now. Why does this not get fixed? Why isn't there more of an outcry about this? Have we all got Stockholm Syndrome when it comes to the geometry manager?

[FourthWorld]

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?

[bogs]

@tetsuo29 - I completely understand your frustration where the GM tool in Lc is concerned. I too do not understand why it seems so impossible to fix. Unfortunately, I don't have any answer for you on why this and several other issues seem to go on year after year after decade.

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?

@Richard, in a language that is claimed to be easy to use, why (if resize handling is so easy to code) don't the built in tools for doing just that work? After all, they work in just about every other HLL I can think of.

To put it another way, IF I own a chisel, why should I have to create my own chisel to work with? The basic idea of having a tool available to do the work is so that you don't have to create your own tool to do the work.

<the following is completely silly, and not a serious question>
Let's extend your question, why have an IDE ? Everyone should write their own before being able to use one.

[stam]

Valid points - the geometry manager is not really fit for use.

It might work OK for 1 simple control, but anything more complex and it just fails... or at least i've never been able to get it to work...

Sounds like others have had the same issues, so really this should be either removed or, ideally fixed.
A simpler geometry manager, like what is available in FileMaker Pro, that just works would be highly preferable for me.
Of course ideally it would be something like what's available in Xcode.

Everything can be done in script but it's much more work...

[bogs]

It might work OK for 1 simple control, but anything more complex and it just fails... or at least i've never been able to get it to work...

Actually, it isn't that bad either heh. If you have all the controls your ever going to need, and you don't plan to add any afterwards, it does *work* and fairly well from all I can tell. If you come from using other GM tools, it isn't as straight forward, though, and requires a different way of thinking by comparison. There is a decent tutorial on it's use in the reference resources...



There were problems along those lines earlier on in the series that were solved later. I *believe* bwilmby (SP?) solved some others a year or two back.

The best way I've found to use it is once your stack layout is more or less finalized as far as controls go, save it as a frozen file and save AS the file you are going to use the GM on, then use the GM for laying out how you want everything to move. The downside is, if you decide you really forgot to add control xyz, you have to go through the whole process again and relay it all out after saving to your frozen file.

*DIsclaimer - I only use versions pre 7.x, I can not say how well it works in versions post 7.x, nor can I comment on the fix mentioned above.

[SparkOut]

It is true that the Geometry Manager is not widely respected. I have used it successfully, but you really have to plan the layout first, and set the geometry at the end of the interface building process. Sometimes during that process it can get borked and needs to be rolled back. (To an actual backup of the stack.)
The difficult part in creating a GM is in catering for all the specifics of many possible variations of layout requirements. Laying out my own interface, it's not too hard to roll my own. Making a one-size fits all GM is much harder.
Given the restraints on resources, I can understand that the mothership doesn't really invest in this, but it is very disappointing. After all this time, I doubt there is going to be any significant attention to the GM. So the only advice can be to roll your own if you need to have a responsive layout. That may be "sound" advice, but doesn't make it palatable.
The "difficulties" in creating my own resize handler are... hmm... well, the effort of having to do it, when I could reasonably expect the inbuilt tool to work reliably. Perhaps the GM should be removed from the IDE if the best suggested solution is for people to roll their own. At least then they wouldn't have a false expectation and a negative impression when discovering the shortfalls of the built in GM.
Personally I would like for "development" to slow down a bit compared to "feature integrity" and bug fixes. Especially long term issues like the GM and inability for LiveCode on Windows to recognise a date prior to 1970. (And let's be clear, this is a "LiveCode issue on Windows" not a "Windows issue".)

[stam]

Given the restraints on resources, I can understand that the mothership doesn't really invest in this, but it is very disappointing.

That’s why I suggested a simplified GM like what’s available in FMP. Would probably be much more feasible to implement and everyone would be happy.
For more complex stuff, can still adjust layout in script, but for quick stuff would be a massive time saver...

[tetsuo29]

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.

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.

[bogs]

There were problems along those lines earlier on in the series that were solved later. I *believe* bwilmby (SP?) solved some others a year or two back.

Sorry Brian, I hadn't had my coffee yet

It should have read bwmilby.

[AxWald]

Hi,

I just don't understand the way the mothership's thinking. Cannot RunRev imagine what a devastating effect such half bugged ruins may have on new customers?

Imagine any developer from another language that heard the songs of praise many of us are singing - and that actually can be convinced to give it a try. She will download the latest "stable" and

• will realize LC istn't able to tell your browser how large the download is, so you just have to wait until it's done, w/o any estimation about "time/ MB left". "First impressions", overrated anyways ...

After the installation, an IDE will open that, at least here (Win10-64 on a typical business PC),

• feels like a snail trapped in concrete until you switch off all the "goodies" offered by it. And that
• will annoy you endlessly with wrongly selected cursors, and that
• will never respond to a menu selection at the first try.

Let's imagine the feelings of the potential new customer now ...

Assuming we haven't lost her yet,

• she'll start to code a bit & so is bound to run into all the new bugs introduced with her "stable" version. Don't pretend there aren't any - just read the forum whenever such a beast is released!

New bugs, regressions, old bugs still ignored - there aren't any new releases anymore, since years, that could be named "stable" using honest terms. The LC developer has to stay back with old, obsolete versions (that, at least, have only a limited amount of known bugs), or has to join the race of the "public betas" chasing one another, fresh bugs every other month. Keeps one young, right? Maybe I should try it, too ...

But assuming we haven't lost her yet,

• she'll soon run into rotting ruins like the geometry manager or the basic table object.

Begun in the days of old, never really finished, instead replaced with "just good enough replacements" (fullScreenMode & dataGrid). But then, never purged. Or well hidden, at least, to not scare 'em newbies (how it may have been done: see "database query builder").

Let's imagine the feelings of our potential new customer now - it's a good guess to imagine her running, screaming in terror, right?

It doesn't make me wonder LC isn't this wide known. RunRev is doing quite a good job scaring customers away.

[tetsuo29]

• will annoy you endlessly with wrongly selected cursors, and that
• will never respond to a menu selection at the first try.

Let's imagine the feelings of the potential new customer now ...

• I’ve just been noticing (and being annoyed by) the incorrect cursors in 9.6.1
• Hadn’t noticed the menu selection thing yet
• I was thinking the same thing about what happens with potential new customers when they come across something like the Geometry Manager and imagining that they go running back to whatever development environment they came from

Yep, I can’t help but wonder how much more well known and used LC would be if the mothership decided to focus on quality and bug fixes. If the product worked as advertised, I’ll bet they’d have many more paying customers than they do now.

[FourthWorld]

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?

@Richard, in a language that is claimed to be easy to use, why (if resize handling is so easy to code) don't the built in tools for doing just that work?

Because it isn't working out for him, hasn't for some time, and appears unlikely to soon.

And the alternative is scripting, no more onerous than anything else we do in a scripting language.

Over the years we see that those who ship the most software have never used it at all.

The engine was designed to provide resizeStack messages we use to handle resizing stacks.

The point-and-click alternative was added about a decade later, and has consistently proven useful only in simple layouts. It was a fine experiment and useful for some things, but not as many as people need.

So like most others I prefer to take a few minutes and script that myself, just as I script anything else in a scripting tool.

Given the primacy of the user interface in the user's perception of quality, time invested in having exactly what I want seems well invested.

And when the alternate doesn't do what I need, my choice is clear.

If using resizeStack handlers for their intended purpose becomes interesting, I'm happy to share what I've learned to help folks learn to use them well.

[stam]

Yep, I can’t help but wonder how much more well known and used LC would be if the mothership decided to focus on quality and bug fixes. If the product worked as advertised, I’ll bet they’d have many more paying customers than they do now.

As a relatively new (but now converted) customer, I completely agree. A simple but well working GM is far preferable to what's there now.
I would add that the IDE could do with a refresh to make it consistent with other IDEs out there that people are used to... Multiple palettes are just not great.

[dunbarx]

I recommend simply dropping it until, if ever, it can be properly updated.

New users often move quickly toward attractive self-contained features, such as the dataGrid. That particular gadget is stable, but not at all trivial, and I have seen many instances where I know that the learning process for LC in general has been sidetracked by the extra learning curve for the DG. One should need a basic license, earned after a certain amount of facility with LCS itself, before being allowed to even open a DG.

The GM also seems like such a standard and attractive tool. Lose it, at least for now.

Craig

[bogs]

@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.

As (almost) everyone else who posted here has put it, the expectation for someone coming to this language to not have basic parts of the tools of the IDE working as they do in any other HLL IDE would (I think) seriously put off a person just starting out. I've made this point before at least once or twice.

From your own post, you must agree with it on some level -

Given the primacy of the user interface in the user's perception of quality, time invested in having exactly what I want seems well invested.

You are a conscientious programmer, and you realize that if your interfaces don't work as your customer's would rightly expect them too, your customers will turn to someone else that can turn out a fully working program.

In this case, LC ltd. is in your position, they are turning out an IDE, and we are their customers. They include tools that *should* work, but in a number of cases do not as mentioned previously. Some of their customers have developed work arounds to tools that aren't working, but if you expect people who just start using this language to start writing their own tools to replace functions the IDE is falling down on, I think you are expecting too much.

I haven't seen a good tutorial on handling resizing and layout since the MC IDE was the IDE, and believe me finding it was no easy matter, but if a good tutorial isn't there to replace it, and you have to search long and hard just to find such, you are not going to have a lot of people sticking around.

I should add that, even *if* such existed, people will still judge the ability of the language by the primary tool used to make a program, after all, if the company making the IDE can't use the language in such a way to produce a stable, working result, how can you expect to turn out programs that work in a stable, consistent way?

Lastly, you mention the engine a lot, new comers won't have any idea most likely to what your referring. They will be interfacing with the visual tools provided by the IDE, not opening a text editor and scripting from scratch. That is, after all, the whole point of having an Integrated Development Environment, isn't it?