Re: [Kicad-developers] Plugin plans (post-stable release)
On 14.06.2015 02:35, Cirilo Bernardo wrote: > 7. STEP: (future plans) the plugin will only provide an Export I'd also like to add STEP visualization in the near future (post-stable ofc) Tom PS. It is possible to export a hierarchical assembly in STEP from OCC. No need to write a special library for that. ___ 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] Scripting
I can't do more than agree, and this is why (very slowly) I'm working on this: https://github.com/kicad/kicad-python https://github.com/KiCad/kicad-python/blob/master/doc/source/index.rst https://github.com/KiCad/kicad-python/blob/master/kicad/pcbnew/board.py https://github.com/KiCad/kicad-python/blob/master/tests/unit/pcbnew/test_pcbnew_board.py This is a work that Piers Titus van der Torren started, and that I perverted a bit to add documentation, testing, and trying to keep uniformity across all object interfaces. If you want to contribute, it can be done via pull requests to the main repository, those are automatically checked by CI, and reported back to github. I haven't wrote any rules yet, but I really believe we should: 1) Document as we code 2) Write unit tests as we code So we avoid regressions and provide a very consistent API for the users, where we can detect regressions or any issues. Chris Pavlina wrote: wrt scripting and SWIG - SWIG's good for generating a low-level wrapper, but if we'd like scripting to go anywhere, I really think we should come up with a more scripting-friendly API and high-level wrapper. Something with more proper iterables, fewer integer enums, fewer getters and setters, objects that are fully and usefully introspectable at the console, etc. Fewer things like this scattered about: http://ci.kicad-pcb.org/job/kicad-doxygen/ws/build/pcbnew/doxygen-python/html/classpcbnew_1_1MODULE.html#a549dccf2a9eecffa83f76cfe8d1a7d19 Anyone else interested in seeing scripting improve? I'd be willing to contribute to this. On Sat, Jun 13, 2015 at 05:26:58PM -0400, Wayne Stambaugh wrote: On 6/12/2015 10:48 AM, Rob Maris wrote: Hi, I'm interested in adding Lua scripting to Kicad as an alternative to Python. Can anybody present some information about complexity and API in order to integrate a lua interpreter? Regards, Rob Rob, There has been some interest in lua in the past. I'm not opposed to adding lua as another scripting language. I not sure if lua can be swigged. That would be the preferred method for generating the lua scripting libraries. To get an idea of the complexity of the kicad API, look at the python swig code and the c++ code documentation at kicad-pcb.org. At this time only Pcbnew is scripted. Eeschema is due a major over hall after the next stable release so I expected it to be scripted at that point. Also, we are pretty much in feature freeze for the next stable release so anything major like supporting another scripting language will have to wait until after the next stable release. Cheers, 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 ___ 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] Scripting
Btw, I forgot, if you clone it to test, you need kicad installed with scripting support so it will find the "raw" C++ interface generated by swig as "pcbnew" on the system. Then, you can run tox -epy27 # to run unit test validation tox -epep8 # to run the standard python code style checks tox -edocs # to generate/render the documentation Miguel Angel Ajo wrote: I can't do more than agree, and this is why (very slowly) I'm working on this: https://github.com/kicad/kicad-python https://github.com/KiCad/kicad-python/blob/master/doc/source/index.rst https://github.com/KiCad/kicad-python/blob/master/kicad/pcbnew/board.py https://github.com/KiCad/kicad-python/blob/master/tests/unit/pcbnew/test_pcbnew_board.py This is a work that Piers Titus van der Torren started, and that I perverted a bit to add documentation, testing, and trying to keep uniformity across all object interfaces. If you want to contribute, it can be done via pull requests to the main repository, those are automatically checked by CI, and reported back to github. I haven't wrote any rules yet, but I really believe we should: 1) Document as we code 2) Write unit tests as we code So we avoid regressions and provide a very consistent API for the users, where we can detect regressions or any issues. Chris Pavlina wrote: wrt scripting and SWIG - SWIG's good for generating a low-level wrapper, but if we'd like scripting to go anywhere, I really think we should come up with a more scripting-friendly API and high-level wrapper. Something with more proper iterables, fewer integer enums, fewer getters and setters, objects that are fully and usefully introspectable at the console, etc. Fewer things like this scattered about: http://ci.kicad-pcb.org/job/kicad-doxygen/ws/build/pcbnew/doxygen-python/html/classpcbnew_1_1MODULE.html#a549dccf2a9eecffa83f76cfe8d1a7d19 Anyone else interested in seeing scripting improve? I'd be willing to contribute to this. On Sat, Jun 13, 2015 at 05:26:58PM -0400, Wayne Stambaugh wrote: On 6/12/2015 10:48 AM, Rob Maris wrote: Hi, I'm interested in adding Lua scripting to Kicad as an alternative to Python. Can anybody present some information about complexity and API in order to integrate a lua interpreter? Regards, Rob Rob, There has been some interest in lua in the past. I'm not opposed to adding lua as another scripting language. I not sure if lua can be swigged. That would be the preferred method for generating the lua scripting libraries. To get an idea of the complexity of the kicad API, look at the python swig code and the c++ code documentation at kicad-pcb.org. At this time only Pcbnew is scripted. Eeschema is due a major over hall after the next stable release so I expected it to be scripted at that point. Also, we are pretty much in feature freeze for the next stable release so anything major like supporting another scripting language will have to wait until after the next stable release. Cheers, 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 ___ 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] Plugin plans (post-stable release)
Hi Tom, I found also https://github.com/stepcode/stepcode that could be an interesting class lib... I agree that if a STEP support will be added, it would be very useful (necessary) to add also the STEP visualization in 3d-viewer... Adding STEP modules to the project without an internal and direct 3D feedback, would need a ping-pong work: add a module, export boards and modules open those in MCAD check mechanical positions, reopen in kicad, move modules, export again and re-check etc... I was thinking that may be an intermediate step in exporting the full board for mechanical purposes could be to add the option to export the plain pcb with bounding boxes of the vrml modules... that would be a nice feature to add to the stable release... Maurice On 14/06/2015 12.01, Tomasz Wlostowski wrote: On 14.06.2015 02:35, Cirilo Bernardo wrote: 7. STEP: (future plans) the plugin will only provide an Export I'd also like to add STEP visualization in the near future (post-stable ofc) Tom PS. It is possible to export a hierarchical assembly in STEP from OCC. No need to write a special library for that. ___ 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] Mac paths help?
Regarding the console; you might want to reopen
https://bugs.launchpad.net/kicad/+bug/1379352.
Den 14/06/2015 05.04 skrev "Adam Wolf" :
> Hi Chris,
>
> The python console is ... quirky in the Mac build as well.
>
> I was not able to enter this into the console. Any character that shares
> a hotkey, like o, for example, doesn't get taken by the console.
>
> I am not sure if there is a workaround--I have been focusing on other
> parts lately.
>
> Adam Wolf
>
> On Sat, Jun 13, 2015 at 8:03 PM, Chris Pavlina
> wrote:
>
>> Hi all,
>>
>> I'm looking into prepopulating the list of BOM plugins in eeschema, and
>> further possibly cleaning up resource file access in general. Can I get
>> someone who's using kicad on Mac to run this script in the pcbnew Python
>> console to help me out a bit?
>>
>> import wx; sp = wx.StandardPaths.Get()
>>
>> for i in dir(sp):
>> if not i.startswith("Get"):
>> continue
>> try:
>> print("%s:\t%s" % (i, getattr(sp, i)()))
>> except Exception:
>> pass
>>
>> You might have to copy and paste it in two blocks as split above...the
>> console's a bit quirky for me.
>>
>> Thanks!
>>
>> --
>> Chris
>>
>>
>> ___
>> 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] Plugin plans (post-stable release)
Le 14/06/2015 12:01, Tomasz Wlostowski a écrit : > On 14.06.2015 02:35, Cirilo Bernardo wrote: >> 7. STEP: (future plans) the plugin will only provide an Export > > I'd also like to add STEP visualization in the near future (post-stable ofc) > > Tom > > PS. It is possible to export a hierarchical assembly in STEP from OCC. > No need to write a special library for that. We all agree (at least guys like me who make designs with very strong mechanical constraints) step import/export is a major feature. However, OCC is a very heavy dependency for Kicad. I am not especially thrilled by OCC dependency. If stepcode is usable, this is a (by far) preferable dependency, even it is not perfect. -- 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
Re: [Kicad-developers] Scripting
Oh, sweet! I'll definitely contribute to this. Hopefully we can get it in usable condition soon. Thanks! On Sun, Jun 14, 2015 at 12:23:16PM +0200, Miguel Angel Ajo wrote: > I can't do more than agree, and this is why (very slowly) I'm working on > this: > > https://github.com/kicad/kicad-python > > https://github.com/KiCad/kicad-python/blob/master/doc/source/index.rst > > https://github.com/KiCad/kicad-python/blob/master/kicad/pcbnew/board.py > > https://github.com/KiCad/kicad-python/blob/master/tests/unit/pcbnew/test_pcbnew_board.py > > > This is a work that Piers Titus van der Torren started, and that I perverted > a bit to > add documentation, testing, and trying to keep uniformity across all object > interfaces. > > If you want to contribute, it can be done via pull requests to the main > repository, > those are automatically checked by CI, and reported back to github. > > I haven't wrote any rules yet, but I really believe we should: > > 1) Document as we code > 2) Write unit tests as we code > > So we avoid regressions and provide a very consistent API for the users, > where > we can detect regressions or any issues. > > > Chris Pavlina wrote: > > > >wrt scripting and SWIG - SWIG's good for generating a low-level wrapper, > >but if we'd like scripting to go anywhere, I really think we should come > >up with a more scripting-friendly API and high-level wrapper. Something > >with more proper iterables, fewer integer enums, fewer getters and > >setters, objects that are fully and usefully introspectable at the > >console, etc. Fewer things like this scattered about: > > > >http://ci.kicad-pcb.org/job/kicad-doxygen/ws/build/pcbnew/doxygen-python/html/classpcbnew_1_1MODULE.html#a549dccf2a9eecffa83f76cfe8d1a7d19 > > > >Anyone else interested in seeing scripting improve? I'd be willing to > >contribute to this. > > > > > >On Sat, Jun 13, 2015 at 05:26:58PM -0400, Wayne Stambaugh wrote: > >> > >>On 6/12/2015 10:48 AM, Rob Maris wrote: > >>> > >>>Hi, > >>> > >>>I'm interested in adding Lua scripting to Kicad as an alternative to > >>>Python. Can anybody present some information about complexity and API in > >>>order to integrate a lua interpreter? > >>> > >>>Regards, > >>> > >>>Rob > >> > >>Rob, > >> > >>There has been some interest in lua in the past. I'm not opposed to > >>adding lua as another scripting language. I not sure if lua can be > >>swigged. That would be the preferred method for generating the lua > >>scripting libraries. To get an idea of the complexity of the kicad API, > >>look at the python swig code and the c++ code documentation at > >>kicad-pcb.org. At this time only Pcbnew is scripted. Eeschema is due a > >>major over hall after the next stable release so I expected it to be > >>scripted at that point. Also, we are pretty much in feature freeze for > >>the next stable release so anything major like supporting another > >>scripting language will have to wait until after the next stable release. > >> > >>Cheers, > >> > >>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 ___ 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] Select all previously searched text when opening Find / FindAndReplace dialogs
Hi all,
Here is a small patch to select the textbox when the Find dialog is opened.
This is more consistent with most text editors as far as I can tell, and
allows typing the needle right after Ctrl+F.
It used to bother me and I figured it would be an easy introduction to
contributing :)
Martin
PS: The following page http://www.kicad-pcb.org/display/DEV/Getting+Started
reads "git bzr clone lp:inkscape inkscape" where "inkscape should obviously
be "kicad"
From d4f607e297a84d9d59fd4ac2ba015b5a50b24ffb Mon Sep 17 00:00:00 2001
From: Martin d'Allens
Date: Sun, 14 Jun 2015 15:54:21 +0200
Subject: [PATCH] Select all previously searched text when opening Find /
FindAndReplace dialogs
---
eeschema/dialogs/dialog_schematic_find.cpp | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/eeschema/dialogs/dialog_schematic_find.cpp b/eeschema/dialogs/dialog_schematic_find.cpp
index 63800ef..5faa294 100644
--- a/eeschema/dialogs/dialog_schematic_find.cpp
+++ b/eeschema/dialogs/dialog_schematic_find.cpp
@@ -264,8 +264,10 @@ void DIALOG_SCH_FIND::SetFindEntries( const wxArrayString& aEntries )
{
m_comboFind->Append( aEntries );
-if( m_comboFind->GetCount() )
+if( m_comboFind->GetCount() ) {
m_comboFind->SetSelection( 0 );
+m_comboFind->SelectAll();
+}
}
@@ -273,6 +275,8 @@ void DIALOG_SCH_FIND::SetReplaceEntries( const wxArrayString& aEntries )
{
m_comboReplace->Append( aEntries );
-if( m_comboReplace->GetCount() )
+if( m_comboReplace->GetCount() ) {
m_comboReplace->SetSelection( 0 );
+m_comboFind->SelectAll();
+}
}
--
2.1.4
___
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] Scripting
Thanks Chris it’d be awesome!!, ping me anytime if you need me to clarify or fix anything of the design. A little bit in the heart of everything is this to let you “wrap” any given swig object (known by the library, of course): https://github.com/KiCad/kicad-python/blob/master/kicad/obj.py and the “new” method: https://github.com/KiCad/kicad-python/blob/master/kicad/__init__.py#L28 In C++ you’d do something like this with operator overload in the constructor, but python knows nothing about operator overloading, since it’s weakly typed. Best, Miguel Ángel Ajo On Sunday 14 June 2015 at 14:48, Chris Pavlina wrote: > Oh, sweet! I'll definitely contribute to this. Hopefully we can get it > in usable condition soon. Thanks! > > On Sun, Jun 14, 2015 at 12:23:16PM +0200, Miguel Angel Ajo wrote: > > I can't do more than agree, and this is why (very slowly) I'm working on > > this: > > > > https://github.com/kicad/kicad-python > > > > https://github.com/KiCad/kicad-python/blob/master/doc/source/index.rst > > > > https://github.com/KiCad/kicad-python/blob/master/kicad/pcbnew/board.py > > > > https://github.com/KiCad/kicad-python/blob/master/tests/unit/pcbnew/test_pcbnew_board.py > > > > > > This is a work that Piers Titus van der Torren started, and that I perverted > > a bit to > > add documentation, testing, and trying to keep uniformity across all object > > interfaces. > > > > If you want to contribute, it can be done via pull requests to the main > > repository, > > those are automatically checked by CI, and reported back to github. > > > > I haven't wrote any rules yet, but I really believe we should: > > > > 1) Document as we code > > 2) Write unit tests as we code > > > > So we avoid regressions and provide a very consistent API for the users, > > where > > we can detect regressions or any issues. > > > > > > Chris Pavlina wrote: > > > > > > wrt scripting and SWIG - SWIG's good for generating a low-level wrapper, > > > but if we'd like scripting to go anywhere, I really think we should come > > > up with a more scripting-friendly API and high-level wrapper. Something > > > with more proper iterables, fewer integer enums, fewer getters and > > > setters, objects that are fully and usefully introspectable at the > > > console, etc. Fewer things like this scattered about: > > > > > > http://ci.kicad-pcb.org/job/kicad-doxygen/ws/build/pcbnew/doxygen-python/html/classpcbnew_1_1MODULE.html#a549dccf2a9eecffa83f76cfe8d1a7d19 > > > > > > Anyone else interested in seeing scripting improve? I'd be willing to > > > contribute to this. > > > > > > > > > On Sat, Jun 13, 2015 at 05:26:58PM -0400, Wayne Stambaugh wrote: > > > > > > > > On 6/12/2015 10:48 AM, Rob Maris wrote: > > > > > > > > > > Hi, > > > > > > > > > > I'm interested in adding Lua scripting to Kicad as an alternative to > > > > > Python. Can anybody present some information about complexity and API > > > > > in > > > > > order to integrate a lua interpreter? > > > > > > > > > > Regards, > > > > > > > > > > Rob > > > > > > > > Rob, > > > > > > > > There has been some interest in lua in the past. I'm not opposed to > > > > adding lua as another scripting language. I not sure if lua can be > > > > swigged. That would be the preferred method for generating the lua > > > > scripting libraries. To get an idea of the complexity of the kicad API, > > > > look at the python swig code and the c++ code documentation at > > > > kicad-pcb.org (http://kicad-pcb.org). At this time only Pcbnew is > > > > scripted. Eeschema is due a > > > > major over hall after the next stable release so I expected it to be > > > > scripted at that point. Also, we are pretty much in feature freeze for > > > > the next stable release so anything major like supporting another > > > > scripting language will have to wait until after the next stable > > > > release. > > > > > > > > Cheers, > > > > > > > > Wayne > > > > > > > > ___ > > > > Mailing list: https://launchpad.net/~kicad-developers > > > > Post to : kicad-developers@lists.launchpad.net > > > > (mailto: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 > > > (mailto: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 > (mailto:kicad-developers@lists.launchpad.net) > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https
[Kicad-developers] [PATCH] Use the OS Documents folder for default project instead of CWD
Hi all,
This recent bug complains about the default project path being in a
read-only directory on Windows:
https://bugs.launchpad.net/kicad/+bug/1463510
The attached patch changes the default project folder to wx's
GetDocumentsDir(), which should translate to "$HOME", "...\My Documents"
(Win), or "~/Documents" (Mac).
I tested it solely on Ubuntu.
There could be more scenarios where we want to do the same. I tried to
extend this behaviour to Eeschema's standalone mode for starters, tell me
if more needs be done.
However the behaviour of writing to some default directory without asking
is unsettling. I suppose most noname.pro / noname.sch wouldn't exist if a
"Save as" popup was shown the first time.
Martin
From 0ed4dd0b95284baba8475144566cfaa0dddb74c2 Mon Sep 17 00:00:00 2001
From: Martin d'Allens
Date: Sun, 14 Jun 2015 18:10:23 +0200
Subject: [PATCH 2/2] Use the OS Documents folder for default project instead
of CWD (bug #1463510)
---
eeschema/schframe.cpp| 10 +-
kicad/kicad.cpp | 4 ++--
kicad/tree_project_frame.cpp | 3 ++-
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/eeschema/schframe.cpp b/eeschema/schframe.cpp
index 769d6cd..142c8bb 100644
--- a/eeschema/schframe.cpp
+++ b/eeschema/schframe.cpp
@@ -27,6 +27,7 @@
*/
#include
+#include
#include
#include
#include
@@ -330,7 +331,8 @@ SCH_EDIT_FRAME::SCH_EDIT_FRAME( KIWAY* aKiway, wxWindow* aParent ):
m_showAxis = false; // true to show axis
m_showBorderAndTitleBlock = true; // true to show sheet references
m_CurrentSheet = new SCH_SHEET_PATH;
-m_DefaultSchematicFileName = NAMELESS_PROJECT;
+m_DefaultSchematicFileName = wxStandardPaths::Get().GetDocumentsDir() + wxFileName::GetPathSeparator();
+m_DefaultSchematicFileName += NAMELESS_PROJECT;
m_DefaultSchematicFileName += wxT( ".sch" );
m_showAllPins = false;
m_previewPosition = wxDefaultPosition;
@@ -910,8 +912,7 @@ void SCH_EDIT_FRAME::OnLoadCmpToFootprintLinkFile( wxCommandEvent& event )
void SCH_EDIT_FRAME::OnNewProject( wxCommandEvent& event )
{
-// wxString pro_dir = wxPathOnly( Prj().GetProjectFullName() );
-wxString pro_dir = wxGetCwd();
+wxString pro_dir = wxStandardPaths::Get().GetDocumentsDir();
wxFileDialog dlg( this, _( "New Schematic" ), pro_dir,
wxEmptyString, SchematicFileWildcard,
@@ -943,8 +944,7 @@ void SCH_EDIT_FRAME::OnNewProject( wxCommandEvent& event )
void SCH_EDIT_FRAME::OnLoadProject( wxCommandEvent& event )
{
-// wxString pro_dir = wxPathOnly( Prj().GetProjectFullName() );
-wxString pro_dir = wxGetCwd();
+wxString pro_dir = wxStandardPaths::Get().GetDocumentsDir();
wxFileDialog dlg( this, _( "Open Schematic" ), pro_dir,
wxEmptyString, SchematicFileWildcard,
diff --git a/kicad/kicad.cpp b/kicad/kicad.cpp
index 4f497e2..08852eb 100644
--- a/kicad/kicad.cpp
+++ b/kicad/kicad.cpp
@@ -162,7 +162,7 @@ bool PGM_KICAD::OnPgmInit( wxApp* aWxApp )
{
GetFileHistory().RemoveFileFromHistory( 0 );
-wxFileName namelessProject( wxGetCwd(), NAMELESS_PROJECT,
+wxFileName namelessProject( wxStandardPaths::Get().GetDocumentsDir(), NAMELESS_PROJECT,
ProjectFileExtension );
frame->SetProjectFileName( namelessProject.GetFullPath() );
@@ -181,7 +181,7 @@ bool PGM_KICAD::OnPgmInit( wxApp* aWxApp )
}
else // there is no history
{
-wxFileName namelessProject( wxGetCwd(), NAMELESS_PROJECT,
+wxFileName namelessProject( wxStandardPaths::Get().GetDocumentsDir(), NAMELESS_PROJECT,
ProjectFileExtension );
frame->SetProjectFileName( namelessProject.GetFullPath() );
diff --git a/kicad/tree_project_frame.cpp b/kicad/tree_project_frame.cpp
index c02d681..cfb4d01 100644
--- a/kicad/tree_project_frame.cpp
+++ b/kicad/tree_project_frame.cpp
@@ -29,6 +29,7 @@
*/
#include
+#include
#include
#include
#include
@@ -592,7 +593,7 @@ void TREE_PROJECT_FRAME::ReCreateTreePrj()
if( !fn.IsOk() )
{
fn.Clear();
-fn.SetPath( ::wxGetCwd() );
+fn.SetPath( wxStandardPaths::Get().GetDocumentsDir() );
fn.SetName( NAMELESS_PROJECT );
fn.SetExt( ProjectFileExtension );
}
--
2.1.4
___
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] Increase layer thickness limit from 3mm to 10mm
Warning : this patch is extremely trivial. The following bug report argues that a 3mm PCB thickness limit is too small : https://bugs.launchpad.net/kicad/+bug/1463689 This patch increases the limit to 10mm, a somewhat arbitrary value. Martin From da458ea6d008671b33fa50b0f0e2422f7951f45c Mon Sep 17 00:00:00 2001 From: Martin d'Allens Date: Sun, 14 Jun 2015 19:04:10 +0200 Subject: [PATCH 3/3] Increase layer thickness limit from 3mm to 10mm (bug #1463689) --- pcbnew/dialogs/dialog_layers_setup.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pcbnew/dialogs/dialog_layers_setup.cpp b/pcbnew/dialogs/dialog_layers_setup.cpp index da06a75..6933b73 100644 --- a/pcbnew/dialogs/dialog_layers_setup.cpp +++ b/pcbnew/dialogs/dialog_layers_setup.cpp @@ -627,7 +627,7 @@ void DIALOG_LAYERS_SETUP::OnOkButtonClick( wxCommandEvent& event ) // Clamp the value between reasonable values -thickness = Clamp( Millimeter2iu( 0.1 ), thickness, Millimeter2iu( 3.0 ) ); +thickness = Clamp( Millimeter2iu( 0.1 ), thickness, Millimeter2iu( 10.0 ) ); m_pcb->GetDesignSettings().SetBoardThickness( thickness ); EndModal( wxID_OK ); -- 2.1.4 ___ 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] Increase layer thickness limit from 3mm to 10mm
I agree with Martin, 3mm limit is too low. I used to build backplanes that were 3/16” thick and 24 layers with a lot of controlled impedance layers. Just my $0.02, Jean-Paul AC9GH > On Jun 14, 2015, at 1:09 PM, Martin d'Allens wrote: > > Warning : this patch is extremely trivial. > > The following bug report argues that a 3mm PCB thickness limit is too small : > https://bugs.launchpad.net/kicad/+bug/1463689 > > This patch increases the limit to 10mm, a somewhat arbitrary value. > > Martin > <0003-Increase-layer-thickness-limit-from-3mm-to-10mm-bug-.patch>___ > 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] Increase layer thickness limit from 3mm to 10mm
Le 14/06/2015 19:09, Martin d'Allens a écrit : > Warning : this patch is extremely trivial. > > The following bug report argues that a 3mm PCB thickness limit is too small > : > https://bugs.launchpad.net/kicad/+bug/1463689 > > This patch increases the limit to 10mm, a somewhat arbitrary value. > > Martin Committed. 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
Re: [Kicad-developers] [PATCH] Select all previously searched text when opening Find / FindAndReplace dialogs
2015-06-14 16:06 GMT+02:00 Martin d'Allens : > PS: The following page http://www.kicad-pcb.org/display/DEV/Getting+Started > reads "git bzr clone lp:inkscape inkscape" where "inkscape should obviously > be "kicad" Fixed. ___ 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] Display pin/entry targets while moving part
This patch displays pin and bus entry targets while they are being
moved, as they are also dangling then (even though the dangling status
has not been updated). This seems to make the interface feel a bit more
responsive, IMO.
--
Chris
commit e2ac9aaff17da3e8cdf3bfb5a698194eb8216d9d
Author: Chris Pavlina
Date: Sun Jun 14 15:24:47 2015 -0400
Display pin targets while dragging components and bus entries
diff --git a/eeschema/sch_bus_entry.cpp b/eeschema/sch_bus_entry.cpp
index 6b3e3b6..b26d5d6 100644
--- a/eeschema/sch_bus_entry.cpp
+++ b/eeschema/sch_bus_entry.cpp
@@ -195,11 +195,15 @@ void SCH_BUS_ENTRY_BASE::Draw( EDA_DRAW_PANEL* aPanel, wxDC* aDC, const wxPoint&
GRLine( clipbox, aDC, m_pos.x + aOffset.x, m_pos.y + aOffset.y,
m_End().x + aOffset.x, m_End().y + aOffset.y, GetPenSize(), color );
-if( m_isDanglingStart ) {
+
+// Draw pin targets if part is being dragged
+bool dragging = ( aPanel->GetScreen()->GetCurItem() == this );
+
+if( m_isDanglingStart || dragging ) {
GRCircle( clipbox, aDC, m_pos.x + aOffset.x, m_pos.y + aOffset.y, TARGET_BUSENTRY_RADIUS, 0, color );
}
-if( m_isDanglingEnd ) {
+if( m_isDanglingEnd || dragging ) {
GRCircle( clipbox, aDC, m_End().x + aOffset.x, m_End().y + aOffset.y, TARGET_BUSENTRY_RADIUS, 0, color );
}
}
diff --git a/eeschema/sch_component.cpp b/eeschema/sch_component.cpp
index dbe2f81..44763d5 100644
--- a/eeschema/sch_component.cpp
+++ b/eeschema/sch_component.cpp
@@ -350,8 +350,11 @@ void SCH_COMPONENT::Draw( EDA_DRAW_PANEL* aPanel, wxDC* aDC, const wxPoint& aOff
{
if( PART_SPTR part = m_part.lock() )
{
+// Draw pin targets if part is being dragged
+bool dragging = ( aPanel->GetScreen()->GetCurItem() == this );
+
part->Draw( aPanel, aDC, m_Pos + aOffset, m_unit, m_convert, aDrawMode, aColor,
-m_transform, aDrawPinText, false, false, &m_isDangling );
+m_transform, aDrawPinText, false, false, dragging ? NULL : &m_isDangling );
}
else// Use dummy() part if the actual cannot be found.
{
___
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] OSX: Pin Table crashes Library Editor
Hi,FYI… I guess this is only OS X related.Yesterday I wanted to use the Pin Table for the first time and it always crashes the Library Editor.After some debugging I am pretty sure that this is a bug in the OS X implementation of wxDataViewCtrl if using wx[V|H]SCROLL when creating it.Did the Pin Table ever work for somebody on OS X (I guess it never did)?I already filed a bug report for wxWidgets (still under moderation, so it doesn’t show up yet).I don’t know how long this will take, so attached a fix/workaround that did it for me (for anyone interested, maybe Adam?).The only possible workaround in KiCad seems to be to remove the wxVSCROLL fromm_Pins = new wxDataViewCtrl( this, wxID_ANY, wxDefaultPosition, wxSize( -1,-1 ), wxDV_HORIZ_RULES|wxDV_MULTIPLE|wxDV_ROW_LINES|wxDV_VERT_RULES|wxVSCROLL ); In my tests OS X doesn’t seem to need this (scroll bars are dynamically shown when needed even without this flag).But, I don’t know about other platforms and this piece of code probably can’t be #ifdef’d because this is generated code from wxFormBuilder?Regards,Bernhard wxWidgets_dataview_crash.patch Description: Binary data ___ 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] Use new footprint selector for "Change Footprints"
This patch enables use of the new (kiface) footprint selector in the
"Exchange Footprints" dialog.
As suggested in this bug report: https://bugs.launchpad.net/kicad/+bug/1464821
I'll look into making this change in the module editor as well, but that
will require more work.
--
Chris
commit 6f3c07f0835898bb4cc022b45c586c4aecaef4b2
Author: Chris Pavlina
Date: Sun Jun 14 16:28:06 2015 -0400
Use new footprint selector for "Change Footprints"
diff --git a/pcbnew/xchgmod.cpp b/pcbnew/xchgmod.cpp
index 3ae43b8..a481419 100644
--- a/pcbnew/xchgmod.cpp
+++ b/pcbnew/xchgmod.cpp
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
#include
@@ -95,14 +96,14 @@ void PCB_EDIT_FRAME::InstallExchangeModuleFrame( MODULE* Module )
{
DIALOG_EXCHANGE_MODULE dialog( this, Module );
-dialog.ShowModal();
+dialog.ShowQuasiModal();
}
void DIALOG_EXCHANGE_MODULE::OnQuit( wxCommandEvent& event )
{
m_selectionMode = m_Selection->GetSelection();
-EndModal( 0 );
+EndQuasiModal( wxID_CANCEL );
}
@@ -507,11 +508,14 @@ void DIALOG_EXCHANGE_MODULE::BrowseAndSelectFootprint( wxCommandEvent& event )
{
wxString newname;
-newname = m_parent->SelectFootprint( m_parent, wxEmptyString, wxEmptyString, wxEmptyString,
- Prj().PcbFootprintLibs() );
+KIWAY_PLAYER* frame = Kiway().Player( FRAME_PCB_MODULE_VIEWER_MODAL, true );
-if( newname != wxEmptyString )
+if( frame->ShowModal( &newname, this ) )
+{
m_NewModule->SetValue( newname );
+}
+
+frame->Destroy();
}
___
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] Plugin plans (post-stable release)
Peter Clifton has been using stepcode for his work on creating STEP models for gEda; we agree that it is the best option to use which isn't very heavy like OCC. Peter has had to fix a few bugs in stepcode but has successfully created some models. I have a copy of the 2014 Step Module Resource Library but the SMRL does not include STEP AP214 which is one of the most common APs for parts models partly because it includes colors. The SMRL does have AP203e2, which is AP203 with parts like color borrowed from AP214, and AP242 which is the merger of AP203 and AP214 (and not yet commonly implemented by MCADs). For a functional STEP export we will need to support AP203 and AP214; I do not believe we will ever have to support AP203e2, but maybe in 5 years we will need to support AP242. - Cirilo On Sun, Jun 14, 2015 at 9:35 PM, jp charras wrote: > Le 14/06/2015 12:01, Tomasz Wlostowski a écrit : > > On 14.06.2015 02:35, Cirilo Bernardo wrote: > >> 7. STEP: (future plans) the plugin will only provide an Export > > > > I'd also like to add STEP visualization in the near future (post-stable > ofc) > > > > Tom > > > > PS. It is possible to export a hierarchical assembly in STEP from OCC. > > No need to write a special library for that. > > We all agree (at least guys like me who make designs with very strong > mechanical constraints) step import/export is a major feature. > > However, OCC is a very heavy dependency for Kicad. > I am not especially thrilled by OCC dependency. > > If stepcode is usable, this is a (by far) preferable dependency, even it > is not perfect. > > > -- > 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
[Kicad-developers] [PATCH] Increased CMake download timeout for boost and openssl
Hi,
I an new to this forum. I have been using KiCad for a little while now
and started looking at how to make some modifications.
Here is a first trivial patch to extend the download timeout in CMake
for some modules.
I found that while using WinBuilder on an older laptop, the boost
download was cut off due to the timeout. After extending the timeout,
the build completes fine on this older machine. The timeout in the
openssl download was also increased.
=== modified file 'CMakeModules/download_boost.cmake'
--- CMakeModules/download_boost.cmake2015-03-03 16:12:41 +
+++ CMakeModules/download_boost.cmake2015-06-13 02:49:50 +
@@ -184,7 +184,7 @@
URL
http://downloads.sourceforge.net/project/boost/boost/${BOOST_RELEASE}/boost_${BOOST_VERS}.tar.bz2
DOWNLOAD_DIR"${DOWNLOAD_DIR}"
-TIMEOUT 1200# 20 minutes
+TIMEOUT 3600# 60 minutes
URL_MD5 ${BOOST_MD5}
# If download fails, then enable "LOG_DOWNLOAD ON" and try again.
# Upon a second failure with logging enabled, then look at these logs:
=== modified file 'CMakeModules/download_openssl.cmake'
--- CMakeModules/download_openssl.cmake2014-04-03 11:55:02 +
+++ CMakeModules/download_openssl.cmake2015-06-13 02:49:40 +
@@ -54,7 +54,7 @@
openssl
DOWNLOAD_DIR ${DOWNLOAD_DIR}
PREFIX ${PREFIX}
-TIMEOUT 60
+TIMEOUT 3600
URL
http://launchpad.net/openssl-cmake/1.0.1e/1.0.1e-1/+download/openssl-cmake-1.0.1e-src.tar.gz
URL_MD5 ${OPENSSL_MD5}
--
Marco Hess
Through IP Pty. Ltd. - AUSTRALIA
www.through-ip.com | marco.h...@through-ip.com
p: +61 407 78 55 66 | f: +61 8 8121 6191
___
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] Increased CMake download timeout for boost and openssl
You might want to keep these patches in your local repo although there
is no harm in committing them. All of the external dependency download
and build code is going away after the stable release.
On 6/14/2015 8:28 PM, Marco Hess wrote:
> Hi,
>
> I an new to this forum. I have been using KiCad for a little while now
> and started looking at how to make some modifications.
>
> Here is a first trivial patch to extend the download timeout in CMake
> for some modules.
>
> I found that while using WinBuilder on an older laptop, the boost
> download was cut off due to the timeout. After extending the timeout,
> the build completes fine on this older machine. The timeout in the
> openssl download was also increased.
>
> === modified file 'CMakeModules/download_boost.cmake'
> --- CMakeModules/download_boost.cmake2015-03-03 16:12:41 +
> +++ CMakeModules/download_boost.cmake2015-06-13 02:49:50 +
> @@ -184,7 +184,7 @@
>
> URL
> http://downloads.sourceforge.net/project/boost/boost/${BOOST_RELEASE}/boost_${BOOST_VERS}.tar.bz2
>
> DOWNLOAD_DIR"${DOWNLOAD_DIR}"
> -TIMEOUT 1200# 20 minutes
> +TIMEOUT 3600# 60 minutes
> URL_MD5 ${BOOST_MD5}
> # If download fails, then enable "LOG_DOWNLOAD ON" and try again.
> # Upon a second failure with logging enabled, then look at these logs:
>
> === modified file 'CMakeModules/download_openssl.cmake'
> --- CMakeModules/download_openssl.cmake2014-04-03 11:55:02 +
> +++ CMakeModules/download_openssl.cmake2015-06-13 02:49:40 +
> @@ -54,7 +54,7 @@
> openssl
> DOWNLOAD_DIR ${DOWNLOAD_DIR}
> PREFIX ${PREFIX}
> -TIMEOUT 60
> +TIMEOUT 3600
> URL
> http://launchpad.net/openssl-cmake/1.0.1e/1.0.1e-1/+download/openssl-cmake-1.0.1e-src.tar.gz
>
> URL_MD5 ${OPENSSL_MD5}
>
>
>
___
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] future of complex board shapes
Lately I have seen more people asking about board shapes which are not easily described by a small number of line segments and circular arcs, and Jean-Pierre mentioned STEP Import for a board shape. I think the best mechanism for complex board shapes will remain the DXF format since STEP (or even IGES) can contain so much information and it is impossible to guess the design intent; however many MCADs will create a DXF outline which will make use of circular arcs, line segments, ellipses, Rational Polynomial Curves, NURBS, and occasionally even Bezier curves. I would suggest that rather than think of attempting to import a board outline + cutouts + drill holes from STEP/IGES we should add to the features of the DXF importer to support at least ellipses and rational polynomial curves (which is what SolidWorks uses even for circular arcs) and possibly 2D NURBS if anyone knows an MCAD that exports it in DXF. The question of natively supporting RPCs and NURBS within KiCad is something to consider in order to preserve such information which is ultimately imported from MCADs, even if we never support native tools to edit these entities. Who knows, maybe in the future someone would like to use such features to describe a track shape rather than generating an inefficient line segment approximation (oh, the DRC nightmare). In the (far) future there is also the PRC file specification which I think would be very good to support. At the very least we can create previews of STEP and IGES files for quick display and this would also allow the eventual creation and decoding of 3D PDFs. The specification allows arbitrary metadata which in theory we can exploit to ensure that KiCad knows what parts are outlines, cutouts, drill holes (N/PTH) and we can have more unambiguous exchange of data; of course every MCAD would need an exporter which could provide the information in just the way KiCad wants, so this would not only be a huge project but we can safely guarantee that DXF will remain the best general solution. - 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
