Re: [Kicad-developers] 5.0.1 status
Cool. I’ll do it tomorrow morning when I’m around for a while to catch any fallout. Cheers, Jeff. > On 8 Oct 2018, at 23:36, Wayne Stambaugh wrote: > > Hey Jeff, > > You can push the big red GAL button (after rebasing of course) as soon > as you are ready. Please don't don't merge any of the cairo printing > stuff just yet. Once it's merged, please let everyone know on the > mailing list. I will also make an announcement on the kicad forum when > I see your post. > > Cheers, > > Wayne > > On 10/08/2018 10:08 AM, Jeff Young wrote: >> My finger is on the big red GAL button…. >> >>> On 8 Oct 2018, at 14:24, Wayne Stambaugh wrote: >>> >>> I'm making a last call for any bug fixes that need to made to the 5.0 >>> branch for the 5.0.1 release. Please let me know if you have any >>> pending fixes before I tag 5.0.1. I intend to tag this around 6PM EST >>> unless I hear otherwise. How much time will our translators and >>> librarians need to tag 5.0.1? Hopefully not too long so we can give our >>> packagers time to get release packages built. I would like to make the >>> release announcement this coming weekend if at all possible. >>> >>> I also intend to leave the 5.0.1 tag as the revision and set the source >>> archive version to 5.0.1-unknown so the -dev suffix will no longer be in >>> play moving forward which should make our packagers happy. >>> >>> 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
Re: [Kicad-developers] Net selector
Hi Jeff- Haven't had a chance to look recently. Just checked and it works well enough to be useful. Still doesn't drop with space/enter on gtk but that's pretty minor. Feels generally good. -S Am Mo., 8. Okt. 2018 um 05:30 Uhr schrieb Jeff Young : > How’s that Net Selector working these days? Is all good, or are people > just tired of reporting issues with it? ;) > > Cheers, > Jeff. > > > ___ > 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] 5.0.1 status
Libraries are tagged. On 09/10/18 00:24, Wayne Stambaugh wrote: Rene, Looks good to me. Tag it as soon as you are ready. Thanks, Wayne On 10/08/2018 04:45 PM, Rene Pöschl wrote: Hi all, Updated list can now be found in comment https://github.com/KiCad/kicad-symbols/issues/856#issuecomment-427971380 (I tried to determine for every change where it comes from. Did not find the pull request in question for the three removed symbols and for one possible false positive.) On 08/10/18 20:52, Wayne Stambaugh wrote: Hi Rene, I didn't see anything the the list you linked that I would consider a show stopper. I wait until you post the results of you test script against the latest changes. Thanks, Wayne On 10/8/2018 11:35 AM, Rene Pöschl wrote: Regarding libs. I would need to run the script testing for incompatible changes with the current master. (I can do this as soon as i am home today. So in a few hours.) I already ran it at the end of August the changes that occurred until then are documented in [1] As soon as i update that list somebody will need to decide if the changes are acceptable for being included. If not then 5.0.1 should continue to ship with the libs tagged as 5.0.0 (It would not make much sense to add a new tag onto the same commit. I would even argue that this might confuse users who would expect changes if a new tag is created.) [1]: https://github.com/KiCad/kicad-symbols/issues/856#issuecomment-417592514 On 08/10/2018 15:24, Wayne Stambaugh wrote: I'm making a last call for any bug fixes that need to made to the 5.0 branch for the 5.0.1 release. Please let me know if you have any pending fixes before I tag 5.0.1. I intend to tag this around 6PM EST unless I hear otherwise. How much time will our translators and librarians need to tag 5.0.1? Hopefully not too long so we can give our packagers time to get release packages built. I would like to make the release announcement this coming weekend if at all possible. I also intend to leave the 5.0.1 tag as the revision and set the source archive version to 5.0.1-unknown so the -dev suffix will no longer be in play moving forward which should make our packagers happy. 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 ___ 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] 5.0.1 status
Hey Jeff, You can push the big red GAL button (after rebasing of course) as soon as you are ready. Please don't don't merge any of the cairo printing stuff just yet. Once it's merged, please let everyone know on the mailing list. I will also make an announcement on the kicad forum when I see your post. Cheers, Wayne On 10/08/2018 10:08 AM, Jeff Young wrote: > My finger is on the big red GAL button…. > >> On 8 Oct 2018, at 14:24, Wayne Stambaugh wrote: >> >> I'm making a last call for any bug fixes that need to made to the 5.0 >> branch for the 5.0.1 release. Please let me know if you have any >> pending fixes before I tag 5.0.1. I intend to tag this around 6PM EST >> unless I hear otherwise. How much time will our translators and >> librarians need to tag 5.0.1? Hopefully not too long so we can give our >> packagers time to get release packages built. I would like to make the >> release announcement this coming weekend if at all possible. >> >> I also intend to leave the 5.0.1 tag as the revision and set the source >> archive version to 5.0.1-unknown so the -dev suffix will no longer be in >> play moving forward which should make our packagers happy. >> >> 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
Re: [Kicad-developers] 5.0.1 status
On 10/08/2018 04:53 PM, Seth Hillbrand wrote: > > > Am Mo., 8. Okt. 2018 um 07:16 Uhr schrieb Wayne Stambaugh > mailto:stambau...@gmail.com>>: > > I'm making a last call for any bug fixes that need to made to the 5.0 > branch for the 5.0.1 release. Please let me know if you have any > pending fixes before I tag 5.0.1. I intend to tag this around 6PM EST > unless I hear otherwise. How much time will our translators and > librarians need to tag 5.0.1? Hopefully not too long so we can give our > packagers time to get release packages built. I would like to make the > release announcement this coming weekend if at all possible. > > > Great news! I pulled a few small bug-fixes from the 5.1 branch this > morning but I think that's the last of them (famous last words) > > -S 5.0.1 source has been tagged and I uploaded the source archive so as soon all of the other repos are tagged for 5.0.1, we should be able to fire up the package builders. I intend to make the release announcement over the weekend unless there is any last minute setbacks. Thanks again everyone for all of your hard work. 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
Re: [Kicad-developers] 5.0.1 status
Rene, Looks good to me. Tag it as soon as you are ready. Thanks, Wayne On 10/08/2018 04:45 PM, Rene Pöschl wrote: > Hi all, > > Updated list can now be found in comment > https://github.com/KiCad/kicad-symbols/issues/856#issuecomment-427971380 > (I tried to determine for every change where it comes from. Did not find > the pull request in question for the three removed symbols and for one > possible false positive.) > > > > On 08/10/18 20:52, Wayne Stambaugh wrote: >> Hi Rene, >> >> I didn't see anything the the list you linked that I would consider a >> show stopper. I wait until you post the results of you test script >> against the latest changes. >> >> Thanks, >> >> Wayne >> >> On 10/8/2018 11:35 AM, Rene Pöschl wrote: >>> Regarding libs. >>> >>> I would need to run the script testing for incompatible changes with the >>> current master. (I can do this as soon as i am home today. So in a few >>> hours.) I already ran it at the end of August the changes that occurred >>> until then are documented in [1] >>> >>> As soon as i update that list somebody will need to decide if the >>> changes are acceptable for being included. If not then 5.0.1 should >>> continue to ship with the libs tagged as 5.0.0 (It would not make much >>> sense to add a new tag onto the same commit. I would even argue that >>> this might confuse users who would expect changes if a new tag is >>> created.) >>> >>> [1]: >>> https://github.com/KiCad/kicad-symbols/issues/856#issuecomment-417592514 >>> >>> On 08/10/2018 15:24, Wayne Stambaugh wrote: I'm making a last call for any bug fixes that need to made to the 5.0 branch for the 5.0.1 release. Please let me know if you have any pending fixes before I tag 5.0.1. I intend to tag this around 6PM EST unless I hear otherwise. How much time will our translators and librarians need to tag 5.0.1? Hopefully not too long so we can give our packagers time to get release packages built. I would like to make the release announcement this coming weekend if at all possible. I also intend to leave the 5.0.1 tag as the revision and set the source archive version to 5.0.1-unknown so the -dev suffix will no longer be in play moving forward which should make our packagers happy. 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 > > > > ___ > 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] 5.0.1 status
Am Mo., 8. Okt. 2018 um 07:16 Uhr schrieb Wayne Stambaugh < stambau...@gmail.com>: > I'm making a last call for any bug fixes that need to made to the 5.0 > branch for the 5.0.1 release. Please let me know if you have any > pending fixes before I tag 5.0.1. I intend to tag this around 6PM EST > unless I hear otherwise. How much time will our translators and > librarians need to tag 5.0.1? Hopefully not too long so we can give our > packagers time to get release packages built. I would like to make the > release announcement this coming weekend if at all possible. > Great news! I pulled a few small bug-fixes from the 5.1 branch this morning but I think that's the last of them (famous last words) -S ___ 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] 5.0.1 status
Hi all, Updated list can now be found in comment https://github.com/KiCad/kicad-symbols/issues/856#issuecomment-427971380 (I tried to determine for every change where it comes from. Did not find the pull request in question for the three removed symbols and for one possible false positive.) On 08/10/18 20:52, Wayne Stambaugh wrote: Hi Rene, I didn't see anything the the list you linked that I would consider a show stopper. I wait until you post the results of you test script against the latest changes. Thanks, Wayne On 10/8/2018 11:35 AM, Rene Pöschl wrote: Regarding libs. I would need to run the script testing for incompatible changes with the current master. (I can do this as soon as i am home today. So in a few hours.) I already ran it at the end of August the changes that occurred until then are documented in [1] As soon as i update that list somebody will need to decide if the changes are acceptable for being included. If not then 5.0.1 should continue to ship with the libs tagged as 5.0.0 (It would not make much sense to add a new tag onto the same commit. I would even argue that this might confuse users who would expect changes if a new tag is created.) [1]: https://github.com/KiCad/kicad-symbols/issues/856#issuecomment-417592514 On 08/10/2018 15:24, Wayne Stambaugh wrote: I'm making a last call for any bug fixes that need to made to the 5.0 branch for the 5.0.1 release. Please let me know if you have any pending fixes before I tag 5.0.1. I intend to tag this around 6PM EST unless I hear otherwise. How much time will our translators and librarians need to tag 5.0.1? Hopefully not too long so we can give our packagers time to get release packages built. I would like to make the release announcement this coming weekend if at all possible. I also intend to leave the 5.0.1 tag as the revision and set the source archive version to 5.0.1-unknown so the -dev suffix will no longer be in play moving forward which should make our packagers happy. 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 ___ 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] 5.0.1 status
Hi Rene, I didn't see anything the the list you linked that I would consider a show stopper. I wait until you post the results of you test script against the latest changes. Thanks, Wayne On 10/8/2018 11:35 AM, Rene Pöschl wrote: > Regarding libs. > > I would need to run the script testing for incompatible changes with the > current master. (I can do this as soon as i am home today. So in a few > hours.) I already ran it at the end of August the changes that occurred > until then are documented in [1] > > As soon as i update that list somebody will need to decide if the > changes are acceptable for being included. If not then 5.0.1 should > continue to ship with the libs tagged as 5.0.0 (It would not make much > sense to add a new tag onto the same commit. I would even argue that > this might confuse users who would expect changes if a new tag is created.) > > [1]: > https://github.com/KiCad/kicad-symbols/issues/856#issuecomment-417592514 > > On 08/10/2018 15:24, Wayne Stambaugh wrote: >> I'm making a last call for any bug fixes that need to made to the 5.0 >> branch for the 5.0.1 release. Please let me know if you have any >> pending fixes before I tag 5.0.1. I intend to tag this around 6PM EST >> unless I hear otherwise. How much time will our translators and >> librarians need to tag 5.0.1? Hopefully not too long so we can give our >> packagers time to get release packages built. I would like to make the >> release announcement this coming weekend if at all possible. >> >> I also intend to leave the 5.0.1 tag as the revision and set the source >> archive version to 5.0.1-unknown so the -dev suffix will no longer be in >> play moving forward which should make our packagers happy. >> >> 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] 5.0.1 status
As a packager, I'd prefer to have both the 5.0.0 and 5.0.1 tags on the same commit, if it turns out that nothing has changed in the libs. The reason is that the Fedora spec file only has one version number, yet it pulls in 7 separate tar balls. It would definitely be awkward to have multiple tar ball versions contributing to a single RPM. Steve On 10/8/18 11:35 AM, Rene Pöschl wrote: > Regarding libs. > > I would need to run the script testing for incompatible changes with the > current master. (I can do this as soon as i am home today. So in a few > hours.) I already ran it at the end of August the changes that occurred until > then are documented in [1] > > As soon as i update that list somebody will need to decide if the changes are > acceptable for being included. If not then 5.0.1 should continue to ship with > the libs tagged as 5.0.0 (It would not make much sense to add a new tag onto > the same commit. I would even argue that this might confuse users who would > expect changes if a new tag is created.) > > [1]: https://github.com/KiCad/kicad-symbols/issues/856#issuecomment-417592514 > > On 08/10/2018 15:24, Wayne Stambaugh wrote: >> I'm making a last call for any bug fixes that need to made to the 5.0 >> branch for the 5.0.1 release. Please let me know if you have any >> pending fixes before I tag 5.0.1. I intend to tag this around 6PM EST >> unless I hear otherwise. How much time will our translators and >> librarians need to tag 5.0.1? Hopefully not too long so we can give our >> packagers time to get release packages built. I would like to make the >> release announcement this coming weekend if at all possible. >> >> I also intend to leave the 5.0.1 tag as the revision and set the source >> archive version to 5.0.1-unknown so the -dev suffix will no longer be in >> play moving forward which should make our packagers happy. >> >> 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] [PATCH]/Question TITLE_BLOCK tests
Hi Wayne,
I have no ideas why that would be, but the QA stuff does have a funny
way of exposing strange link behaviours. In this case, we have:
target_link_libraries( qa_common
common
polygon
bitmaps
${Boost_UNIT_TEST_FRAMEWORK_LIBRARY}
${wxWidgets_LIBRARIES} # doesn't this provide wxcolourbase??
)
I have no explanation for why wxColourBase::FromString doesn't link
here. Perhaps it's a similar reason for whatever prompted this being
necessary for pcb_test_window:
target_link_libraries( test_window
polygon
pnsrouter
common
pcbcommon
bitmaps
polygon
pnsrouter
common
pcbcommon
bitmaps
polygon
pnsrouter
common
pcbcommon
bitmaps
polygon
pnsrouter
common
pcbcommon
3d-viewer
bitmaps
gal
pcad2kicadpcb
common
pcbcommon
${GITHUB_PLUGIN_LIBRARIES}
common
pcbcommon
${Boost_FILESYSTEM_LIBRARY}
${Boost_SYSTEM_LIBRARY}
${Boost_UNIT_TEST_FRAMEWORK_LIBRARY}
${wxWidgets_LIBRARIES}
)
Cheers,
John
On Mon, Oct 8, 2018 at 5:39 PM Wayne Stambaugh wrote:
>
> Hi John,
>
> I am getting the following build error on windows with this patch:
>
> C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe:
> ../../common/libgal.a(color4d.cpp.obj):color4d.cpp:(.text+0x1c9):
> undefined reference to `wxColourBase::FromString(wxString const&)'
> C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe:
> ../../common/libgal.a(color4d.cpp.obj):color4d.cpp:(.text+0x32e):
> undefined reference to `wxColourBase::GetAsString(long) const'
> C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe:
> ../../common/libgal.a(color4d.cpp.obj):color4d.cpp:(.text+0x80c):
> undefined reference to `wxColourBase::GetAsString(long) const'
> C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe:
> ../../common/libgal.a(gal_display_options.cpp.obj):gal_display_options.cpp:(.text+0x22b):
> undefined reference to `wxConfigBase::Read(wxString const&, long*, long)
> const'
> C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe:
> ../../common/libgal.a(gal_display_options.cpp.obj):gal_display_options.cpp:(.text+0x2b8):
> undefined reference to `wxConfigBase::Read(wxString const&, long*, long)
> const'
> C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe:
> ../../common/libgal.a(gal_display_options.cpp.obj):gal_display_options.cpp:(.text+0x347):
> undefined reference to `wxConfigBase::Read(wxString const&, double*,
> double) const'
> C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe:
> ../../common/libgal.a(gal_display_options.cpp.obj):gal_display_options.cpp:(.text+0x398):
> undefined reference to `wxConfigBase::Read(wxString const&, double*,
> double) const'
> collect2.exe: error: ld returned 1 exit status
> make[2]: *** [qa/common/CMakeFiles/qa_common.dir/build.make:217:
> qa/common/qa_common.exe] Error 1
> make[1]: *** [CMakeFiles/Makefile2:3111:
> qa/common/CMakeFiles/qa_common.dir/all]
>
>
>
> On 10/6/2018 3:48 PM, John Beard wrote:
> > Hi Wayne,
> >
> > On Sat, Oct 6, 2018 at 5:29 PM Wayne Stambaugh wrote:
> >> No problem. I will test your patch once you post it.
> >
> > Patch attached. Indeed, it was a missing include in the header that
> > probably worked until now due to serendipitous include ordering in the
> > existing CPPs.
> >
> > This actually illustrates one nice thing about having unit tests CPPs
> > that include only a single KiCad header - they make sure that header
> > and any transitive includes are compilable even when the test CPP only
> > includes that one header (i.e. as recommended by the code guidelines:
> > 6.2 Headers Without Unsatisfied Dependencies [1]).
> >
> > Another way this can improved is when you have a .cpp/.h pair for a
> > self-contained class, the .cpp should include the corresponding .h
> > first before any other include. This ensures the header is compilable
> > by itself, and has no implicit inclusion criteria for use. This is
> > sometimes, but not always true in KiCad. (In this case, there is no
> > .cpp anyway, so the unit test was the first CPP to attempt to include
> > by itself).
> >
> >> The problem is all of the inline functions defined in convert_to_biu.h.
> >> Until they are replaced with per application equivalents, we will
> >> continue to have to compile every common source file multiple times that
> >> use anything in this file.
> >
> > Right, but in the case of dialog_page_settings.cpp in particular, the
> > only definition actually needed from here was IU_PER_MILS,
> > which can be equivalently retrieved, via the virtual BASE_SCREEN
> > interface, from the derived class, where IU_PER_MILS is properly set
> > for each compiled target (eeschema, pl_editor, pcbnew).
Re: [Kicad-developers] [PATCH]/Question TITLE_BLOCK tests
Hi John, I am getting the following build error on windows with this patch: C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe: ../../common/libgal.a(color4d.cpp.obj):color4d.cpp:(.text+0x1c9): undefined reference to `wxColourBase::FromString(wxString const&)' C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe: ../../common/libgal.a(color4d.cpp.obj):color4d.cpp:(.text+0x32e): undefined reference to `wxColourBase::GetAsString(long) const' C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe: ../../common/libgal.a(color4d.cpp.obj):color4d.cpp:(.text+0x80c): undefined reference to `wxColourBase::GetAsString(long) const' C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe: ../../common/libgal.a(gal_display_options.cpp.obj):gal_display_options.cpp:(.text+0x22b): undefined reference to `wxConfigBase::Read(wxString const&, long*, long) const' C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe: ../../common/libgal.a(gal_display_options.cpp.obj):gal_display_options.cpp:(.text+0x2b8): undefined reference to `wxConfigBase::Read(wxString const&, long*, long) const' C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe: ../../common/libgal.a(gal_display_options.cpp.obj):gal_display_options.cpp:(.text+0x347): undefined reference to `wxConfigBase::Read(wxString const&, double*, double) const' C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/bin/ld.exe: ../../common/libgal.a(gal_display_options.cpp.obj):gal_display_options.cpp:(.text+0x398): undefined reference to `wxConfigBase::Read(wxString const&, double*, double) const' collect2.exe: error: ld returned 1 exit status make[2]: *** [qa/common/CMakeFiles/qa_common.dir/build.make:217: qa/common/qa_common.exe] Error 1 make[1]: *** [CMakeFiles/Makefile2:3111: qa/common/CMakeFiles/qa_common.dir/all] On 10/6/2018 3:48 PM, John Beard wrote: > Hi Wayne, > > On Sat, Oct 6, 2018 at 5:29 PM Wayne Stambaugh wrote: >> No problem. I will test your patch once you post it. > > Patch attached. Indeed, it was a missing include in the header that > probably worked until now due to serendipitous include ordering in the > existing CPPs. > > This actually illustrates one nice thing about having unit tests CPPs > that include only a single KiCad header - they make sure that header > and any transitive includes are compilable even when the test CPP only > includes that one header (i.e. as recommended by the code guidelines: > 6.2 Headers Without Unsatisfied Dependencies [1]). > > Another way this can improved is when you have a .cpp/.h pair for a > self-contained class, the .cpp should include the corresponding .h > first before any other include. This ensures the header is compilable > by itself, and has no implicit inclusion criteria for use. This is > sometimes, but not always true in KiCad. (In this case, there is no > .cpp anyway, so the unit test was the first CPP to attempt to include > by itself). > >> The problem is all of the inline functions defined in convert_to_biu.h. >> Until they are replaced with per application equivalents, we will >> continue to have to compile every common source file multiple times that >> use anything in this file. > > Right, but in the case of dialog_page_settings.cpp in particular, the > only definition actually needed from here was IU_PER_MILS, > which can be equivalently retrieved, via the virtual BASE_SCREEN > interface, from the derived class, where IU_PER_MILS is properly set > for each compiled target (eeschema, pl_editor, pcbnew). > >> This is odd as they are both in the COMMON_SRCS list. Actually, >> color.cpp is included twice. Once in KICAD_SRCS and once in COMMON_SRCS >> which includes KICAD_SRCS. We should remove color.cpp from either >> KICAD_SRCS or COMMON_SRCS. I see no need to build it twice. > > Even more odd. Removing one of the colors.cpp from the > common/CMakeLists.cpp didn't stop qa_common having to specifiy it > again, though. > > For colors.cpp specifically, this is an issue which will be resolved > when, as promised in colors.h, the removal of legacy support will make > the global colour table obsolete. So it's perhaps more of a curiosity > than an issue? > > Regardless, if anyone can shed light on this, I'd appreciate it, as it > probably indicates something fishy somewhere? > > Cheers, > > John > > [1]: > http://docs.kicad-pcb.org/doxygen/md_Documentation_development_coding-style-policy.html#header_depends > ___ 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] Fuzzable PCB parsing test harness
Sorry, I wrote "ms", I meant "us" - the times are in the handful-of-millsecond range. Cheers, John On Mon, Oct 8, 2018 at 5:24 PM John Beard wrote: > > Hi, > > This is a patch to add a test program that allows to parse a Pcbnew > file from command line params or stdin. This means you can use it for > fuzz testing. > > I have done a little bit of fuzz testing so far (8 million execs, > about 70% of a cycle), and have not found any crashes, but I can make > it hang in a few ways. These all seem to be in streams which contain > nul's. This is actually not reachable from the UI due to reading files > into wxStrings first (nut quite sure why), whereas this program uses > the parser directly. Thus, the bug is probably not very critical. > Example hanging input attached (note there's a nul in it, so your > editor may or may not like that). > > This program can also be fed a number of files, which means it could > be used for automated testing that all files in a batch can be parsed > successfully, and also provides a handy way to put GDB on a program > when debugging the parser against specific input. > > There is timing on the parsing too, mostly for interest (use the -v > flag). It takes about 150-3000ms per FP on my machine for the FPs in > Connector_PinSocket_2.54mm.pretty. > > There's also some centralisation of some QA-related utils into a > qa_utils library. > > Cheers, > > John ___ 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] Fuzzable PCB parsing test harness
Hi,
This is a patch to add a test program that allows to parse a Pcbnew
file from command line params or stdin. This means you can use it for
fuzz testing.
I have done a little bit of fuzz testing so far (8 million execs,
about 70% of a cycle), and have not found any crashes, but I can make
it hang in a few ways. These all seem to be in streams which contain
nul's. This is actually not reachable from the UI due to reading files
into wxStrings first (nut quite sure why), whereas this program uses
the parser directly. Thus, the bug is probably not very critical.
Example hanging input attached (note there's a nul in it, so your
editor may or may not like that).
This program can also be fed a number of files, which means it could
be used for automated testing that all files in a batch can be parsed
successfully, and also provides a handy way to put GDB on a program
when debugging the parser against specific input.
There is timing on the parsing too, mostly for interest (use the -v
flag). It takes about 150-3000ms per FP on my machine for the FPs in
Connector_PinSocket_2.54mm.pretty.
There's also some centralisation of some QA-related utils into a
qa_utils library.
Cheers,
John
From 642c679fb5c16a4a1fbc76205e745ef8f09cf921 Mon Sep 17 00:00:00 2001
From: John Beard
Date: Sat, 6 Oct 2018 15:35:17 +0100
Subject: [PATCH] QA: PCB file input parse test program (fuzzable)
This adds a test program which can be used to test the
parsing of a given KiCad PCB file. This interface is
useful for both manual or automated debugging of given
files, as well as providing an interface suitable for
fuzz-testing tools.
Also adds to the testing docs to detail how fuzzing can
be used.
Also moves some useful re-usable code from io-benchmark
to a new library qa_utils, which can contain code that
isn't need in the actual KiCad libs.
---
Documentation/development/testing.md | 47 +-
qa/CMakeLists.txt | 4 +
qa/pcb_parse_input/CMakeLists.txt | 70
qa/pcb_parse_input/main.cpp | 157 ++
qa/qa_utils/CMakeLists.txt| 40 +
qa/qa_utils/scoped_timer.h| 62 +++
.../qa_utils}/stdstream_line_reader.cpp | 8 +-
.../qa_utils}/stdstream_line_reader.h | 8 +-
tools/io_benchmark/CMakeLists.txt | 2 +-
9 files changed, 389 insertions(+), 9 deletions(-)
create mode 100644 qa/pcb_parse_input/CMakeLists.txt
create mode 100644 qa/pcb_parse_input/main.cpp
create mode 100644 qa/qa_utils/CMakeLists.txt
create mode 100644 qa/qa_utils/scoped_timer.h
rename {tools/io_benchmark => qa/qa_utils}/stdstream_line_reader.cpp (91%)
rename {tools/io_benchmark => qa/qa_utils}/stdstream_line_reader.h (92%)
diff --git a/Documentation/development/testing.md b/Documentation/development/testing.md
index 4726ca536..cf0d4c129 100644
--- a/Documentation/development/testing.md
+++ b/Documentation/development/testing.md
@@ -103,6 +103,51 @@ You can run the tests in GDB to trace this:
If the test segfaults, you will get a familiar backtrace, just like
if you were running pcbnew under GDB.
+## Fuzz testing ##
+
+It is possible to run fuzz testing on some parts of KiCad. To do this for a
+generic function, you need to be able to pass some kind of input from the fuzz
+testing tool to the function under test.
+
+For example, to use the [AFL fuzzing tool][], you will need:
+
+* A test executable that can:
+** Receive input from `stdin` to be run by `afl-fuzz`.
+** Optional: process input from a filename to allow `afl-tmin` to minimise the
+ input files.
+* To compile this executable with an AFL compiler, to enable the instrumentation
+ that allows the fuzzer to detect the fuzzing state.
+
+For example, the `qa_pcb_parse_input` executable can be compiled like this:
+
+mkdir build
+cd build
+cmake -DCMAKE_CXX_COMPILER=/usr/bin/afl-clang-fast++ -DCMAKE_C_COMPILER=/usr/bin/afl-clang-fast ../kicad_src
+make qa_pcb_parse_input
+
+You may need to disable core dumps and CPU frequency scaling on your system (AFL
+will warn you if you should do this). For example, as root:
+
+# echo core >/proc/sys/kernel/core_pattern
+# echo performance | tee cpu*/cpufreq/scaling_governor
+
+To fuzz:
+
+afl-fuzz -i fuzzin -o fuzzout -m500 qa/pcb_parse_input/qa_pcb_parse_input
+
+where:
+
+* `-i` is a directory of files to use as fuzz input "seeds"
+* `-o` is a directory to write the results (including inputs that provoke crashes
+ or hangs)
+* `-t` is the maximum time that a run is allowed to take before being declared a "hang"
+* `-m` is the memory allowed to use (this often needs to be bumped, as KiCad code
+ tends to use a lot of memory to initialise)
+
+The AFL TUI will then display the fuzzing progress, and you can use the hang- or
+crash-provoking inputs to debug code as needed.
+
[CTest]: https://cmake.org/cmake/help/latest/module/CTest.html
[Boost Unit Test framework]:
Re: [Kicad-developers] 5.0.1 status
Regarding libs. I would need to run the script testing for incompatible changes with the current master. (I can do this as soon as i am home today. So in a few hours.) I already ran it at the end of August the changes that occurred until then are documented in [1] As soon as i update that list somebody will need to decide if the changes are acceptable for being included. If not then 5.0.1 should continue to ship with the libs tagged as 5.0.0 (It would not make much sense to add a new tag onto the same commit. I would even argue that this might confuse users who would expect changes if a new tag is created.) [1]: https://github.com/KiCad/kicad-symbols/issues/856#issuecomment-417592514 On 08/10/2018 15:24, Wayne Stambaugh wrote: I'm making a last call for any bug fixes that need to made to the 5.0 branch for the 5.0.1 release. Please let me know if you have any pending fixes before I tag 5.0.1. I intend to tag this around 6PM EST unless I hear otherwise. How much time will our translators and librarians need to tag 5.0.1? Hopefully not too long so we can give our packagers time to get release packages built. I would like to make the release announcement this coming weekend if at all possible. I also intend to leave the 5.0.1 tag as the revision and set the source archive version to 5.0.1-unknown so the -dev suffix will no longer be in play moving forward which should make our packagers happy. 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
Re: [Kicad-developers] Cairo printing
Le 08/10/2018 à 15:56, Maciej Sumiński a écrit : > Hi Jean-Pierre, > > On 10/8/18 3:08 PM, jp charras wrote: > [snip] >> Hi Orson, >> Very good job. >> >> I tested the Cairo printing both on Windows and Linux. >> >> No problem on Linux. >> On Windows, I have strange artifacts (see attached picture) in print >> preview. >> (more strange, if a zone outline includes the full board items, there >> are no, or very few, artifacts) > > I will check it, but I am afraid it might be beyond my control. Do you > see it in actual printouts/PDFs as well? No. These artifacts are only in print preview, and only when some item uses a opacity < 1.0 > >> It happens only when the opacity of any printed item is not set to 1.0 >> >> Moreover, when the opacity of any printed item is not set to 1.0, the >> resulting printed picture is a bitmap (tested both using Cutepdf and a >> printer using a postscript driver), not really usable. >> (When all objects use a 1.0 opacity, the drawings are vectored, as expected) >> >> Due to the fact transparency is not working very well on Cairo, and >> useless when printing a board with one sheet by layer, I suggest to >> force the opacity to 1.0 in any case. > > That is surprising, I will need a closer look then. I would like to > preserve transparency, but I agree that getting bitmaps instead of > vector graphics is not acceptable. Transparency is useful only when printing many layers on the same sheet. It is not very good when printing one layer by sheet. > > Regards, > Orson -- 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] Cairo printing
On Montag, 8. Oktober 2018 15:52:22 CEST Maciej Sumiński wrote: > Hi Zoltan, > > Good catch, I have just fixed the problem in cairo_printing branch. Fix confirmed, thx > Regards, > Orson > > On 10/8/18 10:49 AM, zgyarm...@zgyarmati.de wrote: > > Dear Maciej, > > > > i checked out and compiled your branch, it builds properly (Ubuntu 18.04, > > x86_64), but when i tested the print functionality, i noted that the > > marker > > for the zone fill perimeter is visible on the printed layout, see attached > > pdf (printed into file via the normal print dialog) and a screenshot of > > the fairly simple board. > > > > > > Regards > > Zoltan Gyarmati > > https://zgyarmati.de ___ 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] 5.0.1 status
My finger is on the big red GAL button…. > On 8 Oct 2018, at 14:24, Wayne Stambaugh wrote: > > I'm making a last call for any bug fixes that need to made to the 5.0 > branch for the 5.0.1 release. Please let me know if you have any > pending fixes before I tag 5.0.1. I intend to tag this around 6PM EST > unless I hear otherwise. How much time will our translators and > librarians need to tag 5.0.1? Hopefully not too long so we can give our > packagers time to get release packages built. I would like to make the > release announcement this coming weekend if at all possible. > > I also intend to leave the 5.0.1 tag as the revision and set the source > archive version to 5.0.1-unknown so the -dev suffix will no longer be in > play moving forward which should make our packagers happy. > > 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
Re: [Kicad-developers] Cairo printing
Hi Simon, On 10/8/18 3:19 PM, Simon Richter wrote: > Hi, > > On 10/08/2018 08:59 AM, Maciej Sumiński wrote: > >> The only reasonable way to make wxDC and Cairo compatible is via >> wxGraphicsContext, as it uses Cairo underneath. > > wxDC also uses Cairo internally when wx is linked against GTK3. :P True, but I am trying solve a GTK version compatibility problem, not add one ;) > Windows binaries for the cairo_printing branch can be found at > > > http://downloads.kicad-pcb.org/windows/testing/patched/kicad-patched-142-3024ded91-x86_64.exe > > in case anyone wants to help testing. Many thanks, I really appreciate it! Cheers, Orson signature.asc Description: OpenPGP digital signature ___ 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] Cairo printing
Hi Jean-Pierre, On 10/8/18 3:08 PM, jp charras wrote: [snip] > Hi Orson, > Very good job. > > I tested the Cairo printing both on Windows and Linux. > > No problem on Linux. > On Windows, I have strange artifacts (see attached picture) in print > preview. > (more strange, if a zone outline includes the full board items, there > are no, or very few, artifacts) I will check it, but I am afraid it might be beyond my control. Do you see it in actual printouts/PDFs as well? > It happens only when the opacity of any printed item is not set to 1.0 > > Moreover, when the opacity of any printed item is not set to 1.0, the > resulting printed picture is a bitmap (tested both using Cutepdf and a > printer using a postscript driver), not really usable. > (When all objects use a 1.0 opacity, the drawings are vectored, as expected) > > Due to the fact transparency is not working very well on Cairo, and > useless when printing a board with one sheet by layer, I suggest to > force the opacity to 1.0 in any case. That is surprising, I will need a closer look then. I would like to preserve transparency, but I agree that getting bitmaps instead of vector graphics is not acceptable. Regards, Orson signature.asc Description: OpenPGP digital signature ___ 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] Cairo printing
Hi Zoltan, Good catch, I have just fixed the problem in cairo_printing branch. Regards, Orson On 10/8/18 10:49 AM, zgyarm...@zgyarmati.de wrote: > Dear Maciej, > > i checked out and compiled your branch, it builds properly (Ubuntu 18.04, > x86_64), but when i tested the print functionality, i noted that the marker > for the zone fill perimeter is visible on the printed layout, see attached > pdf > (printed into file via the normal print dialog) and a screenshot of the > fairly > simple board. > > > Regards > Zoltan Gyarmati > https://zgyarmati.de signature.asc Description: OpenPGP digital signature ___ 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] Cairo printing
Hi, On 10/08/2018 08:59 AM, Maciej Sumiński wrote: > The only reasonable way to make wxDC and Cairo compatible is via > wxGraphicsContext, as it uses Cairo underneath. wxDC also uses Cairo internally when wx is linked against GTK3. :P Windows binaries for the cairo_printing branch can be found at http://downloads.kicad-pcb.org/windows/testing/patched/kicad-patched-142-3024ded91-x86_64.exe in case anyone wants to help testing. 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
[Kicad-developers] 5.0.1 status
I'm making a last call for any bug fixes that need to made to the 5.0 branch for the 5.0.1 release. Please let me know if you have any pending fixes before I tag 5.0.1. I intend to tag this around 6PM EST unless I hear otherwise. How much time will our translators and librarians need to tag 5.0.1? Hopefully not too long so we can give our packagers time to get release packages built. I would like to make the release announcement this coming weekend if at all possible. I also intend to leave the 5.0.1 tag as the revision and set the source archive version to 5.0.1-unknown so the -dev suffix will no longer be in play moving forward which should make our packagers happy. 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
Re: [Kicad-developers] Cairo printing
Le 08/10/2018 à 08:59, Maciej Sumiński a écrit : > On 10/7/18 10:05 PM, Wayne Stambaugh wrote: > [snip] >> This makes me nervous. The gdiplus library brings wxGraphicsContext >> into play on windows. Something from wxGraphicsContext is being pulled >> into the kicad build which can be enabled by configuring builds with >> -DUSE_WX_GRAPHICS_CONTEXT=ON. I would have thought with cairo being >> both the display and print context that gdiplus would not be required >> for linking kicad. > > Hi Wayne, Jean-Pierre, > > Thank you for testing the code. I have already followed Tom's suggestion > and added gdiplus to linked libraries in my branch. > > I wanted to take advantage of wxWidgets as much as I could, so I was > forced to work with wxDC. Otherwise I would have to go much deeper and > deal directly with CUPS and GDI+ to invoke a printing dialog and > actually start printing. > > The only reasonable way to make wxDC and Cairo compatible is via > wxGraphicsContext, as it uses Cairo underneath. Have a look at > cairo_print.cpp [1] to see ugly details, but it is the only place where > I refer to gdiplus. I have not enabled USE_WX_GRAPHICS_CONTEXT on > purpose, as it seems to affect legacy canvases which is not needed here. > > Cheers, > Orson > > 1. > https://git.launchpad.net/~orsonmmz/kicad/tree/common/gal/cairo/cairo_print.cpp?h=cairo_printing#n70 Hi Orson, Very good job. I tested the Cairo printing both on Windows and Linux. No problem on Linux. On Windows, I have strange artifacts (see attached picture) in print preview. (more strange, if a zone outline includes the full board items, there are no, or very few, artifacts) It happens only when the opacity of any printed item is not set to 1.0 Moreover, when the opacity of any printed item is not set to 1.0, the resulting printed picture is a bitmap (tested both using Cutepdf and a printer using a postscript driver), not really usable. (When all objects use a 1.0 opacity, the drawings are vectored, as expected) Due to the fact transparency is not working very well on Cairo, and useless when printing a board with one sheet by layer, I suggest to force the opacity to 1.0 in any case. -- 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
[Kicad-developers] Net selector
How’s that Net Selector working these days? Is all good, or are people just tired of reporting issues with it? ;) Cheers, Jeff. ___ 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] Cairo printing
On 10/7/18 10:05 PM, Wayne Stambaugh wrote: [snip] > This makes me nervous. The gdiplus library brings wxGraphicsContext > into play on windows. Something from wxGraphicsContext is being pulled > into the kicad build which can be enabled by configuring builds with > -DUSE_WX_GRAPHICS_CONTEXT=ON. I would have thought with cairo being > both the display and print context that gdiplus would not be required > for linking kicad. Hi Wayne, Jean-Pierre, Thank you for testing the code. I have already followed Tom's suggestion and added gdiplus to linked libraries in my branch. I wanted to take advantage of wxWidgets as much as I could, so I was forced to work with wxDC. Otherwise I would have to go much deeper and deal directly with CUPS and GDI+ to invoke a printing dialog and actually start printing. The only reasonable way to make wxDC and Cairo compatible is via wxGraphicsContext, as it uses Cairo underneath. Have a look at cairo_print.cpp [1] to see ugly details, but it is the only place where I refer to gdiplus. I have not enabled USE_WX_GRAPHICS_CONTEXT on purpose, as it seems to affect legacy canvases which is not needed here. Cheers, Orson 1. https://git.launchpad.net/~orsonmmz/kicad/tree/common/gal/cairo/cairo_print.cpp?h=cairo_printing#n70 signature.asc Description: OpenPGP digital signature ___ 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
