[Kicad-developers] PATCH: Enhanced Python Shell - V1

[Strontium]

Attached is a patch for the enhanced python shell.

This is what it looks like for me: http://i.imgur.com/je6yv8g.png

The assertions I was getting occur in a debug build and appear to be 
normal behaviour of wxpython, and not actual errors.


See: http://wxpython.org/Phoenix/docs/html/Notebook.html

Specifically : "On platforms other than Windows, or if the application 
is not using Windows themes, GetThemeBackgroundColour 
 
will return an uninitialised colour object"


That is the cause of the exceptions, and according to the docs its what 
it should do.  If someone knows more about this particular aspect of 
wxpython/wxwidgets I would be happy to make them NOT happen in a debug 
build.


I have only tested it on Linux, it needs testing on Windows and Mac, 
although its all standard wxpython stuff, so I expect it should "just 
work" if wxpython works.  That's the hope anyway.


Its just the vanilla implementation of the PyAlacarte shell from 
wxpython at the moment, there are a few enhancements/changes that can be 
made to make it nicer.  I am looking at those now, including the error 
you can see on the screenshot, which appears to not cause any issues, 
but I would like to fix in any event.


Steven
=== modified file 'pcbnew/pcbframe.cpp'
--- pcbnew/pcbframe.cpp	2015-11-29 06:56:27 +
+++ pcbnew/pcbframe.cpp	2015-12-13 14:46:14 +
@@ -70,8 +70,6 @@
 #include 
 #include 
 
-#include 
-
 #if defined(KICAD_SCRIPTING) || defined(KICAD_SCRIPTING_WXPYTHON)
 #include 
 #endif
@@ -980,9 +978,6 @@
 }
 
 
-wxSize PYTHON_CONSOLE_FRAME::m_frameSize;   ///< The size of the PYTHON_CONSOLE_FRAME frame, stored during a session
-wxPoint PYTHON_CONSOLE_FRAME::m_framePos;   ///< The position ofPYTHON_CONSOLE_FRAME  the frame, stored during a session
-
 void PCB_EDIT_FRAME::ScriptingConsoleEnableDisable( wxCommandEvent& aEvent )
 {
 
@@ -990,7 +985,7 @@
 bool pythonPanelShown = true;
 
 if( pythonPanelFrame == NULL )
-pythonPanelFrame = new PYTHON_CONSOLE_FRAME( this, pythonConsoleNameId() );
+pythonPanelFrame = CreatePythonShellWindow( this, pythonConsoleNameId() );
 else
 pythonPanelShown = ! pythonPanelFrame->IsShown();
 

=== modified file 'scripting/python_scripting.cpp'
--- scripting/python_scripting.cpp	2015-08-24 18:32:56 +
+++ scripting/python_scripting.cpp	2015-12-13 14:45:48 +
@@ -227,16 +227,17 @@
 }
 
 
-wxWindow* CreatePythonShellWindow( wxWindow* parent )
+wxWindow* CreatePythonShellWindow( wxWindow* parent, const wxString& aFramenameId )
 {
 const char* pycrust_panel =
 "import wx\n"
-"from wx.py import shell, version\n"
+"from wx.py import editor, version\n"
 "\n"
 "intro = \"PyCrust %s - KiCAD Python Shell\" % version.VERSION\n"
 "\n"
 "def makeWindow(parent):\n"
-"pycrust = shell.Shell(parent, -1, introText=intro)\n"
+"pycrust = editor.EditorNotebookFrame(parent, id=-1, title=intro)\n"
+"pycrust.Show()\n"
 "return pycrust\n"
 "\n";
 
@@ -297,6 +298,8 @@
 
 wxASSERT_MSG( success, _T( "Returned object was not a wxWindow!" ) );
 Py_DECREF( result );
+
+window->SetName(aFramenameId);
 }
 
 // Release the python objects we still have

=== modified file 'scripting/python_scripting.h'
--- scripting/python_scripting.h	2013-07-19 18:27:22 +
+++ scripting/python_scripting.h	2015-12-13 14:37:04 +
@@ -31,7 +31,7 @@
 #ifdef KICAD_SCRIPTING_WXPYTHON
 
 voidRedirectStdio();
