Re: [MC_IDE] Quick Poll
Hi Wilhelm, 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. Don't blame it on Richard, blame it on yourself! 8-) And/or me, if you really need to blame someone, although I plea: not guilty! 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. This is the point, it seemed to have had zero priority for anyone on this list! ... 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
This is the point, it seemed to have had zero priority for anyone on this list! Actually, some of us don't like to ask for things when we know that people are donating their time. We simply silently wait for things. I remember having some sort of frustration with the whole standalone issue which may be why I stayed at MC/Rev 4.0 and did not move forward. I don't recall if I had to build with the engine from 3.5 or if 4.0 was okay. I just know that the whole thing was such a frustration that I took a break and worked on things that would not require builds for awhile in the hopes that the kinks would find resolutions later on. Now I am afraid to move forward because I keep seeing discussions on the Rev list about bugs in things that have been solid for a decade. I don't know if the whole Rev code was rewritten and is now not as solid as before, or if the discussions refer to special versions for iOs and so forth only. If you don't catch the beginning and jump into the middle, it's a bit distressing to see bug after bug listed. I know the standalone issue will revisit me soon as I'm working on something actively right now. I dread that moment. -- Bad Dog Books http://books.gityasome.com Critters, humor, patriots and sports t-shirts http://www.bearsware.com WlND0WS and MAClNT0SH shareware http://www.gipsyking.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: [MC_IDE] Quick Poll
On 3/31/11 9:10 AM, Shari wrote: This is the point, it seemed to have had zero priority for anyone on this list! Actually, some of us don't like to ask for things when we know that people are donating their time. We simply silently wait for things. Hopefully we can all feel comfortable speaking up going forward. A lot of long-time MC users have moved to LC IDE, so without input here there's no way for Klaus or Ken to gauge what's needed. We're all family here - feel free to speak your mind on anything you need or even want from the IDE. And feel free to propose anything you want to contribute yourself - it's open for that reason, to hopefully capture some of the collective talent and motivation from its users. And if your ideas are too weird (as many of mine have been), you're free to modify the IDE however you need (which is how I've been scratching my weirder itches g). Now I am afraid to move forward because I keep seeing discussions on the Rev list about bugs in things that have been solid for a decade. I don't know if the whole Rev code was rewritten and is now not as solid as before, or if the discussions refer to special versions for iOs and so forth only. If you don't catch the beginning and jump into the middle, it's a bit distressing to see bug after bug listed. I would take those with a grain of salt. Well, some of them anyway. Best to look at each reported issue on a case-by-case basis and determine its merit and applicability to your work accordingly. As one of the few people who has a habit of reading every outstanding engine bug report at least twice a year (I'm not just OCD, but so much of my job depends on knowing the ins and outs of the engine), I can safely describe a sadly large percentage of the stuff in the RQCC as merde: duplicates, misunderstood features, RTFM, unreproducible bizarre edge cases that have affected no one else nor even the original reporter since, issues long since addressed, and issues long since irrelevant (you'd be surprised how many things are in there for Mac Classic, which even Apple stopped supporting long ago). I've tried in many cases to prompt the OP to reconfirm the issue in a recent engine version and close or comment accordingly, but only in a few cases has this yielded any response. Most of them sit there a long time, with my being unable to close them, the engine team unsure if they need to be closed, and the OP unresponsive. Sure, software always has a certain number of errors per KLOC, and something as complex as LC has a good many legitimate bug reports against it. But most of the show-stoppers have been addressed, so before random FUD on the list gets you down I would encourage you to take a good look at the specifics and determine how such an issue will actually affect what you do. For myself, with dozens of products in development here, the number of bugs that are actually holding up any of our feature development is fewer than a dozen, and in every case I have plenty of other features to add in the meantime while I wait for those fixes. I know the standalone issue will revisit me soon as I'm working on something actively right now. I dread that moment. If you can use LC for building standalones until after I'm back from the RevLive conference, I'll have you covered in MC on that. -- 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/31/11 11:10 AM, Shari wrote: I remember having some sort of frustration with the whole standalone issue which may be why I stayed at MC/Rev 4.0 and did not move forward. I don't recall if I had to build with the engine from 3.5 or if 4.0 was okay. I just know that the whole thing was such a frustration that I took a break and worked on things that would not require builds for awhile in the hopes that the kinks would find resolutions later on. As far as I know, you're the only one who couldn't make it work. I suspect for your stacks you only need to deal with password protection and embedded MC resources. Also, possibly, you may be having trouble if you haven't set the HCAddressing property to false, if your stacks are imported HC stacks. Now I am afraid to move forward because I keep seeing discussions on the Rev list about bugs in things that have been solid for a decade. Version 4.6 is very solid. Are you sure the bugs you noticed aren't for mobile? The desktop build is very good. Can you remember any bugs you've seen that impact desktop work? I know the standalone issue will revisit me soon as I'm working on something actively right now. I dread that moment. You'll be left in the dust if you don't upgrade, especially if the MC IDE ports the SB from LiveCode with just a few tweaks. I believe that's the plan. I'm still willing to work with you on the standalone issue. I'm not aware of anyone else having trouble. The LiveCode tech queue hasn't had a single inquiry about it for at least the last several years. -- 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
Re: [MC_IDE] Quick Poll
On Wed, 30 Mar 2011, Richard Gaskin wrote: Blame me for that, not RunRev. I wasn't intending to blame you or any other member of this list - and I indeed assess it as honorable that you try to find reasons why this situation has developed as it is now and thus defend RunRev. MC is an open source project outside of RunRev's role. It's not theirs to maintain, it's ours. Of course, I fully agree. We do our own maintenance and I have contributed to it, as you know. But it is another matter when that maintenance is made more difficult because of new features (for that matter new engines and standalone builders) that are extremely troublesome to integrate. What would you like to contribute? I am not sure if I understand your question. Contribute to the MC IDE, or to Revolution/Livecode? For those afflicted by a short term memory I could draw up a lengthy list, but there is another way: Just search the archives of the RunRev lists and also the bug reports. Just to pick out one point: Presently I am working in a cooperative project for integrating embedded Lua into Livecode, which will speed up image-processing by a factor of 100 or more. Kevin has already invited us to write a RunRev newsletter article about that when we are ready. Another example: Here is part of a recent message from Jim Ault (of March, 25), and you can watch the videostream from the URL below: Last Saturday I did a volunteer presentation for the Live Livecode Code group that featured your stack Seamless Tiles Generator 2 One of my goals was to let more people know about your outstanding work with image data and conversions. There is a 50 minute recording of this on UStream. Jim Ault Las Vegas - message from m.schonewi...@economy-x-talk.com You can watch Jim's presentation here: http://www.ustream.tv/recorded/13430477 You can download the Seamless Tiles Generator from here : http://blog.livecode.tv/wp-content/uploads/2011/03/SeamlessTiles2.zip or there http://www.sanke.org/Software/SeamlessTiles2.zip which is meanwhile a stack four years old. Back to the quotes from Richard's post: 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. When they have now moved the build process into the engine, why is the standalone builder still encrypted? 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. You may be right, it may be just disinterest in a negligible minority, not a purposeful attempt to thwart MC. But the actual outcome of this attitude are the difficulties we presently encounter. I think commitments should be observed no matter whether they affect a minority or not. I have never fully understood and accepted the protection of the Rev Standalone Builder. (snip) 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. Didn't you just state that the build process has been moved into the engine, so - again - why maintain the protection of the Rev standalone builder? And, would it be possible to get access to the privileged information Richard and Klaus received for creating the MC standalone builder? 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? Tell him I am keenly interested in the inner workings of Livecode as I have been all the time. This would enable me to make proposals and contributions for future improved standalone builders, too. -- Richard Gaskin Fourth World Let me make a concluding statement: As a member of the tolerated MC IDE user group and at the same time as a holder of a commercial license for Revolution/Livecode since the beginning (and presently up to 2013) I reserve the natural right to make recommendations and to criticize points and developments which I think need attention. If I sometimes sound too aggressive, this is not meant to attack someone personally, but rather an attempt to make points clearer. I am interested both in maintaining the MC IDE and in further developing Livecode, and I have supported these processes actively for many years.
Re: [MC_IDE] Quick Poll
Thanks for your reply. I think we're pretty much in agreement on the things you covered, so let me just address this one area to see if I can provide a little clarification: On 3/31/11 10:12 AM, Wilhelm Sanke wrote: Of course, I fully agree. We do our own maintenance and I have contributed to it, as you know. But it is another matter when that maintenance is made more difficult because of new features (for that matter new engines and standalone builders) that are extremely troublesome to integrate. ... When they have now moved the build process into the engine, why is the standalone builder still encrypted? My understanding of Kevin's agreement with Scott on acquisition of the engine was that RunRev not do anything specifically to prevent an alternative IDE from being developed and enhanced. I do not believe that these terms went so far as requiring Kevin to limit the scope of what he can do with the product he acquired so that it's especially convenient for our of volunteers to maintain MC. That would have been impractically onerous, and Raney is nothing if not practical; he would never have asked for that. I feel Kevin has held up his end of the bargain admirably, going out of his way several times to make work on alternate IDEs easier than it might have been. I can't blame him for not making it a higher priority to do even more. As the keeper of the engine, all of us depend on his team to prioritize his own company's ROI first and foremost; if RunRev goes, the future of the MC IDE would at best be in doubt, and at worst would have no engine to drive it at all. One of the areas any software business owner is free to do as he chooses is to determine the model used for demo versions, and I believe this is the only area where his needs have caused us any difficulty at all -- and even then he still directed his staff to provide whatever assistance was needed to help us achieve our goals. Some background on the differences in the demo model and how it plays our with locked stacks: Raney's demo version was feature-limited, but Kevin feels a time-limited model is more appropriate for his own business. I may have my own opinions, but Kevin runs his own business and I run mine and we both like it that way. :) You may recall that MC's license enforcement was also encrypted, the only difference being which stack was encypted: in Rev it's the Standalone Builder, and in MC it was Home. But in both cases the reason was the same: license enforcement. AFAIK Scott Raney never gave the password to the MC Home stack to anyone in the MC IDE project. The mctools.mc stack was made available under an open source license of our choosing, but the Home stack on which it depended remained locked with no means of accessing its code. Raney never needed to lock his SB because it wasn't relevant to his business model. He felt that if people wanted to make standalones with only 10 executable lines per script they could knock themselves out. But standalone building is directly relevant to Kevin's model, as outlined in the LC license agreement which expressly forbids any standalone from also building its own standalones. FWIW, Kevin has said that if you have a specific app that really NEEDS to make standalones he would be willing to take the time to discuss the possibility of a unique license agreement to allow that. But the off-the-shelf license prohibits it. I don't know to what degree the current engine-based binding method may be restricted to the IDE engine only, or whether it could theoretically be used by the standalone engine. I'll get clarification from him on that. As for why he locks his own standalone builder, that's entirely up to him. What the engine does is primarily the bit-level binding stuff (embedding the engine, icons, and UAC info), and there's a lot of other steps involved in making a working set of builds (which is why mine remains so weak at this point). I have no idea what else his SB is doing, and given the variety of deployment options I wouldn't be surprised if at least some of the license enforcement is handled in scripts. The upside to all of this for us MC folks is that RunRev's move to engine-based license enforcement finally freed us up from the last locked stack in the MC environment, Home. Now you can make your own Home stack any way you want to do whatever you want. With that background, let's step back and look at the big picture: The ONLY area in which it's at all inconvenient to do darn near anything you want with any IDE you can dream up is standalone building. In every other respect, what RunRev has provided for us MC users goes well beyond what he provides most other customers in terms of engine enhancements and info on undocumented features. And even with standalone building, he still devoted resources to making sure we can at least get the job done. So we're free to do whatever we want
Re: [MC_IDE] Quick Poll
Jacque, As far as I know, you're the only one who couldn't make it work. I suspect for your stacks you only need to deal with password protection and embedded MC resources. Also, possibly, you may be having trouble if you haven't set the HCAddressing property to false, if your stacks are imported HC stacks. I did make several attempts to figure out why my main software and Rev wouldn't play nice in the sandbox and I tried to find workarounds that didn't require major changes. I do not recall if the HCaddressing was one of the things I tried, and truthfully, I don't remember if I ported it directly from HC or simply rebuilt it from scratch. Either way, I could try the HCaddressing. I no longer port from HC to MC/Rev, I build new and rewrite the code, but the existing projects may have been imported. I remember attempting to change the names of the embedded stacks that I'd altered in some way, and then having them rename on launch (but only if it was a standalone). Such as xAnswer for the embedded stack, renamed to Answer on standalone launch. Then trying the Rev builder and still running into some issue and throwing up my hands and saying, Metacard is SO much better than this (insert cuss words), I love the MC IDE so why am I trying to fight with that other thing? Then setting it aside. I no longer embed those stacks either, and my two newer (in the works) projects don't use Ask/Answer at all. I created my own versions and call them up differently. But that doesn't help the existing projects. Now I am afraid to move forward because I keep seeing discussions on the Rev list about bugs in things that have been solid for a decade. Version 4.6 is very solid. Are you sure the bugs you noticed aren't for mobile? The desktop build is very good. Can you remember any bugs you've seen that impact desktop work? As everything seems to get discussed on the same list, which tends to be highly active, unless you read every single post it all gets jumbled up. I have no idea if the bugs would affect me. Just the sheer volume of bugs that get discussed, and not knowing for sure which are desktop versus mobile, is distressing. I don't know how the whole mobile thing is handled. I know that before, there was ONE engine that deployed to Mac, Win, Linux, etc. So while there may have been a few platform specific bugs, for the most part the meat was the same regardless. With all the additions of mobile, web, etc., and the different purchase options, I don't know how that is handled in the engine. Are there totally separate engines now for each area? Is it still one big engine for all? My license is good until the end of the world and then far beyond that, so I can upgrade, I've just been afraid to. I know the standalone issue will revisit me soon as I'm working on something actively right now. I dread that moment. You'll be left in the dust if you don't upgrade, especially if the MC IDE ports the SB from LiveCode with just a few tweaks. I believe that's the plan. I'm still willing to work with you on the standalone issue. I'm not aware of anyone else having trouble. The LiveCode tech queue hasn't had a single inquiry about it for at least the last several years. As I've never found the Rev standalone builder to be user friendly, I never reported an issue to them, I simply sidestepped it and used MC. I don't want to set aside the current project to rebuild a project that's out there and basically happy for most folks. But I will take you up on the offer of assistance with the standalone issues when the current project is done and ready for the build. This will be my first release of something NEW for a long time, as opposed to something updated. I'm really excited and expect that it will be well received :-D So, yes, the short answer is that I will take you up on the offer as soon as this project is ready. And again when I update the existing project as that is the cranky one. -- Shari -- (who took a break from programming to write a book about a bad dog we adopted, we squashed most of the bugs that we inherited with her :-) The bugs she still has are livable. There are one, maybe two more dog books on the horizon. But not until this current project gets released. Eggs in many baskets and all that.) -- Bad Dog Books http://books.gityasome.com Critters, humor, patriots and sports t-shirts http://www.bearsware.com WlND0WS and MAClNT0SH shareware http://www.gipsyking.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: [MC_IDE] Quick Poll
On 3/31/11 2:00 PM, Shari wrote: I no longer embed those stacks either, and my two newer (in the works) projects don't use Ask/Answer at all. I created my own versions and call them up differently. But that doesn't help the existing projects. The easiest way to proceed would be to use one of your new projects. It sounds like you won't have any issues with those. Once you understand how the SB works, you'll be able to use your converted ones too. Now I am afraid to move forward because I keep seeing discussions on the Rev list about bugs in things that have been solid for a decade. I'm still not sure what you saw. The discussions I see are mostly about mobile. The desktop engine works very well and I don't think you have anything to be afraid of. The things that used to work still do, as far as I've seen. I don't use the engine for everything of course, but I really haven't had any trouble, and I don't recall any bug discussions that involved regression. (Come to think of it, for two days you couldn't type tabs into fields on Macs, but that was fixed by the next day.) I don't know how the whole mobile thing is handled. I know that before, there was ONE engine that deployed to Mac, Win, Linux, etc. So while there may have been a few platform specific bugs, for the most part the meat was the same regardless. You can still think of the engine that way. It just deploys to more operating systems now. But to do that, the language has had to expand to allow us to access some OS-specific features, like native iOS controls. Those are the ones that still need some tweaking sometimes, and which you may be thinking of when you mention bugs. If you aren't going to deploy to mobile, you can ignore the new language syntax and any discussions about it. With all the additions of mobile, web, etc., and the different purchase options, I don't know how that is handled in the engine. Are there totally separate engines now for each area? Is it still one big engine for all? My license is good until the end of the world and then far beyond that, so I can upgrade, I've just been afraid to. It's still all one engine. Your license determines how much that engine will let you do. There's really no reason not to upgrade, since you have the right to it already. The very worst that could happen is that you decide to go back to an earlier version instead. There have been a lot of improvements in the newer versions though, and you are missing out if you don't try it. As I've never found the Rev standalone builder to be user friendly, I never reported an issue to them, I simply sidestepped it and used MC. This is a little surprising to me. I immediately found it much easier than the MC process and it was the first thing I switched to when I started with LiveCode/Rev. Maybe all the panes are confusing. They are easily explained and each serves a needed purpose that the MC SB doesn't have. I could never go back to all the twiddling and manual copying I used to do. Building an OS X bundle by hand is silly. So, yes, the short answer is that I will take you up on the offer as soon as this project is ready. And again when I update the existing project as that is the cranky one. Do. We'll walk through it. -- 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
Re: [MC_IDE] Quick Poll
One addendum to what Richard delineated about the transition from Metacard to Revolution after Kevin bought the Metacard engine from Scott Raney: The agreement between Scott Raney and Kevin and its details is one matter, the commitment made by Kevin to members of the Metacard user group is another. I had a discussion with Kevin at that time about the future relation of Metacard and Revolution. Among other things I had proposed to keep and maintain Metacard as a sort of Revolution lite that would have of course less features than were planned for Revolution. Kevin disagreed to this proposal, probably fearing a competition in his own house then, also in financial terms. I do not remember exactly what he said concerning this point. But he assured me that the compatibility of all future Revolution engines with the Metacard IDE would be guaranteed. I do not know which other members got similar messages, but that is what he promised to me at least. We might find these messages in the old archives. Regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: [MC_IDE] Quick Poll
Thank you, Jacque, for clarifying the changes for mobile, web, etc. They are not on my agenda in the near future so you've put my mind much at ease for moving into an updated version. I've often read folks preferring the Rev standalone builder. Maybe with this new project I'll be able to give it a more serious look. Still wouldn't want to work in Rev though, if for no other reason than the Application Browser. REALLY prefer the Control Browser in MC enough to forego some of the finer features of Rev like the ability to update multiple objects with one click (like lock/unlock location etc.) -- Bad Dog Books http://books.gityasome.com Out Loud - Amplified Whispers http://www.gityasome.com/blog WlND0WS and MAClNT0SH shareware http://www.gipsyking.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: [MC_IDE] Quick Poll
On 3/31/11 4:03 PM, Shari wrote: REALLY prefer the Control Browser in MC enough to forego some of the finer features of Rev like the ability to update multiple objects with one click (like lock/unlock location etc.) You can do that in LiveCode too. Actually, the only thing I haven't found in LiveCode is the auto-relayering capability and I think I'm going to put in a feature request for that. I like the MC control browser better for some things too, it depends on what I'm doing. I go back and forth between both programs all the time though. -- 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
Re: [MC_IDE] Quick Poll
On Thu, 31 Mar 2011, J. Landman Gay wrote On 3/31/11 12:12 PM, Wilhelm Sanke wrote: Didn't you just state that the build process has been moved into the engine, so - again - why maintain the protection of the Rev standalone builder? The actual building is done in the engine, but the *ability* to build is in the IDE and is protected. Without that protection, anyone with a current LiveCode license could create a competing product. I know you yourself wouldn't do that, but others might. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com Thank you Jacqueline, this makes sense to me, point taken. And as I assured not to develop a competing product and can be relied on that assurance, Kevin maybe may allow me to have a look at that priviledged info needed to build a MC standalone. Best regards, Wilhelm ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
