Re: gEDA-user: What is the standard of gEDA tools and PCB - me too

[Alvin Oga <alvin@Virtual.linux-consulting.com>]

hi ya

> 
> I'm glad to see that PCB project gets into another run
> of
> development. I expressed my wish on PCB with eye on
> getting more and more developers, and more and more 
> users.
> 
> Schematic capture and Layou are two major point tools
> in
> the PCB design flow. For gEDA project, they shoud
> share
> a common GUI environment from the user's point of
> view.
> 
> Besides, PCB GUI seems written in Xt (correct me if
> I'm 
> wrong). For most OpenSoftware developers, working with
> some new technology may be the only motivation and 
> reward. 

i think that all apps will always have some of it major
components that is NOT part of the "standard" that is
support

- i always write my own interface/temporary db...
	- read any format from "xyz vendor"
	- generate abc format reqired for ijk processes

- my requirements ... 100% fully integrated ...
	- highlight anything part or net and all other
	  related item that is on the screen is also hightlighted
	- schematics db
	- simulation db ( ckt, logic, timing, functional .. )
	- parts defintions
	- symbol libraries
	- properties within each macro
	- properties on a flatten design
	- report generation tools
	- erc checking
	- drc checking
	- lvs checking
	- lpe extractions
	- netlist generation
	- netlist parsing
	- test vector generation
	- testbed final testing and rejects
	- pcb gerber output
	- fab drawings
	- assembly drawings
	- 2D modeling
	- 3D modeling, n-dimensional modeling
	- thermal mapping
	- air flow modeling
	- gui for viewing ...
	- on and on

	- it can be done ... not too difficult w/ some forethought
	( been there .. done that  ... but it can get messy )

	- gui is for user feedback and will always need tweeking
		- gui and look-n-feel should NOT drive/dictate
		how things are done ... imho 

	- databases should be extensible and explandable
	and distributed 
		- this db design ( always in 100x terabytes of data )
		is the limiting factor of what you can and cannot
		do with the data you NEED to process and engineer

	- each industry has their own separate standards 
	( picking one standard means you'll fafil in a different
	( industry that needs similar info but tweeked with their data/models
		- i say use our own "GPL extensible db" w/ various 
		industry standard API

	- ease of use .. depends on if you can make the gui
	model after some prev app they've been accustomed to using
		( simple keyboard or mouse mapping )

	- only a small fraction of the db is needed at any given
	time to data entry, but a different 10% is needed
	by another simulation engineer

- am hoping for a day i can scribble into "autocad equivalent"
  and simulate a PC ...
	and at the same time, scribble parts into a schematic
	editor and i can simulate read or write to system memory
	and watch the heat/airflow and move traces around to make it faster
	and run cooler

	- so close .. and yet so far ...
c ya
alvin