-wxWindow*   CreatePythonShellWindow( wxWindow* parent );
+wxWindow*   CreatePythonShellWindow( wxWindow* parent, const wxString& aFramenameId );
 
 class PyLOCK
 {

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema field placement feature branch question

[Wayne Stambaugh]

Chris,  I'll commit the latest patch as is.  You can tweak it as time
goes by.  This will also give other developers and users a chance to
comment on it as well.

Technically there is no reason not to use the full resolution of
eeschema (0.001") when placing the fields rather than using a fixed grid
spacing.  This way the field spacing could be flexible.  Maybe you could
use a fixed distance between each field so that no matter what the text
height is, the spacing will always be constant.  It's something to think
about.

On 12/12/2015 4:17 PM, Chris Pavlina wrote:
> Wayne, would you rather I make this change and submit an updated monolithic 
> patch (will take a few days), or would you rather I make a second patch on 
> top of this one to be applied in a second commit?
> 
> JP, the horizontal grid is already flexible, but the autoplacer doesn't do 
> vertical texts. How would that even work? It has to arrange them in a grid 
> somehow. Texts are always placed horizontally with respect to the sheet.
> 
> 
> On Sat, Dec 12, 2015 at 07:43:47PM +0100, jp charras wrote:
>> Le 12/12/2015 18:26, Chris Pavlina a écrit :
>>> I actually thought a bit about that, and wasn't sure how to reconcile 
>>> "make the labels look nice" with "we like 50mil grids". But then, I went 
>>> off-grid for horizontal _anyway_, so... *shrug*
>>>
>>> It'll take some reworking of the placement code to make the vertical 
>>> grid flexible - not something I'd probably bother doing on my own, but 
>>> if other people want it, let me know and I'll have no problem 
>>> implementing that.
>>>
>>
>> The 50 mils grid is good (read: mandatory) to place pins.
>> So "we like this grid" for connected items (pins, labels, wires ..)
>>
>> But for graphics items a smaller grid is often needed.
>>
>> Fields can be seen as graphics items.
>> I am thinking a smaller grid like 10 mils could be used to place them.
>>
>> (the horizontal grid should be also flexible, especially for vertical texts)
>>
>> Thanks.
>>
>> -- 
>> Jean-Pierre CHARRAS
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH 2/4] Use CMake function for position independent code

[Wayne Stambaugh]

What version of boost is distributed with Redhat 4.4.7-11?

On 12/13/2015 9:17 AM, Nick Østergaard wrote:
> So on the jenkins master we see the following build error when
> building with the bundled boost.
> 
> 00:48:29.154 [100%] Building CXX object
> pcbnew/CMakeFiles/_pcbnew.dir/tools/size_menu.cpp.o
> 00:48:34.401 [100%] Building CXX object
> pcbnew/CMakeFiles/_pcbnew.dir/__/common/dialogs/dialog_page_settings.cpp.o
> 00:48:34.482 [100%] Building CXX object
> pcbnew/CMakeFiles/_pcbnew.dir/__/common/base_units.cpp.o
> 00:48:37.511 Linking CXX shared module _pcbnew.kiface
> 00:48:38.675 Linking CXX shared module _pcbnew.so
> 00:48:57.455 /usr/bin/ld:
> ../../boost_root/lib/libboost_filesystem.a(operations.o): relocation
> R_X86_64_32 against `.rodata.str1.1' can not be used when making a
> shared object; recompile with -fPIC
> 00:48:57.456 ../../boost_root/lib/libboost_filesystem.a: could not
> read symbols: Bad value
> 00:48:57.456 collect2: ld returned 1 exit status
> 00:48:57.460 /usr/bin/ld:
> ../../boost_root/lib/libboost_filesystem.a(operations.o): relocation
> R_X86_64_32 against `.rodata.str1.1' can not be used when making a
> shared object; recompile with -fPIC
> 00:48:57.460 ../../boost_root/lib/libboost_filesystem.a: could not
> read symbols: Bad value
> 00:48:57.460 collect2: ld returned 1 exit status
> 00:48:57.482 make[2]: *** [pcbnew/_pcbnew.kiface] Error 1
> 00:48:57.497 make[2]: *** [pcbnew/_pcbnew.so] Error 1
> 00:48:57.501 make[1]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2
> 00:48:57.527 make[1]: *** [pcbnew/CMakeFiles/_pcbnew.dir/all] Error 2
> 00:48:57.614 make: *** [all] Error 2
> 
> cmake version 2.8.12.2
> gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11)
> 
> What should we do, except probably consider upgrading cmake and gcc?
> 
> Regards
> Nick Østergaard
> 
> 
> -- Forwarded message --
> From: Simon Richter 
> Date: 2015-12-10 18:27 GMT+01:00
> Subject: Re: [Kicad-developers] [PATCH 2/4] Use CMake function for
> position independent code
> To: kicad-developers@lists.launchpad.net
> 
> 
> Hi,
> 
>> - set( BOOST_CFLAGS "cflags=${PIC_FLAG}" )
>> - set( BOOST_CXXFLAGS "cxxflags=${PIC_FLAG}" )
> 
>> because cmake will only set -fpic in CFLAGS but the entire cmake file
>> uses BOOST_CFLAGS and never passes the plain CFLAGS
> 
> The Boost build knows on its own that it needs -fPIC -- except if you
> link statically, which has its own issues.
> 
>Simon
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema field placement feature branch question

