On Fri, Nov 01, 2013 at 01:22:12AM +0100, Tomasz Wlostowski wrote:
application. IMHO a fixed enum type is probably not the best solution
here...
Yes, I have seen that, there functions/macro to generate them
(offsetting the value IIRC). Maybe the best way to handle it would be
a different type
Modedit and Modview have a strange behavior when the main canvas is redrawn.
Something is drawn in the upper left corner of the screen (i.e. form the
center of the main canvas to the left corner of the main window client area.
Could be related to the fact the logical origin and therefore the draw
Thank you for the report, I am going to fix it now.
Regards,
Orson
On 11/01/2013 12:10 PM, jp charras wrote:
Modedit and Modview have a strange behavior when the main canvas is redrawn.
Something is drawn in the upper left corner of the screen (i.e. form the
center of the main canvas to the
OK, I'm trying to follow the road to isolate GAL layers and pcbnew
layers. Let's see if it can work:
- pcbnew still uses LAYER_NUM (for layers) and PCB_VISIBLE (for other
stuff)
- GAL *doesn't* use LAYER_NUM, because a) it wouldn't work anyway with
eeschema in future and b) it extends the
Le 01/11/2013 13:16, Maciej Sumiński a écrit :
On 11/01/2013 12:10 PM, jp charras wrote:
Modedit and Modview have a strange behavior when the main canvas is
redrawn.
Something is drawn in the upper left corner of the screen (i.e. form the
center of the main canvas to the left corner of the
On 11/01/2013 01:50 PM, jp charras wrote:
Le 01/11/2013 13:16, Maciej Sumiński a écrit :
On 11/01/2013 12:10 PM, jp charras wrote:
Modedit and Modview have a strange behavior when the main canvas is
redrawn.
Something is drawn in the upper left corner of the screen (i.e. form the
center of the
On 11/01/2013 01:48 PM, Lorenzo Marcantonio wrote:
OK, I'm trying to follow the road to isolate GAL layers and pcbnew
layers. Let's see if it can work:
- pcbnew still uses LAYER_NUM (for layers) and PCB_VISIBLE (for other
stuff)
- GAL *doesn't* use LAYER_NUM, because a) it wouldn't work
On Fri, Nov 01, 2013 at 03:28:03PM +0100, Maciej Sumiński wrote:
Seems quite interesting. As far I understand - you have already introduced
the changes? If yes - may I have a look at them?
I was also considering using classes for storing layers information (name,
visiblity, rendering order,
Another thing that's not clear to me in the GAL mechanism.
VIEW::draw, if I got correctly the algorithm should go like this:
- Ask the view for the needed GAL_LAYER_NUMs
- Depth sort them for cairo (and probably for correct GL blending)
- For each layer in sorted order
- Set the Z depth
-
To make it easier to follow the drawing routines, it is good to go in
that order:
common/drawpanel_gal.cpp:119 (onPaint()) - OnPaint event handler
common/view/view.cpp:766 (Redraw()) - Chooses the area that has to be
redrawn
common/view/view.cpp:591 (redrawRect()) - Iterates through layers
On Fri, Nov 01, 2013 at 05:35:10PM +0100, Maciej Sumiński wrote:
Groups are handled by rendering backends and are identified only by their
number (think of it as a handle) and there is a 1-to-1 relation between
group id and VIEW_ITEM/layer combination.
That makes suspiciously easy to use
Wayne,
I enabled an experimental feature when USE_FP_LIB_TABLE is in play.
If you pass a nickname-less (nickname is blank) FPID from eeschema FOOTPRINT
field through
netlist into pcbnew, there is a compile flag to take that incomplete FPID and
do a
sequential search through all nicknames for
On 11/1/2013 8:42 PM, Dick Hollenbeck wrote:
Wayne,
I enabled an experimental feature when USE_FP_LIB_TABLE is in play.
If you pass a nickname-less (nickname is blank) FPID from eeschema FOOTPRINT
field through
netlist into pcbnew, there is a compile flag to take that incomplete FPID
Sent from my Galaxy S®III
Original message
From: Wayne Stambaugh stambau...@verizon.net
Date: 11/01/2013 8:44 PM (GMT-06:00)
To: kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] netlist reading of nickname-less fpids.
On 11/1/2013 8:42 PM, Dick
I think it's a good idea. This will be better than nothing once the
search path stuff gets removed (at least for Pcbnew and CvPcb, yeah!!!).
It still could lead to incorrect footprint selection in the case where
there are footprints with the same name in multiple libraries. I don't
think
http://www.eevblog.com/forum/open-source-kicad-geda/seriously-irritated-with-the-library-editor!/
I intend to spend some time on this.
The most important sentence to me in the whole thread is this one:
A lot of confusion would disappear if the part placement tool in the schematic
editor
16 matches
Mail list logo
