lsr@Apple.COM (Larry Rosenstein) (03/22/88)
In article <3715@super.upenn.edu> mayerk@linc.cis.upenn.edu.UUCP (Kenneth Mayer) writes: > >come. My group has discovered several minor (and some not so minor) >bugs in MacApp. The MacApp team would like to hear about these, so that they can be fixed in MacApp 2.0. Send them to MacApp@Apple.COM. > MacApp, in addition, makes it very difficult to do things that you may >want to do, but was never in the original design. For example: it is >impossible to center dialog boxes dynamicly. That is, if you place a dialog >window in the center of MacPlus screen in your resource description file, >it will be in the upper left quadrant of a MacII display. Not pretty, and >NOT in accordance with Apple standards. And there is no workaround that we >have found. This is a problem with the Dialog Manager in general. The only complete workaround is to patch the NewDialog trap and modify the coordinates that are passed in there. The problem is that there are dialogs over which you have no control (eg, the print dialogs). MacApp exacerbates the problem by putting up dialogs itself. For application-specific dialogs, you can simply move the dialog window before you display it. (MacApp 2.0 has a totally rewritten dialog unit, which can automatically center dialogs if you choose. This dialog unit is a superset of the Toolbox Dialog Manager.) This still doesn't handle alerts, which will still be done using the the Toolbox. To handle these, you would have to read in the ALRT resource and modify the rectangle to center the alerts. It should be possible for your application to read in all the ALRT resoruces, center the rectangles, and make the resources non-purgeable. (For MacApp 2.0, it should be possible to put this code into MacApp.) >You may discover that the source code specific to your applicatio is smaller, >but that the overall source and object code is much larger. Object oriented >Pascal in MPW tends to be huge (a minimum of 100K). This is not true in general. There is nothing in Object Pascal (or object-oriented programming) that requires the code size to be excessively large. The MPW linker can strip out method tables that don't need to be there, which means you pay for the object-oriented features only when you use them. Even if you are talking about MacApp programs it is not true. Many people look at the size of their first MacApp program and don't realize that more than half of it is debugging code that is stripped out of the final version. (MacApp without debugging code is only about 50K.) Also, people compare a MacApp sample program with an equivalent non-MacApp sample, without realizing that the MacApp program does many more things. Unfortunately, it is difficult to throw out only the clipboard (or printing, or memory management, or ...) support in MacApp; we targetted MacApp for complete applications rather than small utilities. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 32E Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
mce@tc.fluke.COM (Brian McElhinney) (08/24/89)
In article <10505@claris.com> peirce@claris.com (Michael Peirce) writes: >But, but, but.. MacApp *is* catching on. Look around. There are lots >of NEW software projects using MacApp (people revving old stuff doesn't >count). You overlook one of the best kinds of software development: evolutionary. A person, or project team, with "old stuff" has a lot of learning and experience invested in code that can be re-used for "NEW software". Still, I would argue that the benefits of an object oriented language would most often out weigh re-using older code. I thought MacApp might be manna from heaven when it first came out. It was certainly what the 1984 hype claimed the Toolbox to be. Experience with MPW (slow) and the MPW linker (slow *and* buggy) quickly changed my mind. It will be interesting to see if the THINK C 4.0 class library catches on. It is very much like MacApp (to the point where the dynamic array class is also called a list; where did this meme come from?). The style of "object orientedness" is also very similar to Object Pascal, too much so, perhaps. Pascal can have locally scoped procedures that have access to the parents local variables, which makes the CList/TList DoForEach-type operation fairly natural. C doesn't support such a "wild" concept and so you end up introducing "extraneous" globals. It works, but it, well, *feels* wrong... Brian McElhinney mce@tc.fluke.com
peirce@claris.com (Michael Peirce) (08/24/89)
In article <10612@fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes: >In article <10505@claris.com> peirce@claris.com (Michael Peirce) writes: >>But, but, but.. MacApp *is* catching on. Look around. There are lots >>of NEW software projects using MacApp (people revving old stuff doesn't >>count). > >You overlook one of the best kinds of software development: evolutionary. A >person, or project team, with "old stuff" has a lot of learning and experience >invested in code that can be re-used for "NEW software". Still, I would argue >that the benefits of an object oriented language would most often out weigh >re-using older code. > When using MacApp I still reuse LOTS of old code (I have a MassMicro catridge filled with old code). I don't reuse the event loop or other framework parts of the code, but lots of code snippits that do various things. >I thought MacApp might be manna from heaven when it first came out. It was >certainly what the 1984 hype claimed the Toolbox to be. Experience with MPW >(slow) and the MPW linker (slow *and* buggy) quickly changed my mind. > >Brian McElhinney >mce@tc.fluke.com MacApp/MPW is still slower than Think's products, but it is getting better. MacApp 1.0b9 improved MABuild quite a bit (THANKS!) and using Jasik's patch link can make turn around time very fast. If you haven't looked at MacApp lately, it might be worth checking it out again... Claris Corp. | Michael R. Peirce -------------+-------------------------------------- | 5201 Patrick Henry Drive MS-C4 | Box 58168 | Santa Clara, CA 95051-8168 | (408) 987-7319 | AppleLink: peirce1 | Internet: peirce@claris.com | uucp: {ames,decwrl,apple,sun}!claris!peirce
amanda@intercon.uu.net (Amanda Walker) (08/24/89)
In article <10513@claris.com>, peirce@claris.com (Michael Peirce) writes: > using Jasik's patch > link can make turn around time very fast. So, what's Jasik's patch? Please to elaborate... -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda
chewy@apple.com (Paul Snively) (08/25/89)
In article <1396@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: > So, what's Jasik's patch? Please to elaborate... Steve Jasik has implemented, as part of his MacNosy/The Debugger system, a system called IBS (the Incremental Build System). WHAT it does is really neat; HOW it does it is really scary. He applies some patches to the MPW Pascal compiler to enable it to compile incrementally (!) and has an incremental linker that links the new code into your application WHILE IT IS RUNNING (read that again, sports fans). The reduction in MPW Pascal turnaround is stunning; when dealing with MacApp, it's even more astounding. Remind me to order my copy, as I think this will catch on with people who do LOTS of MacApp builds, and I am, after all, in the Development Platforms Group in Macintosh Developer Technical Support; keeping up on this stuff is my job (it's also a lotta fun, but don't tell my bosses)! ;-) ___________________________________________________________________________ chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. ___________________________________________________________________________
gwills@maths.tcd.ie (Graham Wills) (08/25/89)
In article <10513@claris.com> peirce@claris.com (Michael Peirce) writes: -In article <10612@fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes: -> ->You overlook one of the best kinds of software development: evolutionary. A ->person, or project team, with "old stuff" has a lot of learning and experience ->invested in code that can be re-used for "NEW software". Still, I would argue ->that the benefits of an object oriented language would most often out weigh ->re-using older code. -> -When using MacApp I still reuse LOTS of old code (I have a MassMicro catridge -filled with old code). I don't reuse the event loop or other framework parts -of the code, but lots of code snippits that do various things. - Just to add my opinion to Michael's; Here in rainy Ireland we wrote several medium sized applications in std. pascal. When we upgraded (and I *mean* upgraded) to using MacApp we found that the process was FAR easier then we imagined. E.g. an integrated scatterplot matrix program which was a 1 year project was converted in 3 days. The main work was ditching the redundant bits, not writing new bits. I get people working on sub-sections of my project to write them in normal Pascal and then take a couple of hours to plug them into MacApp myself. They get the advantage of faster development, and so long as they don't write dreadful code, I have no problem slipping it in. - -MacApp/MPW is still slower than Think's products, but it is getting better. -MacApp 1.0b9 improved MABuild quite a bit (THANKS!) and using Jasik's patch -link can make turn around time very fast. If you haven't looked at MacApp -lately, it might be worth checking it out again... - The slowness is a problem still. But the fact that it's easy to plug in STD code means I can test something new in LSP, and then just add it in. Things are a little slower when I have to use MacApp at the development stage, but not enough to worry me. In fact, I was slightly annoyed at the MABuild speedup. I used to be able to read a bit of MacUser or PCW while building. Now I don't get enough time to read more than a couple of sentences! :-\ Graham Wills, Dept. of Statistics, TCD, Ireland. gwills@maths.tcd.ie
ericsc@microsoft.UUCP (Eric Schlegel) (08/25/89)
In article <10513@claris.com> peirce@claris.com (Michael Peirce) writes: >MacApp/MPW is still slower than Think's products, but it is getting better. >... using Jasik's patch link can make turn aroudn time very fast. ^^^^^^^^^^^^^^^^^^ What is this patch link? I've heard several references to Jasik producing some kind of incremental compile/link/etc system, but no descriptions of what it really is, is it a real product, how much it costs, etc, etc. If someone would describe it, THANKS! Eric Schlegel ----- Microsoft owns my code, but the opinions are all mine.
lsr@Apple.COM (Larry Rosenstein) (09/23/89)
In article <11104@fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes: > Because you can't write a non-trivial application unless you spend a *large* > amount of time studying the MacApp source code. It is certainly possible to > switch back in forth between languages, but at the intimate level of From my experience, the programmers who have the easiest time with MacApp are the ones that don't dive into the souce code right away. I think it is possible to do significant applications with MacApp and not look at the MacApp source code. This is especially true with the latest manuals, which include a nice tutorial volume. (The tutorial goes step by step through the design of an icon editor program.) I agree that it is not pleasant to switch back and forth between languages, but that should be necessary only if one encounters a bug in MacApp. We won't know for sure if this is an issue until people start using MacApp with C++. It is unlikely, however, that MacApp will be translated into C++, given the effort that would require plus the overhead of maintaing parallel versions. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
lsr@Apple.com (Larry Rosenstein) (01/08/91)
>>One point to mention is that MacApp cannot be used to write DAs, >>INITs, etc. I imagine that it will be possible to do so in the future. In article <14571@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > > I would be *very* surprised if it were. Agreed. There would be no point in trying to adapt MacApp to allow writing other kinds of programs (DAs, INITs, etc.). The structures of these programs are totally different from that of an application. It might be worthwhile to do a framework for writing DAs, but you would want to start from scratch.
d88-jwa@dront.nada.kth.se (Jon W{tte) (01/09/91)
In article <11656@goofy.Apple.COM> lsr@Apple.com (Larry Rosenstein) writes: >Agreed. There would be no point in trying to adapt MacApp to allow writing >other kinds of programs (DAs, INITs, etc.). The structures of these >programs are totally different from that of an application. It might be >worthwhile to do a framework for writing DAs, but you would want to start >from scratch. Check out Think C - it provides a basic framework for writing "object-oriented" cdevs, and possibly DAs to (haven't looked) It sure allows OOP in code resources, anyway. H+ Jon W{tte, Stockholm, Sweden, h+@nada.kth.se
gmarzot@mbunix.mitre.org (G. Marzot) (02/08/91)
A while ago someone made an announcement about MacApp being entirely written in c++ now? (this is a question)And something about all future support for macapp being in c++. Is this true - whats the real scoop. Thanks -GSM ps . I may have misread the post. Responsibility for the views expressed here belongs only to myself and not to any organization.
ph@cci632.UUCP (Pete Hoch) (02/09/91)
gmarzot@mbunix.mitre.org (G. Marzot) writes: > A while ago someone made an announcement about MacApp being entirely > written in c++ now? That was me. > (this is a question)And something about all future support for macapp > being in c++. > Is this true - whats the real scoop. Thanks -GSM > ps . I may have misread the post. No, you did not misread the post but I may have jumped the gun. MacApp has been rewritten in C++, however there is still no final desision to drop support for Object pascal. It seems that some people THINK it is nessesary to keep it arround. As to the new C++ MacAPP. It is reported that the MacApp team ported all of MacApp to C++ in *two* weeks. Then they took three more to shake out the bugs. Imagin that five weeks from a non portable unknown (outside of Apple) language, to a very popular language that crosses many OS boundaries. I have been told that they also added new string, point, and rect classes, so now in C++ you can do nice things like rect1 = rect2 + rect3, or myString = yourString. Yes! Pete
keith@Apple.COM (Keith Rollin) (02/09/91)
In article <50461@cci632.UUCP> ph@cci632.UUCP (Pete Hoch) writes: >gmarzot@mbunix.mitre.org (G. Marzot) writes: >> A while ago someone made an announcement about MacApp being entirely >> written in c++ now? > >MacApp has been rewritten in C++, however there is still no final >desision to drop support for Object pascal. It seems that some >people THINK it is nessesary to keep it arround. Support for Object Pascal has not been dropped and will never be dropped. This will be true regardless of whether or not MacApp will be ultimately available in Pascal or C++. You will still be able to program your applications in Object Pascal if you wish. For example, Mouser and ViewEdit will stay in Object Pascal. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
peirce@outpost.UUCP (Michael Peirce) (02/10/91)
In article <48992@apple.Apple.COM>, keith@Apple.COM (Keith Rollin) writes: > > In article <50461@cci632.UUCP> ph@cci632.UUCP (Pete Hoch) writes: > >gmarzot@mbunix.mitre.org (G. Marzot) writes: > >> A while ago someone made an announcement about MacApp being entirely > >> written in c++ now? > > > >MacApp has been rewritten in C++, however there is still no final > >desision to drop support for Object pascal. It seems that some > >people THINK it is nessesary to keep it arround. > > Support for Object Pascal has not been dropped and will never be > dropped. This will be true regardless of whether or not MacApp will be > ultimately available in Pascal or C++. You will still be able to > program your applications in Object Pascal if you wish. For example, > Mouser and ViewEdit will stay in Object Pascal. There is a distiction between the latter use of "support for Pascal" and the previous use. My reading is that the first use was refering to supporting MacApp written in Object Pascal. This is important for the people who use THINK Pascal with MacApp as it's kind of hard to use that with a C++ version of MacApp. I assume you mean that this C++ version of MacApp will always be able to be linked in with Object Pascal using MPW and Pascal users will be able to access all MacApp part (i.e. no use of C++ exclusive features). Of course I may be wrong... -- michael -- Michael Peirce -- outpost!peirce@claris.com -- Peirce Software -- Suite 301, 719 Hibiscus Place -- Macintosh Programming -- San Jose, California 95117 -- & Consulting -- (408) 244-6554, AppleLink: PEIRCE -- Ask me about AppSizer (and ask Claris about Public Folder :-)
finnegan@dhw68k.cts.com (Greg Finnegan) (02/11/91)
RE: MacApp 3.0 in C++
It's true! Steve Freidrich announced at the MacApp developer's
conference that his engineers (he's a higher level mgr of the
MacApp group) came to him and asked to convert MacApp to C++.
Apparently, they converted 2.0 (or whatever the latest version)
in just 2 weeks. Since then, all development effort has been in
C++. There were some serious disussions about the future of Pascal
(see below) but nothing concrete was decided - they're sticking to
C++.
Understandably, guys like David Neal @ Symantec and Stever Jasik (the
Debugger) were a little peaved. Even some people at Apple are not
happy with the decision (someone was passing out C++ barf bags).
Oh well, we'll see...
Greg (I wasn't there :-(
--
uucp: ...{spsd,zardoz,felix}!dhw68k!finnegan
InterNet: finnegan@dhw68k.cts.com
--------------------------------------------ph@cci632.UUCP (Pete Hoch) (02/12/91)
> In article <50461@cci632.UUCP> ph@cci632.UUCP (Pete Hoch) writes: > >MacApp has been rewritten in C++, however there is still no final > >desision to drop support for Object pascal. It seems that some > >people THINK it is nessesary to keep it arround. In article <48992@apple.Apple.COM>, keith@Apple.COM (Keith Rollin) replies: > Support for Object Pascal has not been dropped and will never be > dropped. This will be true regardless of whether or not MacApp will be > ultimately available in Pascal or C++. You will still be able to > program your applications in Object Pascal if you wish. For example, > Mouser and ViewEdit will stay in Object Pascal. You are absolutly right. Useing the word support was a bad choice of words on my part. What I ment to say in a round about way was that if MacApp 3.0 source is only released in C++, the people who use THINK Pascal will have a hard time changing the MacApp source and recompiling it if they need to. Pete
Jim.Spencer@p510.f22.n282.z1.mmug.edgar.mn.org (Jim Spencer) (02/13/91)
Pete Hoch writes in a message to All PH> You are absolutly right. Useing the word support was a bad choice PH> of words on my part. What I ment to say in a round about way PH> was that if MacApp 3.0 source is only released in C++, the people PH> who use THINK Pascal will have a hard time changing the MacApp PH> source and recompiling it if they need to. It occurs to me that the Think Pascal user will have a bigger problem than that, i.e. the fact that the MPW C++ produced object libraries probably won't be compatable with Think Pascal meaning that TP users will be SOL. -- Jim Spencer - via The Minnesota Macintosh Users Group UUCP-Fido Gateway UUCP: ...uunet!tcnet!kksys!edgar!mmug!22.510!Jim.Spencer INET: Jim.Spencer@p510.f22.n282.z1.mmug.edgar.mn.org