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

[gedau@xxxxxxxxxxxxx]

On Mon, Jan 17, 2011 at 10:26:58AM +0000, Peter TB Brett wrote:
> 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

Maybe I oversimplify it, but I still suggesting having UUIDs. Long 
random numbers, like 256 bits, stored in hex. Whenever a new object 
appears, generate a new one. Whenever an object is transformed, keep the 
UUID. When saving, order objects numerically by UUID (within each level, 
if the save file is not flat). 

Some corner cases:
- UUID wouldn't be used for anything else than keep order, so in the 
  extreme case someone deletes something and adds something else and the 
  new object happens to get the same UUID, that only means it will  
  really be at the same place in the file
- if two persons editing the same file and there are only a small amount 
  of objects, both adding a new object, the probability of having the 
  new object in between the same existing object is higher, in this case 
  some version control systems may handle it as a conflict. With large 
  enough files the probability is lower, and in any case, it is probably 
  better than not having anything.
- if two developers add new objects independently and they happen to get 
  the same UUID against all reasonable odds, well, then the file will 
  contain the same UUID twice after merge. This is a real problem, as if 
  they both change one UUID to random on load, that will be a new 
  conflict the next time they exchange the file. Provided UUIDs are long 
  enough this would probably happen less freuqently than having 2 usres 
  adding new objects to the same file ending up modifying the same 
  section with the current solutions, if I get it right.

Regards,

Tibor



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