LC 8 Property Inspector

Tue Oct 13 11:35:12 EDT 2015

Mark Waddingham wrote:
> 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).

Of course, which is why I wrote "they need to provide at a solid basic 
toolkit to accompany the engine".

Thumbs up on the team's continued IDE efforts.

Noting I've written is an "or". merely a "yes, and...."

>> 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.

I refer to the engine with admiration only because we all understand 
that it's what runs all scripts, including those in an IDE.  I rather 
like LiveCode Script, and find it very capable.  The existence of any 
IDE suggests it's useful for making those sorts of things.

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.

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, I see no way to stop them. :)

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?

Why not explore new ways of authoring in LiveCode?

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?

Maybe even one for weirdos who like to play with exploratory skunkworks 
projects.  Sometimes useful discoveries come from such explorations.

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.

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.

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

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.

Of course the core dev team should also continue doing what they're 
doing too.  And over time each can learn from the other.

Play, explore, create, share.

Let a thousand flowers bloom.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com