I'd like to take a completely tangential approach to this whole dilemma. When I first came aboard, I was thrilled by what I thought was to be a continuation of "H/C"; but, shortly I was to be disillusioned by a number of factors.
1. I had little problem with the initial cost to sign up for Revolution; but, very soon I discovered that it was going to be MUCH more expensive for the "H/C" accustomed user to adopt. I'll talk about this more, later on. 2. Though I certainly appreciated the multi-platform aspects and a few other "tweaks"; I was flabbergasted to discover that RunRev had mangled the H/C framework by eliminating the Background layer in stacks, providing a very clumsy alternative method, so that the millions who could be adopting it from H/C would have to re-implement most of their legacy stacks. It just wasn't the same Object Hierarchy any more. I tried to be upbeat with the articles I wrote on MacInstruct about Revolution, but Revolution just wasn't a better H/C. What RunRev did later in transitioning to LiveCode is a totally different issue. The damage had already been done. So.... what should have been done? I realize that one of the Steves would be a hard sell; but, in some manner, Apple needed to get behind Revolution. We needed some really deep pockets, such as Woz to endorse Revolution so that the price for Revolution would be like H/C - you bought it once. Then it should have been developed to perfection as Revolution, probably up to the Intel Mac level and "bug-free". Once Macs switched to Intel CPUs, a totally new line could begin that would have been LiveCode. At this point Revolution should then have been bundled (free) with all new Macs and PCs, providing an option to down-load the new LiveCode Platform for a nominal, layered fee of some amount that users knew they could count on for new major - releases; knowing in advance that they would be able to use these as fully functional and reliable should they elect not to continue with the new releases. I realize that, in hind-sight it is fairly easy to see where things "might" be going; something that most of us would not have been able to anticipate in the moment, but the future of LC should have been better scripted so that RunRev was ALWAYS producing identifiable products that were capable of performing predictable applications; so the users ended with a list of products instead of an endless string of unreliable prodcts with a single name. Yes, there would be nominal charges for each new level, but the user would know that without the new "product", he/she could stop at any point. I know I'm glossing over many of the obstacles that might have been encountered, but I'm sure you all get my point. I feel confident that that a well structured plan similar to this would have brought a great many into the fold. I want my background layer back. Not going to happen, I know. (sigh) Joe Wilkins On Feb 1, 2013, at 2:45 PM, Mark Wieder wrote: > Peter Haworth <pete@...> writes: > >> >> OK, but Java isn't "Apple software", is it? Even their own software >> updates notify me it's about to be updated and a chance to say yay or nay. >> Plus, owning the software doesn't seem like it gives them the right to >> block it from running on my computer. > > Of course it does - my guess is that it was installed as part of the operating > system, meaning that you didn't take it upon yourself to delete it and replace > it with OpenJDK or something similar. Look, I'm not going to try to explain > the > rest of the EULA to you because I'm not one of them lawyer fellas and I'll > probably screw it up. But "Apple software" is defined, various third-party > licenses are dealt with, and you agreed to it, including that part about Apple > reserving "all rights not expressly granted to you". Game over. > > -- > Mark Wieder > mwie...@ahsoftware.net > > > > > _______________________________________________ > 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 _______________________________________________ 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