[Chris Pavlina]

Sounds good, Wayne. Currently I am in fact using the full resolution for 
placement, unless the option to round to 50 mils is enabled. I'm working 
on a patch to make the vertical spacing flexible, at the moment, so 
should have that ready soon - I'll submit it as an incremental patch.

Thanks
Chris

On Sun, Dec 13, 2015 at 10:39:25AM -0500, Wayne Stambaugh wrote:
> Chris,  I'll commit the latest patch as is.  You can tweak it as time
> goes by.  This will also give other developers and users a chance to
> comment on it as well.
> 
> Technically there is no reason not to use the full resolution of
> eeschema (0.001") when placing the fields rather than using a fixed grid
> spacing.  This way the field spacing could be flexible.  Maybe you could
> use a fixed distance between each field so that no matter what the text
> height is, the spacing will always be constant.  It's something to think
> about.
> 
> On 12/12/2015 4:17 PM, Chris Pavlina wrote:
> > Wayne, would you rather I make this change and submit an updated monolithic 
> > patch (will take a few days), or would you rather I make a second patch on 
> > top of this one to be applied in a second commit?
> > 
> > JP, the horizontal grid is already flexible, but the autoplacer doesn't do 
> > vertical texts. How would that even work? It has to arrange them in a grid 
> > somehow. Texts are always placed horizontally with respect to the sheet.
> > 
> > 
> > On Sat, Dec 12, 2015 at 07:43:47PM +0100, jp charras wrote:
> >> Le 12/12/2015 18:26, Chris Pavlina a écrit :
> >>> I actually thought a bit about that, and wasn't sure how to reconcile 
> >>> "make the labels look nice" with "we like 50mil grids". But then, I went 
> >>> off-grid for horizontal _anyway_, so... *shrug*
> >>>
> >>> It'll take some reworking of the placement code to make the vertical 
> >>> grid flexible - not something I'd probably bother doing on my own, but 
> >>> if other people want it, let me know and I'll have no problem 
> >>> implementing that.
> >>>
> >>
> >> The 50 mils grid is good (read: mandatory) to place pins.
> >> So "we like this grid" for connected items (pins, labels, wires ..)
> >>
> >> But for graphics items a smaller grid is often needed.
> >>
> >> Fields can be seen as graphics items.
> >> I am thinking a smaller grid like 10 mils could be used to place them.
> >>
> >> (the horizontal grid should be also flexible, especially for vertical 
> >> texts)
> >>
> >> Thanks.
> >>
> >> -- 
> >> Jean-Pierre CHARRAS
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema field placement feature branch question

[Wayne Stambaugh]

I committed your patch in the product branch r6371.  Thanks.

On 12/13/2015 10:42 AM, Chris Pavlina wrote:
> Sounds good, Wayne. Currently I am in fact using the full resolution for 
> placement, unless the option to round to 50 mils is enabled. I'm working 
> on a patch to make the vertical spacing flexible, at the moment, so 
> should have that ready soon - I'll submit it as an incremental patch.
> 
> Thanks
> Chris
> 
> On Sun, Dec 13, 2015 at 10:39:25AM -0500, Wayne Stambaugh wrote:
>> Chris,  I'll commit the latest patch as is.  You can tweak it as time
>> goes by.  This will also give other developers and users a chance to
>> comment on it as well.
>>
>> Technically there is no reason not to use the full resolution of
>> eeschema (0.001") when placing the fields rather than using a fixed grid
>> spacing.  This way the field spacing could be flexible.  Maybe you could
>> use a fixed distance between each field so that no matter what the text
>> height is, the spacing will always be constant.  It's something to think
>> about.
>>
>> On 12/12/2015 4:17 PM, Chris Pavlina wrote:
>>> Wayne, would you rather I make this change and submit an updated monolithic 
>>> patch (will take a few days), or would you rather I make a second patch on 
>>> top of this one to be applied in a second commit?
>>>
>>> JP, the horizontal grid is already flexible, but the autoplacer doesn't do 
>>> vertical texts. How would that even work? It has to arrange them in a grid 
>>> somehow. Texts are always placed horizontally with respect to the sheet.
>>>
>>>
>>> On Sat, Dec 12, 2015 at 07:43:47PM +0100, jp charras wrote:
 Le 12/12/2015 18:26, Chris Pavlina a écrit :
> I actually thought a bit about that, and wasn't sure how to reconcile 
> "make the labels look nice" with "we like 50mil grids". But then, I went 
> off-grid for horizontal _anyway_, so... *shrug*
>
> It'll take some reworking of the placement code to make the vertical 
> grid flexible - not something I'd probably bother doing on my own, but 
> if other people want it, let me know and I'll have no problem 
> implementing that.
>

 The 50 mils grid is good (read: mandatory) to place pins.
 So "we like this grid" for connected items (pins, labels, wires ..)

 But for graphics items a smaller grid is often needed.

 Fields can be seen as graphics items.
 I am thinking a smaller grid like 10 mils could be used to place them.

 (the horizontal grid should be also flexible, especially for vertical 
 texts)

 Thanks.

 -- 
 Jean-Pierre CHARRAS

 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] OSX 10.9.5 Crash with 4.0.0

[Jose A. Saumell]

Hi Adam, thanks! I've posted on bug tracker with details. Didn't work but
version from Dec 13 did.

On Sun, Dec 13, 2015 at 12:28 AM Adam Wolf 
wrote:

> Hello Jose,
>
> If you could, please follow the bug on the bug tracker.  In case you
> didn't, please try this build (
> http://downloads.kicad-pcb.org/osx/nightly/kicad-r6370.20151212-152723.dmg)
> and please report if it fixes the issue for you.
>
> Thank you.
>
> Adam Wolf
>
> On Sat, Dec 12, 2015 at 1:15 PM, Adam Wolf 
> wrote:
>
>> Yeah.  I will redo the cairo/pixman recompile soon, but I really think I
>> set it up the same way as I did in February when I rebuilt them.
>>
>> I hope I'm not hitting a homebrew bug--but everything on that machine is
>> pretty heavily logged so I should have the information I need to fix that
>> bug if that is the case.
>>
>> Adam Wolf
>>
>> On Sat, Dec 12, 2015 at 1:02 PM, Garth Corral  wrote:
>>
>>> We had a long thread about this back in February.  I don’t remember what
>>> the outcome was, but it was during the debate about whether to support
>>> 10.7, and I thought that a line was drawn at supporting Core Duo and 10.7
>>> in the nightlies.
>>>
>>> https://lists.launchpad.net/kicad-developers/msg17055.html
>>>
>>>
>>> On Dec 12, 2015, at 7:41 AM, Adam Wolf 
>>> wrote:
>>>
>>> I'm looking at my notes from when I started the Mac nightlies last
>>> February and I have the flags for the way they were compiled before.  It'll
>>> be a good start at least.
>>>
>>> On Sat, Dec 12, 2015, 7:07 AM Jose A. Saumell 
>>> wrote:
>>>
 The Core 2 Duo is the first batch of Intel macs with 64-bit processor.
 The 'core duo' are 32-bit, if you go back enough to cover Core2duo would be
 great! at least for me :)

 Cheers. Jose

 On Sat, Dec 12, 2015 at 9:49 AM Bernhard Stegmaier <
 stegma...@sw-systems.de> wrote:

