menu-bar

• To: Lawrence.G.Mayka@att.com
• Subject: menu-bar
• From: Scott McKay <swm@harlequin.com>
• Date: Fri, 6 May 94 11:22:17 EDT
• Cc: jmorrill@BBN.COM, miller@cs.rochester.edu, clim@BBN.COM
• In-Reply-To: Lawrence.G.Mayka@att.com's message of Fri, 6 May 94 09:22:34 CDT <9405061422.AA04596@ieain.ih.att.com>

   From: Lawrence.G.Mayka@att.com
   Date: Fri, 6 May 94 09:22:34 CDT
   Original-From: lgm@ieain.ih.att.com

      Date: Fri, 06 May 1994 09:37:36 -0400
      From: Jeff Morrill <jmorrill@BBN.COM>

      I also believe that vendor-supplied extensions are a good thing.
      I would only ask that the "clim" package be sacrosanct, much like
      the ANSI "common-lisp" package.  It is good hygiene to put new
      symbols in other packages, "clim-extensions" for example.
      The keyword :menu-bar wouldn't apply, of course, but the class
      name MENU-BAR would.

   I agree with the need to distinguish portable capabilities from
   extensions.  The only question is whether CLIM has matured
   sufficiently to make that distinction clearly.  What we would need is
   a single, up-to-date document to which the major vendors have agreed
   to conform.  My understanding is that the CLIM 2.0 spec was meant to
   be that document, but I don't think it's been kept up to date.

I have a reasonable up-to-date set of spec sources, mostly having
editorial fixes over the old CLIM 2.0 spec.  There are some changes
that needed to be made when CER and I discovered there were things in
the spec that were just brain-dead (for which I must take the blame).

• Re: menu-bar
• From: Lawrence.G.Mayka@att.com

• Prev: menu-bar
• Next: menu-bar
• Index: CLIM Mailing list (1-Jun-94 to 30-Jun-95)
• Thread: CLIM Mailing list Index (1-Jun-94 to 30-Jun-95)