Background: we have propedit and attribute edit. You can access attributes 
from the property editor as well, but in cschem attributes are central in 
the data model with all sort of complicated machinery operating on them. 
Plus attributes can be scalar or array, and array edit didn't fit well in 
the property editor concept.

Reminder: we have a concrete model, the drawing (or data) you are directly 
editing. Then we have an abstract model that a compiler is going to 
produce (in a few months). The abstract model is what cschem thinks your 
drawing/data really means. Then we have export plugins (e.g. netlisters) 
working from the abstract model, generating whatever output needed for a 
workflow. You can't directly edit the abstract model, you can edit it 
indirectly by changing things in the concrete model that's the source for 
the abstract model.

So the splitup is like this:

- the property editor is where you have full access to properties (e.g. 
circle radius, stroke pens, floater flags, etc), and limited access to 
scalar concrete attributes so you can easily change the name ("refdes") 
attribute for example; you can mass-edit multiple objects

- the attribute editor is where you have full access to attributes, all 
details included, result in the abstract model also shown (later); you can 
edit only one object at a time in an attribute window

Easiest way to test the things below is loading the attached sheet, which 
features an opamp symbol.

All operations are undoable, please always test undo.

Please test the following:


1. attribute editor invocaton

You can get to the attribute editor multiple ways:

- right click over a concrete object, context menu, attribute editor

- {a a} over an object (I think this will be the most common way in 
practice)

- the property editor has a new cross-link button too, if it is editing 
a single object (the button is not available when your property editor is 
editing multiple objects, e.g. the selection)

- the AttributeDialog action (works over an object)

The left side of the dialog is where you can edit the attributes of the 
concrete group. Only groups have attributes. Symbols and terminals are 
groups. The right side is for the abstract model, will be done later.



2. Editing scalars

On the bottom half you can change the key, value and priority. The default 
user attribute priority is 250, you normally don't need to change that.
After editing, you need to press enter or click on the 'set' button.

Attributes that have special meaning in the core data model are marked 
with '*' in the second column.



3. Creating/deleting attributes

You can use the New and Del buttons for this. 




4. The floater button

Unlike in gschem, in the cschem data model attributes do not automatically 
imply any visible drawing objects. Our data model is more similar to 
pcb-rnd's: if you want an attribute printed, you need to place a text 
object, mark it dyntext and write a template that tells which attribute(s) 
it should print.

To make the common case easy, there's a floater button under the attribute 
list. Select a scalar attribute and click on the floater button: it will 
automatically create a dyntext+floater text object with the selected 
attribute in template. This is how you can "make an attribute visible". 
"Making it invisible" is simply removing the text object from the drawing.

Note: you can make multiple floaters for the same attribute, that's not a 
bug.



5. Array attributes: convert and edit

Select one of the auxiliary attributes, like sym-license-dist, and click 
on the "convert to array". The scalar attribute is converted into an array 
with a single element. The bottom side editor changes and you can now 
manipulate array values. Since order of elements in an array matters, you 
have buttons for moving the selected item up or down.

You can convert back to scalar, but note: there is no round-trip between 
scalar and array. We have array type attributes exactly because we do not 
want to try to store and manage arrays/lists in single string scalar 
attributes! So the code, by design, will not make any attempt to parse a 
scalar attribute into a multi-element array.


6. closing words

If the attribute dialog looks a bit complex and scary, don't worry: this 
is only how you will have full access to things. But there will be a few 
shorthands to common attributes, attribute-specific assisted/quick edit 
dialogs. So in normal daily use, when you want to set "refdes" or make 
connections with attributes you won't need to deal with every single 
detail, attribute priorities, abstract models, etc. 

But this will be the subject of another batch of test requests.