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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user