HDTenEightyP/NetNews huggingface dataset:
From: LENOIL@CATALOGIC.COM
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: * Takeover Proposal *
Date: 25 Dec 92 13:15:00 GMT
Organization: AppleLink Gateway

From: Robert Lenoil <lenoil@catalogic.com>
Organization: Catalogic, Mountain View, California [Voice:
    415-961-4649]
To: MacApp3Tech$@AppleLink.Apple.com
Cc: RSD@AppleLink.Apple.com (Dave Goldman)
 
Dave,
 
I like the idea of keeping MacApp alive for the scores who committed to it
as a platform. But I'm not optimistic that MADA could effectively take over
that maintenance role. Yes, just rolling in bug fixes that come in could be
a one-man job, but that doesn't include testing on all supported Macintosh
configurations, and it certainly doesn't include upgrading MacApp to
support QuickTime, AOCE, AppleScript, and QuickDraw GX. And let's not
forget the cross-platform thing. In short, it's one matter to maintain
MacApp on life support but quite another to keep it current, let alone
leading-edge. MADA could not undertake a project of that scope without a
significant increase in its operating budget, which would probably require
MacApp maintenance to be a fee-based service (members that have moved
beyond MacApp would not want their dues being used to fund a MacApp
lifeline).
 
What MADA is good at is publishing and distributing information and
software. If a coalition of individuals took on the task of integrating and
testing bug fixes and rolling in support for new technologies to MacApp, I
think MADA could play a role in coordinating that effort and making the
results widely available. There are successful instances of distributed
development projects like that (GNU and Linux come to mind), but those
projects have not been widely adopted by business users, who are
justifiedly unwilling to stake their businesses on systems that are
maintained by a loosely-coupled network of volunteers. My hunch is that the
bulk of MacApp developers fall into that business user category.
 
So how can MacApp live on? It probably can't as the commercial framework
that it is today. But it would be a shame to let the technology wither and
die. I would like to see Apple release the MacApp code into the public
domain, or to retain copyright but grant a no-fee license to use the code
and to create derivative works. This simple act would likely make MacApp
the overnight favorite framework among students and tiny developers. With
that new expanded base of users, enough interest could probably be
generated to keep the framework current via contributed modules and bug
fixes. MacApp would become a learning tool for aspiring object-oriented Mac
programmers that will create the amazing applications of tomorrow. That's
not a bad retirement home for a venerable old framework.
 
Robert Lenoil
MADA Vice President and Treasurer
From: DIGIMATCH@AppleLink.Apple.COM (3M, Ran Bedekar,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Bedrock News
Date: 21 Dec 92 15:32:00 GMT
Organization: AppleLink Gateway

Since this thread is diverging a little bit (and someone from Taligent is
chipping in), there was an interesting remark buried in an article on IBM's
microkernal in the December 14 issue of InfoWorld.
 
"In the first half of next year IBM will release beta versions of tools based
on Taligent technology called application frameworks."
 
So the question is:  do we port to Bedrock only to move to a Taligent-based
framework a little while later (same song, next verse), or is it better to wait
and see how the framework situtation shapes up?  It would be nice if Apple
would finalize a plan and let us know what to expect (and when).  Is Bedrock
going to be Apple's long term framework, or is it going to turn into a Symantec
product without direct support from Apple?  Hopefully, Taligent will provide a
framework that is integral enough to the OS that we can all get off of this
framework merry-go-round.
 
I guess that's life on the "bleeding edge",
Nick Nallick
From: malcolm@Apple.COM (Malcolm Slaney)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: MacApp3 Gateway to Internet
Keywords: macapp3, gateway, internet, applelink
Date: 22 Dec 92 17:40:11 GMT
Organization: Apple Computer Inc., Cupertino, CA

This is a test and an annoucement.  The MacApp3Tech$<->comp.sys.mac.oop.macapp3
gateway should be fully operational.  

Messages to the AppleLink group mailing list MacApp3Tech$ have been 
automatically fed to the Usenet newsgroup comp.sys.mac.oop.macapp3 for a 
couple of weeks now.  We did have a problem with half the message never
getting out but that has been fixed.  (It was caused by a local newsfeed with
the same information.  Depending on timing, only one of the two newsgroups
got the message and the other dropped it because it was a duplicate.)

I think we have the Usenet to AppleLink gateway working now and as of last
night it should be automatic.  All Usenet messages, that didn't come from 
AppleLink, are automatically sent to MacApp3Tech$ on Applelink so the rest 
of the readers can see them.  AppleLink users will not see much difference
between those messages that were sent directly to the mailing list from the
Internet and those that went through the Usenet system.

So far, most (90%) of the messages are coming from AppleLink.  MacApp3Tech$
is now readable on tens of thousands of hosts around the world that participate
in Usenet.  

Thanks to John Werner for organizing all the comp.sys.mac.oop.macapp3 effort.
Thanks to Chuq Von Rospach for doing the legwork inside of Apple.

Now we return to our regularly scheduled MacApp discussions.

-- Malcolm
From: D0220@AppleLink.Apple.COM (American Zettler, David Every,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re:
Date: 29 Dec 92 16:42:00 GMT
Organization: AppleLink Gateway

> Anyway, wait and see before you start critisizing; this reminds
> me of Republicans that are already complaining about the presidency
> of Clinton :-).
 
----------------------------------------------------------------------------
    Actually thats a real good analogy... all that we have to go on with
Clinton (and computers) is the past... Clinton did alot of damage to his state,
has nothing he stands behind, and has been two faced... so many Repubs. are
scared of what he might do in the future (but he might turn out to be a man,
who knows)...    ;)
    All emulations in the past have been slow... I mean really slow... as in
