Re: [RE: emc really needs a copyleft cad/cam package]

[Anne Ogborn <anniepoo-at-netmagic.net>]

Comments about user interface and the copyleft cad/cam package -

While Tcl/Tk seems an appropriate thing to implement a relatively simple
UI like that required for a CAM package, a CAD/CAM package is a different
beast entirely. Not being a Tcl/Tk programmer, though, I'll defer to your
common judgement - is Tcl/Tk an appropriate solution for what soon promises
to become a large user interface?
Secondly, Everett McKay, in his recent book, distinguishes between "Utilities" and
"Applications". We're definitely talking an application here.
While rough edges on a UI are totally acceptable on a utility, they will kill an
application.
  (Actually,  discussing such implementation issues is definitely premature. It leads to
the dread "it looks like a hypercard stack because it is a hypercard stack" phenomenon.)

second comment -
  "begin an open discussion as to what features
   should an opensource cad/cam package/program
   have. the goal being to draft a design specifcation
   that most everyone could live with for the first
   cut." - Terry Ridder

   I thought there was a lot of wisdom in Terry's original post. It seems he laid out
a sane program for getting where we're going. As I interpret that program, it is -
   1. Figure out where to hold the discussion (new list/this list/CAD_CAM_EDM_DRO)
   2. Produce a list of "features an opensource cad/cam package/program should have"
   3. Draft a design specifcation that most everyone could live with for the first cut.
   4. Plan how we are to accomplish the design spec.
   5. Code this puppy

   I might be persuaded to help with/organize some UI testing and design effort when
we get that far. Any editor progam, particularly one that works with 3D, lives or dies on it's user interface.  If we are to
invest such a large amount of our own time and energy in such
a project, we owe it to ourselves to produce software which is widely used, not an
arcane hack which is impossible for anyone except our small group to actually create
real work with.
   Coming from the commercial software end of things I also notice a couple of missing
items in the above. It will behoove us to invest some time in developing a reasonably friendly
way of distributing and installing this, as our target audience is not programmers.
No program is helped by being QA'ed by it's end users. The size of this project probably deserves
some organized QA effort.

   I suspect we are trying to attach ourselves to the emc process. That's probably inappropriate,
since emc is far along in the process. We need to start at the beginning with this one.

   To summarize, I believe we have the cart before the horse. A discussion of how to organize
the CVS repository, or whether to use Tcl/Tk, etc. can only lead to fixing those decisions
at a time when we cannot know the consequences of those decisions.
   I assure you that I've seen many millions of dollars thrown down ratholes in the commercial
world trying to develop software usng "code, then design". Invariably it has lead to
"code, design, try to fix the code, find a compromise within budget constraints, push this
kludge out the door, find somebody to blame it on."

   Terry, you're process meister on this.

Annie

)$%&[8c)  <--- Annie with her UI design and project management hats on