> If I remember correctly the first Intel Mac’s came with Core Duo.
> With gcc IMHO —march=nocona was the way to go with those.
>
> I don’t know what clang supports and how far back we want to be
> compatible.
>
>
> Regards,
> Bernhard
>
> On 11 Dec 2015, at 21:32, Adam Wolf 
> wrote:
>
> That looks right.  Now to figure out what a better "more generic" set
> of CFLAGS and CPPFLAGS we need...
>
> On Fri, Dec 11, 2015 at 2:11 PM, Bernhard Stegmaier <
> stegma...@sw-systems.de> wrote:
>
>> EXC_BAD_INSTRUCTION almost looks like maybe pixman chooses some
>> CPU-dependant optimisation from the build machine on its own, which maybe
>> doesn’t work on this machine?
>>
>> From below this seems to be some old Core2Duo?
>>
>>
>> Regards,
>> Bernhard
>>
>> On 11 Dec 2015, at 21:02, Adam Wolf 
>> wrote:
>>
>> Yes, this is on the bug tracker.
>>
>> This is probably the same issue as
>> https://bugs.launchpad.net/kicad/+bug/1522987.
>>
>> I recompiled pixman and cairo on the build server multiple times from
>> 11/16 to 11/19 for another issue.  It fixed that issue, but some people,
>> I'm not sure who/why, have a different issue now.
>>
>> I was chasing down other issues this week, but I hope to get to this
>> soon.
>>
>> Adam Wolf
>>
>> On Fri, Dec 11, 2015 at 1:51 PM, Jose A. Saumell <
>> saumell.j...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I've updated kicad to stable version 4.0.0 today, but I can't open
>>> pcbnew or footprint editor anymore. Did anyone experience this issue?
>>> kicad.app, eeschema, gerbview, pl_editor and pcb_calculator open fine.
>>>
>>> This is the crash report I get, any help appreciated:
>>>
>>> Jose
>>> 
>>> Process: pcbnew [552]
>>> Path:
>>>  
>>> /Applications/Kicad/kicad.app/Contents/Applications/pcbnew.app/Contents/MacOS/pcbnew
>>> Identifier:  org.kicad-pcb.pcbnew
>>> Version: ??? (???)
>>> Code Type:   X86-64 (Native)
>>> Parent Process:  launchd [424]
>>> Responsible: pcbnew [552]
>>> User ID: 502
>>>
>>> Date/Time:   2015-12-11 16:44:02.528 -0300
>>> OS Version:  Mac OS X 10.9.5 (13F1134)
>>> Report Version:  11
>>> Anonymous UUID:  9A8847B2-8485-B67C-8D2E-78A6F7A6FC2E
>>>
>>>
>>> Crashed Thread:  0  Dispatch queue: com.apple.main-thread
>>>
>>> Exception Type:  EXC_BAD_INSTRUCTION (SIGILL)
>>> Exception Codes: 0x0001, 0x
>>>
>>> Application Specific Information:
>>>
>>> /Applications/Kicad/kicad.app/Contents/Applications/pcbnew.app/Contents/MacOS/../Frameworks/libpixman-1.0.dylib
>>>
>>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
>>> 0   

