I really don't want any *major* changes to the core workflow and UI TBH. The changes that would make this a more complete tool (for me anyway) are: PCB: - better control over polygons. Ie better awareness/ability to tie to nets, built in crosshatching (intstead of solid), and an option to hide all polygons without having to put them on a separate layer (this messes with DRC) (thin draw poly is cool though!) - footprints: native text capability, polygons, manual solder-mask, manual paste mask - A manual paste layer - Not sure about how to describe this, but I think it comes under the back-annotation editing of symbols... PCB is a little thin on the ground when it comes to editing elements on the fly (can you even edit text from the gui once placed?) gschem: not too many changes as I see it... - A footprint viewer - when selecting/setting a footprint it would be nice to have a preview (this could most likely be done as some sort of plugin) - A more complete channelisation/subcircuit/bus concept - basically just tie buses and subcircuits together (i think I may try and do this myself - i've asked about it before and got some useful feedback) Light vs heavy I think this has all been said but *my* summary is * you can never have *all* the heavy symbols - and chances are most of your heavy symbols will be useful as is to less than half gEDAs users. * purely light symbols leave beginners wondering why their projects don't compile out of the box solution (as discussed) - set up a default beginner/base library with a subset of the most commonly used components (defined by how much time and effort people are prepared to put in I guess) that is shipped - don't do anything to over complicate the heavyfication process - as it stands is fine :) I think tying gschem and pcb together more closely is a separate task - DJs database. I've been thinking of attempting to do this myself for some time - i'm as far along as writing a base schema to capture the core information... A functional component can take on many forms - the alignment of function to pin and whether the function is available is interdependent with the choice of footprint, functions can be remapped amongst pins (look at most ARM chips). Ideally one should be able to define a functional requirement in the schematic, swapping which pin provides said function in the final layout shouldn't be a major chore. I don't think this is an improvement that needs to be made in gschem - gschem is for schematic capture, which it does fine. Parts/symbol/component management is a separate task, so long as gschem doesn't hinder this process great - if it can include some plugins to make the task better integrated (such as a footprint preview) even better. A tool like gschem shouldn't be tied up trying to define and handle all variations of what any given person thinks makes up a symbol. It already has the capability to have arbitrary text attributes - that's enough. Just link the gschem symbol to the database/tool (separate program) that handles the various symbol permutations via a unique ID of some description or other... Anyway - the database idea has been looked at before, and from memory even implemented somewhat; so its nothing new. Geoff (If anyone is interested in the schema I've started [1]http://nixotic.com/partsdb.png)
References 1. http://nixotic.com/partsdb.png
_______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
