Mike Kerner wrote:
> Interesting - I just started messing with Xojo, again, since I see
> they're (finally) getting into the ios game (I didn't see anything
> about Android). Their version of the Geometry Manager is implemented
> on ios. I wonder if we're going to see it again in LC 8...
Am I the only person who enjoys hand-crafting resizeStack handlers?
I've tried the IDE's GM and third-party alternatives, and even
experimented a bit with custom options for that. But inevitably with
all of them I've found myself tasked with layouts that represent edge
cases in terms of what those tools handle, sequences of nested layout
dependencies that no generic tool can be expected to anticipate.
Even if the Ultimate Point And Click Layout Tool existed, by the time we
click click click click click click our way through it, how much time
have we saved over writing code that most often require typing only one
line per moved control, and frequently only a fraction of that with
groups, etc.
And while I appreciate the resizing is a far less frequent user action
than many others in an app's workflow, I still care that the resizing
happens with a more fluid responsiveness than we see with
layout-management bloat like attempting to resize the GarageBand window.
Any generic tool for layout will, by definition, trigger more code than
a custom-crafted handler that does only what's needed for the task at
hand. And geometry management in general is fairly tricky stuff, filled
with if-thens, case statements, and the like that push it way up on the
McCabe complexity scale. When I run into the inevitable edge case it
won't handle, I'd rather be looking at code I wrote myself.
So over time I just stopped worrying about it trying to find or make the
Ultimate Point And Click Layout Tool, and just respond to the
resizeStack message directly. This gives me complete control over every
detail of the layout in exactly the order of dependencies I need, and in
the most efficient way possible, all for just a few lines of code.
Besides, over the life cycle of an app relatively little of our time is
spent in anything related to layout. Most of our time is in writing,
testing, and debugging the core business logic of the app.
So resizing is often something you write once, make sure it does what
you want, and you never have to look at it again for months or years
until you make a significant UI change. And when you do make that
change you know exactly where to go to handle the new objects, since all
the instructions are laid out step by step in readable code.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
[email protected] http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
