On 5/1/2014 4:54 PM, Lorenzo Marcantonio wrote:
On Thu, May 01, 2014 at 04:05:09PM -0400, Wayne Stambaugh wrote:
My preference is 50mils but no matter what field text size you choose,
please revise all of the existing symbols accordingly. As of right now,
symbol field text sizes are all over
I've seen the notice in the base class and dug around. More than
intermediate values it seems that the only thing get modified around is
the 'selected corner' in ZONE_CONTAINER. It works like a 'last
picked' corner for the zone object (and also as a 'current corner' for
some operations).
Wouldn't
02/05/14 16:06, Lorenzo Marcantonio kirjoitti:
On Fri, May 02, 2014 at 07:54:24AM -0400, Wayne Stambaugh wrote:
My primary concern is consistency. I am less concerned about the actual
text size. As of right now, there is no consistency that I can see in
the symbol libraries.
I haven't
02/05/14 18:41, Vesa Solonen kirjoitti:
To make things a bit easier and avoid duplicate work my proposal is to
make a meta library that gets scripted to current library format. The
script pulls in the relevant graphic symbol and builds the alias list,
pin names/numbers and package options if
On 05/02/2014 03:43 PM, Lorenzo Marcantonio wrote:
(...)
I think the design issue is that the zone has the selected part as an
internal state, but I reckon that would be very difficult to fix (I have
no better place to store it, at the moment, especially during edit): the
problem is that a zone
On Fri, May 02, 2014 at 07:54:19PM +0200, Tomasz Wlostowski wrote:
I'm not sure if I understand your point... Our approach is to take a copy
of the edited item, modify it and replace the old item in the model with the
modified one. No in-place modifications keeping tool states in the model.
6 matches
Mail list logo
