On Jan 9, 2009, at 10:48 AM, Peter Clifton wrote: > On Fri, 2009-01-09 at 10:36 -0700, John Doty wrote: >> On Jan 8, 2009, at 10:30 PM, al davis wrote: >> >>> On Friday 09 January 2009, Paul Tan wrote: >>>> I do raise concern if changes are imposed to >>>> constrain gEDA flexible architecture unnecessarily. >>> >>> Don't worry about it. None of the key developers would tolerate >>> any reduction in flexibility. If anything, it will become more >>> flexible. >> >> Well, that's their goal. But, there's a tendency to be scenario- >> oriented that causes gEDA to become more rigid, at least "out of the >> box", as it evolves. > > Yes, we are focusing on common use-cases,
What's common? To me, it's common to want to change all the opamp footprints to something smaller. This is tedious with the current defaults. I bet a lot of users "draw first, fix component details later". Promoting the wrong details over and over and over gets in the way of the fix. > and an out of the box install > which works well for those is what we should be trying to achieve. It seems to me you're making it easy for the user to create a trap: a project where trivial modification (like changing an opamp footprint) requires substantial manual work (you have to track down every instance). > If > that doesn't fit your flow, sorry - you'll need to keep some locally > modified config files. That isn't a big burden for a technical user. The burden is when the defaults change in some way that's not immediately obvious. I eventually figured out that (always-promote- attributes "") was necessary. But it took awhile. > >> I just spent a couple of hours tracking down attributes that should >> never have been "promoted". Apparently, I drew some schematics after >> the defaults changed and didn't fix the gafrc to do what I think is >> the right thing. Getting rid of unwanted invisible attributes in a >> dense schematic is a pain. > >> Having things like footprints in the schematic is generally an >> unnecessary barrier to schematic reuse between projects. To me, >> footprints usually belong in the symbol: I'm not going to mix >> footprints between instances of the same component in a given >> project! > > I guess its a shame we don't embed a cached copy (or checksum) of the > symbol on-disk in the schematic page. That way it would be possible > for > you to change the symbol on disk and run a scan for places which were > affected by the change. Please no. There should be only one copy of the symbol *PER PROJECT*. Generally, most attributes should be in that copy. Then, if you want a project- wide change, Hs, edit, and the per-project global attribute has been fixed. Quick and simple. No "scanning" or other confusion. No extra "databases" or other distractions. "Hs" is the tool. Make that useful (it's not out of the box: you can't edit distributed symbols, usually) at a *project* scale (not just one instance). John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [email protected] _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
