On Tuesday 26 June 2007 00:10:36 John Doty wrote:
(By the way, I do subscribe to geda-user, I just don't post here very often!)
Warning: really long e-mail ahead:
> 1. When I make a change in a symbol, I most often want that change to
> propagate to *all* instances of that symbol in a project. A
> collection of project symbols makes this easy: Hs takes me into the
> symbol, where I can make any change I want.
However, currently when you save the symbol the changes *do not* automatically
propagate to all the currently open schematics.
> 2. Once I start on a project, I want my symbols under the project's
> revision control, not gEDA's, so that nobody can break my project by
> "fixing" a symbol.
>
> It seems to me that your approach could be accommodated by fixing Hs
> so that it can go down into an embedded symbol. Embed your symbol,
> edit it as you please. No incompatible changes required to the software.
This is needed anyway for going down into library symbols which do not have an
immediate on-disk representation (e.g. symbols generated by a Scheme-based
component-library backend).
However, this is not so simple as you make it sound. Currently, there are
many places where gschem makes the assumption that a view is associated with
a file on disk. Secondly, there are a number of issues to resolve:
- How should gschem decide which symbols in the original schematic to update?
- How would updating work?
- How would you keep all of the symbols in your multiple-schematic project in
sync?
While I agree that it would be nice to edit an embedded symbol, there are
major technical hurdles to overcome. Embedded symbols are implemented in a
rather "brute force" fashion currently. Only recently was I able to
eliminate checks for "EMBEDDED" in the symbol name (except for in the file IO
code).
The "Right Thing", I believe, would be for symbols to be embedded _separately_
from the symbols _instances_. So if you have 80 resistors in your schematic,
there would be one copy of the resistor symbol in the file, and when the
system looks for a "RESISTOR" symbol it'll use the embedded version
preferentially to the library version.
Edit->Update would then automatically update _all_ instances of the symbol,
meaning that you won't miss one.
However, this requires a file-format change.
> On the other hand, what *I'd* really like is explicit support for the
> "project symbol library" concept. Specify it in gafrc. When you place
> a symbol from the regular library, a copy should be automagically
> placed in the project library. Symbols in the project library should
> have priority without "duplicate symbol" warnings. The project
> library should be first in the component dialog's list.
This is not likely to happen before the 1.3 unstable series, despite my
extensive changes planned for 1.1. However, before I dwell on the exactly
why, I'd like to explain what I've got up my sleeve for 1.1.
- I've already added the ability to add symbols generated by Scheme commands
or other programs. I'm going to create some sort of system which allows
gschem to transparently populate its component library from
gedasymbols.org -- because all you'll need to publish a component library
online will be an HTTP server. *vague hand-waving*.
- I'm going to make the component selector tabbed; the "Libraries" tab will
show something like the current view, and a new "Existing" tab will show a
list of all non-embedded symbols used in schematics which are currently
open. (If I can fix the component selector dialog, perhaps I can refine it
to the current schematic only, and iff the file-format bump happens, I can
include the current schematic's embedded symbols). The "Existing" tab will
be the default unless there are no symbols yet in use.
- I'm going to add symbol categorisation, so there is more fine-grained
control over symbol selection than just which component library they're
from. However, at least initially all symbols in a directory-based
component library will have to be in the same category; only command- and
Scheme-based libraries will be able to take full advantage of the system
until I devise some sort of library index file. You'll be able to switch
between viewing by category and viewing by library.
So why won't per-project component libraries happen soon? Basically, gEDA has
no _concept_ of a project. There is no distinction made between
configuration variables set by the system rc files, the personal rc files, or
the project rc files. All configuration variables are stored in one of two
places: static variables in libgeda, or as members of the singleton TOPLEVEL
structure. This includes the list of current libraries.
As an example of this (works in any version of gschem):
1. Create two directories, a/ & b/.
2. Create a blank schematic "test.sch" in each.
3. Create a "gafrc" file in b/ containing the expression
"(reset-component-library)".
4. Run gschem. Open a/test.sch. Verify that component libraries are
available as usual.
5. Load b/test.sch. Observe that for _both_ schematics the component
library is now empty.
In fact, as an example of extreme bugginess, just _previewing_ b/test.sch
causes the component library to be reset! _All_ configuration variables are
affected by this, and there needs to be extensive changes made to the gEDA
configuration mechanism in order to make per-project, per-user and default
system settings have contextual separation.
There are some other ancillary problems as well, but that's the major one.[1]
For the time being (and for the foreseeable near future) the best bet is to
have a component directory specific to the project and to make it the only
library loaded by the project gafrc file. In addition, it's wise to load
separate copies of gschem to edit files from different projects.
I hope that clarifies things.
Regards,
Peter
[1] Someone is bound to suggest a hack fix. The problem with hacks is that
with the best will in the world to fix them properly when you have some
time, is that you never have some time.
--
Fisher Society http://tinyurl.com/o39w2
CU Small-Bore Club http://tinyurl.com/mwrc9
09f911029d74e35bd84156c5635688c0 peter-b.co.uk
Attachment:
pgpr8gHTKEVOy.pgp
Description: PGP signature
_______________________________________________ geda-user mailing list geda-user@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-user