HDTenEightyP/NetNews huggingface dataset:
From: Jim.Matthews@dartmouth.edu (Jim Matthews)
Newsgroups: comp.sys.mac.advocacy
Subject: un-amazing NeXT (was: Will the real Taligent please stand up?)
Date: 16 Dec 92 15:18:26 GMT
Organization: Dartmouth College, Hanover, NH

Eric M Hermanson writes
> From a design standpoint, in what ways is Mac better than NeXT?  

The Mac has a standard user interface, and software is expected to use it;  
the NeXT has two interfaces (NeXTStep and your favorite Unix shell) and  
has software split between the two.  On my Mac I can configure network  
services, schedule background tasks, restore crashed disks, or whatever  
else using the same visual interface that everything else uses; on my NeXT  
I have to use text editors, command line shells, syntax-laden batch files,  
and utilities written a decade or more ago.

> Why is NeXT's current advancement in Technology less amazing than what  
Mac
> did some years back?

When the Mac came out the standard personal computer was an IBM AT running  
DOS 2.0 (or maybe 3.0) with a green-on-black screen (text, no graphics).   
The Mac represented a fundemental change in the computing experience: the  
screen was black-on-white, graphics-only.  Text was displayed and edited  
in a variety of fonts and styles, and screen displays closely resembled  
the final printout.  The user interface was point-and-click instead of  
type-and-hope.  All the applications followed certain conventions (menu  
names and common commands, text editing conventions, the select-then-act  
model).  All these things were new in the personal computer business  
(modulo the Lisa), and made using a Mac completely different from using  
other personal computers.

By contrast, the NeXT user experience is at its best a refinement of the  
Mac; it might be faster, there are new wrinkles in the visual display (3-D  
buttons, proportional scroll bars) and there are new behaviors (i.e. drag  
and drop), but there is no fundemental change.  For that you should look  
at PenPoint or Newton, or perhaps virtual reality systems; *those* are  
amazing.  The NeXT is just neat.

Jim Matthews
Dartmouth Software Development

p.s. you could make the argument that NeXT has done for GUI software  
development what the Mac did for GUI user interfaces. I don't think that's  
quite true, and advances in development environments aren't as widely  
useful as advances in user interfaces, but that is where NeXT has taken  
its largest strides.
Newsgroups: comp.sys.mac.advocacy
Subject: Re: Mac multitasking?
From: goblec@physc1.byu.edu
Date: 14 Dec 92 19:03:12 -0700
Distribution: world
Organization: Brigham Young University

> NeXTSTEP 3.0 broke no software.  3.0 is totally binary comptible with
> 2.1.  ADB keyboards broke software that was peeking at hardware
> dependant key codes rather than hardware independant char codes, but
> this is not NeXT's fault.

Isn't this like saying that no software crashed under Systen 7 because
Microsoft wrote their programs wrong?  It is true it isn't Apple's fault,
but software still crashed.  (actually none of my software crashed in
the upgrade - but I had already bought Word 5.0)

> Where Mac has 10 programs in a specific field, NeXT only has three or four
> at most, but the fact is that those three or four packages are most likely
> superior in their speed and versatility than the 10 Mac programs.

What WP programs are available for the Next other than WriteNow and
(ugh) Word Perfect.  WriteNow is nice, but is lacking quite a few features
that some writers need.  It has no table editor for instance, one reason
why MS-Word is so popular.  The last version I saw had no style sheets
either.  The Mac version does now, but I don't know if this has been
ported to the Next yet.  I don't know about it's glossary, footnoting,
indexing or table of contents managers.

As far as I know there is only one page layout program for the Next,
and it is considered a shoddy port by many I have talked to.  I've
heard many people on the Mac side who don't like FrameMaker either.
PageMaker and QuarkExpress aren't available.

In graphics things are better, but there still isn't a program
akin to the Mac's photo retouchers.  In spreadsheets there is
Improv and Wingz which are indeed nice, unless you need Excel
compatability.  I'm afraid I don't know much about terminal
emulators, beyond the fact that Terminal isn't up to much.  That
is what I am using to post this message.  It is incompatable with
our Vax's editor for some reason.

__________________________________________________________________

Clark Goble                      Logic merely sanctions the 
goblec@theory.byu.edu            the conquests of intuition.
__________________________________________________________________


Newsgroups: comp.sys.mac.advocacy
From: straka@cbnewsc.cb.att.com (richard.j.straka)
Subject: HAL
Organization: AT&T
Distribution: na
Date: Thu, 17 Dec 1992 14:39:51 GMT
Keywords: apple ibm pink talgent microsoft

In article <wondertr.724355474@sfu.ca> wondertr@fraser.sfu.ca (wondertree learning center) writes:
>matoh@lysator.liu.se (Mats \hrman) writes:
>
>>wondertr@fraser.sfu.ca (wondertree learning center) writes:
>>Well, haven't you noticed that VMS++ = W(indows)NT?
>>(V+1=W, M+1=N, S+1=T) 
>
>>"Windos NT - takes VMS one step further!" Yeacch...
>NO I hadn't noticed that.... is that like HAL being one step behind IBM

Isn't it that HAL is one step (perhaps many steps) *ahead* of IBM?

And, by the way, didn't we just pass one of those fateful days in
pre-history?  As I recall, in the movie 2001, HAL was first turned on in
Champaign, Illinois (University of Illinois) on December 12, 1992.
-- 
Richard Straka      AT&T Bell Laboratories
UUCP:     att!ihlpw!straka       INTERNET: richard.straka@att.com
From the 'ed' manual page: "A one-character regular expression is a regular
expression that matches whatever the one-character regular expression matches."
From: maynard@leah.msc.cornell.edu (Maynard J. Handley)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: MAC Harddrive space
Date: 16 Dec 92 07:45:25 GMT
Distribution: na
Organization: Cornell-Materials-Science-Center


>
>  BC> When you run out of space, that's the time to start shopping for
>  BC> a larger drive, not before.
>
>I tend to disagree.  If you buy a small drive now, one which just
>barely fits everything you *know* you need, that money is pretty much
>gone.  When you find that you need more disk space you will be forced
>to trash the old drive (or sell it for next to nothing) and re-invest
>in a larger drive.  See?  You're out almost every penny you used to
>buy the first hard drive.
>
>End story: buy what you need, plus a little bit.  Never get less than
>what you think you need, but not more than twice that ammount either.

Oh this is rich. On a mac when you need a new hard drive you buy it and
stick it in your SCSI chain. I have 3 hard drives connected to my Mac right
now. Lots of space for more if necessary. I guess your IDE drive isn't
quite that intelligent? Same with monitors. When you need more screen
space, buy another monitor.

Lord, and these are the people who tell us how powerful their systems are
because they can format floppies in the background. No wonder they have to
keep buying hardware if they have such a useless design that none of it can
ever be re-used.

Maynard
From: drm@esl.com (Don McGregor)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: Mac multitasking?
Date: 15 Dec 92 21:28:29 GMT
Reply-To: drm@esl.com

In article <1992Dec14.190312.271@physc1.byu.edu> goblec@physc1.byu.edu  
writes:
> 
> As far as I know there is only one page layout program for the Next,

In addition to Frame there's also PasteUp from RightBrain, and, coming  
soon, Pages. Lack of decent high-end word processors is a legit gripe.   
There have been a bunch of (unverified) rumors about Nisus on the NeXT.

> 
> In graphics things are better, but there still isn't a program
> akin to the Mac's photo retouchers.

Appsoft Image in a few weeks, looks like. 

>  In spreadsheets there is
> Improv and Wingz which are indeed nice, unless you need Excel
> compatability.  

Also Mesa, for 1-2-3 compatability, and Questor (new, haven't seen that  
one.)  The PowerStep SS is going to be released from Appsoft fairly soon.   
There are a bunch of spreadsheets around.  That category is covered.

