LC 8 Property Inspector

[Mark Waddingham]

On 2015-10-13 17:35, Richard Gaskin wrote:
> It's possible to invest our time enumerating reasons why people
> shouldn't enjoy crafting tools in LiveCode, but to what end?
> 
> Any IDE (or IDE "tool" or "framework" or any other subset) is just a
> collections of stacks. The one thing we know about LiveCode
> programmers is that they know how to program in LiveCode.  Many of
> them are quite good at it.

This is where I have to disagree - an 'IDE' is *not* 'just' a collection 
of stacks. Those stacks have to work together in a consistent way, agree 
on certain conventions, protocols and 'how things should generally fit 
together'. It is a 'framework' which does this (even if it is one which 
contains no code, and just a long list of 'do's' and 'don't's).

> I see no harm in encouraging people to just continue doing what
> they've been enjoying for decades:  making tools to help their work
> and sharing them with others.

Indeed - there is no harm at all - it is actually quite important. I 
wasn't implying that it shouldn't be encouraged...

> All of the tools I've referred to - Mark Weider's, Bjornke's, Geoff's,
> Peter's, and others' - exist.  Why not have more?  Why not have a
> convenient launcher for them?

Great - how do you ensure that Mark's tools don't interfere with Geoff's 
so users can use them side-by-side?

If every toolmaker has to take into account every other toolmaker's 'way 
of doing things' you end up with a situation where one individual who 
wants to write a tool needs to learn about everybody else's if they want 
to distribute it for the benefit of all.

> Why not have an IDE for pro devs, another for kids, and other for
> educators, and others for just about anything people might want to do?

Again, let us not confuse 'IDE' with 'IDE Framework'.

> It's possible to imagine a perfect circle, but in the natural world
> none exists.  All systems are imperfect, influenced by subtle but
> pervasive forces that ultimately alter them from their ideal form.
> Anything that seems otherwise lives in the space between design specs
> and shipping. :)  Even the OSes we love are riddled with kludgey
> workarounds - not that we should pursue kludges, but it's no more
> useful to postpone everything until a perfect system exists.

Things are never perfect, it is true - but most people's daily lives are 
governed by rules, regulations and policies to ensure that everyone can 
co-exist (reasonably?) 'happily'. (Or at least function without huge 
amount of friction at every interaction).

My main assertion here is that I don't think 'the engine' in its current 
form provides a sufficiently strict set of such things for the purposes 
of interchangeable IDE Tool writing so there needs to be a concerted 
effort to build something on top of it which is.

> Ultimately you and I are describing the same goal, a modular and
> lightweight IDE system in which tools are plentiful and
> interchangeable, something Ken Ray and others have been advocating
> since the engine acquisition in 2003.

Indeed - advocacy and implementation are two entirely separate things 
though - which is perhaps why no such widespread 'lightweight IDE 
system' has appeared (to my knowledge at least).

> And there is one salient aspect: neither of us is describing an IDE
> that exists today.

I cannot agree there. You may be describing an IDE which does not exist 
today - some sort of mystical entity which will just appear naturally 
out of a lot of people playing around in a sandpit. Unfortunately, I 
don't have much confidence in chaos producing anything in any 
particularly useful timeframe (the mathematician in me screams that the 
numbers just don't add up in that regard).

On the other hand, I am describing an IDE (Framework) which is currently 
in the process of being built - we are working quite hard to try and 
separate out what tools in a LiveCode IDE need to function from what is 
specific to the tools themselves. As I've already said, we are trying to 
build APIs upon which any tool written by anyone could sit and still 
work together with any other tool written on the same APIs.

> All I'm offering here is encouragement for the things that led to this
> thread, an acknowledgement that some folks like the App Browser and
> others like the Project Browser and still others like Geoff Canyon's
> Navigator and others like their own.  And the same goes for object
> creation tools, and inspectors, and the rest.

What I'm offering here is more than encouragement - which means I hope 
that things might actually change :)

There are a number of people who are interested in creating IDE Tools - 
it is clear - indeed, many such tools already exist.

My offer to those who are interested in this are of things is simply 
this:

Take a look at what we are trying to do with the LC8+ IDE, dig around in 
the libraries we are creating. Play with moving your tools to those APIs 
which are gradually being chiselled out of the monolithic system which 
was there before, talk to us and help us improve and add to those APIs 
to ensure that over time all the services that any tool might need are 
there for them to use.

The aim is that, over time, we have a clean, thin, high-level API which 
everything else sits upon which tries to make no predetermination about 
any sort of part of an IDE, or the tools which sit within it. Indeed, I 
wouldn't discount the possibility that such an API could eventually be 
rendered in proper English-like syntax, embedded in the engine in some 
form to make it even easier for anyone to access and use.

Will this happen in the LC8.0 timeframe? No, I'm not expecting it to - 
I've become very patient with regards large scale technical projects 
these days ;)

However, LC8 will be better than LC7, and subsequent LC versions will be 
better still. The more people who get involved to help us reach the goal 
of a lightweight IDE Framework, the more quickly it will happen and the 
better it will be.

(By the way, I'm fully aware that for this approach to work we really 
need to start clearly documenting the IDE APIs we are building - I don't 
want people to start to get lots of bruises from wandering around in a 
dark room!)

> Let a thousand flowers bloom.

Indeed - a thousand flowers blooming can be a truly breathtaking sight.

However, it is much less amazing if those thousand flowers are dotted 
around the world individually, not being able to be brought together 
because they cannot co-exist within the same climate, or in the same 
soil.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps