Re: [MC_IDE] Quick Poll
Hallo Wilhelm, On Tue, 29 Mar 2011, Richard Gaskin wrote: In keeping with RunRev's commitment to the MC IDE, Oliver Kenyon provided the necessary info to allow us to use the new engine-based standalone building process in v4.0 and later. I checked my mails to the Metacard list and found that I had sent 6 mails on the subject of standalone building between Sept 7 to 9, 2009, referring among other things to comments made by Oliver Canyon concerning bug #2217 and a patched Rev stack also concerning standalone building. Klaus Major and you participated in that discussion as did others. But this information from Oliver Canyon was apparently not sufficient, why else had Klaus encountered so many difficulties in writing a standalone builder? Building the new standalone builder a bit complex, but not impossible. I had some personal problems at that time that prevented me from doing so! Could you possibly point out where we could find this necessary info from Oliver Canyon, if it was available it surely escaped me?. This and the difficulties of Klaus - there are other reasons as I understand and deplore on the side of Klaus - led me to assume that there unfortunately had *not* been sufficient information from the RunRev side to build a new MC-compatible standalone builder I received the neccessary infos from scotland but this is of course nothing that should go into a public mailing list, so I did not publish this info! As I noted earlier, I've been using this info to make a new standalone builder, which I'll donate to the MC IDE project. Richard, this is really great news. Many, many thanks to you for this donation! I should note that mine only builds desktop standalones, and does not support RevWeb or mobile at this time. I'll probably get around to adding mobile support, but RevWeb is of no interest to me so if anyone wants that they'll have to add it to the donated stack once it's available. I think a desktop standalone builder is a giant step forward at the moment. Add-ons for web and mobile development could follow later if really needed. Adding support for iOS (and RevMoile in general) was explicitely NOT allowed to be put into the MC standalone builder due to licensing issues! At least that was the state about a year ago, don't know how this is today. But Ken knows about this and will check this with Heather before taking any action in this direction! -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Again, thank you Richard and best regards, Wilhelm Sanke Best Klaus -- Klaus Major http://www.major-k.de kl...@major.on-rev.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: [MC_IDE] Quick Poll
Richard wrote: On 3/29/11 11:24 AM, Wilhelm Sanke wrote: Could you possibly point out where we could find this necessary info from Oliver Canyon, if it was available it surely escaped me?. This and the difficulties of Klaus - there are other reasons as I understand and deplore on the side of Klaus - led me to assume that there unfortunately had *not* been sufficient information from the RunRev side to build a new MC-compatible standalone builder In all fairness to RunRev, it's not an easy change. And I would even go so far as to say it was a useful change, actually necessary as far as RevWeb is concerned and also UAC, and also helpful for both RunRev's license protection and for the MC IDE, since now the engine does all the bit-level stuff (binding the engine, embedding icons, embedding UAC info, etc.). It took a few back-and-forth emails with Oliver to get this down, and a fair bit of trial-and-error on my part. Actually, a lot of trial and error since any error messages that come back from the engine are rather sparse. It's not a task I'd wish on anyone who has other things to do, but I do feel it's fair to say that RunRev, and particularly Kevin, Mark Waddingham and Oliver, made themselves available to help with my understanding of the initial example that Oliver had sent to Klaus and I, and ultimately it was their willingness to help that made the new SB possible. and Klaus wrote: I received the neccessary infos from scotland but this is of course nothing that should go into a public mailing list, so I did not publish this info! Thanks Richard and Klaus for the feedback, and also to Monte for chiming in. Richard indeed makes it plausible that Kevin and his team still stick to their commitment to continue to help to support the MC IDE in its compatibility with newer engines of Revolution/Livecode. Though - I say this with a piece of my tongue in cheek - the whole matter reminds me a bit of the communication problem political parties in Germany recently used as an argument when they had lost elections: We stand to our principles and our goals are OK, but unfortunately we had a communication problem with explaining our goals to the voters.-- Apparently the - somehow privileged - information received from RunRev was not comprehensive enough to let Richard and Klaus create a new standalone builder at once. Richard needed several contacts with more than one person and additionally trial and error processes as he writes. And we had to wait one and a half year until finally we now got the prospect to see this new standalone builder soon. I think such a kind of support from the RunRev side urgently needs to be improved and accelerated! There is also the question - having been asked and discussed heatedly on the RunRev lists time and again - why are things sometimes made so overly complicated that they affect functionality and user-friendliness that negatively? While overall it could be stated that Revolution/Livecode has indeed improved considerably over time, there are still features that are not up to par or have even deteriorated, among them the support for the MC IDE. Aditionally Revolution has had a lot of egregious problem issues during its development, think of one of the earlier application browsers that were practically unusable or the Rev standalone builder in 2004, which needed an hour or more to build standalones from certain types of stacks. In my Teststack http://www.sanke.org/Software/RevTestStacks.zip I had described some of the problems encountered at that time and also outlined a recipe to fix this particular standalone problem. At that time - 2004 - RunRev had also given up its principle to allow the possibility of total customization of the Rev IDE (a principle introduced and observed by Scott Raney for Metacard) by encrypting the standalone builder. Fortunately, there occurred a small time window to look at an inadvertently unencrypted update, which enabled me to make proposals how to fix the issue. Shortly after this Monte Goulding was assigned to repair the standalone builder, which he did with great success - maybe using some of my recommendations (I do not know) or along his own lines - obvious to his analytical and practical mind. Had we had access to the code of Rev standalone builder now, it would have been much easier for many of the Metacard group members to understand how the standalone file is being attached to a stack, and then create our own standalone builder accordingly. I have never fully understood and accepted the protection of the Rev Standalone Builder. I know they give reasons pertaining to licensing procedures, and they want to prevent that someone circumvents the embedded licensing procedures and builds his own product and then competes with Revolution, but I believe these fears are unfounded, as there are surely means to guarantee a proper licensing process without
Re: [MC_IDE] Quick Poll
On 3/30/11 12:52 PM, Wilhelm Sanke wrote: Apparently the - somehow privileged - information received from RunRev was not comprehensive enough to let Richard and Klaus create a new standalone builder at once. Richard needed several contacts with more than one person and additionally trial and error processes as he writes. And we had to wait one and a half year until finally we now got the prospect to see this new standalone builder soon. Blame me for that, not RunRev. They provided this info long ago, but during all this time the number of requests for an updated MC SB here - or just about any other enhancement - has been close to zero. As far as I could tell the only folks still using MC was just Ken, Klaus, and I, and even after the recent round of discussions we still see only about a dozen people using it. So with all the client work I've had keeping me busy and no evident use of MC here, my time has been spent accordingly. Oliver provided the info we asked for almost as soon as we asked for it. I can't expect any better than that. Any delays in getting a working SB to you fall on me, not RunRev. They've done their part, promptly and helpfully. Now that we see some activity here I'm happy to get back to it, but let's please remember that this is a community-driven process in which MC enhancements come at the expense of paying work. Klaus has done a wonderful job adding the stuff he has, and I appreciate Ken taking the lead this time around. But all that work is donated, paid for by their client work, and for the benefit of a notably small and ever-smaller MC user base. So I apologize for taking the nearly complete inactivity on this list at face value, and will do my best to make this latest contribution as quickly as time permits. But please, let's keep RunRev out of it, at least as far as blame-hunting goes. While overall it could be stated that Revolution/Livecode has indeed improved considerably over time, there are still features that are not up to par or have even deteriorated, among them the support for the MC IDE. MC is an open source project outside of RunRev's role. It's not theirs to maintain, it's ours. What would you like to contribute? At that time - 2004 - RunRev had also given up its principle to allow the possibility of total customization of the Rev IDE (a principle introduced and observed by Scott Raney for Metacard) by encrypting the standalone builder. Right, but as I noted earlier they've since fixed this by moving the build process into the engine. If sufficiently motivated I suppose one could make a case that this move to engine-based building is also somehow an anti-MC plot from RunRev - but what would be the motivation? Trust me, they have bigger fish to fry than picking on us. I've seen nothing worse than disinterest from RunRev with regard to MC, and often some very direct support of our effort even though it has almost nothing to do with their business plan. Never have I seen any indication of any attempt to thwart MC. I have never fully understood and accepted the protection of the Rev Standalone Builder. I know they give reasons pertaining to licensing procedures, and they want to prevent that someone circumvents the embedded licensing procedures and builds his own product and then competes with Revolution, but I believe these fears are unfounded, as there are surely means to guarantee a proper licensing process without necessarily encrypting the standalone builder. It's happened once before, with SuperCard and Digital Chisel. I can't blame RunRev for not wanting to be the second example. And, would it be possible to get access to the privileged information Richard and Klaus received for creating the MC standalone builder? I would really like to know - and I think others, too - how the standalone file is being attached to a stack. And I assure sincerely that I am not intending to produce a competing product. Offhand I don't think that would be a problem, but I'm not Kevin so I should probably run the request by him first. He'll probably ask what the purpose is, esp. given that an updated SB for MC is already well underway. What should I tell him? -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com LiveCode Journal blog: http://LiveCodejournal.com/blog.irv ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: [MC_IDE] Quick Poll
Monte, I'll risk redundancy because your efforts warrant the recognition: thanks again for the help you provided during the last major change to MC's SB. Many of us have contributed code to MC, but your contributions involved bit-level tedium that a lesser man would not have attempted. :) Let's not overstate things. What I did back then was just a cut and paste job. It's funny you talk about the low traffic on this list. I didn't know I was still on it ;-) Cheers Monte ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: [MC_IDE] Quick Poll
Shortly after this Monte Goulding was assigned to repair the standalone builder, which he did with great success - maybe using some of my recommendations (I do not know) or along his own lines - obvious to his analytical and practical mind. OK, I know what you are talking about. Richard this is that slowness when parsing object properties when the stack isn't toplevel. We discussed it a while back on improve in the middle of a data storage request you had. The LiveCode SB has to parse the stack to remove some IDE properties, make sure images etc are moved from libraries and so forth. Wilhelm's test stacks have many thousands of controls on one card and so they are slow. I did resolve the issue but it resulted in stacks flashing up on screen and obviously that wasn't appreciated. I can't remember why I didn't use go invisible but there must have been a reason... Your test stacks are in my opinion such a unique use case (I'd be interested to see a real app that requires 10 controls) that it's probably reasonable to ignore it to avoid the visually disturbing flashing up of stacks. The MC SB doesn't or didn't do anything like this so the issue was never present there which leads you to believe there is an issue in the LiveCode SB. It does more and therefore takes more time. Standalone building isn't or at least I don't believe it should be a regular part of your day. Particularly working in MC where the standalone builder doesn't include anything you really only have to build once for each app per engine. So if it takes half an hour go and get a coffee. As for the protection of the standalone builder I assume RunRev believe it's critical to protect their investment and therefore my investment in my business. As a result when I considered some development I was considering for the GLX framework and I realised it could be used to circumvent LiveCode deployment packs I decided not to implement it. I would be concerned if the MC IDE included unprotected code that could be used in the same way. My recommendation to anybody working on the MC SB would be to create code that extracted the SB and SB settings from LiveCode and any supporting handlers and insert it into the MC IDE. Obviously there's going to continue to be regular development of deployment options and that seems the only reasonable way to spend your time given the limited number of users and developers of MC. Cheers Monte ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: [MC_IDE] Quick Poll
On 3/30/11 4:15 PM, Monte Goulding wrote: My recommendation to anybody working on the MC SB would be to create code that extracted the SB and SB settings from LiveCode and any supporting handlers and insert it into the MC IDE. Obviously there's going to continue to be regular development of deployment options and that seems the only reasonable way to spend your time given the limited number of users and developers of MC. Agreed - that's exactly the route I'm taking. It won't make use of any of the info for the extra stuff Rev does, but it won't alter that info either, so one can build standalones interchangeably from one IDE to the other. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com LiveCode Journal blog: http://LiveCodejournal.com/blog.irv ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: [MC_IDE] Quick Poll
On 3/30/11 6:15 PM, Monte Goulding wrote: As for the protection of the standalone builder I assume RunRev believe it's critical to protect their investment and therefore my investment in my business. As a result when I considered some development I was considering for the GLX framework and I realised it could be used to circumvent LiveCode deployment packs I decided not to implement it. I would be concerned if the MC IDE included unprotected code that could be used in the same way. I find that very honorable. Like you, I need RR to flourish if I want my own business to remain healthy. I appreciate what you've done, Monte. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