[Kicad-developers] [PATCH] Eeschema: make field autoplace grid flexible with field height

[Chris Pavlina]

Okay, here's a patch to make the autoplacement grid for fields flexible, 
so fields are positioned sanely when they have different heights. Just 
finished this an hour ago, as opposed to the main autoplacement patch 
which got months of testing, so somebody else might want to try this 
out.

I'm going to prepare one more patch, to handle a slightly quirky field 
placement in a specific arrangement with a long component symbol 
sandwiched between wires. That should be it.

--
Chris
commit b8fdf66034c0028ae33a3d372937279919427916
Author: Chris Pavlina 
Date:   Sat Dec 12 16:29:19 2015 -0500

Make vertical autoplacement grid flexible

diff --git a/eeschema/autoplace_fields.cpp b/eeschema/autoplace_fields.cpp
index 001127a..5849309 100644
--- a/eeschema/autoplace_fields.cpp
+++ b/eeschema/autoplace_fields.cpp
@@ -63,9 +63,11 @@
 #include 
 #include 
 
-#define FIELD_V_SPACING 100
+#define FIELD_PADDING 10// arbitrarily chosen for aesthetics
+#define FIELD_PADDING_ALIGNED 18// aligns 50 mil text to a 100 mil grid
+#define WIRE_V_SPACING 100
 #define HPADDING 25
-#define VPADDING 50
+#define VPADDING 25
 
 /**
  * Function round_n
@@ -127,7 +129,7 @@ public:
 Kiface().KifaceSettings()->Read( AUTOPLACE_ALIGN_KEY, _align_to_grid, false );
 
 m_comp_bbox = m_component->GetBodyBoundingBox();
-m_fbox_size = ComputeFBoxSize();
+m_fbox_size = ComputeFBoxSize( /* aDynamic */ true );
 
 m_power_symbol = ! m_component->IsInNetlist();
 
