Re: hypercard domenu comptability
Hi First, I must say: I don't just want a solution for me. I want a solution for anyone using revolution or metacard. Second, I think it is reasonable to expect a solution. The question that raises is how to do the solution. Richard gives me the impression that there is in fact no way out. MetaCard does not let you override handler (or write self modifying code - and on these two points I prefer hypercard). The handlers for doMenu are there, just not implemented. Consequently, if I understand Richard correctly they cannot be overriden by card objects. Alain, I agree, I could easily modify my own stacks so that my own projects would be compatible on my own machine. You're missing the point: the issue is the compatability on all machines running any flavor of metacard/revolution. Also, Scott very much still owns metacard. He has licensed its engine to revolution in exchange for a GUI, nothing more or less. As far as I know they are two different companies with no overlapping directors or ownership of stock. Anyway, my point remains: this is an unimplemented feature. In the interest of compatability it should be implemented. It need not be implemented in a manner that either interferes with speed of other functions. However it must be implemented such that revolution/metacard can properly import hypercard stacks. Which means while it could be scripted using open source it would have to be implemented by MC/RR. Once upon a time metacard had no native bitmap art tools just vector tools and there was no art compatability. Now there is and most art stacks run fine under metacard. Currently many domenu items are not implemented. They could be. Mostly though my domenu commands return no such menu. Which to me means that they could be implemented just by adding invisible menu items to the metacard menu bar. Richard is implying that that is not possible. And Alain thinks it is but is ignoring the fact that I'm not autistic. If I implement a change on my version of metacard that does nothing for the other people using metacard. I don't want a solution just for myself. I want a proper solution that benefits all users of xTalk machines. one of the reasons MC is so darn fast is that it doesn't allow the overriding of built-in commands and functions (it cuts the token search space down dramatically). Fortunately, for the few cases where that might be useful it isn't hard to work around it: That argument ignores the processor speed of machines is increasing and will continue to increase such that any speed gain is really not that important and will become less and less important. For example, you could write a menuPick handler at the stack level and move your doMenu stuff there. That way you could handle visible menu items there and also makes calls to it from other scripts by writing: menuPick Menu Item Name ...rather than HC's: doMenu Menu Item Name Which is no solution for the easy import of hypercard stacks to metacard, you're missing my point. Indeed. I have longed for doMenu in MC, many times, for many years. So have I. I had a in-depth debate about it with Scott Raney, back when MC was still owned and hosted by Scott. Still is. He concluded with the argument that Richard reiterated in a very-recent post to this list, e.g. MC's speed is dramatically improved without doMenu'. I rebut processor speed is increasing rapidly and point out the lack of compatability is extremely frustrating to people thinking of switching. This is an argument for supercard, isn't it... There is nothing preventing you from editing MC's menu bar. Yes, but that is no solution for everyone else. This is an avoidable and easily solved problem. the invisible button would not solve syntax like doMenu item 3 of menu 2 (or similar) but I never used that syntax ... Some of do use that syntax, and it was awesome in terms of learning to script HyperCard gra-du-ally, by coding exactly what the user normally does manually. Sure, and IDEALLY the metacard menu would ALSO reflect that: all menus and menu items of hypercard would be retained, with new menu items appended after the existing menu items or using entirely new menus in addition to the cloned hypercard menus. I would also point out I want a tear off tools palette. With art tools built in. A tear off pattern palette would be nice - including the hypercard patterns which are now available on metacard but not in the metacard pattern palette. I have no comment to make on your invisible menu idea but it seems to me that you could achieve your goal by scripting a doMenu handler, in MetaCard, which maps the doMenu requested with its corresponding equivalent in MC code. Not according to Richard, unless I'm misreading him. Example: doMenu New stack... without dialog gets handled by : on doMenu menuItem -- -- setup a CASE statement, -- one case for each menuItem possibility -- -- case
Re: hypercard domenu comptability
Eric Engle wrote: First, I must say: I don't just want a solution for me. I want a solution for anyone using revolution or metacard. It would only matter to the subset of Rev and MC developers who still have HyperCard stacks to port. And really it's the smaller subset who will deal with other conversion issues (AddColor, etc. as outlined in Jacque Gays' article at http://hyperactivesw.com/mctutorial/index.html) but still expect complete automation for this one issue with doMenu. If you want to write an AddColor library that'll do more for conversion than the proposed engine change. Richard gives me the impression that there is in fact no way out. On the contrary I gave you a solution, albeit one that asks the developer to think in terms of the tool they're currently using rather than the one they're leaving behind: ...you could write a menuPick handler at the stack level and move your doMenu stuff there. That way you could handle visible menu items there and also makes calls to it from other scripts by writing: menuPick Menu Item Name ...rather than HC's: doMenu Menu Item Name Remember that menus are implemented differently in Rev than in HC, arguably somewhere in the middle between HC's text-only implementation and SuperCard's object-only variant. Even if we slowed down the engine to accomodate those who feel the need to type doMenu rather than handle the native menuPick in Rev, you'd still need to figure out how to handle all of HyperCard's prefab menus that don't exist in this engine if instant out-of-the-box complete compatibility is the goal. I think Alain's original approach of providing an alternative IDE and supporting libraries aimed at giving the HyperCard experience to those using the Rev engine is the better way to go. Alain has mentioned the only thing that stands between where FreeGUI is today and a fully completed version is a little volunteer help. Know anyone who feels that providing that level of HyperCard compatibility is important enough to lend a hand with? Also, Scott very much still owns metacard. He has licensed its engine to revolution in exchange for a GUI, nothing more or less. Actually, Scott has sold the engine to RunRev in July 2003, as described in the acquisition press release: http://www.runrev.com/section/press/10.php RunRev Ltd. is a completely separate business from MetaCard Corp. MC Corp still retains the copyright on its own IDE, though it has licensed its use by others under the X11 open source license. Neither Scott Raney nor MetaCard Corp. have ownership of the Rev IDE. Like the engine, that's fully ownwed by RunRev Ltd of Edinburgh, Scotland. Anyway, my point remains: this is an unimplemented feature. In the interest of compatability it should be implemented. It need not be implemented in a manner that either interferes with speed of other functions. However it must be implemented such that revolution/metacard can properly import hypercard stacks. Which means while it could be scripted using open source it would have to be implemented by MC/RR. No two tools are completely the same as each other. After all these years and nearly a dozen xTalk dialects later, it seems that for a tool to justify it's existence it will differ from HyperCard; indeed, if it did not why would they bother? But with those differences come conflicting paradigms, such as AddColor vs. built-in color, or script-only menus vs Rev's object menus. These differences invariably require changes to a stack to run. While Rev has that in common with all other xTalk tools, to its credit it's the only one which reads the HyperCard file format natively and supports more of HC's syntax than anything tool but HC itself. Once upon a time metacard had no native bitmap art tools just vector tools and there was no art compatability. Now there is and most art stacks run fine under metacard. Currently many domenu items are not implemented. They could be. There's a big difference, however: bitmap tools weren't added for the Mac platform for HyperCard compatibility. In fact, the person who lobbied hardest for them was porting something from VB. Paint tools were added because they benefit all developers, not just the subset looking for HyperCard compatibility. Mostly though my domenu commands return no such menu. Which to me means that they could be implemented just by adding invisible menu items to the metacard menu bar. Richard is implying that that is not possible. What happened when you tried it? In my experience anything in the menu group will appear in the Mac OS menubar. But there's no need to be adding additional objects, invisible or otherwise, if you'll simply handle the scripts as suggested above. Menus aren't objects in HC, so the behaviors are defined in scripts anyway. Just handle those at the stack level and you're done and can move on to bigger and better
Re: hypercard domenu comptability
On 5/21/05 1:09 PM, Eric Engle wrote: First, I must say: I don't just want a solution for me. I want a solution for anyone using revolution or metacard. Second, I think it is reasonable to expect a solution. Funny how styles differ. I've probably converted more stacks to MC/Rev than anybody and I have never wished for a domenu translator. I was actually glad to see it go, because the MC/Rev way is so much cleaner and faster. Anyway, my point remains: this is an unimplemented feature. In the interest of compatability it should be implemented. It need not be implemented in a manner that either interferes with speed of other functions. However it must be implemented such that revolution/metacard can properly import hypercard stacks. I pretty much agree with Richard that the market for this would be awfully slim. It is so trivial to do a general script search for domenu and then fix the lines. I haven't seen many stacks that require more than a few minutes work on this minor revision. Also, most stacks that I've seen which require menu revisions have also required me to make a new menu bar to accomodate a lot of custom menus. This is a much bigger task than changing a few embedded domenu commands. And since I have to create all the new menu objects and assign them scripts, it is easier to just move pieces of any existing domenu handler into the new MC menu buttons. Since I'm doing that anyway as a necessary part of the conversion, the domenu issue becomes moot. I don't need it any more. That leaves only those situations where a script in a non-menu object happens to use a native HC domenu command. These are almost always things like you suggested -- cut picture or copy text. These are so few and far between in most stacks that they don't matter. It only takes a few seconds to find and fix them, and so far it has been such a trivial job that it never even showed up on my radar. So, for me, a domenu translator would go unused. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
RE: hypercard domenu comptability
how about on domenu amenu, anitem try send (menupick anitem) to amenu catch return the result end try end domenu that should work for most cases... cheers Xav -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J. Landman Gay Sent: Sunday, May 22, 2005 04:50 To: Discussions on Metacard Subject: Re: hypercard domenu comptability On 5/21/05 1:09 PM, Eric Engle wrote: First, I must say: I don't just want a solution for me. I want a solution for anyone using revolution or metacard. Second, I think it is reasonable to expect a solution. Funny how styles differ. I've probably converted more stacks to MC/Rev than anybody and I have never wished for a domenu translator. I was actually glad to see it go, because the MC/Rev way is so much cleaner and faster. Anyway, my point remains: this is an unimplemented feature. In the interest of compatability it should be implemented. It need not be implemented in a manner that either interferes with speed of other functions. However it must be implemented such that revolution/metacard can properly import hypercard stacks. I pretty much agree with Richard that the market for this would be awfully slim. It is so trivial to do a general script search for domenu and then fix the lines. I haven't seen many stacks that require more than a few minutes work on this minor revision. Also, most stacks that I've seen which require menu revisions have also required me to make a new menu bar to accomodate a lot of custom menus. This is a much bigger task than changing a few embedded domenu commands. And since I have to create all the new menu objects and assign them scripts, it is easier to just move pieces of any existing domenu handler into the new MC menu buttons. Since I'm doing that anyway as a necessary part of the conversion, the domenu issue becomes moot. I don't need it any more. That leaves only those situations where a script in a non-menu object happens to use a native HC domenu command. These are almost always things like you suggested -- cut picture or copy text. These are so few and far between in most stacks that they don't matter. It only takes a few seconds to find and fix them, and so far it has been such a trivial job that it never even showed up on my radar. So, for me, a domenu translator would go unused. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: hypercard domenu comptability
Eric Engle wrote: Something about metacard that really bothers me... domenu... domenu in hypercard is really important and convenient. problem is: the menus in metacard don't match. ... This is an avoidable and easily solved problem. It could even be solved open source. If rev or metacard promises to incorporate the hidden button with missing menu items I would do it open source as a fun project. So it could even be solved at no cost (presuming my scripting is up to scratch). What do people think? I know the invisible button would not solve syntax like do menu item 3 of menu 2 (or similar) but I never used that syntax - and the syntax example i just gave could well be buggy - I always wrote doMenu cut picture which would work using an extra invisible menu button with the missing commands exactly as appearing in hypercard (and if someone else would supply missing supercard buttons we could cover that too). What do you think? For doMenu the docs say: The doMenu command is not implemented for all menu items. This command is included in Transcript for compatibility with imported HyperCard stacks. This implies that only menus common between HC and MC are supported. I verified this by trying this in the Message Box: domenu create card ...and got this result: doMenu create card not implemented So while I agree it might be handy to come up with a generic solution, doMenu appears to be hard-wired for a very specific and limited use. Even if it did work, there should be no need for making invisible objects -- we could simply trap doMenu in the stack and handle it from there. But one of the reasons MC is so darn fast is that it doesn't allow the overriding of built-in commands and functions (it cuts the token search space down dramatically). Fortunately, for the few cases where that might be useful it isn't hard to work around it: For example, you could write a menuPick handler at the stack level and move your doMenu stuff there. That way you could handle visible menu items there and also makes calls to it from other scripts by writing: menuPick Menu Item Name ...rather than HC's: doMenu Menu Item Name -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: hypercard domenu comptability
Hello Eric Engle, Something about metacard that really bothers me... domenu... domenu in hypercard is really important and convenient. Indeed. I have longed for doMenu in MC, many times, for many years. I had a in-depth debate about it with Scott Raney, back when MC was still owned and hosted by Scott. He concluded with the argument that Richard reiterated in a very-recent post to this list, e.g. MC's speed is dramatically improved without doMenu'. problem is: the menus in metacard don't match. solution would be:... could have all the menu items that HC has: cut picture instead of... There is nothing preventing you from editing MC's menu bar. It is precisely what I did when I crafted FreeGUI which, btw, has ALL of the menus and menuItems as they are in HyperCard. Therefore you might want to download FreeGUI, as a good starting point for your alternative menu bar. This is an avoidable and easily solved problem. the invisible button would not solve syntax like doMenu item 3 of menu 2 (or similar) but I never used that syntax ... Some of do use that syntax, and it was awesome in terms of learning to script HyperCard gra-du-ally, by coding exactly what the user normally does manually. One very simple command goes a l-o-o-o-n-g way. It accomplishes many many things, from navigation to authoring. :-) What do people think? I have no comment to make on your invisible menu idea but it seems to me that you could achieve your goal by scripting a doMenu handler, in MetaCard, which maps the doMenu requested with its corresponding equivalent in MC code. Example: doMenu New stack... without dialog gets handled by : on doMenu menuItem -- -- setup a CASE statement, -- one case for each menuItem possibility -- -- case where menuItem is the above create new stack break -- -- other cases where menuItem is other -- end doMenu Good hunting, Alain __ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
