Hi Stuart (and all),

Trying to catch up on my e-mail here... (still way behind)


>I am currently combing through the libgeda and gnetlist code, trying
>to figure out how it works so that I can learn enough about gEDA's
>data structures to hack together "gattrib".   If I have it figure out,
>it looks to me like attributes are found starting from TOPLEVEL in the
>following way: 
>
>(TOPLEVEL pr_current)->(PAGE p_current)->(OBJECT o_current)->attribs->object->
>text->string
>                                                      |                 |     
>        |
>                                                      V                 V     
>        V
>                                              graphical object  type=OBJ_TEXT  
>   name=value
>                                              on current page
>                                              can be component,
>                                              net, or any other
>                                              graphical object.
>
>My questions:
>
>1.  Is this correct?  

        Yes it is correct.  Just to clarify further: 
(TOPLEVEL pr_current)->(PAGE p_current)->(OBJECT object_head) can point to 
a text item.  And the moment that item takes the form of name=value, then 
it is considered an attribute.  

        An o_current's attribs pointer which points to a linked list
of st_attrib objects which point to (via object) to the attached
attributes for o_current.  Maybe a few more pictures will help:

A schematic consists of lots of objects which are stored in:
(TOPLEVEL pr_current)->(PAGE p_current)->(OBJECT object_head)

These objects can be boxes, components, lines, nets, AND text items (which
themselves can be attributes.

So, here's an example:

(TOPLEVEL pr_current)->
        (PAGE p_current)->
        (OBJECT object_head)->  (points to a head obj which should be ignored)
#1.     (OBJECT next)->         (points to a component, say a 7400)
#2.     (OBJECT next)->         (points to a text object, say "refdes=U?")
        
        Now, #2. (refdes=...) is attached to #1. and this is done via the
attribs pointer.

...
1.      (OBJECT next)->attribs->next->object-> points to #2.  And by doing this,
this text item is considered a attached attribute of #1.

Also, in #2. object (the text item) there is an attached_to pointer
which points to the parent's object's attrib structure (the one that is 
point to the text item in the first place).  If you traverse this 
list (attrib) all the way to the head node, there the object pointer
points to the object which owns the attributes.  This allows attached
attributes (like #2) to eventually figure out who owns them.

You had it right.


>
>2.  Why are the attribs handled this way, instead, say, of having
>attribs just be a linked list of text attached to those objects with
>attributes?  

        The main reason I did this was so that I could treat attached 
text items as first class objects without having to make second class
objects buried inside of a link list inside of a OBJECT data structure.
Effectively I have create this link list, it just happens to point up
instead of contain the actual objects themselves.

        The real reason this is all so complicated is because when 
I started gschem, glib was just starting to appear and if I had just
waited about a year, I would have use glists exclusively. 

>
>3.  In particular, what purpose does the attribs->object reference
>serve?  What info does the second object hold?

        It points to the list of text items which are attached to this 
object.  The text items are at the same level as the components (this
only applies to attributes which are attached to the components;
attributes inside the component are not stored inside of the component's
attribs pointer).

        Don't forget that attrib-> points to a head node.  This head
node is really a place holder.  attrib->next is the first attached
attribute.  attrib->object (in the head node) points to the object to
which the attributes are attached.


>
>Thanks for any and all helpful answers!  I am new to dealing with complex
>data structures like these, and I don't know all the "hows and whys".


        Yeah and I don't think my answers above really make sense. 

What specificly are you doing?, maybe I can provide some sample code
to make your life easier.  I can make things crystal clear (I hope)
by writing more code... (really, clear code, unlike the current code in
libgeda. :-)  I have a whole slew of helper functions for finding 
attributes based on certain criteria, maybe one of those will help.

                                                                -Ales

PS. You may now understand my desire to rewrite gaf to create something
    more sane.

Reply via email to