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
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
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
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
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
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
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
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,
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
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,
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,
11 matches
Mail list logo