@@ -143,17 +145,16 @@ public:
  */
 void DoAutoplace( bool aManual )
 {
+bool force_wire_spacing = false;
 SIDE field_side = choose_side_for_fields( aManual );
 wxPoint fbox_pos = field_box_placement( field_side );
 EDA_RECT field_box( fbox_pos, m_fbox_size );
 
 if( aManual )
-{
-fbox_pos = fit_fields_between_wires( field_box, field_side );
-field_box.SetOrigin( fbox_pos );
-}
+force_wire_spacing = fit_fields_between_wires( _box, field_side );
 
 // Move the fields
+int last_y_coord = field_box.GetTop();
 for( int field_idx = 0; field_idx < m_fields.size(); ++field_idx )
 {
 SCH_FIELD* field = m_fields[field_idx];
@@ -163,7 +164,7 @@ public:
 
 wxPoint pos(
 field_horiz_placement( field, field_box ),
-field_box.GetY() + (FIELD_V_SPACING * field_idx) );
+field_vert_placement( field, field_box, _y_coord, !force_wire_spacing ) );
 
 if( m_align_to_grid )
 {
@@ -179,29 +180,40 @@ public:
 protected:
 /**
  * Compute and return the size of the fields' bounding box.
+ * @param aDynamic - if true, use dynamic spacing
  */
-wxSize ComputeFBoxSize()
+wxSize ComputeFBoxSize( bool aDynamic )
 {
 int max_field_width = 0;
+int total_height = 0;
+
 BOOST_FOREACH( SCH_FIELD* field, m_fields )
 {
 int field_width;
+int field_height;
 
 if( m_component->GetTransform().y1 )
 {
 field->SetOrientation( TEXT_ORIENT_VERT );
-field_width = field->GetBoundingBox().GetHeight();
 }
 else
 {
 field->SetOrientation( TEXT_ORIENT_HORIZ );
-field_width = field->GetBoundingBox().GetWidth();
 }
 
+field_width = field->GetBoundingBox().GetWidth();
+field_height = field->GetBoundingBox().GetHeight();
+
 max_field_width = std::max( max_field_width, field_width );
+
+if( aDynamic )
+total_height += field_height + get_field_padding();
+else
+total_height += WIRE_V_SPACING;
+
 }
 
-return wxSize( max_field_width, int( FIELD_V_SPACING * (m_fields.size() - 1) ) );
+return wxSize( max_field_width, total_height );
 }
 
 
@@ -519,16 +531,16 @@ protected:
 /**
  * Function fit_fields_between_wires
  * Shift a field box up or down a bit to make the fields fit between some wires.
- * Returns the new position of the field bounding box.
+ * Returns true if a shift was made.
  */
-wxPoint fit_fields_between_wires( const EDA_RECT& aBox, SIDE aSide )
+bool fit_fields_between_wires( EDA_RECT* aBox, SIDE aSide )
 {
 if( aSide != SIDE_TOP && aSide != SIDE_BOTTOM )
-return aBox.GetPosition();
+return false;
 
-std::vector colliders = filtered_colliders( aBox );
+std::vector colliders = filtered_colliders( *aBox );
 if( colliders.empty() )
-return aBox.GetPosition();
+return false;
 
 // Find the offset of the wires for proper positioning
 int offset = 0;
@@ -537,24 +549,28 @@ protected:
 {
 SCH_LINE* line = 

Re: [Kicad-developers] Removal of download_boost.cmake.

[Adam Wolf]

Fine for OS X!

On Sun, Dec 13, 2015 at 4:13 PM, Wayne Stambaugh 
wrote:

> This is a last call notice for all of our package developers.  I'm
> getting ready to remove download_boost.cmake from the source tree within
> the next week or so.  If that is an issue, please let me know and I will
> push it off.  The sooner we can get rid of this, the better.  I will set
> the cmake find boost version to 1.55 (the current version in Debian
> stable) or greater.
>
> Thanks,
>
> Wayne
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Removal of download_boost.cmake.

[Marco Ciampa]

On Sun, Dec 13, 2015 at 05:13:49PM -0500, Wayne Stambaugh wrote:
> This is a last call notice for all of our package developers.  I'm
> getting ready to remove download_boost.cmake from the source tree within
> the next week or so.  If that is an issue, please let me know and I will
> push it off.  The sooner we can get rid of this, the better.  I will set
> the cmake find boost version to 1.55 (the current version in Debian
> stable) or greater.
> 
> Thanks,
> 
> Wayne

Ubuntu 14.04 (LTS)

apt-cache show libboost-all-dev
[...]
This package is a dependency package, which depends on Debian's default
Boost version (currently 1.54).

bye

--


Marco Ciampa

I know a joke about UDP, but you might not get it.

++
| GNU/Linux User  #78271 |
| FSFE fellow   #364 |
++


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Removal of download_boost.cmake.

[Mark Roszko]

Debian never had 1.54 in stable.. It has 1.55 now(jessie) and the last release
was 1.49 (wheezy).

Debian had 1.54 as "unstable" in 2013, it never shipped as stable.

But yes, ubuntu 14 has 1.54.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Removal of download_boost.cmake.

[Marco Ciampa]

On Sun, Dec 13, 2015 at 07:36:24PM -0500, Mark Roszko wrote:
> Debian never had 1.54 in stable.. It has 1.55 now(jessie) and the last release
> was 1.49 (wheezy).
> 
> Debian had 1.54 as "unstable" in 2013, it never shipped as stable.
> 
> But yes, ubuntu 14 has 1.54.

I was only reporting cut the output of the apt-cache show command.

Seems that ubuntu LTS is taken from Debian unstable... and not stable as
they write...

--


Marco Ciampa

I know a joke about UDP, but you might not get it.

++
| GNU/Linux User  #78271 |
| FSFE fellow   #364 |
++


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Text rotation Angle and part rotation Angle pcbnew

[Lachlan Audas]

You can't set text rotation angle of part reference's and vale's in
pcbnew,  only part rotation angle,

This is bit of a problem  for importing eagle  pcb's,   as parts
reference/vales may have angle's set,  also when manually setting angle's
you need to enter 900 for 90..  etc
instead of 90.5 etc  this very odd way of entering angles,   is they any
objection make a patch to change this to the standard way of entering
angle's, and allowing rations of
reference/vale fields ?

Lachlan
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [PATCH] Dark Theme Fixups

[Windsor Schmidt]

Hi everyone,

This is my first post to the list, so please go easy on me. :D I have made a 
couple of changes to improve the appearance of the GUI for users with dark 
themes in Linux. A patch is attached.

* Removed toolbar gradient by adding wxAUI_TB_PLAIN_BACKGROUND to
  wxAuiToolBar style (gradient is the default).

* Removed the white border from the main project tree view
  by replacing style constant wxSW_3D with wxSW_3DSASH.

* Removed the white border from wxAui panes in KiCad manager,
  pcbnew, and eeschema by calling PaneBorder( false ) on AUI panes.

Here are some screenshots from my Arch Linux desktop running bspwm (GTK2):

Dark theme from trunk: http://i.imgur.com/o1ueuVm.png
Dark theme after fixups: http://i.imgur.com/TMdu8TF.png
Light theme from trunk: http://i.imgur.com/MohCz76.png
Light theme after fixups: http://i.imgur.com/Oj6Bi0F.png

NOTE: That third fixup involves a loop that runs before updating the wxAUI 
manager. I duplicate this code in 3 places where the white border was most 
prominent (toolbars in the manager, eeschema, and pcbnew). I assume this 
routine could be centralized and called before any time the AUI manager is 
updated, however I don't know the KiCad codebase well enough to approach this.

Thanks. KiCad rocks!

-Windsor
diff --git a/3d-viewer/3d_toolbar.cpp b/3d-viewer/3d_toolbar.cpp
index d24729f..5daf11f 100644
--- a/3d-viewer/3d_toolbar.cpp
+++ b/3d-viewer/3d_toolbar.cpp
@@ -45,7 +45,7 @@ void EDA_3D_FRAME::ReCreateMainToolbar()
 }
 
 m_mainToolBar = new wxAuiToolBar( this, ID_H_TOOLBAR, wxDefaultPosition, wxDefaultSize,
-   wxAUI_TB_DEFAULT_STYLE | wxAUI_TB_HORZ_LAYOUT );
+   wxAUI_TB_DEFAULT_STYLE | wxAUI_TB_HORZ_LAYOUT | wxAUI_TB_PLAIN_BACKGROUND );
 
 // Set up toolbar
 m_mainToolBar->AddTool( ID_RELOAD3D_BOARD, wxEmptyString,
diff --git a/cvpcb/class_DisplayFootprintsFrame.cpp b/cvpcb/class_DisplayFootprintsFrame.cpp
index 0b3a76a..8ff361d 100644
--- a/cvpcb/class_DisplayFootprintsFrame.cpp
+++ b/cvpcb/class_DisplayFootprintsFrame.cpp
@@ -170,7 +170,7 @@ void DISPLAY_FOOTPRINTS_FRAME::ReCreateOptToolbar()
 
 // Create options tool bar.
 m_optionsToolBar = new wxAuiToolBar( this, ID_OPT_TOOLBAR, wxDefaultPosition, wxDefaultSize,
- wxAUI_TB_DEFAULT_STYLE | wxAUI_TB_VERTICAL );
+ wxAUI_TB_DEFAULT_STYLE | wxAUI_TB_VERTICAL | wxAUI_TB_PLAIN_BACKGROUND );
 
 m_optionsToolBar->AddTool( ID_TB_OPTIONS_SHOW_GRID, wxEmptyString, KiBitmap( grid_xpm ),
_( "Hide grid" ), wxITEM_CHECK );
@@ -214,7 +214,7 @@ void DISPLAY_FOOTPRINTS_FRAME::ReCreateHToolbar()
 return;
 
 m_mainToolBar = new wxAuiToolBar( this, ID_H_TOOLBAR, wxDefaultPosition, wxDefaultSize,
-  wxAUI_TB_DEFAULT_STYLE | wxAUI_TB_HORZ_LAYOUT );
+  wxAUI_TB_DEFAULT_STYLE | wxAUI_TB_HORZ_LAYOUT | wxAUI_TB_PLAIN_BACKGROUND );
 
 m_mainToolBar->AddTool( ID_OPTIONS_SETUP, wxEmptyString, KiBitmap( display_options_xpm ),
 _( "Display options" ) );
diff --git a/cvpcb/tool_cvpcb.cpp b/cvpcb/tool_cvpcb.cpp
index b53f9c9..935d05b 100644
--- a/cvpcb/tool_cvpcb.cpp
+++ b/cvpcb/tool_cvpcb.cpp
@@ -47,7 +47,7 @@ void CVPCB_MAINFRAME::ReCreateHToolbar()
 return;
 
 m_mainToolBar = new wxAuiToolBar( this, ID_H_TOOLBAR, wxDefaultPosition, wxDefaultSize,
-  wxAUI_TB_DEFAULT_STYLE | wxAUI_TB_HORZ_LAYOUT );
+  wxAUI_TB_DEFAULT_STYLE | wxAUI_TB_HORZ_LAYOUT | wxAUI_TB_PLAIN_BACKGROUND );
 
 m_mainToolBar->AddTool( wxID_SAVE, wxEmptyString, KiBitmap( save_xpm ), SAVE_HLP_MSG );
 
