[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]

On Monday 17 Jan 2011 08:58:18 John Doty wrote:
> On Jan 17, 2011, at 5:41 PM, Peter TB Brett wrote:
> > Due to the way the gschem editing model works, and particularly the undo
> > system, stuff tends to get shifted to the end of the file when edited.
> > This is something that I've made a few improvements to in the past, but
> > fundamentally the problem hasn't gone away.
> >
> > This is actually an extremely difficult problem to solve.  Saving a file
> > could be considered as mapping a three-dimensional space (x position, y
> > position, z-index) onto a one-dimensional space (file position).  At the
> > moment, the file position is mapped 1:1 to z-index, i.e. last-on-top.
> > Other possibilities (assuming that an alternative way of indicating z-
> > ordering can be found) include defining a Hilbert-Peano curve on the x-y
> > schematic plane and mapping position along that curve to file position.
> >
> > There is no easy fix here.
> When it comes to gschem files, I believe there is a potentially useful
> compromise. The .sch file structure describes a tree.

No. The very shallow, wide nature of a .sch file's (at most, if symbols are 
embedded) two level structure means that it's much more meaningful to consider 
it as a list.

> At each level in this tree the order of the branches does not matter.

No. It does matter; the ordering indicates the draw order of primitives in any 
viewer or graphics exporter.  Arguably, it shouldn't, but if not, the file 
format needs to be amended to provide this information in another way.

> So, a canonical ordering of a .sch file just requires some sorting criterion.

Correct.  I suggested one in my previous e-mail.


Peter Brett <peter@xxxxxxxxxxxxx>
Remote Sensing Research Group
Surrey Space Centre

geda-user mailing list