Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]
On Tue, 2011-01-18 at 13:03 +, Peter Clifton wrote: > On Tue, 2011-01-18 at 10:00 +0900, John Doty wrote: > (Goes to file a feature request about that now). https://bugs.launchpad.net/geda/+bug/704407 -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]
On Tue, 2011-01-18 at 10:00 +0900, John Doty wrote: > OK, that's a good point. But there's no easy way to control this in > gschem. Is it a "feature", or merely accident? Should there be "pull > forward" and "push backward" commands? It is half and half. It became more useful with the addition of filled paths, and as you suggest - we ought to introduce some user control over the z-order. (Goes to file a feature request about that now). -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]
On Tuesday 18 January 2011 01:00:32 John Doty wrote: > > Example: Create square with solid background. Create smaller circle > > with hashed background, set to a different colour. Move circle on > > top of square. Obviously, if z-order is not preserved through save > > and load, this will be rendered incorrectly. See attached > > schematic. > > OK, that's a good point. But there's no easy way to control this in > gschem. Is it a "feature", or merely accident? Should there be "pull > forward" and "push backward" commands? Yes, along with "to back" and "to front" commands. These are missing features, just like path drawing commands. To me, this is one of those capabilities that's totally utterly useless 99.9% of the time, but can't-finish-drawing-without-it the other 0.1%. If an alternative and obviously-superior algorithm for choosing drawing order was suggested, it wouldn't be a big deal to me. Peter -- Peter Brett Remote Sensing Research Group Surrey Space Centre signature.asc Description: This is a digitally signed message part. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]
On Jan 17, 2011, at 9:26 PM, Peter TB Brett wrote: > On Monday 17 Jan 2011 11:07:16 John Doty wrote: > 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. >> >> But the draw order doesn't matter unless you're using an old-fashioned >> mechanical plotter. In any case, in gschem, merely cutting something and >> pasting it back in the same place changes the order, but this is rarely >> significant. > > For someone who is very defensive of features that you see as important, you > are very quick to propose that those you don't care about are removed, aren't > you? Nobody understands all use cases of the toolkit. Certainly not me. I fell into the trap here, yes. Mea culpa. > > Example: Create square with solid background. Create smaller circle with > hashed background, set to a different colour. Move circle on top of square. > Obviously, if z-order is not preserved through save and load, this will be > rendered incorrectly. See attached schematic. OK, that's a good point. But there's no easy way to control this in gschem. Is it a "feature", or merely accident? Should there be "pull forward" and "push backward" commands? John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]
On Monday 17 Jan 2011 12:17:50 Karl Hammar wrote: > Tibor: > ... > > > 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). > > ... > > Thoose UUID might not be what a person that edit thoose files by hand > wants. Yes, it's often useful that the file-format makes it trivial to copy and paste bits of schematic around. I like it. Peter -- Peter Brett Remote Sensing Research Group Surrey Space Centre ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]
On Monday 17 Jan 2011 11:07:16 John Doty wrote: > >> 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. > > But the draw order doesn't matter unless you're using an old-fashioned > mechanical plotter. In any case, in gschem, merely cutting something and > pasting it back in the same place changes the order, but this is rarely > significant. For someone who is very defensive of features that you see as important, you are very quick to propose that those you don't care about are removed, aren't you? Example: Create square with solid background. Create smaller circle with hashed background, set to a different colour. Move circle on top of square. Obviously, if z-order is not preserved through save and load, this will be rendered incorrectly. See attached schematic. Peter -- Peter Brett Remote Sensing Research Group Surrey Space Centre v 20110116 2 C 4 4 0 0 0 title-B.sym B 44500 48500 1000 1000 3 0 0 0 -1 -1 1 -1 -1 -1 -1 -1 V 45000 49000 500 8 0 0 0 -1 -1 2 1 0 200 90 200 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]
Tibor: ... > 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). ... Thoose UUID might not be what a person that edit thoose files by hand wants. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]
John Doty: > On Jan 17, 2011, at 7:26 PM, Peter TB Brett wrote: > > On Monday 17 Jan 2011 08:58:18 John Doty wrote: ... > >> 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. > But the draw order doesn't matter unless you're using an > old-fashioned mechanical plotter. In any case, in gschem, > merely cutting something and pasting it back in the same place > changes the order, but this is rarely significant. It matters for the program diff and hence the version system. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]
On Mon, Jan 17, 2011 at 10:26:58AM +, 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
Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]
On Jan 17, 2011, at 7:26 PM, 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. It's two levels without embedded symbols (objects, attached attributes). In any case, the sorting must happen separately at each level. > >> 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. But the draw order doesn't matter unless you're using an old-fashioned mechanical plotter. In any case, in gschem, merely cutting something and pasting it back in the same place changes the order, but this is rarely significant. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
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 -- Peter Brett Remote Sensing Research Group Surrey Space Centre ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
