Re: [Kicad-developers] announcing eeshow (schematics renderer and viewer)
Eldar Khayrullin wrote: > Now eeshow search relative path relative current directory ($PWD) but should > to search relative project file path. Errors if $PWD not equal to project > file path. Hmm, that seems to work here. For example: ~/t$ grep Lib test.pro LibDir=y LibName1=test ~/t$ ls test.pro test.sch x/ y/ ~/t$ ls y test.lib ~/t$ cd x ~/t/x$ eeshow ../test.pro Could you please provide more details on the context in which it fails ? E.g., LibDir and LibNameX, and the exact invocation ? > eeshow doesn't search title sheets in default directory > /usr/share/kicad/template/. Now it does :-) > I use gost_landscape.kicad_wks from there. There were a few more things missing before that one would render properly, now added. Alas, Cairo's "toy" text system doesn't seem to want to render Cyrillic characters, but you can make eeshow use Pango, by adding the option -P Unfortunately, Pango is much slower than Cairo and I haven't implemented overlining support for Pango yet. - Werner ___ 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] [RFC] [PATCH] simple C++ tests
Tom,
Here's a patch against your patch that fixes the compile and some of the
link issues. It linker still cannot find some of the PNS_NODE code. I
thought PNS_NODE was in the libpcbcommon.a library but apparently not.
I'm calling it a night. I'll see if I can get it to build tomorrow.
Cheers,
Wayne
On 9/7/2016 5:39 PM, Tomasz Wlostowski wrote:
> On 07.09.2016 21:24, Wayne Stambaugh wrote:
>> Tom,
>>
>> I also forgot to mention there were tabs in the CMakeLists.txt file.
>>
> Hi Wayne,
>
> Here's a (hopefully) fixed version.
>
> Cheers,
> Tom
>
>> Cheers,
>>
>> Wayne
>>
>> On 9/7/2016 12:17 PM, Tomasz Wlostowski wrote:
>>> Hi,
>>>
>>> This patch adds possibility to build C++ tests for pcbnew, using
>>> Boost.Test framework. I intended it primarily to make tests for the P&S,
>>> which I used to develop out-of-tree before.
>>>
>>> Since Kicad's codebase is rather monolithic, testing/refactoring
>>> anything drags in pretty much everything else in the code as a
>>> dependency. This causes long rebuild and linking times, which I find
>>> very annoying. Also, while developing new features, most of the time is
>>> spent linking pcbnew and clicking in the GUI to trigger the particular
>>> feature.
>>>
>>> For that reason I decided to link all the test cases directly to the
>>> _pcbnew_kiface library and skip pcbnew's dependency scanning when
>>> building tests. I'm also preparing a bare PCB test window for verifying
>>> interactive/graphical operations without rebuilding pcbnew as a whole app.
>>>
>>> I've attached the patch (set the KICAD_BUILD_TESTS=ON option to enable).
>>> There's one trivial unit test included as an example. Let me know if
>>> such solution would be acceptable.
>>>
>>> Cheers,
>>> Tom
>>>
>>>
>>>
>>> ___
>>> 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
>>
>
diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt
index 6a3abea..cc1254c 100644
--- a/tests/CMakeLists.txt
+++ b/tests/CMakeLists.txt
@@ -1,15 +1,21 @@
-include_directories (
-${CMAKE_SOURCE_DIR}
+include_directories(
+${CMAKE_BINARY_DIR}
+${CMAKE_SOURCE_DIR}
${CMAKE_SOURCE_DIR}/polygon
${CMAKE_SOURCE_DIR}/include
${CMAKE_SOURCE_DIR}/pcbnew
-${CMAKE_SOURCE_DIR}/pcbnew/router )
+${CMAKE_SOURCE_DIR}/pcbnew/router
+)
-link_directories ( ${CMAKE_BINARY_DIR}/pcbnew )
+link_directories( ${CMAKE_BINARY_DIR}/pcbnew )
function( add_test_case name )
-add_executable ( ${name} ${name}.cpp )
-target_link_libraries ( ${name} ${wxWidgets_LIBRARIES} _pcbnew_kiface
${Boost_LIBRARIES} )
+add_executable( ${name} ${name}.cpp )
+target_link_libraries( ${name} ${wxWidgets_LIBRARIES}
+${CMAKE_BINARY_DIR}/pcbnew/_pcbnew.kiface
+${CMAKE_BINARY_DIR}/common/libcommon.a
+${CMAKE_BINARY_DIR}/common/libpcbcommon.a
+${Boost_LIBRARIES} )
endfunction( add_test_case )
-add_subdirectory ( pns )
+add_subdirectory( pns )
diff --git a/tests/pns/CMakeLists.txt b/tests/pns/CMakeLists.txt
index b305e1e..2da310b 100644
--- a/tests/pns/CMakeLists.txt
+++ b/tests/pns/CMakeLists.txt
@@ -1,3 +1 @@
add_test_case( test_node )
-
-
___
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] announcing eeshow (schematics renderer and viewer)
Eldar Khayrullin wrote: > Conflicting of libgit2-dev (eeshow dependence) and libcurl4-openssl-dev > (kicad dependence) packages in Ubuntu. If you're on a "stable" installation (i.e., a base one should reasonably expect to have no such issues), that would be something you may want to report this to the package maintainers. What I do when there are conflicts is that I use "aptitude" instead of "apt-get" to install the new package. Aptitude searches for ways to resolve the conflicts, e.g., by changing (usually downgrading) other packages in the dependency graph. I typically look at a few first few proposals aptitude makes, then start it again and pick one. The first one is usually to keep the package I ask for at the current version (i.e., not installed), but the rest tend to be more reasonable. I'd avoid the ones that involve rearranging lots of things or sending some package back by many revisions, though. - Werner ___ 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] wxformbuilder version
Sorry - ignore the last post - I managed to miss the part of the patch that did specify the branch. - Cirilo On Thu, Sep 8, 2016 at 8:08 AM, Cirilo Bernardo wrote: > I think the note needs to add some instructions to check out the > wxFB3.5-RC1 branch. > The default 'master' is probably not something we want at this point in > time. > > - Cirilo > > On Wed, Sep 7, 2016 at 10:09 PM, Maciej Sumiński > wrote: > >> Wayne, >> >> I attach a patch updating the UI policy. I would rather you commit the >> patch, to be sure you agree with the changes. >> >> Regards, >> Orson >> >> On 09/03/2016 02:17 AM, Wayne Stambaugh wrote: >> > We've been dancing around this issue for a while without any real >> > resolution. I'm fine with using Mark's version of wxFB but a lot folks >> > are going to want to use whatever is packaged for their distro rather >> > than build wxFB from source which presents a serious issue. I'm not >> > sure there is a good answer for this problem. If no one else has any >> > objections, I'm willing to make Mark's wxFB fork the official version >> > for KiCad dialog submission for the time being. In the long run, if >> > wxFB is not actively being developed, I would rather come up with an >> > alternative. >> > >> > FWIW, I think most of you know how I feel about dialog creation tools >> > vs. creating them programmatically. Kicad's dialogs used to be created >> > this way but I got out voted at the time the decision was made to switch >> > to wxFB. I'm feeling better about my choice all the time. ;) >> > >> > On 9/2/2016 7:11 PM, Chris Pavlina wrote: >> >> I would vote in favor of using Mark's fork officially for everyone, if >> >> it builds okay on all the platforms. wxfb is kinda nasty, if we're >> going >> >> to use it it's nice to have our own fork that solves at least a few of >> >> these issues. >> >> >> >> On Sat, Sep 03, 2016 at 08:45:12AM +1000, Cirilo Bernardo wrote: >> >>> I just use MRoszko's fork; it's cleaner than the original and much >> >>> easier to configure and build since the bizarre wxFB build system >> >>> had been eradicated and replaced by CMake. >> >>> >> >>> git clone https://github.com/marekr/wxFormBuilder.git wxfb >> >>> cd wxfb && git checkout wxFB3.5-1 >> >>> >> >>> A half year or so ago I tried the later wxFB in development but it >> >>> broke so many things that I just reverted the files and went back to >> >>> wxFB3,5-1. >> >>> >> >>> - Cirilo >> >>> >> >>> >> >>> On Sat, Sep 3, 2016 at 7:28 AM, Chris Pavlina < >> pavlina.ch...@gmail.com> >> >>> wrote: >> >>> >> Along these lines: this isn't the first time wxfb version issues have >> come up. Perhaps we should pick an "official" wxfb version for the >> project to use, and then actually provide builds of it for developer >> use >> (as it can be a bit annoying to track down a specific version)? Then >> we >> can upgrade together as new versions come out. >> >> >> On Sat, Sep 03, 2016 at 09:16:41AM +1200, Simon Wells wrote: >> > dialog_pad_properties_base.fbp h cpp was last modified in commit >> > >> > 63decd70e6ab1bf2fe95db3f426f6cdfc79be213 >> > https://git.launchpad.net/kicad/commit/?id= >> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213 >> > >> > the problem is this version of wxformbuilder is newer than the one >> > available on sourceforge and it is very difficult to build on other >> > platforms ( i tried a while ago and gave up as it had issues) >> > >> > the version that was used to save these files has broken it on older >> > versions of wxformbuilder >> > >> > Is there a version of wxformbuilder that we should be using to avoid >> > it breaking on other versions? >> > >> > the last available from sf.net is 3.5rc1 iirc >> > >> > thanks >> > >> > 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
Re: [Kicad-developers] wxformbuilder version
I think the note needs to add some instructions to check out the wxFB3.5-RC1 branch. The default 'master' is probably not something we want at this point in time. - Cirilo On Wed, Sep 7, 2016 at 10:09 PM, Maciej Sumiński wrote: > Wayne, > > I attach a patch updating the UI policy. I would rather you commit the > patch, to be sure you agree with the changes. > > Regards, > Orson > > On 09/03/2016 02:17 AM, Wayne Stambaugh wrote: > > We've been dancing around this issue for a while without any real > > resolution. I'm fine with using Mark's version of wxFB but a lot folks > > are going to want to use whatever is packaged for their distro rather > > than build wxFB from source which presents a serious issue. I'm not > > sure there is a good answer for this problem. If no one else has any > > objections, I'm willing to make Mark's wxFB fork the official version > > for KiCad dialog submission for the time being. In the long run, if > > wxFB is not actively being developed, I would rather come up with an > > alternative. > > > > FWIW, I think most of you know how I feel about dialog creation tools > > vs. creating them programmatically. Kicad's dialogs used to be created > > this way but I got out voted at the time the decision was made to switch > > to wxFB. I'm feeling better about my choice all the time. ;) > > > > On 9/2/2016 7:11 PM, Chris Pavlina wrote: > >> I would vote in favor of using Mark's fork officially for everyone, if > >> it builds okay on all the platforms. wxfb is kinda nasty, if we're going > >> to use it it's nice to have our own fork that solves at least a few of > >> these issues. > >> > >> On Sat, Sep 03, 2016 at 08:45:12AM +1000, Cirilo Bernardo wrote: > >>> I just use MRoszko's fork; it's cleaner than the original and much > >>> easier to configure and build since the bizarre wxFB build system > >>> had been eradicated and replaced by CMake. > >>> > >>> git clone https://github.com/marekr/wxFormBuilder.git wxfb > >>> cd wxfb && git checkout wxFB3.5-1 > >>> > >>> A half year or so ago I tried the later wxFB in development but it > >>> broke so many things that I just reverted the files and went back to > >>> wxFB3,5-1. > >>> > >>> - Cirilo > >>> > >>> > >>> On Sat, Sep 3, 2016 at 7:28 AM, Chris Pavlina > > >>> wrote: > >>> > Along these lines: this isn't the first time wxfb version issues have > come up. Perhaps we should pick an "official" wxfb version for the > project to use, and then actually provide builds of it for developer > use > (as it can be a bit annoying to track down a specific version)? Then > we > can upgrade together as new versions come out. > > > On Sat, Sep 03, 2016 at 09:16:41AM +1200, Simon Wells wrote: > > dialog_pad_properties_base.fbp h cpp was last modified in commit > > > > 63decd70e6ab1bf2fe95db3f426f6cdfc79be213 > > https://git.launchpad.net/kicad/commit/?id= > 63decd70e6ab1bf2fe95db3f426f6cdfc79be213 > > > > the problem is this version of wxformbuilder is newer than the one > > available on sourceforge and it is very difficult to build on other > > platforms ( i tried a while ago and gave up as it had issues) > > > > the version that was used to save these files has broken it on older > > versions of wxformbuilder > > > > Is there a version of wxformbuilder that we should be using to avoid > > it breaking on other versions? > > > > the last available from sf.net is 3.5rc1 iirc > > > > thanks > > > > 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
Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests
On 07.09.2016 21:24, Wayne Stambaugh wrote:
> Tom,
>
> I also forgot to mention there were tabs in the CMakeLists.txt file.
>
Hi Wayne,
Here's a (hopefully) fixed version.
Cheers,
Tom
> Cheers,
>
> Wayne
>
> On 9/7/2016 12:17 PM, Tomasz Wlostowski wrote:
>> Hi,
>>
>> This patch adds possibility to build C++ tests for pcbnew, using
>> Boost.Test framework. I intended it primarily to make tests for the P&S,
>> which I used to develop out-of-tree before.
>>
>> Since Kicad's codebase is rather monolithic, testing/refactoring
>> anything drags in pretty much everything else in the code as a
>> dependency. This causes long rebuild and linking times, which I find
>> very annoying. Also, while developing new features, most of the time is
>> spent linking pcbnew and clicking in the GUI to trigger the particular
>> feature.
>>
>> For that reason I decided to link all the test cases directly to the
>> _pcbnew_kiface library and skip pcbnew's dependency scanning when
>> building tests. I'm also preparing a bare PCB test window for verifying
>> interactive/graphical operations without rebuilding pcbnew as a whole app.
>>
>> I've attached the patch (set the KICAD_BUILD_TESTS=ON option to enable).
>> There's one trivial unit test included as an example. Let me know if
>> such solution would be acceptable.
>>
>> Cheers,
>> Tom
>>
>>
>>
>> ___
>> 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
>
>From 287624c8bee0c6d3c05877c41533fc90b3ab2523 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomasz=20W=C5=82ostowski?=
Date: Wed, 7 Sep 2016 17:53:20 +0200
Subject: [PATCH] Initial support for unit tests in pcbnew using Boost.Test
---
CMakeLists.txt | 32 ++--
pcbnew/CMakeLists.txt| 12
tests/CMakeLists.txt | 15 +++
tests/pns/CMakeLists.txt | 3 +++
tests/pns/test_node.cpp | 21 +
5 files changed, 73 insertions(+), 10 deletions(-)
create mode 100644 tests/CMakeLists.txt
create mode 100644 tests/pns/CMakeLists.txt
create mode 100644 tests/pns/test_node.cpp
diff --git a/CMakeLists.txt b/CMakeLists.txt
index bfeaac5..b3371f6 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -49,6 +49,9 @@ option( KICAD_USE_OCE
"Build tools and plugins related to OpenCascade Community Edition (default OFF)"
)
+option( KICAD_BUILD_TESTS
+"Builds C++ tests (default OFF)"
+)
# when option KICAD_SCRIPTING OR KICAD_SCRIPTING_MODULES is enabled:
# PYTHON_EXECUTABLE can be defined when invoking cmake
# ( use -DPYTHON_EXECUTABLE=/python.exe or python2 )
@@ -69,10 +72,14 @@ option( KICAD_SPICE "Build Kicad with internal Spice simulator." OFF )
set( KICAD_REPO_NAME "product" CACHE STRING "Name of the tree from which this build came." )
-# Global setting: exports are explicit
-set( CMAKE_CXX_VISIBILITY_PRESET "hidden" )
-set( CMAKE_VISIBILITY_INLINES_HIDDEN ON )
-
+# Global setting: exports are explicit by default
+if ( KICAD_BUILD_TESTS )
+set( CMAKE_CXX_VISIBILITY_PRESET "default" )
+set( CMAKE_VISIBILITY_INLINES_HIDDEN OFF )
+else()
+set( CMAKE_CXX_VISIBILITY_PRESET "hidden" )
+set( CMAKE_VISIBILITY_INLINES_HIDDEN ON )
+endif()
# Global setting: build everything position independent
set( CMAKE_POSITION_INDEPENDENT_CODE ON )
@@ -93,11 +100,13 @@ if( POLICY CMP0063 )
cmake_policy( SET CMP0063 NEW )
endif()
else()
-if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY AND NOT APPLE )
-set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY}hidden" )
-endif()
-if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN AND NOT APPLE )
-set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN}" )
+if( CMAKE_CXX_VISIBILITY_PRESET STREQUAL "hidden" )
+if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY AND NOT APPLE )
+set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY}hidden" )
+endif()
+if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN AND NOT APPLE )
+set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN}" )
+endif()
endif()
endif()
@@ -503,7 +512,7 @@ find_package( Cairo 1.8.8 REQUIRED )
#
# Note: Prior to Boost 1.59, the Boost context library is not built when compiling on windows
# with GCC. You must patch the Boost sources.
-find_package( Boost 1.54.0 REQUIRED COMPONENTS context system thread )
+find_p
Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests
Tom, I also forgot to mention there were tabs in the CMakeLists.txt file. Cheers, Wayne On 9/7/2016 12:17 PM, Tomasz Wlostowski wrote: > Hi, > > This patch adds possibility to build C++ tests for pcbnew, using > Boost.Test framework. I intended it primarily to make tests for the P&S, > which I used to develop out-of-tree before. > > Since Kicad's codebase is rather monolithic, testing/refactoring > anything drags in pretty much everything else in the code as a > dependency. This causes long rebuild and linking times, which I find > very annoying. Also, while developing new features, most of the time is > spent linking pcbnew and clicking in the GUI to trigger the particular > feature. > > For that reason I decided to link all the test cases directly to the > _pcbnew_kiface library and skip pcbnew's dependency scanning when > building tests. I'm also preparing a bare PCB test window for verifying > interactive/graphical operations without rebuilding pcbnew as a whole app. > > I've attached the patch (set the KICAD_BUILD_TESTS=ON option to enable). > There's one trivial unit test included as an example. Let me know if > such solution would be acceptable. > > Cheers, > Tom > > > > ___ > 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] Undo buffer refactor
On 06.09.2016 11:45, jp charras wrote: Le 05/09/2016 à 23:34, Sergey Borshch a écrit : On 05.09.2016 17:06, Maciej Sumiński wrote: As you may have noticed, there are a lot of changes to the KiCad internals. It would be great if there were some brave folks to take the branch for a test ride. I'm unable to compile it: sources/pcb_calculator/attenuators/attenuator_classes.cpp:100:21: error: cannot convert ‘wxString (*)()’ to ‘wxString*’ in assignment m_FormulaName = &pi_formula; ^ sources/pcb_calculator/attenuators/attenuator_classes.cpp: In constructor ‘ATTENUATOR_TEE::ATTENUATOR_TEE()’: sources/pcb_calculator/attenuators/attenuator_classes.cpp:121:21: error: cannot convert ‘wxString (*)()’ to ‘wxString*’ in assignment m_FormulaName = &tee_formula; ^ sources/pcb_calculator/attenuators/attenuator_classes.cpp: In constructor ‘ATTENUATOR_BRIDGE::ATTENUATOR_BRIDGE()’: sources/pcb_calculator/attenuators/attenuator_classes.cpp:144:21: error: cannot convert ‘wxString (*)()’ to ‘wxString*’ in assignment m_FormulaName = &bridget_tee_formula; ^ sources/pcb_calculator/attenuators/attenuator_classes.cpp: In constructor ‘ATTENUATOR_SPLITTER::ATTENUATOR_SPLITTER()’: sources/pcb_calculator/attenuators/attenuator_classes.cpp:170:21: error: cannot convert ‘wxString (*)()’ to ‘wxString*’ in assignment m_FormulaName = &splitter_formula; ^ pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/build.make:625: recipe for target 'pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/attenuators/attenuator_classes.cpp.o' failed Looks like it is a compiler issue. What compiler are you using? g++ (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609 I'm under Linux Mint 18 and it seems like problem began after system upgrade from Mint 17.3. Reinstalling all wx components fixed the issue. -- Regards, Sergey A. Borshchmailto: sb...@users.sourceforge.net SB ELDI ltd. Riga, Latvia ___ 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] [RFC] [PATCH] simple C++ tests
Tom, It looks like you did not include the build path in the unit test build configuration. I'm getting a build error when the unit test is enabled: [ 33%] Building CXX object tests/pns/CMakeFiles/test_node.dir/test_node.cpp.obj In file included from C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/pcbnew.h:33:0, from C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/class_track.h:34, from C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/router/pns_via.h:28, from C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/router/pns_line.h:33, from C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/router/pns_segment.h:32, from C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/router/pns_joint.h:31, from C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/router/pns_node.h:37, from C:/msys64/home/wstambaugh/src/kicad-trunk/tests/pns/test_node.cpp:7: C:/msys64/home/wstambaugh/src/kicad-trunk/include/fctsys.h:37:20: fatal error: config.h: No such file or directory compilation terminated. make[2]: *** [tests/pns/CMakeFiles/test_node.dir/build.make:63: tests/pns/CMakeFiles/test_node.dir/test_node.cpp.obj] Error 1 On 9/7/2016 12:17 PM, Tomasz Wlostowski wrote: > Hi, > > This patch adds possibility to build C++ tests for pcbnew, using > Boost.Test framework. I intended it primarily to make tests for the P&S, > which I used to develop out-of-tree before. > > Since Kicad's codebase is rather monolithic, testing/refactoring > anything drags in pretty much everything else in the code as a > dependency. This causes long rebuild and linking times, which I find > very annoying. Also, while developing new features, most of the time is > spent linking pcbnew and clicking in the GUI to trigger the particular > feature. > > For that reason I decided to link all the test cases directly to the > _pcbnew_kiface library and skip pcbnew's dependency scanning when > building tests. I'm also preparing a bare PCB test window for verifying > interactive/graphical operations without rebuilding pcbnew as a whole app. > > I've attached the patch (set the KICAD_BUILD_TESTS=ON option to enable). > There's one trivial unit test included as an example. Let me know if > such solution would be acceptable. > > Cheers, > Tom > > > > ___ > 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] translation code rework
Well if you want all contributers since the epoch this could be documented in a text/md file in the kicad tree or preferably in the i18n package so that it can be updated seperate to the kicad project. On Thu, Sep 8, 2016 at 6:27 AM, Nick Østergaard wrote: > 2016-03-12 1:37 GMT+01:00 Simon Wells : >> As part of the translation code rework that i am working on (and >> auto-detection) part of it is moving the need for changing anything in >> code to add a new language. As part of this involves the flags i was >> wondering whether anyone would be against moving them into the i18n >> repo (and distributed in the individual language folders, so that if >> kicad is compiled with having icons enabled in the menu they could >> still be used but they will be pulled at runtime so no addtional code >> nor icons required in the kicad tree >> > > This discussion seem to be related to the other thread: > https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg17648.html > > It does not seem anyone is directly against removing the flags all together. > > I like the idea of validating the available languages runtime as > mentioned in the related thread. > >> Something unrelated to the flags but similar is do we need the >> translations tab with all the translators in the about box? or would a >> better place be in the i18n repo on github and linked from the website >> and only the current translation information provided in the about >> dialog. This can be pulled at runtime from the po files using the >> Language-Team header in the po file. There are a few ways this could >> be left how it is, including having a list of all INSTALLED >> translations in the translations tab instead of only showing current, >> would just require the program at startup processing all the language >> files to get the header information. >> >> for example the one in the ru po file is >> "Language-Team: Russian KiCad Translation Team: Andrey Fedorushkov, Eldar " >> "Khayrullin, Igor Plyatov \n" >> >> As i only know english i haven't had the oppurtunity to use the po >> utility but i have been advised this is a setting rather than just >> something that is edited manually >> >> the one in the fr po file is >> "Language-Team: jp-charras\n" >> >> which if this idea is implemented jp might need to change his to be a >> bit more informative, (at least being his full name or something) >> >> I think i have mentioned before about making the language list in >> preferences reliant on whether the i18n files have been installed so >> that people don't get caught up with wondering why no other languages >> work. >> > > Lets assume that all contributors have "proper" names here. > > What will happen with translators which work might not even be present > anymore, how are we supposed to detect that? Or are we just going to > count all contributors from epoch? > >> Mainly i am looking for arguments against moving the flags into the >> i18n repo as that may prove that most of my code is not possible. >> seeing as some people seem to be against just ditching the flags >> > > Remove the flags. :P > > I don't know if the languages maybe sould be written in their > localized form, maybe? > >> thanks >> >> 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
Re: [Kicad-developers] translation code rework
2016-03-12 1:37 GMT+01:00 Simon Wells : > As part of the translation code rework that i am working on (and > auto-detection) part of it is moving the need for changing anything in > code to add a new language. As part of this involves the flags i was > wondering whether anyone would be against moving them into the i18n > repo (and distributed in the individual language folders, so that if > kicad is compiled with having icons enabled in the menu they could > still be used but they will be pulled at runtime so no addtional code > nor icons required in the kicad tree > This discussion seem to be related to the other thread: https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg17648.html It does not seem anyone is directly against removing the flags all together. I like the idea of validating the available languages runtime as mentioned in the related thread. > Something unrelated to the flags but similar is do we need the > translations tab with all the translators in the about box? or would a > better place be in the i18n repo on github and linked from the website > and only the current translation information provided in the about > dialog. This can be pulled at runtime from the po files using the > Language-Team header in the po file. There are a few ways this could > be left how it is, including having a list of all INSTALLED > translations in the translations tab instead of only showing current, > would just require the program at startup processing all the language > files to get the header information. > > for example the one in the ru po file is > "Language-Team: Russian KiCad Translation Team: Andrey Fedorushkov, Eldar " > "Khayrullin, Igor Plyatov \n" > > As i only know english i haven't had the oppurtunity to use the po > utility but i have been advised this is a setting rather than just > something that is edited manually > > the one in the fr po file is > "Language-Team: jp-charras\n" > > which if this idea is implemented jp might need to change his to be a > bit more informative, (at least being his full name or something) > > I think i have mentioned before about making the language list in > preferences reliant on whether the i18n files have been installed so > that people don't get caught up with wondering why no other languages > work. > Lets assume that all contributors have "proper" names here. What will happen with translators which work might not even be present anymore, how are we supposed to detect that? Or are we just going to count all contributors from epoch? > Mainly i am looking for arguments against moving the flags into the > i18n repo as that may prove that most of my code is not possible. > seeing as some people seem to be against just ditching the flags > Remove the flags. :P I don't know if the languages maybe sould be written in their localized form, maybe? > thanks > > 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
Re: [Kicad-developers] Undo buffer refactor
Orson,
I did some limited testing on this and it seems OK. The only thing I'm
going to ask to wait until your going to be available in case things go
sideways before you commit it.
Thanks,
Wayne
On 9/5/2016 10:06 AM, Maciej Sumiński wrote:
> Recently I was refactoring the undo buffer code [1], as I have mentioned
> sometime ago. The main goal was to make the code simpler and more
> generic, remove some redundant parts.
>
> Short changelog:
>
> - BOARD_COMMIT class.
> Wrapper around undo buffer to simplify storing changes. Also performs
> all the necessary updates (ratsnest, view) once anything changes. A good
> entry point to introduce an observer interface.
>
> - Removed BOARD_ITEM::Copy(), switched to C++ copy constructors and
> operator=.
>
> - BOARD_ITEM_CONTAINER interface.
> A generic interface for adding & removing items, base class for MODULE
> and BOARD.
>
> - Removed UR_MODEDIT.
> Module editor now uses the same UR_* flags as the layout editor. Now,
> together with BOARD_COMMIT is the way to unify undo handling code in
> tools (no more ugly 'if(m_editModules) {...} else {...}').
>
> - Common code for handling undo buffer in the layout & module editor.
> board_undo_redo.cpp and modedit_undo_redo.cpp are merged to
> undo_redo.cpp. A lot of redundant code removed.
>
> As you may have noticed, there are a lot of changes to the KiCad
> internals. It would be great if there were some brave folks to take the
> branch for a test ride. I have tested the code for some time, including
> a few sessions of valgrind and I had no problems.
>
> If there are no objections I would like to commit the patches next week.
>
> Regards,
> Orson
>
> 1.
> https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+ref/undobuffer_refactor
>
>
>
> ___
> 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] announcing eeshow (schematics renderer and viewer)
Now eeshow search relative path relative current directory ($PWD) but should to search relative project file path. Errors if $PWD not equal to project file path. eeshow doesn't search title sheets in default directory /usr/share/kicad/template/. I use gost_landscape.kicad_wks from there. В Среда, 7 сен. 2016 в 9:13 , Werner Almesberger написал: Eldar Khayrullin wrote: Does eeshow watch to User defined search path? Ah yes, I hadn't implemented this. Now searching LibDir and the default paths from common/gestfich.cpp:KicadDatasPath should work, too. The searching can be a bit too optimistic: if you've deleted or moved a file, eeshow may still find it in the underlying commit (if on a repo) and seem to magically resurrect it. Such foibles will go away once I rewrite the path lookup logic, which currently underestimates how complex setups may really get. Thanks ! - Werner ___ 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] announcing eeshow (schematics renderer and viewer)
Conflicting of libgit2-dev (eeshow dependence) and libcurl4-openssl-dev (kicad dependence) packages in Ubuntu. В Среда, 7 сен. 2016 в 9:13 , Werner Almesberger написал: Eldar Khayrullin wrote: Does eeshow watch to User defined search path? Ah yes, I hadn't implemented this. Now searching LibDir and the default paths from common/gestfich.cpp:KicadDatasPath should work, too. The searching can be a bit too optimistic: if you've deleted or moved a file, eeshow may still find it in the underlying commit (if on a repo) and seem to magically resurrect it. Such foibles will go away once I rewrite the path lookup logic, which currently underestimates how complex setups may really get. Thanks ! - Werner ___ 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] [RFC] [PATCH] simple C++ tests
Hi,
This patch adds possibility to build C++ tests for pcbnew, using
Boost.Test framework. I intended it primarily to make tests for the P&S,
which I used to develop out-of-tree before.
Since Kicad's codebase is rather monolithic, testing/refactoring
anything drags in pretty much everything else in the code as a
dependency. This causes long rebuild and linking times, which I find
very annoying. Also, while developing new features, most of the time is
spent linking pcbnew and clicking in the GUI to trigger the particular
feature.
For that reason I decided to link all the test cases directly to the
_pcbnew_kiface library and skip pcbnew's dependency scanning when
building tests. I'm also preparing a bare PCB test window for verifying
interactive/graphical operations without rebuilding pcbnew as a whole app.
I've attached the patch (set the KICAD_BUILD_TESTS=ON option to enable).
There's one trivial unit test included as an example. Let me know if
such solution would be acceptable.
Cheers,
Tom
>From fb308460da32cb7a30e66f0c114ac3a0a159ef60 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomasz=20W=C5=82ostowski?=
Date: Wed, 7 Sep 2016 17:53:20 +0200
Subject: [PATCH] Initial support for unit tests in pcbnew using Boost.Test
---
CMakeLists.txt | 34 +++---
pcbnew/CMakeLists.txt| 12
tests/CMakeLists.txt | 10 ++
tests/pns/CMakeLists.txt | 3 +++
tests/pns/test_node.cpp | 21 +
5 files changed, 69 insertions(+), 11 deletions(-)
create mode 100644 tests/CMakeLists.txt
create mode 100644 tests/pns/CMakeLists.txt
create mode 100644 tests/pns/test_node.cpp
diff --git a/CMakeLists.txt b/CMakeLists.txt
index bfeaac5..0dbd735 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -49,6 +49,9 @@ option( KICAD_USE_OCE
"Build tools and plugins related to OpenCascade Community Edition (default OFF)"
)
+option( KICAD_BUILD_TESTS
+"Builds C++ tests (default OFF)"
+)
# when option KICAD_SCRIPTING OR KICAD_SCRIPTING_MODULES is enabled:
# PYTHON_EXECUTABLE can be defined when invoking cmake
# ( use -DPYTHON_EXECUTABLE=/python.exe or python2 )
@@ -69,10 +72,14 @@ option( KICAD_SPICE "Build Kicad with internal Spice simulator." OFF )
set( KICAD_REPO_NAME "product" CACHE STRING "Name of the tree from which this build came." )
-# Global setting: exports are explicit
-set( CMAKE_CXX_VISIBILITY_PRESET "hidden" )
-set( CMAKE_VISIBILITY_INLINES_HIDDEN ON )
-
+# Global setting: exports are explicit by default
+if ( KICAD_BUILD_TESTS )
+set( CMAKE_CXX_VISIBILITY_PRESET "default" )
+set( CMAKE_VISIBILITY_INLINES_HIDDEN OFF )
+else()
+set( CMAKE_CXX_VISIBILITY_PRESET "hidden" )
+set( CMAKE_VISIBILITY_INLINES_HIDDEN ON )
+endif()
# Global setting: build everything position independent
set( CMAKE_POSITION_INDEPENDENT_CODE ON )
@@ -93,12 +100,14 @@ if( POLICY CMP0063 )
cmake_policy( SET CMP0063 NEW )
endif()
else()
-if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY AND NOT APPLE )
-set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY}hidden" )
-endif()
-if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN AND NOT APPLE )
-set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN}" )
-endif()
+if( CMAKE_CXX_VISIBILITY_PRESET STREQUAL "hidden" )
+ if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY AND NOT APPLE )
+ set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY}hidden" )
+ endif()
+ if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN AND NOT APPLE )
+ set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN}" )
+ endif()
+ endif()
endif()
@@ -503,7 +512,7 @@ find_package( Cairo 1.8.8 REQUIRED )
#
# Note: Prior to Boost 1.59, the Boost context library is not built when compiling on windows
# with GCC. You must patch the Boost sources.
-find_package( Boost 1.54.0 REQUIRED COMPONENTS context system thread )
+find_package( Boost 1.54.0 REQUIRED COMPONENTS context system thread unit_test_framework )
# Include MinGW resource compiler.
include( MinGWResourceCompiler )
@@ -804,6 +813,9 @@ add_subdirectory( kicad ) # should follow pcbnew, eeschema
add_subdirectory( tools )
add_subdirectory( utils )
add_subdirectory( qa )
+if ( KICAD_BUILD_TESTS )
+add_subdirectory( tests )
+endif()
# Resources
add_subdirectory( demos )
diff --git a/pcbnew/CMakeLists.txt b/pcbnew/CMakeLists.txt
index c4aff51..5ce31a0 100644
--- a/pcbnew/CMakeLists.txt
+++ b/pcbnew/CMakeLists.txt
@@ -578,6 +578,18 @@ set_target_properties( pcbnew_kiface PROPERTIES
SUFFIX ${KIFACE_SUFFIX}
)
+if ( KICAD_BUILD_TESTS )
+if ( UNIX )
+ add_custom_command(TARGET pcbnew_kiface POST_BUILD
+ COMMAND ln -sf _pcbnew.kiface lib_pcbnew_kiface.so )
+else()
+ add_custom_command(TARGET pcbnew_kiface POST_BU
Re: [Kicad-developers] wxformbuilder version
yeah there has been talk in the irc channel On Thu, Sep 8, 2016 at 3:51 AM, Wayne Stambaugh wrote: > Simon, thanks for update. I knew it wasn't going to be that easy. I'm > guessing mroszko will be OK with this. > > On 9/7/2016 11:50 AM, Simon Wells wrote: >> Just fyi mroszko's code doesn't currently build on osx, due to missing >> stuff in cmakelists.txt i will try and find some time to make a patch >> and send it to mroszko so there is something on osx >> >> >> >> On Thu, Sep 8, 2016 at 3:05 AM, Wayne Stambaugh wrote: >>> I'll commit it if there are no other serious objections. Speak now or >>> forever hold your peace. This may be short lived if the wxFB folks >>> start working on wxFB again. If they do, I hope they come up with a >>> better release version policy. >>> >>> On 9/7/2016 8:09 AM, Maciej Sumiński wrote: Wayne, I attach a patch updating the UI policy. I would rather you commit the patch, to be sure you agree with the changes. Regards, Orson On 09/03/2016 02:17 AM, Wayne Stambaugh wrote: > We've been dancing around this issue for a while without any real > resolution. I'm fine with using Mark's version of wxFB but a lot folks > are going to want to use whatever is packaged for their distro rather > than build wxFB from source which presents a serious issue. I'm not > sure there is a good answer for this problem. If no one else has any > objections, I'm willing to make Mark's wxFB fork the official version > for KiCad dialog submission for the time being. In the long run, if > wxFB is not actively being developed, I would rather come up with an > alternative. > > FWIW, I think most of you know how I feel about dialog creation tools > vs. creating them programmatically. Kicad's dialogs used to be created > this way but I got out voted at the time the decision was made to switch > to wxFB. I'm feeling better about my choice all the time. ;) > > On 9/2/2016 7:11 PM, Chris Pavlina wrote: >> I would vote in favor of using Mark's fork officially for everyone, if >> it builds okay on all the platforms. wxfb is kinda nasty, if we're going >> to use it it's nice to have our own fork that solves at least a few of >> these issues. >> >> On Sat, Sep 03, 2016 at 08:45:12AM +1000, Cirilo Bernardo wrote: >>> I just use MRoszko's fork; it's cleaner than the original and much >>> easier to configure and build since the bizarre wxFB build system >>> had been eradicated and replaced by CMake. >>> >>> git clone https://github.com/marekr/wxFormBuilder.git wxfb >>> cd wxfb && git checkout wxFB3.5-1 >>> >>> A half year or so ago I tried the later wxFB in development but it >>> broke so many things that I just reverted the files and went back to >>> wxFB3,5-1. >>> >>> - Cirilo >>> >>> >>> On Sat, Sep 3, 2016 at 7:28 AM, Chris Pavlina >>> wrote: >>> Along these lines: this isn't the first time wxfb version issues have come up. Perhaps we should pick an "official" wxfb version for the project to use, and then actually provide builds of it for developer use (as it can be a bit annoying to track down a specific version)? Then we can upgrade together as new versions come out. On Sat, Sep 03, 2016 at 09:16:41AM +1200, Simon Wells wrote: > dialog_pad_properties_base.fbp h cpp was last modified in commit > > 63decd70e6ab1bf2fe95db3f426f6cdfc79be213 > https://git.launchpad.net/kicad/commit/?id= 63decd70e6ab1bf2fe95db3f426f6cdfc79be213 > > the problem is this version of wxformbuilder is newer than the one > available on sourceforge and it is very difficult to build on other > platforms ( i tried a while ago and gave up as it had issues) > > the version that was used to save these files has broken it on older > versions of wxformbuilder > > Is there a version of wxformbuilder that we should be using to avoid > it breaking on other versions? > > the last available from sf.net is 3.5rc1 iirc > > thanks > > 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
Re: [Kicad-developers] wxformbuilder version
Simon, thanks for update. I knew it wasn't going to be that easy. I'm guessing mroszko will be OK with this. On 9/7/2016 11:50 AM, Simon Wells wrote: > Just fyi mroszko's code doesn't currently build on osx, due to missing > stuff in cmakelists.txt i will try and find some time to make a patch > and send it to mroszko so there is something on osx > > > > On Thu, Sep 8, 2016 at 3:05 AM, Wayne Stambaugh wrote: >> I'll commit it if there are no other serious objections. Speak now or >> forever hold your peace. This may be short lived if the wxFB folks >> start working on wxFB again. If they do, I hope they come up with a >> better release version policy. >> >> On 9/7/2016 8:09 AM, Maciej Sumiński wrote: >>> Wayne, >>> >>> I attach a patch updating the UI policy. I would rather you commit the >>> patch, to be sure you agree with the changes. >>> >>> Regards, >>> Orson >>> >>> On 09/03/2016 02:17 AM, Wayne Stambaugh wrote: We've been dancing around this issue for a while without any real resolution. I'm fine with using Mark's version of wxFB but a lot folks are going to want to use whatever is packaged for their distro rather than build wxFB from source which presents a serious issue. I'm not sure there is a good answer for this problem. If no one else has any objections, I'm willing to make Mark's wxFB fork the official version for KiCad dialog submission for the time being. In the long run, if wxFB is not actively being developed, I would rather come up with an alternative. FWIW, I think most of you know how I feel about dialog creation tools vs. creating them programmatically. Kicad's dialogs used to be created this way but I got out voted at the time the decision was made to switch to wxFB. I'm feeling better about my choice all the time. ;) On 9/2/2016 7:11 PM, Chris Pavlina wrote: > I would vote in favor of using Mark's fork officially for everyone, if > it builds okay on all the platforms. wxfb is kinda nasty, if we're going > to use it it's nice to have our own fork that solves at least a few of > these issues. > > On Sat, Sep 03, 2016 at 08:45:12AM +1000, Cirilo Bernardo wrote: >> I just use MRoszko's fork; it's cleaner than the original and much >> easier to configure and build since the bizarre wxFB build system >> had been eradicated and replaced by CMake. >> >> git clone https://github.com/marekr/wxFormBuilder.git wxfb >> cd wxfb && git checkout wxFB3.5-1 >> >> A half year or so ago I tried the later wxFB in development but it >> broke so many things that I just reverted the files and went back to >> wxFB3,5-1. >> >> - Cirilo >> >> >> On Sat, Sep 3, 2016 at 7:28 AM, Chris Pavlina >> wrote: >> >>> Along these lines: this isn't the first time wxfb version issues have >>> come up. Perhaps we should pick an "official" wxfb version for the >>> project to use, and then actually provide builds of it for developer use >>> (as it can be a bit annoying to track down a specific version)? Then we >>> can upgrade together as new versions come out. >>> >>> >>> On Sat, Sep 03, 2016 at 09:16:41AM +1200, Simon Wells wrote: dialog_pad_properties_base.fbp h cpp was last modified in commit 63decd70e6ab1bf2fe95db3f426f6cdfc79be213 https://git.launchpad.net/kicad/commit/?id= >>> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213 the problem is this version of wxformbuilder is newer than the one available on sourceforge and it is very difficult to build on other platforms ( i tried a while ago and gave up as it had issues) the version that was used to save these files has broken it on older versions of wxformbuilder Is there a version of wxformbuilder that we should be using to avoid it breaking on other versions? the last available from sf.net is 3.5rc1 iirc thanks 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
Re: [Kicad-developers] wxformbuilder version
Just fyi mroszko's code doesn't currently build on osx, due to missing stuff in cmakelists.txt i will try and find some time to make a patch and send it to mroszko so there is something on osx On Thu, Sep 8, 2016 at 3:05 AM, Wayne Stambaugh wrote: > I'll commit it if there are no other serious objections. Speak now or > forever hold your peace. This may be short lived if the wxFB folks > start working on wxFB again. If they do, I hope they come up with a > better release version policy. > > On 9/7/2016 8:09 AM, Maciej Sumiński wrote: >> Wayne, >> >> I attach a patch updating the UI policy. I would rather you commit the >> patch, to be sure you agree with the changes. >> >> Regards, >> Orson >> >> On 09/03/2016 02:17 AM, Wayne Stambaugh wrote: >>> We've been dancing around this issue for a while without any real >>> resolution. I'm fine with using Mark's version of wxFB but a lot folks >>> are going to want to use whatever is packaged for their distro rather >>> than build wxFB from source which presents a serious issue. I'm not >>> sure there is a good answer for this problem. If no one else has any >>> objections, I'm willing to make Mark's wxFB fork the official version >>> for KiCad dialog submission for the time being. In the long run, if >>> wxFB is not actively being developed, I would rather come up with an >>> alternative. >>> >>> FWIW, I think most of you know how I feel about dialog creation tools >>> vs. creating them programmatically. Kicad's dialogs used to be created >>> this way but I got out voted at the time the decision was made to switch >>> to wxFB. I'm feeling better about my choice all the time. ;) >>> >>> On 9/2/2016 7:11 PM, Chris Pavlina wrote: I would vote in favor of using Mark's fork officially for everyone, if it builds okay on all the platforms. wxfb is kinda nasty, if we're going to use it it's nice to have our own fork that solves at least a few of these issues. On Sat, Sep 03, 2016 at 08:45:12AM +1000, Cirilo Bernardo wrote: > I just use MRoszko's fork; it's cleaner than the original and much > easier to configure and build since the bizarre wxFB build system > had been eradicated and replaced by CMake. > > git clone https://github.com/marekr/wxFormBuilder.git wxfb > cd wxfb && git checkout wxFB3.5-1 > > A half year or so ago I tried the later wxFB in development but it > broke so many things that I just reverted the files and went back to > wxFB3,5-1. > > - Cirilo > > > On Sat, Sep 3, 2016 at 7:28 AM, Chris Pavlina > wrote: > >> Along these lines: this isn't the first time wxfb version issues have >> come up. Perhaps we should pick an "official" wxfb version for the >> project to use, and then actually provide builds of it for developer use >> (as it can be a bit annoying to track down a specific version)? Then we >> can upgrade together as new versions come out. >> >> >> On Sat, Sep 03, 2016 at 09:16:41AM +1200, Simon Wells wrote: >>> dialog_pad_properties_base.fbp h cpp was last modified in commit >>> >>> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213 >>> https://git.launchpad.net/kicad/commit/?id= >> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213 >>> >>> the problem is this version of wxformbuilder is newer than the one >>> available on sourceforge and it is very difficult to build on other >>> platforms ( i tried a while ago and gave up as it had issues) >>> >>> the version that was used to save these files has broken it on older >>> versions of wxformbuilder >>> >>> Is there a version of wxformbuilder that we should be using to avoid >>> it breaking on other versions? >>> >>> the last available from sf.net is 3.5rc1 iirc >>> >>> thanks >>> >>> 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
Re: [Kicad-developers] wxformbuilder version
I'll commit it if there are no other serious objections. Speak now or forever hold your peace. This may be short lived if the wxFB folks start working on wxFB again. If they do, I hope they come up with a better release version policy. On 9/7/2016 8:09 AM, Maciej Sumiński wrote: > Wayne, > > I attach a patch updating the UI policy. I would rather you commit the > patch, to be sure you agree with the changes. > > Regards, > Orson > > On 09/03/2016 02:17 AM, Wayne Stambaugh wrote: >> We've been dancing around this issue for a while without any real >> resolution. I'm fine with using Mark's version of wxFB but a lot folks >> are going to want to use whatever is packaged for their distro rather >> than build wxFB from source which presents a serious issue. I'm not >> sure there is a good answer for this problem. If no one else has any >> objections, I'm willing to make Mark's wxFB fork the official version >> for KiCad dialog submission for the time being. In the long run, if >> wxFB is not actively being developed, I would rather come up with an >> alternative. >> >> FWIW, I think most of you know how I feel about dialog creation tools >> vs. creating them programmatically. Kicad's dialogs used to be created >> this way but I got out voted at the time the decision was made to switch >> to wxFB. I'm feeling better about my choice all the time. ;) >> >> On 9/2/2016 7:11 PM, Chris Pavlina wrote: >>> I would vote in favor of using Mark's fork officially for everyone, if >>> it builds okay on all the platforms. wxfb is kinda nasty, if we're going >>> to use it it's nice to have our own fork that solves at least a few of >>> these issues. >>> >>> On Sat, Sep 03, 2016 at 08:45:12AM +1000, Cirilo Bernardo wrote: I just use MRoszko's fork; it's cleaner than the original and much easier to configure and build since the bizarre wxFB build system had been eradicated and replaced by CMake. git clone https://github.com/marekr/wxFormBuilder.git wxfb cd wxfb && git checkout wxFB3.5-1 A half year or so ago I tried the later wxFB in development but it broke so many things that I just reverted the files and went back to wxFB3,5-1. - Cirilo On Sat, Sep 3, 2016 at 7:28 AM, Chris Pavlina wrote: > Along these lines: this isn't the first time wxfb version issues have > come up. Perhaps we should pick an "official" wxfb version for the > project to use, and then actually provide builds of it for developer use > (as it can be a bit annoying to track down a specific version)? Then we > can upgrade together as new versions come out. > > > On Sat, Sep 03, 2016 at 09:16:41AM +1200, Simon Wells wrote: >> dialog_pad_properties_base.fbp h cpp was last modified in commit >> >> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213 >> https://git.launchpad.net/kicad/commit/?id= > 63decd70e6ab1bf2fe95db3f426f6cdfc79be213 >> >> the problem is this version of wxformbuilder is newer than the one >> available on sourceforge and it is very difficult to build on other >> platforms ( i tried a while ago and gave up as it had issues) >> >> the version that was used to save these files has broken it on older >> versions of wxformbuilder >> >> Is there a version of wxformbuilder that we should be using to avoid >> it breaking on other versions? >> >> the last available from sf.net is 3.5rc1 iirc >> >> thanks >> >> 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
Re: [Kicad-developers] wxformbuilder version
Wayne,
I attach a patch updating the UI policy. I would rather you commit the
patch, to be sure you agree with the changes.
Regards,
Orson
On 09/03/2016 02:17 AM, Wayne Stambaugh wrote:
> We've been dancing around this issue for a while without any real
> resolution. I'm fine with using Mark's version of wxFB but a lot folks
> are going to want to use whatever is packaged for their distro rather
> than build wxFB from source which presents a serious issue. I'm not
> sure there is a good answer for this problem. If no one else has any
> objections, I'm willing to make Mark's wxFB fork the official version
> for KiCad dialog submission for the time being. In the long run, if
> wxFB is not actively being developed, I would rather come up with an
> alternative.
>
> FWIW, I think most of you know how I feel about dialog creation tools
> vs. creating them programmatically. Kicad's dialogs used to be created
> this way but I got out voted at the time the decision was made to switch
> to wxFB. I'm feeling better about my choice all the time. ;)
>
> On 9/2/2016 7:11 PM, Chris Pavlina wrote:
>> I would vote in favor of using Mark's fork officially for everyone, if
>> it builds okay on all the platforms. wxfb is kinda nasty, if we're going
>> to use it it's nice to have our own fork that solves at least a few of
>> these issues.
>>
>> On Sat, Sep 03, 2016 at 08:45:12AM +1000, Cirilo Bernardo wrote:
>>> I just use MRoszko's fork; it's cleaner than the original and much
>>> easier to configure and build since the bizarre wxFB build system
>>> had been eradicated and replaced by CMake.
>>>
>>> git clone https://github.com/marekr/wxFormBuilder.git wxfb
>>> cd wxfb && git checkout wxFB3.5-1
>>>
>>> A half year or so ago I tried the later wxFB in development but it
>>> broke so many things that I just reverted the files and went back to
>>> wxFB3,5-1.
>>>
>>> - Cirilo
>>>
>>>
>>> On Sat, Sep 3, 2016 at 7:28 AM, Chris Pavlina
>>> wrote:
>>>
Along these lines: this isn't the first time wxfb version issues have
come up. Perhaps we should pick an "official" wxfb version for the
project to use, and then actually provide builds of it for developer use
(as it can be a bit annoying to track down a specific version)? Then we
can upgrade together as new versions come out.
On Sat, Sep 03, 2016 at 09:16:41AM +1200, Simon Wells wrote:
> dialog_pad_properties_base.fbp h cpp was last modified in commit
>
> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213
> https://git.launchpad.net/kicad/commit/?id=
63decd70e6ab1bf2fe95db3f426f6cdfc79be213
>
> the problem is this version of wxformbuilder is newer than the one
> available on sourceforge and it is very difficult to build on other
> platforms ( i tried a while ago and gave up as it had issues)
>
> the version that was used to save these files has broken it on older
> versions of wxformbuilder
>
> Is there a version of wxformbuilder that we should be using to avoid
> it breaking on other versions?
>
> the last available from sf.net is 3.5rc1 iirc
>
> thanks
>
> Simon
From 1572c5e69a11f4dff74901c5f4eb323a8fff6cf3 Mon Sep 17 00:00:00 2001
From: Maciej Suminski
Date: Wed, 7 Sep 2016 13:59:58 +0200
Subject: [PATCH] UI policy update
Added a note about Mark's wxFormBuilder repository and
'internationalize' checkbox in wxFB.
---
Documentation/development/ui-policy.md | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/Documentation/development/ui-policy.md b/Documentation/development/ui-policy.md
index 8fe0be5..a938790 100644
--- a/Documentation/development/ui-policy.md
+++ b/Documentation/development/ui-policy.md
@@ -72,9 +72,11 @@ Webpage titles and navigational elements | Header
This section defines how dialog boxes should be designed. The KiCad project
uses the [GNOME User Interface Guidelines][gnome-ui-guidelines] for laying out
dialogs. KiCad's dialogs must be designed with [wxFormBuilder][wxformbuilder].
-Please use the most recent version of wxFormBuilder possible to prevent version
-issues with other developers. When designing dialogs, follow the [visual layout
-section of the GNOME User Interface Guidelines][gnome-ui-layout].
+As wxFormBuilder available in packages is likely to be a different version than
+what other developers have installed, it has been decided to use the version
+kept in a Github repository, branch [wxFB3.5RC-1][wxformbuilder-github] to avoid
+version mismatch. When designing dialogs, follow the [visual layout section of
+the GNOME User Interface Guidelines][gnome-ui-layout].
## Escape Key Termination ## {#dialogs-esc-key}
Please note that the escape key termination only works properly if there is a
@@ -147,6 +149,12 @@ broken. Do not implement default button handlers in your dialog code. Use
validators to transfer data to and from controls and allow the default dialog
button handlers work t
Re: [Kicad-developers] OCE plugin for 3D viewer
It's good to see that people is starting using the feature and special, new people joined with contributions to the 3D-Viewer (José Ignacio, Chris ...) Mario Luzeiro From: Kicad-developers [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of Nick Østergaard [oe.n...@gmail.com] Sent: 07 September 2016 09:31 To: Cirilo Bernardo Cc: KiCad Developers Subject: Re: [Kicad-developers] OCE plugin for 3D viewer FYI the windows nightlies now built with OCE enabled. The first nightlies are ready and my sanity check says that it works. As I write this only the x86_64 build have it enabled, but I expect the i686 build to be ready within a few hours from now on. I know that js-reynaud also enabled it on the ubunut PPA's. I don't know what the status for getting OSX nightlies running again is. So all in all this is good news. Lets see if we get any new bug reports on its usage now. :) Cirilo and Mario (and others), thank you for making this feature a reality. ___ 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] OCE plugin for 3D viewer
Thanks Nick for sorting out all the build issues on Windows - it would have taken much longer without all your work. - Cirilo On Wed, Sep 7, 2016 at 6:31 PM, Nick Østergaard wrote: > FYI the windows nightlies now built with OCE enabled. The first > nightlies are ready and my sanity check says that it works. As I write > this only the x86_64 build have it enabled, but I expect the i686 > build to be ready within a few hours from now on. > > I know that js-reynaud also enabled it on the ubunut PPA's. > > I don't know what the status for getting OSX nightlies running again is. > > So all in all this is good news. Lets see if we get any new bug > reports on its usage now. :) > > Cirilo and Mario (and others), thank you for making this feature a reality. > > 2016-09-03 2:18 GMT+02:00 Cirilo Bernardo : > > > > > > On Sat, Sep 3, 2016 at 5:25 AM, Wayne Stambaugh > > wrote: > >> > >> Cirilo, > >> > >> Someone still needs to address building oce on msys2. I just spent way > >> too much time building oce from source on msys2. The oce folks decided > >> to ignore CMAKE_INSTALL_PREFIX and use there own install path stuff > >> which is is not compatible with the msys2 file system hierarchy. The > >> bad thing is you cannot manually copy the dlls and link stub files to > >> the appropriate paths because the generated cmake oce find stuff will > >> point to the incorrect paths. To create PKGBUILD for msys2 will require > >> JP's patch to fix long command lengths along with a patch to fix oce's > >> install path issues. If someone else has time to work on this please > do. > >> > >> Thanks, > >> > >> Wayne > >> > > > > Nick's been doing all the hard work on OCE + MSYS2 issues; I'm pretty > > awful at working within MSYS2 and it doesn't help that the MSYS2 > > ecosystem is frequently broken. I was finally able to build OCE and > > the plugins on MSYS2 about a week ago only to discover catastrophic ABI > > incompatibilities between wxWidgets and the newly compiled software. > > I have no doubt these issues will be resolved before the next release > > thank's to Nick's persistence, and I keep in touch on IRC and try to > > help out however I can. Having the code in the main branch is a huge > > help though; some OSX devs in particular had been cursing me due to > > numerous problems with building the plugin out of the tree but building > > the same code from within the kicad tree was painless. > > > > - Cirilo > > > >> > >> On 9/2/2016 6:22 AM, Cirilo Bernardo wrote: > >> > Thanks for the merge and to everyone who's helped out with the > >> > cross-platform issues. > >> > I've got a new feature branch "kicad-step" with the kicad2step > >> > standalone tool if anyone > >> > feels like playing with it and providing some feedback. This is the > >> > tool which I plan to > >> > make available as an item in the "Export" menu to give KiCad it's own > >> > built-in MCAD > >> > export. > >> > > >> > https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce > >> > > >> > The long-term plan is to make this tool a genuine plugin, but the API > >> > required for that > >> > is turning out to be quite a big job and is currently on hold due to > my > >> > limited free time. > >> > > >> > This stand-alone tool makes use of mRoszko's SEXPR parser which is a > >> > great tool > >> > for making third-party tools that can read KiCad PCB files. > >> > > >> > - 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
Re: [Kicad-developers] OCE plugin for 3D viewer
FYI the windows nightlies now built with OCE enabled. The first nightlies are ready and my sanity check says that it works. As I write this only the x86_64 build have it enabled, but I expect the i686 build to be ready within a few hours from now on. I know that js-reynaud also enabled it on the ubunut PPA's. I don't know what the status for getting OSX nightlies running again is. So all in all this is good news. Lets see if we get any new bug reports on its usage now. :) Cirilo and Mario (and others), thank you for making this feature a reality. 2016-09-03 2:18 GMT+02:00 Cirilo Bernardo : > > > On Sat, Sep 3, 2016 at 5:25 AM, Wayne Stambaugh > wrote: >> >> Cirilo, >> >> Someone still needs to address building oce on msys2. I just spent way >> too much time building oce from source on msys2. The oce folks decided >> to ignore CMAKE_INSTALL_PREFIX and use there own install path stuff >> which is is not compatible with the msys2 file system hierarchy. The >> bad thing is you cannot manually copy the dlls and link stub files to >> the appropriate paths because the generated cmake oce find stuff will >> point to the incorrect paths. To create PKGBUILD for msys2 will require >> JP's patch to fix long command lengths along with a patch to fix oce's >> install path issues. If someone else has time to work on this please do. >> >> Thanks, >> >> Wayne >> > > Nick's been doing all the hard work on OCE + MSYS2 issues; I'm pretty > awful at working within MSYS2 and it doesn't help that the MSYS2 > ecosystem is frequently broken. I was finally able to build OCE and > the plugins on MSYS2 about a week ago only to discover catastrophic ABI > incompatibilities between wxWidgets and the newly compiled software. > I have no doubt these issues will be resolved before the next release > thank's to Nick's persistence, and I keep in touch on IRC and try to > help out however I can. Having the code in the main branch is a huge > help though; some OSX devs in particular had been cursing me due to > numerous problems with building the plugin out of the tree but building > the same code from within the kicad tree was painless. > > - Cirilo > >> >> On 9/2/2016 6:22 AM, Cirilo Bernardo wrote: >> > Thanks for the merge and to everyone who's helped out with the >> > cross-platform issues. >> > I've got a new feature branch "kicad-step" with the kicad2step >> > standalone tool if anyone >> > feels like playing with it and providing some feedback. This is the >> > tool which I plan to >> > make available as an item in the "Export" menu to give KiCad it's own >> > built-in MCAD >> > export. >> > >> > https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce >> > >> > The long-term plan is to make this tool a genuine plugin, but the API >> > required for that >> > is turning out to be quite a big job and is currently on hold due to my >> > limited free time. >> > >> > This stand-alone tool makes use of mRoszko's SEXPR parser which is a >> > great tool >> > for making third-party tools that can read KiCad PCB files. >> > >> > - 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
