One of the beautiful things about making GUIs in LiveCode is that we
generally get a very satisfying and immediate sense of physicality with
the controls we're working with: we envision the user interface, drag
out controls to match that vision, and we have a one-to-one
correspondence between what we're doing as developers and what the
end-user is working with.
Most of the time this physicality lends itself to an uncommonly
productive workflow. I was talking about this with Trevor the other
day, and we both agreed that the direct manipulation of controls in a
"live" environment, coupled with a language that includes GUI controls
as first-class citizens, is a big part of why we continue to rely on and
enjoy LiveCode.
But from time to time, we find particularly ambitious GUI designs that
become problematic within this paradigm. Not impossible, but requiring
us to abandon the comfortable sense of physicality to consider more
traditional solutions.
As Mark Waddingham pointed out, the memory and CPU requirements for
working with tens of thousands of objects can be onerous, in some cases
perhaps prohibitively so.
That's part of the reason why most of the world solves GUI problems
through radically different means than LC does.
LiveCode does such a good job of maintaining the illusion that GUIs are
physical objects that we often take it for granted. But in lower-level
tools, you're required to be constantly aware that all of that is just
an illusion - the structs, the buffering, the hit-testing, it's all
abstraction that only appears physical at the very end of a very complex
set of processes.
In lower-level languages, most of the time if it ain't on screen it
ain't instantiated. They don't even bother. No need - no one can see
it anyway. They maintain just enough info to know when a control needs
to be instantiated, and then do so only when it will be visible in the
window.
The DataGrid is a good example of a middle path between the abstraction
of lower-level languages and the physicality of LC controls:
You can have any number of rows in a DG, but truth be told the only ones
that actually exist are the ones you're looking at.
Trevor has made very smart of use of fluid scrollBarDrag message to
populate the visible portion of the group with the controls relevant for
that scroll position. Everything out of view doesn't really exist, at
least not in terms of GUI controls.
It's a non-trivial task to effectively virtualize large numbers of rows
and instantiate only what's visible on the fly. He's done an excellent
job of that.
In addition to being a very valuable part of the LC toolkit, the DG is
also a reminder that with a little effort we can solve even big problems
in LC, even though some of the bigger ones require us to set aside the
perceived physicality and think about things in a more traditional
computer science way.
I've found, as Mark confirms, that the coordinate space in LC is limited
to about 32765 px.
Given the power of computers and the ease of using LC, we might
sometimes see that as a constraining limitation.
But think about it: at 96dpi that's just under 28 feet on a side - far
larger than any monitor you can buy, which means far larger than
anything any user could possibly see.
When we need to work in unusually large spaces, it becomes time to think
in unusual ways.
By paging rendered elements, as the DG does, we can handle nearly any
size of coordinate space.
It requires more work to think through a solution that makes sense for
the design at hand, but just about anything you can imagine is doable,
even if the worst that happens is that we have to think about solutions
using methods similar to how the rest of the world has to deal with them.
In the case of the task at hand here in this thread, the solution is
even simpler: the DG already provides one way to virtualize large
numbers of controls for us with minimal effort to use, and it may be
possible to take advantage of the flexibility of LC fields, with their
excelling buffering, to do that as well.
But even the in a worst-case outcome, where we'd need to figure out a
paging mechanism from scratch. I wager that even though it requires more
effort than just laying out tens of thousand of controls, it can be done
in LC far more productively than one could do in just about any other
GUI toolkit.
--
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
