LC 8 Property Inspector

[Richard Gaskin]

J. Landman Gay wrote:
 > It's likely you've never had interference issues with Navigator
 > because users wouldn't be using more than one property inspector
 > simultaneously. But my Zygodact system did interfere with the GLX
 > framework and I had to rewrite it to accommodate GLX. It wasn't how
 > I wanted things to work, but enough people were using GLX at the
 > time that it was necessary. Fixing the problem required communication
 > between me and the author.
 >
 > The conflict occurred because of different approaches when handling
 > preferences files. Standardization would have avoided the issue.

It would be interesting to learn more about the details of that 
conflict, informative for both the IDE team and skunkworks projects alike.

It may be a question of scope, since as you noted that GLX isn't a 
discrete tool but a framework.  Ideally even frameworks should coexist, 
at least when of different types, since things like GLX are for apps and 
an IDE's being for the tools run alongside the app during development.

This is one reason why, although I'm aware of the difference between a 
plugin and a framework (I've been making both for decades), I don't 
often distinguish them in discussions of the opportunities and 
challenges of either:  the underlying issues with regard to components 
playing nice together are similar, varying mostly in scope but not so 
much in their nature.

Indeed. the more I think about your specific circumstance the more I 
realize that what you're describing reinforces my point that dependence 
on presumptions of a single monolithic framework can sometimes introduce 
as many issues as they seek to address:

Even if there were one single modular framework for IDE tools, what 
occurred in your circumstance is quite different, a conflict between 
*application* frameworks which each assume themselves to be the only 
such thing in play.

We hope that the LC world would have many app frameworks over time, just 
as one expects to find for any popular language like JavaScript or Python.

And like frameworks in other languages, they're not always mix-and-match.

Standardizing some core elements like prefs handling may be useful for 
all app framework developers to discuss and explore solutions for (Andre 
once proposed a stdLib for LiveCode for exactly that reason), but 
anything app frameworks do would be independent of any IDE frameworks 
used alongside them.

There are many ways to resolve such conflicts, one of them being lengthy 
discussions of all possible circumstances and an expensive effort to 
craft a single one-size-fits-all solution to accommodate every app 
developer's need.

But I find I learn a lot just watching how things organically evolve, as 
they did here:  a conflict was discovered, a script change affordably 
implemented, and both toolkits now live happily together with minimal 
effort.

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