Vincent Nonnenmacher <dpi@pobox.oleane.com> wrote: > I don't think you get the point here. I think you don't get it here. I don't want to communicate with an external application because AppleEvent is slow. And for sure I do not want to communicate with something built on AppleScript, because AppleScript gives a whole now definition to the word "slow". Actually I use MacPerl because it is _fast_. What I definitely need is something to build GUIs that can be easily ported to other systems - as soon as my Perl scripts should run on Unixes, I need such a thing. And the only option there is Perl/TK. And tell you what: I don't give a dime on how those scripts look. Actually I won't use TK for Mac-only scripts even with TK 8.0, because TK sucks. But Unix-users are suckers, so give them what they deserve ;-) What MacPerl needs though, is a native interface that's easier to use than direct toolbox calls. Toolbox is much to complicated to just jot down a simple idea and build a prototype. A MacApp-like structure (a class framework) would help much - you could use existing Mac documentation and you could build constructors and such in MacPerl to make it even more easy to build GUIs. But this should be written in MacPerl (or in some native extensions to MacPerl), because anything else is just to slow to be usefull. I am currently using MacPerl for several tools. One converts message formats from some proprietary BBS format to the Soup format to be read by MacSoup. 60% of the runtime is for calling ZipIt using the DoScript feature of MacPerl. That's no fault of MacPerl - it's a fault of AppleScript/AppleEvent. Hey, it even isn't that reliable: from time to time I get timeout's starting ZipIt! And that are local applications! Sorry to say that, but with AppleEvents, Apple got a great idea and a nice concept and totally missed the goal with it's implementation. bye, Georg ***** Want to unsubscribe from this list? ***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch