From: nevin@dtint.dtint.com
Subject: Re: Coding Rules (NOT rtf)
Reply-To: nevin@dtint.dtint.com
Organization: Digital Technology, International
Date: Thu, 19 Nov 92 00:08:58 GMT


>> It'll port easily to every NeXTSTEP supported platform and that's all I care
>> about.  Other programmers may not be as lucky, though, and may not have that
>> luxury.

> Sigh... Most of us in the "Real World" (tm) don't have that luxury. In fact,
> most business cases for making money cannot count on NeXT (WP, Lotus, Boss,
> Adobe, etc), or the business plans are extremely optimistic without much hard
> data (AppSoft), or are destined to remain small players (Metrosoft, Stone
> Design). If NeXT can get their act together for the cross-platform support
> many of us will be ready and willing to ride the bow-wave. So far, NeXT lags
> in that area . Hence, we look at markets like Windoze (tm).

I'm not so sure that the assursion that others "are destined to remain small  
players (Metrosoft, Stone Design)" will prove to be accurate.  These companies  
that have committed whole heart and soul to the NeXT way of developing won't be  
as wrapped-up in cross-platform compatability issues (I'll bet that's why  
Virtuoso was so late).  If NeXTSTEP really takes off, these "small player"  
companies will be the ones that are ahead.
 
> The one window-per-nib is considered proper NeXT IB ettiquete. It also was
> originally related to early performance considerations (i.e. wanting to
> lazy-load as much as possible). An anti-example of this (If I remember
> correctly) is WordPerfect, which loads slowly because multiple windows/panels
> in a single nib (in which the archived objects will be getting a read: and
> awake call). I might add that there has been discussion about nib loading and
> 3.0 which might tend to reverse NeXT's original position (most of the 3.0
> slow-down is related to nib/disk/memory stuff).

I've heard a slightly different story about the 3.0 slowdown, from an ex-
NeXT employee.  It was caused (according to him) by a generalization of
things like "malloc(512)" to "malloc(sizeof(somesuch) * 4)" in order to better  
support new platforms (ala 486).

>> I presume you mean: "some panels/windows in some NIB's don't have titles".
>> My question would then be: why doesn't the panel/window have a title?
>> What would it hurt to put a title in?  Note that the rule I gave does
>> give you some discretion in the choice of the title:

> Often times nibs are used to collection images (as in parts of WM), or
> controls (common for custom windows), or insets to other panels (i.e.
> customizing NeXT's print panel, NeXT's use of subpanels in the Color picker).
> These titles never get displayed and often are multi-purpose.

Then the rule wouldn't apply.  The language of the rule was written such that  
it only applies to NIB's with windows or panels.  Or at least, that was my  
intent, and has been clarified in my latest version of the rules.

--
Nevin Pratt, Digital Technology, Int'l    Orem, Ut
NeXTmail preferred, but ONLY at my REAL email address: nevin@dtint.dtint.com

-- 
---
root	                               root@dtint.dtint.com
Digital Technology Int.                (801)226-2984	
500 W. 1200 South, Orem UT, 84057      FAX (801) 226-8438