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
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
