LC 8 Property Inspector

[Richard Gaskin]

Mark Wieder wrote:

 > ...we have reached the point where LC8 is no longer "LC7 with
 > widgets"... there's a serious divide here. So while I can play
 > around with LC8 and try to figure out the new gadgety things
 > that are being thrown our way, in order to get any work done
 > I'm using tools that will soon be end-of-lifed.
 >
 > I'm no fan of the current property inspector. Or the application
 > browser, for that matter. But right now they allow me to get
 > work done.
 > So I'm a bit dismayed that rather than fixing/improving these tools,
 > they've just been replaced wholesale, and judging by the controversy
 > this has raised it appears I'm not alone.

I see three options, listed here in order of ascending weirdness, though 
I feel obliged to note that "weird" simply means "of or pertaining to 
the supernatural", which is not necessarily a bad thing:


Weird: Finish Github-compatible tools to allow community contributions
----------------------------------------------------------------------
Given the variety of array-based and XML-based tools we already have for 
comparing stack files, and that all that needs to happen is some way to 
help the team identify and review changes efficiently, this may not be 
quite as onerous as it once seemed if managed by competent trusted 
community members in a check-in/check-out workflow.


Weirder: Fork the IDE and maintain it through any convenient means
------------------------------------------------------------------
The longest-running open source project in the history of the LiveCode 
engine was the MetaCard IDE, managed through an informal 
check-in/check-out process using technology no more sophisticated than 
email.  True, the MC IDE was a far less complex beast, but we were kids 
with far less experience. :)  We can't expect the company to fold our 
updated IDE into the product build (thought they're welcome to if they 
like and perhaps it may be very cost-effective to consider it), but at a 
minimum we could make a simple plugin that installs it and updates 
independently of the product build, just as Jacque did with her MC Setup 
plugin (available in RevOnline).


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.

At that point the IDE becomes a very slender thing, just a tool rack on 
which we hang our own tools.  And the tools within it would not only be 
the best of what the community has to offer, but could also be 
interchangeable.

I started down this road with the latest version of my devolution 
toolkit, but since I already have it set up with my own favorites I 
haven't spent the time finishing that part of it (see the disabled group 
in the middle of this Prefs window):
<http://fourthworld.net/lc/dev-prefs.png>

The idea there is that the option controls allow the user to pick the 
built-in IDE tool, or any plugin, to be opened when clicking the 
corresponding button to the left.

Finishing something like that wouldn't be hard, merely tedious, so you'd 
be able to assign any stacks to specific menu and/or buttons used to 
access them.

The weird soul using such an IDE could keep any LC parts if they like, 
or replace any parts with any suitably robust plugin, according to their 
whims.

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.

-- 
  Richard Gaskin
  LiveCode Community Manager
  richard at livecode.org