Geometry Manager - Anyone?

[Richard Gaskin]

Mike Kerner wrote:
 > I would like the GM to get some attention, because "writing your
 > own" is worse than tedious.

Related, Rick Harrison wrote:
 > Thank you for your well put together answer on the subject.
 >
 > It does however bring up the point that all of us are probably
 > reinventing everyone’s wheel over and over. It might make
 > sense to put together a routine that could be shared with
 > everyone that is of a generic nature to help solve this problem.

Generalization is usually a good thing to pursue, allowing us to reuse 
code in multiple contexts.

But if we take it far enough the limits of generalization become obvious.

For example, we can imagine the IDE reduced to a single button labeled 
"Build App", and out pops whatever you need.

Of course that's silly, since each of us needs something different.

And to varying degrees, that "something different" applies to what is 
arguably the most intimate part of our apps, the layout of the user 
interface.

All solutions for handling resizing are responding to the same 
resizeStack engine message. Given how important UI is for a good app, I 
would no sooner leave those decisions to some tool to guess what I meant 
than I would want a "Build App" button to guess about everything else I 
want my app to do.

Any point-and-click solution will have some appeal, but by its nature it 
will still need to be learned and will add a good deal of complexity to 
your resize code.  Other people's code is still code, but code you're 
not familiar with, code that's much more complex by virtue of being 
generalized, and depending on the library you use it may also be code 
you don't have access to.

And when it's all said and done, whether you make several clicks to 
adjust an object or type a few lines of code, what is the net savings on 
time?

If the GM or an alternative is working well for you, enjoy it.  If you 
need to extend it for mobile, extend it.  But most experienced 
developers who've chimed in on this discussion of point-and-click vs. 
total lean control through code have expressed the same opinion 
consistently over the years:  even when a point-and-click solution works 
well initially, there will inevitably be a time when you need to do 
something with your layout that such a tool couldn't have anticipated. 
At that point you'll need custom code anyway, but with the added 
question of how your responding to the engine's resizeStack message may 
be affected by whatever library you've installed to handled the 
placement properties put into place by a point-and-click tool.

Programming requires typing, and if handling a resizeStack message seems 
tedious then just consider adequate error handling. :)  In most apps the 
resizing code is a very small part, but we may see a fourth or more of 
all code in a program written just to handle exceptions.

LiveCode is easier than other languages, but no language is a magic 
pony.  Purely point-and-click programming systems like Scratch have 
fixed walls you run into fairly early on.  Textual programming offers 
much more flexibility.  We choose textual programming to express 
everything else we do in LiveCode, why not for our UI layouts as well?

Total control, lean performance, explicit maintenance, all for the low 
cost of a fraction of the time you'll spend on non-feature things like 
error handling.  Seems like a bargain to me.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com