LC 8 Property Inspector

[Mark Waddingham]

On 2015-10-12 22:31, Richard Gaskin wrote:
> That's an obvious option if we assume there must be only one IDE.  And
> from the company's perspective that's a useful assumption, at least in
> as much as they need to provide at a solid basic toolkit to accompany
> the engine.

Well, the engine is pretty useless in isolation without tools to be able 
to build apps with it (unless of course you are happy with restricting 
yourself to script libraries and using a text editor - which whilst 
appropriate for some endeavours, for most purposes it would be extremely 
tedious).

> I've been using my own tools within every xTalk IDE I've used, and as
> long as frontScripts work and we pass messages as good citizens do,
> there's an opportunity to have LESS dependence on a large IDE
> framework rather than more.  Or if we were to be thorough, a fairly
> slender one.

I think you might be confusing 'IDE' with 'IDE Framework' here - they 
are two quite distinct things.

> Tools can be entirely self-contained and fully interchangeable, even
> open at the same time, using nothing more than what the engine has
> provided for years.

Really? Are you sure that is true?

So you would have every 'application browser' type tool implement its 
own code for monitoring for changes in the user stacks, and for 
collecting all the data about the objects in user stacks?

You would have every 'tools palette' type tool implement its own code to 
go digging around on disk for all extensions, listing, enumerating and 
providing an ability to create them?

You would have every 'documentation palette' type tool implements its 
own code to go digging around on disk for the content it needs to 
display, and then its own code for processing that content into the form 
it wishes to display?

You would have every 'standalone builder palette' type tool implement 
its own code for building standalones?

You would have every palette which wants a button on some sort of 
'launcher stack' have to understand how every 'independent' launcher 
stack needs to be told to add its button?

And assuming you would have that, how do you ensure that all these 
components which can be used in a 'fully interchangeable' and in an 
entirely 'self-contained' fashion don't actually interfere with each 
other to the detriment of the user stacks they are acting upon?

In order for any system to work where you can plug-and-play components 
from different sources you need to have a common basis of communication 
which provides the basic services all the components need to ensure that 
they can be used together in the same environment without conflict. 
Also, you need to ensure that said set of basic services is rich enough 
that those that wish to write such components don't spend most of their 
time re-inventing the wheel and can focus entirely on the purpose of 
their component.

Now, I see that you appear to regard the 'engine' with some sort of 
magical prowess. Indeed, it does provide a 'standard' interface to a 
common set of functionality that is exposed through its object model and 
syntax; however, I'd assert that the engine's interface is not at a 
high-enough level right now to give you what is needed for what you 
dream of in terms of the 'bit that binds all these decentralised built 
components together'. Thus any solution which provides the above 
'nirvana' in terms of interchangeable tools will end up relying on a 
collection of script libraries which everyone's tools rely on and use to 
ensure they can all co-exist together - i.e. you end up with precisely 
the IDE Framework that I've been talking about.

It is important to remember that 'framework' means precisely that - it 
is scaffolding, policy, and ancillary services. A 'framework' is just 
there to ensure that everything works together for its particular end 
purpose - and good ones interfere as little as possible with the actual 
action of the components which sit within them.

Ideally, of course, the 'engine' would provide such an appropriate 
high-level interface - a strong API - for tools written by disparate 
parties acting together in a single environment to give users complete 
choice in their toolkit for creating LiveCode applications...

... Sounds like a good way to approach that (given how much faster it is 
to write LiveCode Script than C++) would be to provide the engine with a 
standard set of script libraries which present a suitable high-level 
interface for building IDE Tools to ensure tool writers (including 
ourselves) can easily build tools...

... Which is rather like what we've been working on in the LC8 IDE ;)

Warmest Regards,

Mark.

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