Re: gEDA-user: Solving the light/heavy symbol problem

[John Griessen <john@xxxxxxxxxxxxxx>]

On 05/24/2011 07:22 AM, DJ Delorie wrote:
> if it's layout-specific data, the copy in the layout is correct.
> Perhaps we need to keep track of whether the data in the layout and
> schematic originated in that file, or is the result of user changes
> elsewhere being imported.
>
> But any solution depends on (1) allowing data to originate from
> multiple places, and (2) sane rules for which "wins".

This is a concept I like and think it could be maintainable.
The sanity of the data-conflict-rules would come from simplicity,
so they don't grow to be high maintenance.   Call it
data-conflict-rules for resolving effects of two way
data flows between tools.

On 05/24/2011 07:37 AM, DJ Delorie wrote:
> Yup.  I had proposed using the pin*label*  as the identifier, not the
> pin*number*.  The label is "owned" by the schematic, but the number
> is "owned" by the partdb or layout.  That lets you, for example,
> change the package in layout without having to change the schematics
> first.

This will get involved with pin swapping as in FPGAs or other
programmable chips.  Each symbol for a pin function programmable
chip will have either a large number of variants or be able
to adapt pins with the standard positional numbering to have
any functional labeling.

I think pin swapping for layout purposes where identical functions
are swapped in groups, such as I2:NAND-in-1 and I2:NAND-out-1 swap
with another pair in same or another package should not involve
changing package labels, just changing the netlist.  Otherwise my
head starts to twirl in confusion over how to support it or
maintain the tool that does it.

IOW, my idea of pin swapping convenience would be a
plugin that calls for a new netlist to be made, perhaps
saving a history of netlists recently asked for, then loads that
new netlist, and maybe does some topology equivalence check.
That reasoning comes from the plugin's purpose being swapping
pins for better layout while preserving circuit function
and logic.

On 05/24/2011 02:04 PM, John Doty wrote:
>>   The GUI needs to*hide*  that, not replace it, making the
>> >  underlying data*seem*  integrated and easy to manage, when in fact it
>> >  is not.
> This is where we disagree. The GUI needs to make the data easy to manage,
> but at the same time it needs to*reveal*  its machinations.

I like the way of hiding from normal view, while keeping a log of commands used
such that the state of the document(s)/project would be the same if done by the
GUI or replaying the commands.  This is especially valuable in capturing flows
of work done first with the GUI, to turn them into scripted macro sections you
can do in other positions, or use as basis for a parameterized script.


John


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