On Saturday 17 January 2009 15:56:03 Ales Hvezda wrote:
> [snip]
>
> >gEDA currently allows symbols or pictures to be embedded in a
> >schematic. However, the current embedding system requires the full
> >data to be embedded for each instance of an embedded item.
> >
> >This has a number of shortcomings:
> >
> >1. It bloats filesize by requiring multiple redundant copies of the same
> > data.
> >
> >2. It makes updating embedded symbols a hassle, especially if you
> > accidentally miss one copy of a particular symbol.
> >
> >3. It is limited in terms of the filetypes that can be
> > embedded. Although I can't currently think of any reason to embed
> > file types other than images, symbols or (possibly) schematics, one
> > might crop up in the future.
> >
> >I propose that a schematic or symbol file explicitly embed each embedded
> >file once only, to then be referred to each time a component or picture
> >object instantiates that file.
>
> 1. Disk space is cheap and it is currently really obvious how things are
> being stored.
>
> 2. Updating symbols is not that hard (select everything and update). Plus
> gschlas can probably be modified to provide functionality update all
> components in the specified schematics. However, what happens if a
> user does want N different versions of the same symbol embedded?
Quite a lot of people have requested being able to edit embedded
symbols "in-place", and on "closing" them (e.g. by up-hierarchy), to update
the instances in the top-level schematic.
Supposing we *already have* a memory buffer containing the embedded symbol (as
we would with this scheme) then to "open" the symbol we could:
1. Generate a PAGE with special flags indicating that it's embedded in another
PAGE (we don't have a way of doing yet).
2. Call the existing function for loading a PAGE from a buffer (which I wrote
in my symbol library re-write).
I can't think of a practical way of achieving this without changing the
embedding mechanism as described.
How would we "save" it? With the new embedding approach, we can:
1. Save the PAGE to a memory buffer, and copy it into the store of embedded
files.
2. Call the "resolve components" function (see my spec).
... and it really is that simple, and results in all the embedded instances
being updated in one swoop.
Another thing this enables: because we now have an easy-to-get-at list of
embedded files, we can "catch" attempts to insert a library component with
the same name as an embedded component, and offer the user some options for
resolving the conflict.
Finally, *if* someone wanted the option to embed all symbols by default, this
makes it much easier to enable that behaviour for them.
Convinced yet? Of course, as you both quite rightly point out, we *could*
implement the features I've just described using the current embedding syntax
and a pile of hacks. :)
Peter
--
Peter Brett
Electronic Systems Engineer
Integral Informatics Ltd
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ geda-user mailing list geda-user@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-user