TOO DAMN SLOW!!!! And they have been getting better at compatibility... but
usually nothing like the original... so apple promises speed and compatibility,
and people are a little sceptical. I imagine apple will do much better than the
nay-sayers predict, and still fall short of what they (and we) hope for.
    I hear good things from the emulation, but still if you want to run
Macintosh software, it will be in your best interests to buy a Mac (not a
PowerPC)... but that the PowerPC's are still great, and in a few years will be
THE computer to own.
 
    Dave Every
From: landon@Apple.COM (Landon Dyer)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Re2: * Takeover Proposal *
Date: 26 Dec 92 16:44:02 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <1992Dec26.022347.9730@netcom.com>, nagle@netcom.com (John Nagle) writes:
> 
>       The fact that Apple has announced the demise of MacApp before
> Bedrock is even released is a bad sign....
>
> ... It's entirely
> possible that there will be a long hiatus during which there will be NO
> commercially supported tools for the development of complex Mac
> applications.  This can only accelerate the move to Windows.
> 
>       Apple has not yet provided a credible statement of direction 
> which would encourage developers to continue investing effort in
> its Mac platform.  Perhaps it will do so.  Meanwhile, the Windows
> development kit is widely available at low cost.

well put.  your concerns are widely shared.

i could say a great deal here and land in hot water
(it wouldn't be very constructive anyway).  instead,
all i will say is this:

if you are a developer with concerns (i need to
stress here that they don't have to be just about
development systems), take the time to write a
letter to Roger Heinen, our high muckity-muck and
head panjandrum of engineering.  i hear that roger
likes letters (*don't* e-mail, because he's swamped,
and if it's not worth a postage stamp and a walk to
the mailbox, you're simply not serious).

that's:		Roger Heinen
		Apple Computer, Inc.
		20525 Mariani Avenue
		Cupertino, CA 95014

i imagine that even a short, simple letter like "I'm
concerned about X, Y and Z and I'm moving to Windows
next week.  Sincerely, <yourname>" would make an
impression.

'nuff said.   i gotta get back to my tar-pit....

-- 
landon dyer
apple computer newton team

NOT THE VIEWS OF APPLE COMPUTER
From: LENOIL@CATALOGIC.COM
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: TEditText P.S.
Date: 28 Dec 92 11:31:00 GMT
Organization: AppleLink Gateway

From: lenoil@catalogic.com (Robert Lenoil)
Organization: Catalogic, Mountain View, California [Voice:
    415-961-4649]
To: MacApp3Tech$@Applelink.app|e.com
 
>By the way, despite the occasional inquiry here, I've never seen an
>explanation of the point of all this floating TEView business in the first
>place
 
Pre-3.0, TEditText could only be used with TDialogView, which was essentially
an objectized version of the toolbox Dialog Manager. So the short answer to
your question is "because that's how the dialog manager did it." As to why
the *dialog manager* used a floating TextEdit record, I suspect the 64k RAM
of the original Macintosh had everything to do with it.
From: JOLICOEUR.B@AppleLink.Apple.COM (Jolicoeur, Bernadette)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Takeover
Date: 28 Dec 92 20:08:00 GMT
Organization: AppleLink Gateway

Hello all,
 
I feel the need to shed some "light of reality" on the takeover discussion.
Many people have put forth their ideas as to how a bug fix might be made to the
MacApp 3.0.1 code base by an external developer.  More than one person has
suggested that these fixes could be easy and relatively localized for "easy
testing".  Within the last day or two somebody has actually recommended a "by
sight" verification of bug fixes.
 
Now let me speak from a point of experience.  We (the MacApp SQA team) learned
something very important during the MacApp development process: changing any
MacApp code can have some unexpected side effects.  We did let an alpha release
of MacApp go to our internal source code management group (the last stop before
sending a release out) *once* with a last minute "by sight" bug fix in it.
Three engineers looked at the fix and "ok'd" it.  That fix resulted in a new
crashing bug that developers would have found rather quickly.  The lesson
learned - we always did a full testing cycle for each release of MacApp after
*every* bug fix was in.  A full testing cycle is an 8 person-week job.
 
I say all of this not in the attempt to derail or undermine the takeover
discussion but to let people know just what is involved in a "simple" or not so
simple bug fix to MacApp.
 
Bernadette Jolicoeur
ex-MacApp SQA team member
From: DRAPER@ODIN.MDA.UTH.TMC.EDU
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Re2: Takeover
Date: 29 Dec 92 16:59:00 GMT
Organization: AppleLink Gateway

> I don't have any particular interest in taking over MacApp, but it would
> be nice to see _someone_ do it.  So, in the interest of moving things off
> the moral plane and on to business issues, let's put some real numbers on
> this "takeover" business.
 
Before we start talking about the moral or business issues concerning a
takeover, I think there's an even bigger question we need to have answered:
 
What are the terms and conditions of the Apple/Symantec deal?
 
Or, in other words: Is the code available at any price?
 
In all the press I've read concerning this agreement, I've yet to read
anything but vague details.  Statements such as:
 
"Apple will provide technical assistance to Symantec"
"Apple engineers are working with Symantec"
 
don't *really* mean anything.  Symantec seems to be calling the shots.
What I'd like to know is what (contractual) leverage Apple has.
 
I'd also like to know why Symantec was anointed with such honors in the
first place.
 
 
 
 
      |E|J-  ED DRAPER
 rEpar|D|<-  Radiologic/Pathologic Institute
             The University of Texas M.D. Anderson Cancer Center
             draper@odin.mda.uth.tmc.edu
From: SPECK@RUC.DK
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Removal from Mailing List
Date: 29 Dec 92 01:13:00 GMT
Organization: AppleLink Gateway

From: <speck@ruc.dk> (Peter Speck)
X-Sender: speck@pops.ruc.dk
To: MACAPP3TECH$@AppleLink.Apple.COM
 
I would like to be removed from the MacApp3Tech$ mailing list.
 
I'm reading it with Nuntius/news.
 
Peter Speck, speck@dat.ruc.dk
 
Newsgroups: comp.sys.mac.oop.macapp3
From: ksand@apple.com (Kent Sandvik )
Subject: Re: Takeover Example
Date: Mon, 28 Dec 1992 00:16:08 GMT
Organization: (Evil Eye Creature from Mars, Inc.)
Followup-To: comp.sys.mac.oop.macapp3

In article <725492228.1473624@AppleLink.Apple.COM>, RSD@AppleLink.Apple.COM
(Research SW Design, D Goldman,PRT) wrote:
> Regarding my accompanying link ("TEditText Bug")...
>  
> I would speculate that this is a bug whose fix will:
>  
> (a) involve a very slight change to the MacApp code;
> (b) easily be seen to not have distant side-effects;
> (c) at best show up in an Apple bug doc, and that only if we're unexpectedly
> lucky (Kent says he's being transfered to another engineering department!);
> (d) belong in MacApp 3.0.2 (which there is no indication we will ever see Apple
> create or distribute).
>  
> If Apple supported MacApp 3.0, then this is what would happen now:
> (1) Apple confirms and repairs this very small and easy bug.
> (2) The fix is made to MacApp 3.0.2, which is distributed on ETO #10.
>  
> Since Apple no longer supports MacApp 3.0 [Go ahead: prove me wrong! Follow
> the above 2 steps.], let us suppose that MADA buys it. Then here is the
> scenario:

I just want to raise one issue, Q&A of a product is a very expensive
phase, and in the case of MacApp we are even dealing with a multitude
of testing cases. In other words one engineer for testing/maintenance
is maybe OK, maybe not (I'm skeptical but I might be wrong, if you find
someone willing to hack 20 hours a day :-) ).

I've seen this problem over here in DTS, where we have people, resources,
even a lot of equipment. The problem we have is time, it takes a lot of
time
and energy to test out bug fixes, and we don't have the infrastructure
concerning a full SQA process, something that needs to be in place day
one concerning bug fix releases. In addition, you have to be very, very
sure that bug fixes are properly working, because developers don't like
sudden updates to bug fixes (yes we know, we sometimes have the same
QA problem over here).

Cheers,
Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.		
"Don't just do something!  Stand there!"  -- Mystery Science Theater 3000
From: COMPONENT@AppleLink.Apple.COM (Component Software, S Ballard,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: RE><C> Re: Re2: Bedrock N
Date: 24 Dec 92 17:18:00 GMT
Organization: AppleLink Gateway

Attn:
SentBy: Stoney Ballard
 
Regarding:                    RE><C> Re: Re2: Bedrock News
Sam,
 
  Component Workshop is a product of Component Software Corp. It's a software
development system that uses a Smalltalk-like dynamic environment, but is
based on the C++ language. It's not a complete implementation of C++ (yet),
but does provide the size and performance attributes of C++ in the completed
applications, which are removed from the environment by our Extruder tool and
converted to ordinary size-and-performance application files. It includes an
application framework similar to MacApp, extensive class libraries (esp.
collections), an incremental C++ compiler, an integrated suite of browsing and
inspecting tools, and a garbage collector (which also works with the final
application).
 
CW is ideally suited for new development where a strong object-orientation is
important, but the cost of keeping a dynamic environment in the shipping
application (as with Lisp and Smalltalk) is too high to be practical.
 
CW is shipping on the Mac now, and we are porting it to Windows and other
platforms.
 
If you (or anyone else) want more information, send your postal address to us
at:
 
  Applelink    :COMPONEN
or T
 Interne           t:keli@cosoco.c
 
or call 1-617-862-9700
 
or fax to 1-617-862-7749
 
  - Stoney Ballard, CTO, Component Software Corp.om
From: STRATA3D@AppleLink.Apple.COM (StrataVision, Gary Bringhurst,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: re: Camelot (phone number)
Date: 31 Dec 92 11:49:00 GMT
Organization: AppleLink Gateway

The phone number I gave on my Camelot link appears to be bogus.  Sorry about
that.  Here's the complete address for Wyvern:
 
 
Wyvern Technologies Inc.
1367 Wellington Street
Ottawa, Ontario
Canada  K1Y 3C2
Tel: (613) 729-8236
and  1-800-265-4386
Fax: (613) 729-8838
 
Newsgroups: comp.sys.mac.oop.macapp3
From: ksand@apple.com (Kent Sandvik )
Subject: Re: TEditText P.S.
Date: Mon, 28 Dec 1992 00:10:19 GMT
Organization: (Evil Eye Creature from Mars, Inc.)
Followup-To: comp.sys.mac.oop.macapp3

In article <725492220.0782951@AppleLink.Apple.COM>, RSD@AppleLink.Apple.COM
(Research SW Design, D Goldman,PRT) wrote:
> By the way, despite the occasional inquiry here, I've never seen an explanation
> of the point of all this floating TEView business in the first place (as
> opposed to having TEditText simply be a subclass of TTEView). The memory
> savings per instantiation are small, but the increased code complexity is VERY
> high.
  
> [Since Apple actively supports MacApp 3.0, I look forward to any *current*
> Apple MacApp engineer answering this question.]

Is an answer from a MacApp support engineer OK? Based on my recollection
talking with the originators of the floating view, there were talks about
deleting the floating TEView construct from MacApp 3.0, but due to time
limits the operation was never done. I agree, the complexity behind 
the floating view is a support/port/maintenance nightmare, a good example
when a splendid idea does not automatically imply a splendid end result.

Cheers,
Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.		
"Don't just do something!  Stand there!"  -- Mystery Science Theater 3000
Newsgroups: comp.sys.mac.oop.macapp3
From: knee@netcom.com (Mark Lanett)
Subject: Galaxy?
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Sun, 27 Dec 1992 06:08:47 GMT

ALGER@AppleLink.Apple.COM (Alger, Jeff,VCA) writes:

>Fellow OOPers,
> 
>This is getting pretty confusing: Bedrock, Component Workshop, Dylan, OOPC,
>Camelot, Galaxy, CLOS, Smalltalk (the language that refuses to die!), and who

Hmmm. New-framework-of-the-week month it seems. What's Galaxy?
From: B.HABLUTZEL@AppleLink.Apple.COM (Hablutzel, Bob,CST)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: DrawString in OffScreen
Date: 29 Dec 92 15:21:00 GMT
Organization: AppleLink Gateway

Bill -
 
  Of course, you realize that you have violated unspoken net etiquete by
posting this to MacApp3Tech$ - this newsgroup is dedicated to bashing
unreleased products. But I'll take a stab anyhow.
 
  I think the problem might be in the SetRect/ViewToQDRect code that you have
at the beginning. Unless you mistyped the code, and it is really a SetVRect
call, something funky is going to happen when you call ViewToQDRect. Remember
that SetRect creates a CRect (16 bits) and a ViewToQDRect expects a VRect (32
bits) in the first argument. So the VRect( CRect ) constructor will be fired,
converting the first argument to a VRect. Then ViewToQDRect gets called,
converting the rect back into a CRect. BUT, in this process the CRect is
translocated to be in line with the view coordinate system. In other words,
this sequence does nothing but move the rectangle to the view coordinate
system. Since all your text is high up in the rectangle, I would guess that
this translocation moves the text above the top of the rectangle, and therefore
it gets clipped.
 
  Try changing
 
   SetRect(theRect, 0, 4, 208, 248);
   this->ViewToQDRect(theRect, theQDRect);
 
 to
 
   SetRect(theQDRect, 0, 4, 208, 248);
 
 and see what happens.
 
 
Bob
 
 
 
Bob Hablutzel
Hablutzel Consulting
ALink: B.HABLUTZEL
Phone: 708 328 0130
From: CEL.MKTG@AppleLink.Apple.COM (CEL Software, R Matichuk,CAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: RE- HC XCMDs in MacApp 3?
Date: 29 Dec 92 19:31:00 GMT
Organization: AppleLink Gateway

Attn: G. Gordon
SentBy: Chris Matichuk
 
Date   12/23/92
Subject    RE- HC XCMDs in MacApp 3?
From   Chris Matichuk
To G. Gordon
 
                      RE: HC XCMDs in MacApp 3?
<<Has anyone done a HyperCard XCMD interface for MacApp 3.0?  I know there was
something called XLink Access, but I haven't located it yet and don't know if
it would do what I want anyway.  I want to be able to include XCMDs such as
the PlayMovie XCMD for MacroMind Director.  Thanks.>>
 
The "XLink Access" was a source code version of "XLink XCMD Manager". It is
not a product that was actually sold. XLink has C and Pascal interfaces to
allow you to link XCMDs into MacApp.  Send us a link if you are interesed.
 
There is a DEMO version of XLink on the "CEL" board on AppleLink.
 
Chris Matichuk
CEL Corporation
CEL.MKTG
From: ALGER@AppleLink.Apple.COM (Alger, Jeff,VCA)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Frameworks wars and MADACON
Date: 24 Dec 92 20:44:00 GMT
Organization: AppleLink Gateway

Fellow OOPers,
 
This is getting pretty confusing: Bedrock, Component Workshop, Dylan, OOPC,
Camelot, Galaxy, CLOS, Smalltalk (the language that refuses to die!), and who
knows how many others?  A year ago, choosing a framework was easy.  A year or
two from now it may be easy again, since these products cannot each keep a
large enough market share to prosper.  But right now it's sheer chaos.  Which
leads to the following idea: with the MADA conference coming up in February,
how about an evening session devoted to emerging frameworks and development
environments?  Get as many vendors as possible on the stage at the same time
and give them a set of specific topics to address so that it doesn't become a
group sales pitch.  Make sure there is plenty of time for Q&A.  Invite the
press (e.g., JOOP and Object Magazine).  I can't think of any way for MADA to
better serve the interests of its members this year, nor a better forum for
vendors to receive critical feedback about how their products stack up from one
of the most literate and business-saavy OOP groups in the industry.
 
If this is already being done, please excuse the link.  If not, count me a
volunteer to help bring it about.
 
With best holiday wishes to all,
Jeff Alger
SBM International
 
Newsgroups: comp.sys.mac.oop.macapp3
From: william.zwicky@cray.com (Bill Zwicky)
Subject: What is Component Workshop?
Followup-To: comp.sys.mac.oop.macapp3
Organization: Cray Research
Date: 23 Dec 92 15:25:56 CST

I've seen a couple of postings for a product called "Component Workshop". 
Who makes this product?  Is it available now?  Is anyone using it for
production development?  

Thanks,

Bill Zwicky
Cray Research