Hi there,
The best way to inspect exposed functions at this moment is doing a:
import pcbnew
dir(pcbnew)
Also opening pcbnew.py at /usr/lib/python-2.7/site-packages/ something like
that, it really depends on your system..
I have some plans in a paper to build something to suck o
After long meditation my plan is this:
First idea (really good but has issues)
- Internal and names do not change (I myself am tired of
these renames)
- Default layer names for a board are the the internal ones
- In the layer setup the user can rename all the layers (the original
name is sh
On Thu, Apr 11, 2013 at 04:11:51PM -0500, Dick Hollenbeck wrote:
> No, I don't agree, since it is behind an interface and only accessors use it.
My question could be rephrased as: there is a need to put colours in the board
interface?
> Its the guy in the stair well walking on his hands, allowed
On Thu, Apr 11, 2013 at 04:17:15PM -0400, Wayne Stambaugh wrote:
> This isn't a bad thing unless the pointer to g_colorSettings changes.
> It hides the fact the color settings in Pcbnew are a global variable (it
> seems to me that they should be a member of PCB_EDIT_FRAME or one of the
> classes i
Awesome work, I must find some time to try putting all this together in OSX and
see how does it go, it seems that we will have more fun compiling, but if we're
lucky the wx overlay problems in OSX will be gone.
Miguel Angel Ajo
http://www.nbee.es (http://www.nbee.es/)
+34911407752
skype: ajoajoa
On 04/11/2013 03:17 PM, Wayne Stambaugh wrote:
> On 4/11/2013 2:26 PM, Lorenzo Marcantonio wrote:
>> I'm fixing #1167884 (pretty trivial) and I noticed a curious thing:
>>
>> BOARD has it's own m_colorsSettings, with accessors and simply
>> initialized with a pointer to the global g_colorsSetti
On 4/11/2013 2:26 PM, Lorenzo Marcantonio wrote:
> I'm fixing #1167884 (pretty trivial) and I noticed a curious thing:
>
> BOARD has it's own m_colorsSettings, with accessors and simply
> initialized with a pointer to the global g_colorsSettings. After that
> it's never changed.
This isn't a bad
You're welcome. I hope it solved it for you.
Thanks for your work on KiCad as it is getting easier and easier to work with
and to teach to beginners.
/Martijn
On Apr 11, 2013, at 6:54 PM, Dick Hollenbeck wrote:
> Thank you Martin.
>
> Sorry to involve the list with this, but it did concern t
The templates have nothing to do with the code base... in fact they
*depends* on the component library...
--
Lorenzo Marcantonio
Logos Srl
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsu
> Probably because nuveau drivers aren't very mature yet? An intel gpu
> simply cannot outperform a dedicated nvidia...
It's a very complicated issue and reasons are longwinded. Nouveau outperforms
Nvidia proprietary drivers sometimes, 2D for example. This time they
outperformed unmeasurably, be
I'm fixing #1167884 (pretty trivial) and I noticed a curious thing:
BOARD has it's own m_colorsSettings, with accessors and simply
initialized with a pointer to the global g_colorsSettings. After that
it's never changed.
Other stuff in pcbnew instead goes directly to the g_colorsSettings.
What i
On Thu, Apr 11, 2013 at 06:09:29PM +, Solonen Vesa wrote:
> > Tests will continue soon on Intel and older Ati hardware.
>
> Better performance on this HW than yesterdays Nvidia. PCBnew alternate
> renderer crashes silently.
Probably because nuveau drivers aren't very mature yet? An intel gpu
> Tests will continue soon on Intel and older Ati hardware.
Better performance on this HW than yesterdays Nvidia. PCBnew alternate renderer
crashes silently.
Renderer (glxinfo):
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Q35
OpenGL versio
Thank you Martin.
Sorry to involve the list with this, but it did concern the list in as
much as my postings will now be more intelligible, thanks to Martin.
Dick
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers
Le 11/04/2013 15:57, Dick Hollenbeck a écrit :
On 04/09/2013 01:01 PM, Dick Hollenbeck wrote:
On 04/09/2013 03:28 AM, Lorenzo Marcantonio wrote:
Found this in loadMODULE_TEXT:
if( layer < FIRST_LAYER )
layer = FIRST_LAYER;
else if( layer > LAST_NON_COPPER_LAYER )
la
On Thu, Apr 11, 2013 at 09:45:52AM -0500, Dick Hollenbeck wrote:
> Layer naming is fine as is. If someone commits a change to layer
> naming without first getting agreement from me, then I will revoke his
> commit privileges.
We're not talking about the 'internal' or 'default' layer names, we're
On 04/11/2013 09:18 AM, Lorenzo Marcantonio wrote:
> On Thu, Apr 11, 2013 at 09:01:33AM -0500, Dick Hollenbeck wrote:
>> I am happy using the same names in the UI that end up going into the
>> board file. Achieving familiarity with those names have value.
>
> Then rip out the whole renaming facil
I'm using this since a few days and I'm finding it useful. Here's the
patch (I don't want to commit it without some feedback, it's on the "for
me it works" quality/testing level)
It does two things:
1) Implements the 'lean on track' behaviour even for single segment and
free direction mode; it
On 4/11/2013 9:57 AM, Dick Hollenbeck wrote:
> On 04/09/2013 01:01 PM, Dick Hollenbeck wrote:
>> On 04/09/2013 03:28 AM, Lorenzo Marcantonio wrote:
>>> Found this in loadMODULE_TEXT:
>>>
>>> if( layer < FIRST_LAYER )
>>> layer = FIRST_LAYER;
>>> else if( layer > LAST_NON_COPPER_LAYE
On Thu, Apr 11, 2013 at 09:01:33AM -0500, Dick Hollenbeck wrote:
> I am happy using the same names in the UI that end up going into the
> board file. Achieving familiarity with those names have value.
Then rip out the whole renaming facility. Except for 'special' layer
(mask, silk, paste and edge
On 04/11/2013 09:11 AM, Lorenzo Marcantonio wrote:
> On Thu, Apr 11, 2013 at 08:57:24AM -0500, Dick Hollenbeck wrote:
>
>> If I can broaden this topic somewhat, this type of on the fly board
>> change (during loading) falls into a general category of "doctoring a
>> board during loading". Let's
On Thu, Apr 11, 2013 at 08:57:24AM -0500, Dick Hollenbeck wrote:
> If I can broaden this topic somewhat, this type of on the fly board
> change (during loading) falls into a general category of "doctoring a
> board during loading". Let's call it "board doctoring".
>
> Generally it makes me nerv
On 04/11/2013 08:28 AM, Fabrizio Tappero wrote:
> Here I am uniquely talking about UI layer names, names that appear in
> he various Kicad GUIs. Names used in the code do not really interest
> me, here.
>
> As originally discussed with Dick, here we are talking about replacing
> stuff like "Front"
On 04/09/2013 01:01 PM, Dick Hollenbeck wrote:
> On 04/09/2013 03:28 AM, Lorenzo Marcantonio wrote:
>> Found this in loadMODULE_TEXT:
>>
>> if( layer < FIRST_LAYER )
>> layer = FIRST_LAYER;
>> else if( layer > LAST_NON_COPPER_LAYER )
>> layer = LAST_NON_COPPER_LAYER;
>>
On 04/10/2013 09:44 AM, Lorenzo Marcantonio wrote:
> On Wed, Apr 10, 2013 at 09:25:15AM -0500, Dick Hollenbeck wrote:
>> Lorenzo,
>>
>> In the course of updating some translatable strings, I see you removed
>> some quotes around some of the non-filename values where I had
>> inserted them.
>>
>> Th
Here I am uniquely talking about UI layer names, names that appear in
he various Kicad GUIs. Names used in the code do not really interest
me, here.
As originally discussed with Dick, here we are talking about replacing
stuff like "Front" with "Top" and stuff like that.
Regards
Fabrizio
On Thu,
Dear all,
As you know, the BE-CO-HT section at CERN has been contributing to Kicad
for some time now. We see this involvement as a key part of our activities
regarding Open Source Hardware [1]. We are also contributing to the
adoption of VHDL and SystemVerilog in the Icarus Verilog simulator, so a
On Thu, Apr 11, 2013 at 08:49:38AM -0400, Wayne Stambaugh wrote:
> used when available. I don't think it would be a lot of work to make
> non-copper layers support user defined names.
That was more or less the core of what I meant. The only issue it the
module editor which lives on another world
On 4/11/2013 7:07 AM, Fabrizio Tappero wrote:
> Hello,
>
> Thank you guys for the lengthy answers.
>
> Silly question: does the content of the two previous e-mails mean that
> we cannot talk about changing these names?
Internally to the kicad_pcb file and the code that manipulates the
layers, th
On 4/11/2013 3:40 AM, Martijn Kuipers wrote:
> Hi Dick,
>
> Perhaps you already tried, but you have HTML formatting switched off, right?
> HTML setting in Thunderbird are notorious for missing spaces.
Interesting. Maybe that's why I've never seen this issue. I always set
up Thunderbird to compo
On Thu, Apr 11, 2013 at 01:07:28PM +0200, Fabrizio Tappero wrote:
> Thank you guys for the lengthy answers.
>
> Silly question: does the content of the two previous e-mails mean that
> we cannot talk about changing these names?
Especially for the default names, in short, yes, they will not be
cha
Hello,
Thank you guys for the lengthy answers.
Silly question: does the content of the two previous e-mails mean that
we cannot talk about changing these names?
Regards
Fabrizio
On Wed, Apr 10, 2013 at 5:25 PM, Lorenzo Marcantonio
wrote:
> On Wed, Apr 10, 2013 at 04:16:50PM +0200, Fabrizio Tap
Hi Dick,
Perhaps you already tried, but you have HTML formatting switched off, right?
HTML setting in Thunderbird are notorious for missing spaces.
You can set the default via
Tools->Account Settings, Select account
Inside the Composition and addressing tab there is a checkbox for setting HTML
33 matches
Mail list logo