> I'm afraid I don't know much about terminal
> emulators, beyond the fact that Terminal isn't up to much.  

Stuart, from the incomparable Scott Hess.

--
Don McGregor | Double your pleasure, double your fun.  Xerox
drm@esl.com  | your paycheck.
Xref: sparky comp.sys.mac:562 comp.sys.mac.comm:12300 comp.sys.mac.apps:18823 comp.sys.mac.misc:20942
From: roussea@server.uwindsor.ca (ROUSSEAU PAUL            )
Newsgroups: comp.sys.mac,comp.sys.mac.comm,comp.sys.mac.apps,comp.sys.mac.misc
Subject: Eliminating soft-carriage return characters when cut and pasting
Date: 20 Dec 1992 20:27:36 GMT
Followup-To: comp.sys.mac
Distribution: na
Organization: University of Windsor, Ontario, Canada

I am using White Knight 11.12 on a SE/30.  When I cut and past
text written on my word processor to my communications software
screen, apostrophes(sp?) are converted into vertically long
rectangles (I think they are the ascii characters for soft carriage 
returns).  It also happens if I transfer a text file to my
mainframe server (I use the kermit protocol).

I use the geneva font when I create documents to be cut and pasted to

my white knight screen.


Thus far, I've solved the solution by not using the apostrophe.  Is there
a solution to this problem.

Send response via e-mail and I will summarize a response and post it
to comp.sys.mac,comp.sys.mac.comm,comp.sys.mac.apps,comp.sys.mac.misc.

Thanks

Paul
-- 
Paul Rousseau			roussea@uwindsor.ca
(519) 735-7959			"It's too bad ignorance is not painful"
						-anonymous