diff --git a/eeschema/schframe.cpp b/eeschema/schframe.cpp
index 953e7f6..21ded0b 100644
--- a/eeschema/schframe.cpp
+++ b/eeschema/schframe.cpp
@@ -411,6 +411,13 @@ SCH_EDIT_FRAME::SCH_EDIT_FRAME( KIWAY* aKiway, wxWindow* aParent ):
 m_auimgr.AddPane( m_messagePanel, wxAuiPaneInfo( mesg ).Name( wxT( "MsgPanel" ) ).Bottom().
   Layer(10) );
 
+// remote the ugly 1-pixel white border on AUI panes
+wxAuiPaneInfoArray panes = m_auimgr.GetAllPanes();
+for ( size_t i = 0; i < panes.GetCount(); i++ )
+{
+m_auimgr.GetPane(panes.Item(i).name).PaneBorder( false );
+}
+
 m_auimgr.Update();
 
 // Now Drawpanel is sized, we can use BestZoom to show the component (if any)
@@ -1323,4 +1330,3 @@ void SCH_EDIT_FRAME::UpdateTitle()
 
 SetTitle( title );
 }
-
diff --git a/eeschema/tool_lib.cpp b/eeschema/tool_lib.cpp
index 729b768..8745b0b 100644
--- a/eeschema/tool_lib.cpp
+++ b/eeschema/tool_lib.cpp
@@ -55,7 +55,7 @@ void LIB_EDIT_FRAME::ReCreateVToolbar()
 return;
 
 m_drawToolBar = new wxAuiToolBar( this, ID_V_TOOLBAR, wxDefaultPosition, wxDefaultSize,
-  

[Kicad-developers] plugins and out-of-tree builds

[Cirilo Bernardo]

Hi folks,

 If/when we merge the 3D refactor branch we will finally have the ability
to build out-of-tree plugins for kicad. One major implication of this is
that at install time we will have to decide whether the required headers
for plugins should also be installed. If anyone has any ideas on how to
handle this I'd like to hear about it. From my point of view the headers
should always be installed and it is up to the package maintainers to
decide whether to install the headers with kicad or to split them off
into a '-dev' install package.

- Cirilo
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] update on 3D refactor

