[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

gEDA-user: Task list for: Solving the light/heavy symbol problem



The "what" phase seems to have drawn to a close, so now it's time for
the "how" phase.  How do we do the things we want to do?  What tasks
will lead us to the features we want?

Here, in no particular order, are the tasks I think we need to
undertake to get started (others will come up as we progress).  If you
were one of the proponents of one of these ideas, it's up to you to
make sure it happens.  Don't worry about "pretty" - just put together
something that shows off the concept, so we can see it in action and
evaluate it.



We need to create a few small heavy symbol libraries.  These are the
self-contained "starter" libraries we talked about.  Since these do
not require any software changes, we should start on these right away.
The purpose of these will be to give new users an opportunity to learn
the editing tools without having to simultaneously learn how to make a
library.  These libraries should be packaged such that it's easy for
the user to replace the standard library with them, and immediately be
productive.

gschem and pcb both need to be better at referencing multiple
libraries of arbitrary depth.  This includes a better way to manage
the libraries (gui, config, query rules), enable/disable them, and
browse them.  This information should be sharable between tools,
specifically, at least, between gschem, gnetlist, and pcb.

While I do not wish to start a discussion about what kind of data
should go in our "metadata", we need tools to work with it.  I think
that breaks down to the following:

* On the database end, design an API or two with which we talk to the
  data servers.  Implement a few servers to see how it works.  I've
  started some ideas at http://www.delorie.com/pcb/component-dbs.html
  at the "How is the database stored?" text.

* In gschem and pcb, we need a way to query the data servers in the
  attribute editors, in order to suggest attributes.

* In gschem and pcb, be able to choose symbols/footprints based on
  metadata queries - use the metadata as a filter for the library
  dialog.

* gnetlist needs the most work.  It needs to be able to read a set of
  rules, query the database, and fill in additional attributes based
  on the rules.  This need not be more than just "fill in the blanks"
  for now.

gschem, pcb, and the sims need ways to query remote libraries.  I
suggest HTTP as the protocol, so we can use pretty much any web server
out there.  Gedasymbols is the obvious candidate, and I can work with
whoever does this task to install any needed server-side logic.

Someone needs to build a test library where the symbols have symbolic
pin names, and the metadata maps those to physical pins in footprints.
I suggest using the transistor problem as a basis for this library.
Gnetlist will need to be modified to apply the mappings, although for
this first step, there's no need to include pin or gate swapping
information.

Gschem and pcb need a way to swap variants on symbols and footprints,
for example, switching between resistor-1 and resistor-2, or RESC1608N
and RESC1608M.  This depends on the metadata being available (above).

Modify gschem's symbol chooser to allow filtering based on attributes
within the symbol, not just the symbol name.



I think it would be better if, at this point, people choose tasks and
develop a quick prototype to (1) see if it works, (2) provide a basis
for comparison against other potential solutions.  Less talkie, more
typie!  ;-)

Send a reply letting us know what you're working on, to make sure
nothing gets left out.  It's OK (in fact desirable) to have multiple
people working on different solutions to the same tasks, so don't
worry if someone else took your favorite.


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user