Newsgroups: comp.sys.mac.oop.macapp3
From: D6431@AppleLink.Apple.COM (OptImage Interactive Svcs,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Stack size in MacApp
Date: 15 Dec 92 20:50:00 GMT
Organization: AppleLink Gateway

Help,
 
I need a Large stack in my MacApp Application.  Is there any way I can increase
my stack size on application start up??
 
Any Help would be appreciated
 
Jay Bartot @OptImage 
 
Newsgroups: comp.sys.mac.oop.macapp3
From: ksand@apple.com (Kent Sandvik )
Subject: Re: 7.0 Color -> windoid WDEF?
Date: Wed, 16 Dec 1992 20:17:39 GMT
Organization: (Evil Eye Creature from Mars, Inc.)
Followup-To: comp.sys.mac.oop.macapp3

In article <724519728.1734027@AppleLink.Apple.COM>,
GILLAM.R@AppleLink.Apple.COM (Richard Gillam,GEIS) wrote:
> I think it's kind of interesting that Apple hasn't yet provided their own
> windoid WDEF (digression:  I really hate the term "windoid"!) with this feature
> in it.  This user-interface element is so common now that it seems natural to
> include it.  I know that certain foreign script systems have to have this
> window type to display their input methods.

Look at System 7.1!

Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.
From: RANSON@AppleLink.Apple.COM (Ranson, Lannion,FR,IDV)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: MacApp and CPU caches
Date: 12 Dec 92 07:18:00 GMT
Organization: AppleLink Gateway

Because of its smart memory management, MacApp calls UnloadSeg all the time.
According to the new Inside Mac, this trap clears the CPU caches. I wonder what
effect this has on the performance of MacApp appls. Has anyone done any testing
of this?
     Daniel.
From: GILLAM.R@AppleLink.Apple.COM (Richard Gillam,GEIS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: 7.0 Color -> windoid WDEF?
Date: 16 Dec 92 15:05:00 GMT
Organization: AppleLink Gateway

Nik--
 
I've done this, but I did it for a former employer, so I have a feeling finding
and releasing the source code could potentially get me into trouble.  (I could
do it anyway, as long as you promised not to know where you got it, but even
here we might have problems.)
 
I think it's kind of interesting that Apple hasn't yet provided their own
windoid WDEF (digression:  I really hate the term "windoid"!) with this feature
in it.  This user-interface element is so common now that it seems natural to
include it.  I know that certain foreign script systems have to have this
window type to display their input methods.
 
Equally annoying is that there is no documentation on doing the color stuff.
There's a Tech Note that describes the current format of the 'wctb' resource.
But this is only half the problem.  The standard WDEF doesn't use the colors in
the wctb; they calculate the colors they do use from the ones in the wctb.  I
had to look at the WDEF source code to find the algorithm, and I never did
figure out how to translate the algorithm into C, copying the assembler
instead.  This is a BIG hole in Apple's documentation.  Apple, if you want us
to support your approach to window-frame coloring in our own WDEFs and CDEFs,
we need ALL the information!  Specifically, we need the algorithm used to
calculate the real colors to be published, along with which parameters are used
to get all the actual colors used in drawing the window frame.  Making us
figure all this out ourselves isn't developer-friendly.
 
Rich Gillam
GE Information Services
 
Xref: sparky comp.sys.mac.oop.macapp3:228 comp.sys.mac.programmer:19933
From: werner@dewey.soe.berkeley.edu (John Werner)
Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.programmer
Subject: Re: ViewEdit question
Followup-To: comp.sys.mac.oop.macapp3
Date: 16 Dec 1992 22:43:42 GMT
Organization: School of Education, U.C. Berkeley
NNTP-Posting-Host: dewey.soe.berkeley.edu

[Note: followups redirected to comp.sys.mac.oop.macapp3.]

In article <1992Dec16.214331.4233@u.washington.edu> Bob Cent writes:
>I want to make a window with ViewEdit that can only be enlarged in 
>the vertical direction when one drags the "grow box" (a window like 
>you see when you configure a TView while in ViewEdit).

The good news: TWindow has a fResizeLimits field that will do what you
want.  I think you just need to set fResizeLimits.left =
fResizeLimits.right = your fixed size.

The bad news: I don't think there's a way to set this with ViewEdit.
You'll have to do it in the code, either by explicitly calling
SetResizeLimits on the window, or by creating a subclass with a method
(maybe DoPostCreate?) that automatically figures out the horizontal
size, then calls SetResizeLimits.

-- 
John Werner                        werner@soe.berkeley.edu
UC Berkeley School of Education    510-642-9651
Newsgroups: comp.sys.mac.oop.macapp3
From: lsr@taligent.com (Larry Rosenstein)
Subject: Re: Bedrock News
Followup-To: comp.sys.mac.oop.macapp3
Organization: Taligent, Inc.
Date: Fri, 18 Dec 1992 20:23:26 GMT

In article <724520795.6224101@AppleLink.Apple.COM>,
GOTTSHALL.R@AppleLink.Apple.COM (Robert Gottshall,GEIS) wrote:
> 
> It really seems that the current approach to OOP isn't delivering its
> promises. Eiffel and Smalltalk do better, but they have different
> programming environments. Neither of the speakers mentioned any

Bedrock was not intended to address the programming environment issue. 
There is a lot of work going on in terms of C++ progamming environments in
the Unix market (from ParcPlace, HP, Sun, Lucid, etc.) and there's
Component Workshop in the Mac market.  

My understanding is that Bedrock was designed to work with any C++
compiler, and so it could be used in any of these environments.  (Assuming
CW does enough of C++, which I'm not clear about.)

> Apple said that Bedrock sort of tried to fit into the chasm between
> Hypercard and C, but I'm not convinced :) My vision of this project is

I wouldn't be convinced either.  HyperCard and C are totally different
things.  Even if he meant HyperTalk and C, those are languages and Bedrock
in a framework.

> events, etc.). Well, that was what TCL and MacApp were supposed to be.

The difference is that Bedrock was designed to be cross-platform, while TCL
and MacApp were not.

> Framework around as luggage. It seems to me that there should be a
> default application framework that is always active and is part of the
> system software. Your application essentially registers itself to the

That's a good point, but I think it's a third orthogonal point.  In theory,
there's no reason why Bedrock (or MacApp for that matter) couldn't be
shared among apps.

> environment. For example, why do we need to have "includes" or "USES"
> clauses in an OOP environment? There should be a big object database

This is where the C++ environments I mentioned are heading.  Certainly
Component Workshop does something like this, and I think the others may do
this as well.  But I don't think it's a framework issue, although when you
consider the entire task of creating an application you need all these
pieces (development environment, frameworks, shared libraries).

Larry Rosenstein
Taligent, Inc.

lsr@taligent.com
From: D5087@AppleLink.Apple.COM (KR Software, Ken Ryall,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: MacApp demo code ?
Date: 12 Dec 92 16:24:00 GMT
Organization: AppleLink Gateway

Yeah, its really too bad that Object Model support got lost in the rush to
Bedrock. However it's really not that hard to do yourself, but it does require
modifying MacApp a good bit. But, I tell myself, since we'll never see a new
version of MacApp, I might as well go to town on its source code.
 
Eric's article is a great example, but as you noted doesn't mention MacApp.
This is not an accident, as I discovered when I linked him looking for advice
on how to apply the same example to MacApp. He replied that a MacApp example
"involves too much pain and anguish to deal with in a single
article." After working on this a bit, I have to agree with him.
 
His advice for using the example in his artice with MacApp went like this:"
 
1) Put all the MAppleObject behavior into TObject. For the pure virtual
functions, write TObject implementations that call SubclassResponsibility.
This will cause a runtime break, thus implementing the "pure virtualness" of
the object.
 
2) Change TApplication's handling of AppleEvents to check the direct object
just as my C++ dispatcher object does. Dispatch to the appropriate object if
it is an object model event, and to gApplication if not (ie: gApplication will
always be the "default handler")."
 
This puts the basic structure in place for handling the Object Model, but
doesn't implement default functionality for TWindow, TView,
TEventHandler, TApplication, etc. Eric noted that this requires most of the
work. It does, but is mostly tedious, not technically difficult.
 
Of course this does not address making the application recordable in addition
to being scriptable. This will require some modifications to the TCommand
system I'm sure, but I think I'll drive off that bridge when I come to it.
 
Ken Ryall
From: NOR0154@AppleLink.Apple.COM (DATEC A/S,STORAS,NO,IVC)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: TPopup problem..
Date: 18 Dec 92 07:04:00 GMT
Organization: AppleLink Gateway

Attn: MacApp3 Technical Support
SentBy: Bjorn Olav Erland
 
Date   17-12-92
Subject    TPopup problem..
From   Bjorn Olav Erland
To MacApp3 Technical Support
 
                      TPopup problem..
Hi,
 
I have a problem with getting MA3.0 to make popupmenus.
 
At first I had only one Popupmenu in a dialog. The popup got its first three
items from a CMNU resource, and the rest of the items was updated at runtime.
The Popup is by the way a list of layers in a CAD program, and the first items
were ( All layers, No Layers, separator line).
All items in the CMNU had command number 0.
This worked fine.
 
Later I tried to make an equivalent Popup menu to keep a list of systems in
the CAD program, and installed this into the same dialog.
I then got a Failure in TPopup.CreateCMgrControl, during viewcreation. The
defproc does NOT make its datastructure..
 
   // Need to signal failure if the CDEF's private storage couldn't be created
-- this is
   // most likely due to a missing MENU or CMNU resource with fMenuID.
   FailNIL((*aCMgrControl)->contrlData);
 
I have checked the resource map and the CMNU exists with the correct ID= 130.
Could someone give me a clue to what is wrong here?? It seems like the error
occurs when I have got more than one popup in the dialog.
 
Regards
 
Bjorn Olav Erland
From: D4887@AppleLink.Apple.COM (Advanced Comm Eng, G G Apple,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: MacApp 2 to 3 - Dble Click
Date: 16 Dec 92 00:44:00 GMT
Organization: AppleLink Gateway


 
----------------------------------------------------------------------------
>   I've noticed that many of the global variables used no longer
>   exist in 3.0 (ie. gLastClickPart, gClickCount .. )
 
    They didn't go away, they just hid.  when you get the DoMouseCommand, you
also get the TToolBoxEvent* event.  There's no accessor but you can get event
-> fClickCount because it is public.
 
G. Gordon Apple   D4887
Advanced Communications Engineering, Inc.
Redondo Beach, CA
From: D1950@AppleLink.Apple.COM (STM Systems Corp, Don Phillips,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: MacApp 2 to 3 - Dble Clicking
Date: 15 Dec 92 21:31:00 GMT
Organization: AppleLink Gateway


 
 
Background :
 
We are currently converting our applications from MacApp 2.0 to 3.0 using
Object Pascal. Our plans are to convert to 3.0 now and then convert to C++ at a
future time.
 
Problem:
 
The conversion has become very difficult since I can't test any changes that I
make until I finish converting everything. Its also difficult when the original
code was written by someone not working for us anymore.
 
I'm currenlty confused on how to double click on an item list view.
 
Scenario:  We have a list of items and need to know if a double click occurred.
   Therefore we are looking for a double click within a certain period
   of time and within the same pixel location.
   I've noticed that many of the global variables used no longer
   exist in 3.0 (ie. gLastClickPart, gClickCount .. )
   I also noticed that the parameters have changed.
 
   Is there an easier way to detect double clicking within a certain
   area using 3.0.
 
    Below is the old code that I'm currently looking at.
   I hope this is enough information for you.
 
 
*****************************************************************************
FUNCTION TTTextListView.DoMouseCommand( VAR theMouse : Point;
   VAR info : EventInfo; VAR hysteresis : Point) :TCommand; OVERRIDE;
 
VAR
   whereMouseDown  : INTEGER;
   aWMgrWindow : windowPtr;
   tmpDialogView   : TTTextDialogView;
   aRow, aCol  : INTEGER;
   aCellSelectCommand  : TTCellSelectCommand;
 
BEGIN
 
   DoMouseCommand := INHERITED DoMouseCommand( theMouse, info, hysteresis );
 
   WITH info, thePEvent^ DO
   BEGIN
   IF thePEvent^.what = mousedown THEN
   BEGIN
   tmpDialogView := TTTextDialogView( SELF.GetParentView );
   tmpDialogView.DeSelectInEverythingBut( SELF );
 
   whereMouseDown := FindWindow( where, aWMgrWindow );
   IF SELF.DoubleClick( thePEvent, whereMouseDown, theMouse  ) THEN
   SELF.ffDoubleClick := TRUE
   ELSE
   SELF.ffDoubleClick := FALSE;
   END;
   END;
END;
 
*****************************************************************************
FUNCTION TTTextListView.DoubleClick( aPDownEvent: PEventRecord;
   whereMouseDown: INTEGER; theMouse : Point ) : BOOLEAN;
 
   VAR
   clickCount: INTEGER;
 
BEGIN
   clickCount := 1;
 
   WITH aPDownEvent^ DO
   BEGIN
 
   IF whereMouseDown = gLastClickPart THEN
 
   IF gClickCount > 0 THEN
   { not the first click and ... }
 
   IF when - gLastUpTime < GetDblTime THEN
   { ... close enough in time and ... }
 
   IF SELF.FirstSelectedItem = SELF.GetItemClicked( theMouse ) THEN
   { If this second click is on the same item as the first click }
   clickCount := gClickCount;
 
   gLastMsePt := where;
   END;
 
 
   { Consider just the even clicks = 2, 4, 6, etc }
   IF ( ( clickCount MOD 2 ) = 0 ) THEN
   DoubleClick := TRUE
   ELSE
   DoubleClick := FALSE;
 
END;
*****************************************************************************
 
 
 
Any guidance would be appreciated.
 
Ett DiNardo
ISM Corp.
AppleLink : D1950