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
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
Re: [MC_IDE] Quick Poll
I am somewhat late in answering the poll and will post it both to the Yahoo-MC list and the Runrev Metacard list. Ken Ray schrieb: I'd like to take an informal poll to get an idea of how many people are using the MC IDE, and to what extent. So if you could just reply to this email with your answers to the 6 questions below, that would be great. Thanks! Ken METACARD IDE POLL --- Development (up to, but not including standalone/web/mobile deployment) === 1) What percent of the time do you use the MC IDE for LiveCode development, and what percent do you use the LiveCode IDE? About 90 percent MC IDE, that makes a maximum of 10 percent for Livecode. 2) If you use the LiveCode IDE at all, what do you use it for, and why? For special features not yet available in the MC IDE, e.g. manually resetting the points of a polygon. Deployment == I'm aware that the current standalone builder in the MC IDE doesn't work with the latest engines. With that in mind: First a remark: The Livecode standalone builder surely has improved over time. We have had situations where it was nearly or altogether impossible to build standalones of specific stacks, for instance such that contained a greater number of controls. And I do not like the interfering of the Livecode standalone builder with the building process, e.g. putting into the stack a number of unwanted front- and backscripts or unnecessary code of the cRevGeneral kind. I want my standalone to contain what I think it should contain. Also there were problems with the Livecode standalone builder (did not yet test if this issue has been resolved with the last build 4.6) when you had embedded your own partially costumized answer dialogs with the possibility to set the exact loc of the dialog, like we can do with the Metacard dialogs.- 1) Do you build standalones with the MC IDE at all (either because you're using an older version of MC or because you made your own standalone builder)? If the necessity arises of course I have to use an appropriate version of the MC IDE. I would very much like a new MC IDE standalone builder with the simplicity of the earlier MC IDE versions. There must be a way to achieve this, Klaus Major had been working on it, but the difficulties he encountered apparently were too great and his time budget he could allot to the task were insufficient. When Revolution had been launched as a separate product; Kevin Miller had promised that MC compatibility would be fully preserved. I see this new structure of the Livecode standalone builder as a definite step away from this promise. Kevin himself should have supplied us with the means to program a new MC IDE standalone builder. I hope there can be a cooperative enterprise of MC IDE users to eventually produce a MC standalone builder. I suppose, Richard Gaskin has found solutions to all this? Would it be possible that he could share his version of a standalone builder - or offer it as a starting point for a new MC version? 2) Do you build standalones with the LiveCode IDE? If so, is it because you can't with the MC IDE or because you prefer the LiveCode IDE? If you prefer it, then why do you prefer it? As I already have stated, I do not prefer the Livecode IDE. There quite a number of reasons, which would take long to elaborate. I am rather forced sometimes to use the Livecode standalone builder in the temporary absence of a MC version. 3) What percent of your projects are to be deployed to the web plugin? At present none. 4) What percent of your projects are to be deployed to a mobile device? At present none, too. I haven't bought any of the mobile add-ons for two reasons: - they are still in a initial phase of development, and - the changed pricing and licensing conditions indeed do not appeal to me. As a commercial license holder until 2013 - a license I bought out of solidarity with RunRev, prompted by a cry for financial support some of us did receive some time ago - I have just had a short discussion with Heather and Kevin about the pricing and licensing terms for mobile add-ons. I am still not quite clear about the terms and I have to continue this discussion, but I see for instance that the licensing period is determined solely by RunRev (until the next paid update), which could be considerably shorter than a year. I would appreciate a licensing period of at least one year or - if there is no paid update within that year - until the the next paid update. What is more, I cannot find information about how much updates woukl cost - usually update prices have been considerably less than the full price for a version. And there seems to be no possibility to get a trial version of a mobile add-on END POLL --- Thanks for your answers! It will help drive the direction of the IDE... __._,_.___ ___ metacard
Re: [MC_IDE] Quick Poll
On 3/29/11 8:40 AM, Wilhelm Sanke wrote: 1) Do you build standalones with the MC IDE at all (either because you're using an older version of MC or because you made your own standalone builder)? If the necessity arises of course I have to use an appropriate version of the MC IDE. I would very much like a new MC IDE standalone builder with the simplicity of the earlier MC IDE versions. There must be a way to achieve this, Klaus Major had been working on it, but the difficulties he encountered apparently were too great and his time budget he could allot to the task were insufficient. When Revolution had been launched as a separate product; Kevin Miller had promised that MC compatibility would be fully preserved. I see this new structure of the Livecode standalone builder as a definite step away from this promise. Kevin himself should have supplied us with the means to program a new MC IDE standalone builder. I hope there can be a cooperative enterprise of MC IDE users to eventually produce a MC standalone builder. I suppose, Richard Gaskin has found solutions to all this? Would it be possible that he could share his version of a standalone builder - or offer it as a starting point for a new MC version? 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. 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. 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. -- 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 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? 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 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. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Again, thank you Richard and best regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: [MC_IDE] Quick Poll
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. I know that the rate of change in engine features sometimes makes it seems like RunRev is going out of their way to break the MC IDE, but having had more than a few discussions with Kevin about this I can confidently say that the opposite is true. I think Kevin now feels good enough about the RR IDE that he's no longer at all concerned about potential bifurcation of his user base, and has gone from being merely comfortable with MC to actively helping us improve it. In addition to the team's effort to bring our SB up to date, RR has helped with at least two other significant improvements that make our MC work easier: - MessageBoxRedirect: this property was added specifically to address a problem that used to occur if you tried to swap out the Rev IDE for MC within the Rev session.I had at one time explored making a tool for this I called FlipsIDE (long since abandoned because it's just easier to make a fresh install), and Kevin gave this issue priority and had the team address it as soon as it was brought to his attention. - Engine-based licensing: in versions prior to v2.7, the Rev license handling was done outside the engine, which meant that we had to have separate license keys for MC and they had to maintain them; extra work for everyone. With v2.7 the engine now handles registration itself, so any stack at all can be used as a Home stack, which can in turn launch any stacks for any IDE, as long as you first have a working licensed Rev install. Easy to comply with, it's also much easier for us (or anyone else wishing to make an IDE) since the Home stack is now just effectively a launcher, no longer saddled with license enforcement. When launched the engine will first sort out its license stuff, then look for a stack named mchome.mc at the same level as the engine. If not found, it will then proceed to look for home.rev, but if found it will open the file, where you can use any scripts you want to open any tools you want. True, both of these moves also have benefits for RunRev. But that's a good thing: mutually supportive goals that maximize flexibility for all. -- Richard Gaskin Fourth World Media Corporation ___ ambassa...@fourthworld.com http://www.FourthWorld.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: [MC_IDE] Quick Poll
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.). Does it? Great! The windows icon stuff was a headache when I did it. I had to re-order the ico file to match the order of whatever software RunRev had used to make theirs. Back then after contracting to them to reinvent the SB I just volunteered my time to update MC. That was probably the lsst time I ran MC :-) Unfortunately I'm a bit more time deprived these days or I'd offer to help now. Cheers Monte ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: [MC_IDE] Quick Poll
Many years ago we had opted to not use the Yahoo discussion list, and use the existing MC list hosted at runrev instead because it had more members. I'm post my reply here for that reason, and going forward if we keep using only one list for the discussion we can maximize recipients without the replicated messages. METACARD IDE POLL --- Development (up to, but not including standalone/web/mobile deployment) === 1) What percent of the time do you use the MC IDE for LiveCode development, and what percent do you use the LiveCode IDE? Mine is an odd case, since shortly after having the same project burnout Klaus had with the MC IDE I began expanding my devolution toolkit into a full-fledged IDE. It's been a bit of a hodge-podge over the years, with various iterations named m2 (2nd-gen MC) and the latest is nC (which can mean NeXT Card, or NadaCard, or Not Completed, depending on one's mood g). The NeXT reference will become clear when you see it - more on that later. Standalone building is possible in nC, but not especially usable yet. Graphic Effects are supported, along with Gradients, behaviors, etc., and these are all done in a modular way that will allow them to work in MC as well, so we have lots of options for expansion going forward. 2) If you use the LiveCode IDE at all, what do you use it for, and why? I use LC only for testing bugs, to pin down differences between engine and IDE issues. Before I updated my standalone builder to use LiveCode-compliant properties I used to use LC for building standalones for the few clients who require it, but these days with the new SB I can build anywhere and LC can find what it needs to build there too. Deployment == I'm aware that the current standalone builder in the MC IDE doesn't work with the latest engines. With that in mind: 1) Do you build standalones with the MC IDE at all (either because you're using an older version of MC or because you made your own standalone builder)? 2) Do you build standalones with the LiveCode IDE? If so, is it because you can't with the MC IDE or because you prefer the LiveCode IDE? If you prefer it, then why do you prefer it? 3) What percent of your projects are to be deployed to the web plugin? Zero. There's nothing it provides my my clients that we can't do with less effort and greater flexibility using a standalone and downloaded stacks, or writing custom UIs in browser-native JS. I'll go out on a limb to predict RevWeb gets EOL'd within 24 months. Maybe that's just wishful thinking. ;) It's a huge time sink with little practical benefit that can't be provided by other means better (see what RB's been doing with web deployment, what ToolBook did 15 years ago). 4) What percent of your projects are to be deployed to a mobile device? Currently only one project, but I expect that number to grow this year now that RunRev is making such good progress on Android. END POLL --- Thanks for your answers! It will help drive the direction of the IDE... -- Richard Gaskin Fourth World Media Corporation ___ ambassa...@fourthworld.com http://www.FourthWorld.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: [MC_IDE] Quick Poll
On 27 Mar 2011, at 23:25, J. Landman Gay wrote: On 3/27/11 1:51 PM, Björnke von Gierke wrote: As far as Standalones go, I find the LC approach pretty sweet, with the caveat of those horrible IDE properties and the need to scrub them whenever a standalone is built. The SB removes them, you don't have to. Yes, i don't delete anything by hand. But the removal makes the SB about 10 ms per object slower. if they'd actually leave them in (as they don't really take up much space), then the building speed could be vastly increased, especially for larger projects. Obviously much better would be to not add them in the first place... ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
