gattrib awkwardly flails when confronted with duplicate attributes

[Joe Eli Mcilvain]

I discovered this behavior when working on a patch for these duplicate bugs:
https://bugs.launchpad.net/geda/+bug/698575
https://bugs.launchpad.net/geda/+bug/698608

Basically, gattrib uses different rules for dealing with "duplicate" attributes (attributes with the same name, but not necessarily the same value) depending on what operation it's doing. The result is very buggy, and can even corrupt your schematic files if you are somehow relying on duplicate attributes. I'm not sure why you would want to have duplicate attributes, gschem seems to support them just fine, so I'm inclined to say that I should revise a lot of the gattrib code to handle them properly. I'm willing to put the time in for fixing this, but I want input from somebody in authority on this project about what the expected behavior should be.

Here's a summary of what I've found the current behavior to be:

When opening an existing schematic file, gattrib displays one column of data per attribute name, so duplicate attributes only get one column no matter how many of the duplicate attributes exist. The value in this column for each component is taken from the last attribute with the duplicitous name (in the order they are listed in the gschem multiattrib window). However, if I edit this value and save the file, the first attribute with the duplicitous name is the one overwritten.

For example, I created a schematic with a few symbols on it, one of which had three extra attributes that were {bovine=cow, bovine=gnu, bovine=alex}. Opening this file in gattrib gave me "alex" in the "bovine" column. I changed this value to "alisdair", and saved the file. Opening this file in gschem gave me {bovine=alisdair, bovine=gnu, bovine=alex} as the attributes for that device.

As another problem, if I try to create a new column in gattrib with the same name as an existing column, a new column and header is created at the end of table with the same name as the last column, rather than a duplicate column created with the name I asked for. I imagine this is because it doesn't want to duplicate an existing column header, but still has another column to make and just uses the last string in the header string list because it has nothing else to use after it.

Of course, if you try to save and reopen this file with duplicate columns, even more ridiculousness ensues.

So, the question is: how do we want gattrib to handle duplicate attributes? Just tell me and I'm happy to write the code.

[KaiMartin (kmk-familieknaak)]

I don't have any use for an attribute having more than one value. This topic has been discussed on the mailing list about a year a go. IIRC, the only use case that popped up was multiple source attributes in a sub sheet symbol. And even then I am not quite sure what the legitimite reason for it is. gschem can handle more than one source attribute, but just barely. E.g. on "hierarchy->down_symbol" it just inadvertedly enters the schematic the last attribute refers to. Both schematics get added to the page manager, though.

If such a two value situation appears, I'd be happy to receive a warning with the option to return to gschem so I can correct the error. It is most likely a symptom of one of two common failures:

a) I managed to attach the same refdes to two symbols which should not refer to the same component.

b) A set of symbols which refer to the same component contains more than one instance of an attribute and their value was set to conflicting values. This may happen for the footprint attribute of slotted symbols.

---<)kaimartin(>---