LC 8 Property Inspector

Mark Waddingham mark at
Sun Oct 11 05:56:40 EDT 2015

On 2015-10-10 22:12, Richard Gaskin wrote:
> Weirdest: Replace the IDE with the best of community components
> ---------------------------------------------------------------
> Like the "Weirder" option above, this would be independent of the
> product build, but would open the door for anyone to do whatever they
> want.  Bjornke's BVGDocu could replace the Dictionary, Peter's
> lcStackBrowser could replace the App and Proj browsers, your GLX2
> editor could replace the Script Editor, etc.
> It's like the thing I like most about Linux:  although people in the
> Linux world enjoy arguing about darn near everything, the fact is
> there's actually little to argue about since the system is so flexible
> and has so many components available there's no reason why everyone
> can't have exactly what they most desire.

The obvious option (which is the one we have been working towards in the 
LC8 IDE) is that the IDE becomes a 'framework'. It provides well defined 
extension points, well defined APIs for building IDE components, and a 
well defined mechanism to ensure that changes flow properly so all 
components are kept synchronized.

The IDE framework has to be the arbiter which ensures that two distinct 
IDE components (which could be written and maintained by people who 
never speak to each other) can happily co-exist with each other in an 
end-user's install.

In particular, this means that IDE components *cannot* patch random 
parts of the IDE (as they might conflict), and any points within the IDE 
which might be usefully customized (e.g. adding extra buttons to 
revMenubar) need to be explicitly exposed in a well-defined way.

Now a lot of work has been done towards this, but at the moment if you 
want to play with it you have to do a bit of digging around in the 
libraries which are emerging (revidelibrary, revideextensionlibrary 
etc.) and the revised components which use these new APIs. Admittedly we 
aren't quite there yet as it does take time to introduce good 
abstractions into code which did not have them before (well, not ones 
which were suitable for a more step-back and provide the ability for 
anyone to extend point of view at least).

Warmest Regards,


Mark Waddingham ~ mark at ~
LiveCode: Everyone can create apps

More information about the use-livecode mailing list