Richmond wrote:
Gottit at last; the new GUI mockup:
http://web.archive.org/web/20130203003005/http://www.kickstarter.com/projects/1755283828/open-source-edition-of-livecode?
The biggest difference there is that the stack you're working on is
displayed as a pane within a larger IDE window that binds many of the
existing tool palettes together.
On the technical side, this is dependent on completion of a new object,
once referred to as Viewer in another xTalk (Sybase Gain Momentum) but I
don't know what the final LC form will be called:
<http://quality.runrev.com/show_bug.cgi?id=2786>
A Viewer control allows you to have any stack appear as a control in any
other stack. Given the UI shown in the Kickstarter page, it would seem
such a control would be needed before that particular UI could be
implemented.
On the workflow side, as much as I would love to see Gain-style Viewer
objects in LiveCode for my own products, I believe they're of minimal
actual value in the development workflow, though I understand it can be
extremely value for demoing LiveCode to those who don't yet actually
work in it.
We see many comments from newcomers about why LiveCode doesn't look like
other IDEs, as most other IDEs look very much alike, and very similar to
that mockup.
But other tools aren't LiveCode - you're not working in LIVE code.
In other tools, layout and runtime are completely unrelated tasks, often
with a long compile time in between.
So instead of working in a real window, XCode, Xojo, and most other IDEs
offer only a proxy rendering of your layout, within a drawing
environment in which nothing is ever expected to actually execute.
In LiveCode, the windows we work in are the same windows that are
running - it's all LIVE code. Real windows, with real-time results.
Rendering your app's window inside of an IDE window may be helpful for
layout, but introduces differences in runtime that may often be undesirable.
And if you think about it, over the life of an app relatively little
time is spent laying out controls. Most of our time is spent editing
code, debugging, etc.
[As a side note, given how little time we spend doing layout it's always
mystified me that LC offers no preference not to have the Tools palette
always open whenever LC launches.]
This is a difficult balance, however. In order to become one of us who
spends many months working on an app through many versions, you'll need
to first become enamored of the tool. And if it doesn't look like the
IDEs you're used to, even if those IDEs are different because they're
designed for a radically different workflow, LC may seem less modern
than it actually is.
In short, as long as the single-window IDE is an option, it will be very
valuable.
I trust the team appreciates the value of the workflow that
distinguishes LiveCode from other toolkits enough to allow us a choice
in this, like being able to remove training wheels once you understand
how to ride a bike.
--
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
