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
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
