Kickstarter 2013 Revisited

Richard Gaskin ambassador at fourthworld.com
Mon May 11 15:10:47 EDT 2015


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
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com




More information about the use-livecode mailing list