[Cirilo Bernardo]

Hi folks,

 I'm progressing with some cleanup of the 3D refactor in preparation
for merging with the main branch (which we can hopefully do early
in 2016). The latest news:

A small refactor was done to make it easier to produce a dynamic
plugin for kicad. The header include/plugins/kicad_plugin.h declares
a basic set of functions which must be implemented by all kicad
plugins. The header include/plugins/3d_plugin.h extends that set
of functions to define a 3D model plugin, which is currently
the only class of dynamic plugin implemented in kicad. There are
currently 3 definitions of the 3D model plugin and they are all found
in subdirectories of plugins/3d. To make the plugins easy to use
on the kicad side I use a plugin loader class; the basic loader
and a derived class for the 3D model plugins can be found in
plugins/ldr{/3d}. Loading a plugin is a simple matter of:

SOME_PLUGIN* myplugin = new SOME_PLUGIN;
myplugin->Open( "my_plugin_name" );

The entire plugin interface is encapsulated by the plugin loader,
so for example in my 3D plugin I can access the function to
load a 3D model via:

myplugin->Load( "some_3D_model" );

To make life even easier for the programmers, a Plugin Manager
can be designed for each specific class of plugin. In the case
of 3D plugins the manager discovers and registers all 3D model
plugins. Developers can build a plugin out-of-tree and simply
drop the plugin into an appropriate directory and it becomes
available to kicad when kicad is restarted.

When the 3D refactor work is done I plan to use the kicad_plugin.h
class to implement an Export Plugin and decouple the VRML and
IDF Export plugins, and eventually also the GeniCAM and Specctra
exporters.  Eventually it will be possible to convert the PCB File I/O
modules into dynamic plugins as well, thus making it possible for
developers to add support for different PCB formats without
recompiling the bulk of pcbnew for every change made.

- Cirilo
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp