Re: [Kicad-developers] [PATCH] Add preferences dialog hotkey

[John Beard]

Hi,

I'd suggest perhaps Ctrl-Shift-P, which is used by Inkscape. P with various 
modifiers is fairly common shortcut for preferences: 
https://defkey.com/search?irq=Preferences

I feel like Ctrl-, might be useful as paired hotkey with Ctrl-. (eg 
increase/decrease)?

Cheers,

John

On 16 October 2018 22:24:51 BST, Michael Kavanagh  
wrote:
>Hi,
>
>Attached is a patch that assigns Ctrl+, (Cmd+, on Mac as per the HIG)
>to opening the preferences dialog and adds the hotkey to all menu bar
>menus.
>
>Please note this causes a conflict with the "Interactive Router
>Settings..." hotkey in Pcbnew (pcbnew/hotkeys.cpp line 275), so this
>should be set to something else. I didn't know what to set it as so I
>left it. Perhaps require shift or alt?
>
>Also corrected the "hokey" typo throughout.
>
>Cheers,
>Michael
___
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

[John Beard]

Hi Wayne,

I think I might have fixed the ordering in the link libraries (at
least, it now builds on Jenkins).

This is just the first patch to focus on the build error, I'll rebase
the other docs stuff later if/when it works.

Cheers,

John
On Fri, Oct 12, 2018 at 7:58 PM Wayne Stambaugh  wrote:
>
> John,
>
> This patch fails to link on windows.  I've attached the build error.
>
> Wayne
>
> On 10/9/2018 9:53 AM, John Beard wrote:
> > Hi,
> >
> > Here is an update patch that rebases over the commenting out of
> > pcb_test_window, polygon_triangulation and polygon_generator and fixes
> > a link error to do with base_screen.cpp.
> >
> > Cheers,
> >
> > John
> > On Mon, Oct 8, 2018 at 5:27 PM John Beard  wrote:
> >>
> >> 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
> ___
> 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 985a3e5e0007d2a7b17bdfd5173a65fb3de0eb60 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Sat, 6 Oct 2018 15:35:17 +0100
Subject: [PATCH 1/2] 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 |  67 
 qa/pcb_parse_input/main.cpp   | 158 ++
 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, 387 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}/stds

Re: [Kicad-developers] 5.0.1 release status.

[John Beard]

Hi Wayne,

There was a commit on master made for this purpose: 9a3cfb857. The
function is to remove a failing test and thereby avoid having to
exclude it from the CTest harness, which doesn't work on old Boosts. I
thought it was in v5, but it is evidently not (and git branch
--contains concurs).

A simple cherry-pick should work.

Cheers,

John
On Mon, Oct 15, 2018 at 7:03 PM Wayne Stambaugh  wrote:
>
> JS is on the mailing list.  I suspect he will reply soon.
>
> On 10/15/2018 1:59 PM, Ronnie Gaensli wrote:
> > Hi all!
> >
> > I've been awaiting the 5.0.1 release to be officially available via the
> > ppa of js-reynaud. Though unfortunatley there's an issue with the
> > build: 
> > https://launchpad.net/~js-reynaud/+archive/ubuntu/kicad-5/+build/15533528
> > Actually it's the tests that cause the
> > issue: 
> > https://launchpadlibrarian.net/392947878/buildlog_ubuntu-trusty-amd64.kicad_5.0.1-stable-201810121506+33cea8e~66~ubuntu14.04.1_BUILDING.txt.gz
> > at the very bottom
> >
> > I'm not yet in the position to tell the cause, but I would like raise
> > awareness of this. Does Js-Reynaud read this here?, shall I contact him
> > directly via launchpad, ? What best to do?
> >
> > Cheers
> > Ronnie
> >
> >
> > Am So., 14. Okt. 2018 um 19:43 Uhr schrieb Wayne Stambaugh
> > mailto:stambau...@gmail.com>>:
> >
> > We will have to do the usual tagging of all of the repos with 5.0.2
> > so I
> > will have to wait to see if there any issues.  I shouldn't take very
> > long so 5.0.1 may be a very short lived release.
> >
> > On 10/14/2018 01:13 PM, Adam Wolf wrote:
> > > I think there are some 5.0.1s already up for download... Any issue
> > just
> > > going to 5.0.2?
> > >
> > > Adam
> > >
> > > On Sun, Oct 14, 2018, 11:05 AM Wayne Stambaugh
> > mailto:stambau...@gmail.com>
> > > >> wrote:
> > >
> > > I'm fine with pushing the release back another week.  I would
> > rather not
> > > release 5.0.1 with this bug.  We have a lot of ex-Eagle users and
> > > breaking Eagle import is not good.  I see one of two options here.
> > > Retag 5.0.1 with the current changes or release 5.0.2
> > immediately.  I
> > > don't know which is more work for our packagers so I am open
> > to either
> > > option.  Please let me know what works best for you and I will
> > go with
> > > that option.
> > >
> > > Cheers,
> > >
> > > Wayne
> > >
> > > On 10/14/2018 10:02 AM, Seth Hillbrand wrote:
> > >  > Hi Wayne, et al-
> > >  >
> > >  > There is a critical bug that I introduced
> > >  > with a5bdee747a59f80cf46f5aad5593aa4e1617b7c3  in 5.0.1.
> > It affects
> > >  > certain Eagle files imports and causes a crash.
> > >  >
> > >  > I've fixed this in the 5.0.2 tree.  I'm sorry for the extra
> > problems.
> > >  >
> > >  > Between this and the footprint wizard, we may wish to
> > announce a
> > > 5.0.2
> > >  > sooner rather than later.  Or packagers may wish to pull in the
> > >  > post-5.0.2 tagged commits as patches to their builds before
> > > announcement.
> > >  >
> > >  > -S
> > >  >
> > >  > Am Fr., 12. Okt. 2018 um 05:39 Uhr schrieb Wayne Stambaugh
> > >  > mailto:stambau...@gmail.com>
> > >
> > > 
> >  > >  >
> > >  > Does anyone need more time to get packages built for the
> > > 5.0.1 release?
> > >  > I am hoping to release on Sunday if possible.  Please
> > let me
> > > know if you
> > >  > need any additional time.
> > >  >
> > >  > Cheers,
> > >  >
> > >  > Wayne
> > >  >
> > >  > ___
> > >  > Mailing list: https://launchpad.net/~kicad-developers
> > > 
> > >  > 
> > >  > Post to : kicad-developers@lists.launchpad.net
> > 
> > >  > >
> > >  >  > 
> > >  > >>
> > >  > Unsubscribe : https://launchpad.net/~kicad-developers
> > > 
> > >  >   

Re: [Kicad-developers] [PATCH]/Question TITLE_BLOCK tests

[John Beard]

Hi Wayne,

I understand the problems with linking when units are involved. This
particular test executable defines GERBVIEW to satisfy the need to
have a valid #define set in convert_to_biu.h. It doesn't actually use
any unit code directly. TITLE_BLOCK is just a few strings in a class,
but somehow one of the transitive includes ends up pulling enough
stuff in that the define is needed.

I don't think this is caused by unit code in particular, normally
that's pretty clear from the failure messages.

Cheers,

John
On Fri, Oct 12, 2018 at 8:05 PM Wayne Stambaugh  wrote:
>
> Hey John,
>
> Any code that has to be built multiple times to get the correct base
> units scalar will most likely fail linking unless you only care about
> testing a specific unit scalar such as PCBNEW or EESCHEMA in which case
> you would need to include the appropriate libraries.  You cannot make
> any generic test such as the worksheet code which is unit scalar
> dependent.  You would have to create a separate test for each unit
> scalar.  In other words you would have to write a schematic, pcbnew, and
> gerbview worksheet test since they each use a different units scalar.
>
> Cheers,
>
> Wayne
>
> On 10/9/2018 10:25 AM, John Beard wrote:
> > Hi Wayne,
> >
> > No problems, I get it!
> >
> > It's not needed for the fuzzing stuff, it's actually a pre-cursor for
> > a patch set to do with the dialog_page_settings dialog, but that is
> > now probably on hold for a bit due to being unable to now include
> > "class_drawpanel.h" from any common lib cpp.
> >
> > However, it's also needed to be able to use unit testing for many
> > libcommon classes (TITLE_BLOCK is not the only one that ends up
> > sucking in tons of dependencies), so if anyone has any ideas about
> > what else is needed to get this to build, I'd appreciate pointers!
> >
> > Cheers,
> >
> > John
> > On Tue, Oct 9, 2018 at 3:04 PM Wayne Stambaugh  wrote:
> >>
> >> Hey John,
> >>
> >> I would like to help you out with this but I'm slammed at work and I'm
> >> not going to be able to help out.  Is this a patch a prerequisite for
> >> your fuzzing patch?
> >>
> >> Cheers,
> >>
> >> Wayne
> >>
> >> On 10/8/2018 1:11 PM, John Beard wrote:
> >>> 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+0x1

Re: [Kicad-developers] [PATCH] Fuzzable PCB parsing test harness

[John Beard]

Hi,

This is an updated path sets that includes some extras on top of the
previously mentioned:

* TOC for the testing docs
* Update the io_benchmark tool to work with full paths.
* Add an in-memory io_benchmark case, which gives an approximate
baseline for how fast it could be without any IO overhead

Cheers,

John
On Thu, Oct 11, 2018 at 11:43 AM John Beard  wrote:
>
> Hi,
>
> Here's a quick patch to add some documentation about print-debugging
> and trace. It's a follow-up to the fuzz tool, as there would be a
> conflict in the MD file, as one section follows the other, so it needs
> to go in afterwards, or otherwise be manually resolved.
>
> Also includes a handy list of WXTRACE masks, as they aren't easily
> found (you have to grep for wxLogTrace, then grep for the mask
> variable to find the actual string to use). I didn't document the
> functions, as they're pretty self-explanatory ("KICAD_FIND_ITEM: info
> about the "Find Item" tool" is not that helpful!).
>
> Cheers,
>
> John
> On Tue, Oct 9, 2018 at 2:53 PM John Beard  wrote:
> >
> > Hi,
> >
> > Here is an update patch that rebases over the commenting out of
> > pcb_test_window, polygon_triangulation and polygon_generator and fixes
> > a link error to do with base_screen.cpp.
> >
> > Cheers,
> >
> > John
> > On Mon, Oct 8, 2018 at 5:27 PM John Beard  wrote:
> > >
> > > 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
From be14a545f313d01e1048668525fec67a01aa3d75 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Mon, 8 Oct 2018 19:11:46 +0100
Subject: [PATCH 2/3] Add an in-memory STREAM_LINE_READER benchmark

This adds an io-benchmark case of the STRING_LINE_READER
class, which reads a file into a std::string, *then*
reads it line by line.

As expected, due to it all being in memory, this is very fast.

Also fixes an issue in io_benchmark where the input file
must be in the current dir.
---
 qa/qa_utils/stdstream_line_reader.cpp |  4 +-
 tools/io_benchmark/io_benchmark.cpp   | 75 ++-
 2 files changed, 64 insertions(+), 15 deletions(-)

diff --git a/qa/qa_utils/stdstream_line_reader.cpp b/qa/qa_utils/stdstream_line_reader.cpp
index 3f6596fdb..d473f3442 100644
--- a/qa/qa_utils/stdstream_line_reader.cpp
+++ b/qa/qa_utils/stdstream_line_reader.cpp
@@ -68,7 +68,7 @@ void STDISTREAM_LINE_READER::SetStream( std::istream& aStream )
 
 
 IFSTREAM_LINE_READER::IFSTREAM_LINE_READER( const wxFileName& aFileName )  :
-m_fStream( aFileName.GetFullName().ToUTF8() )
+m_fStream( aFileName.GetFullPath().ToUTF8() )
 {
 if( !m_fStream.is_open() )
 {
@@ -79,7 +79,7 @@ IFSTREAM_LINE_READER::IFSTREAM_LINE_READER( const wxFileName& aFileName )  :
 
 SetStream( m_fStream );
 
-m_source = aFileName.GetFullName();
+m_sourc

Re: [Kicad-developers] Net selector

[John Beard]

Hi Jeff,

I'm not a committer, so you might as well go ahead, rather than
messing with a one-line patch from me!

Cheers,

John
On Thu, Oct 11, 2018 at 6:34 PM Jeff Young  wrote:
>
> Hi John,
>
> That’s the right place to adjust it.  There’s also LIST_PADDING which gets 
> put in once (rather than per-item), but it looks like LIST_ITEM_PADDING of 6 
> is doing the trick.
>
> Are you going to commit that, or do you want me to?
>
> Cheers,
> Jeff.
>
>
> On 11 Oct 2018, at 18:33, John Beard  wrote:
>
> Hi Jeff,
>
> It's better now for <= 3 items. For more, it still cuts a little bit
> off, but less than before.
>
> I adjusted LIST_ITEM_PADDING to 6, and it seems to hove done the
> trick. However, I haven't checked very carefully if I have adjusted
> the right thing. Attached are two screenshots, so if you know where to
> measure pixels from, perhaps you can work out if the adjustment is
> even in the right place!
>
> BTW, this is the Xilinx Coldfire demo, if you want to use the same list.
>
> Cheers,
>
> John
> On Thu, Oct 11, 2018 at 12:02 PM Jeff Young  wrote:
>
>
> Hi John,
>
> I removed the filter retention.
>
> I also adjusted the spacing on GTK.  I’ve changed it from what Windows uses 
> to what OSX uses.  It may need yet a 3rd value, so let me know if it’s still 
> too short with only a few list items (or too tall with a bunch of list items).
>
> Cheers,
> Jeff.
>
> On 11 Oct 2018, at 11:54, John Beard  wrote:
>
> Hi Jeff,
>
> It doesn't seem to accept spaces for me on GTK (bea75753d).
>
> I don't think retaining the last filter is extremely useful, though
> perhaps if you were going around changing a lot of things to the same
> net? But that will be a better job for the Object Inspector in future
> anyway.
>
> Cheers,
>
> John
> On Thu, Oct 11, 2018 at 11:15 AM Jeff Young  wrote:
>
>
> I’ve been finding that saving the filter is unexpected, even when useful.  
> And unexpected is always bad, because it erodes one’s confidence in their 
> user model.  So I think I’ll just remove it.
>
> Anyone else (with current code) able to type a space into the filter?  The 
> commits Eeli mentions use the same technique as the Label Properties dialog 
> (although they don’t exclude ‘\’ as you may want to search on that).
>
> On 10 Oct 2018, at 21:20, Eeli Kaikkonen  wrote:
>
> Was the purpose of a0b8755f478f7829ca5 and the one before that to let the 
> filter field to ignore spacebar? If so, it doesn't seem to work. Editing the 
> net label in eeshcema's Label Properties dialog apparently has some excluding 
> code, maybe there's something useful?
>
> Keeping the filter text between combobox "sessions" isn't necessarily good, 
> at least in some cases. If there's nothing to match the filter and it's then 
> canceled by closing the box the user hardly wants to keep the same 
> non-working filter text. Or if (s)he doesn't actually select a net matching 
> the filter. On the other hand it may be wanted after the net has been found 
> and selected. A good compromise could be to always set the text as selected 
> (in the filter text field) when the box is opened. Then the first key press 
> would delete the old text, but the old filtering result would still be 
> available if there's no need to change it. This requires text selecting and 
> cursor to work, but now they don't, as John told. Or maybe he didn't mention 
> text selecting, but it doesn't work anyways.
>
> -Eeli Kaikkonen
> ___
> 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] Net selector

[John Beard]

Hi Jeff,

It's better now for <= 3 items. For more, it still cuts a little bit
off, but less than before.

I adjusted LIST_ITEM_PADDING to 6, and it seems to hove done the
trick. However, I haven't checked very carefully if I have adjusted
the right thing. Attached are two screenshots, so if you know where to
measure pixels from, perhaps you can work out if the adjustment is
even in the right place!

BTW, this is the Xilinx Coldfire demo, if you want to use the same list.

Cheers,

John
On Thu, Oct 11, 2018 at 12:02 PM Jeff Young  wrote:
>
> Hi John,
>
> I removed the filter retention.
>
> I also adjusted the spacing on GTK.  I’ve changed it from what Windows uses 
> to what OSX uses.  It may need yet a 3rd value, so let me know if it’s still 
> too short with only a few list items (or too tall with a bunch of list items).
>
> Cheers,
> Jeff.
>
> > On 11 Oct 2018, at 11:54, John Beard  wrote:
> >
> > Hi Jeff,
> >
> > It doesn't seem to accept spaces for me on GTK (bea75753d).
> >
> > I don't think retaining the last filter is extremely useful, though
> > perhaps if you were going around changing a lot of things to the same
> > net? But that will be a better job for the Object Inspector in future
> > anyway.
> >
> > Cheers,
> >
> > John
> > On Thu, Oct 11, 2018 at 11:15 AM Jeff Young  wrote:
> >>
> >> I’ve been finding that saving the filter is unexpected, even when useful.  
> >> And unexpected is always bad, because it erodes one’s confidence in their 
> >> user model.  So I think I’ll just remove it.
> >>
> >> Anyone else (with current code) able to type a space into the filter?  The 
> >> commits Eeli mentions use the same technique as the Label Properties 
> >> dialog (although they don’t exclude ‘\’ as you may want to search on that).
> >>
> >>> On 10 Oct 2018, at 21:20, Eeli Kaikkonen  wrote:
> >>>
> >>> Was the purpose of a0b8755f478f7829ca5 and the one before that to let the 
> >>> filter field to ignore spacebar? If so, it doesn't seem to work. Editing 
> >>> the net label in eeshcema's Label Properties dialog apparently has some 
> >>> excluding code, maybe there's something useful?
> >>>
> >>> Keeping the filter text between combobox "sessions" isn't necessarily 
> >>> good, at least in some cases. If there's nothing to match the filter and 
> >>> it's then canceled by closing the box the user hardly wants to keep the 
> >>> same non-working filter text. Or if (s)he doesn't actually select a net 
> >>> matching the filter. On the other hand it may be wanted after the net has 
> >>> been found and selected. A good compromise could be to always set the 
> >>> text as selected (in the filter text field) when the box is opened. Then 
> >>> the first key press would delete the old text, but the old filtering 
> >>> result would still be available if there's no need to change it. This 
> >>> requires text selecting and cursor to work, but now they don't, as John 
> >>> told. Or maybe he didn't mention text selecting, but it doesn't work 
> >>> anyways.
> >>>
> >>> -Eeli Kaikkonen
> >>> ___
> >>> 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] Fuzzable PCB parsing test harness

[John Beard]

Hi,

Here's a quick patch to add some documentation about print-debugging
and trace. It's a follow-up to the fuzz tool, as there would be a
conflict in the MD file, as one section follows the other, so it needs
to go in afterwards, or otherwise be manually resolved.

Also includes a handy list of WXTRACE masks, as they aren't easily
found (you have to grep for wxLogTrace, then grep for the mask
variable to find the actual string to use). I didn't document the
functions, as they're pretty self-explanatory ("KICAD_FIND_ITEM: info
about the "Find Item" tool" is not that helpful!).

Cheers,

John
On Tue, Oct 9, 2018 at 2:53 PM John Beard  wrote:
>
> Hi,
>
> Here is an update patch that rebases over the commenting out of
> pcb_test_window, polygon_triangulation and polygon_generator and fixes
> a link error to do with base_screen.cpp.
>
> Cheers,
>
> John
> On Mon, Oct 8, 2018 at 5:27 PM John Beard  wrote:
> >
> > 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
From e70f1d6e86b4d0ebb5605d742a423e5b18f447af Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Wed, 10 Oct 2018 17:53:00 +0100
Subject: [PATCH] Docs: printing and trace

Add a quick outline of some of the ways you can dump debug during
debugging. Also include a list of known trace mask strings.
---
 Documentation/development/testing.md | 70 
 1 file changed, 70 insertions(+)

diff --git a/Documentation/development/testing.md b/Documentation/development/testing.md
index cf0d4c129..ae3bac342 100644
--- a/Documentation/development/testing.md
+++ b/Documentation/development/testing.md
@@ -147,6 +147,76 @@ where:
 The AFL TUI will then display the fuzzing progress, and you can use the hang- or
 crash-provoking inputs to debug code as needed.
 
+# Run-time debugging #
+
+KiCad can be debugged at run-time, either under a full debugger
+such as GDB, or using simple methods like logging debug to the
+console.
+
+## Printing debug ##
+
+If you are compiling KiCad yourself, you can simply add debugging statements to
+relevant places in the code, for example:
+
+wxLogDebug( "Value of variable: %d", my_int );
+
+This produces debug output that can only be seen when compiling
+in Debug mode.
+
+You can also use `std::cout` and `printf`.
+
+Ensure you do not leave this kind of debugging in place when
+submitting code.
+
+## Printing trace ##
+
+Some parts of the code have "trace" that can be enabled selectively according to
+a "mask", for example:
+
+wxLogTrace( "TRACEMASK", "My trace, value: %d", my_int );
+
+This will not be printed by default. To show it, set the `WXTRACE` environment
+variable when you run KiCad to include the masks you wish to enable:
+
+$ WXTRACE="TRACEKEY,OTHERKEY" kicad
+
+When printed, the debug will be prefixed with a timestamp and the trace mask:
+
+11:22:33: Trace: (KICAD_FIND_ITEM)   item Symbol GNDPWR, #PWR020
+
+Some available masks:
+
+* Core KiCad functions:
+* `KICAD_KEY_EVENTS`
+* `KicadScrollSettings`
+* `KICAD_FIND_ITEM`
+* 

Re: [Kicad-developers] Net selector

[John Beard]

Hi Jeff,

It doesn't seem to accept spaces for me on GTK (bea75753d).

I don't think retaining the last filter is extremely useful, though
perhaps if you were going around changing a lot of things to the same
net? But that will be a better job for the Object Inspector in future
anyway.

Cheers,

John
On Thu, Oct 11, 2018 at 11:15 AM Jeff Young  wrote:
>
> I’ve been finding that saving the filter is unexpected, even when useful.  
> And unexpected is always bad, because it erodes one’s confidence in their 
> user model.  So I think I’ll just remove it.
>
> Anyone else (with current code) able to type a space into the filter?  The 
> commits Eeli mentions use the same technique as the Label Properties dialog 
> (although they don’t exclude ‘\’ as you may want to search on that).
>
> > On 10 Oct 2018, at 21:20, Eeli Kaikkonen  wrote:
> >
> > Was the purpose of a0b8755f478f7829ca5 and the one before that to let the 
> > filter field to ignore spacebar? If so, it doesn't seem to work. Editing 
> > the net label in eeshcema's Label Properties dialog apparently has some 
> > excluding code, maybe there's something useful?
> >
> > Keeping the filter text between combobox "sessions" isn't necessarily good, 
> > at least in some cases. If there's nothing to match the filter and it's 
> > then canceled by closing the box the user hardly wants to keep the same 
> > non-working filter text. Or if (s)he doesn't actually select a net matching 
> > the filter. On the other hand it may be wanted after the net has been found 
> > and selected. A good compromise could be to always set the text as selected 
> > (in the filter text field) when the box is opened. Then the first key press 
> > would delete the old text, but the old filtering result would still be 
> > available if there's no need to change it. This requires text selecting and 
> > cursor to work, but now they don't, as John told. Or maybe he didn't 
> > mention text selecting, but it doesn't work anyways.
> >
> > -Eeli Kaikkonen
> > ___
> > 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] Net selector

[John Beard]

Hi Jeff,

In general it looks very nice.

On GTK+ (Arch), freshly rebased and built today on the new GAL stuff.

* The net field is reachable by tab-traversal. For example, in the
trace properties, it can be reached with "Shift-Tab, Shift-Tab" from
the default focus when the dialog opens.
* It cannot be activated with any key, as far as I can tell:
** Any letter key does nothing
** Enter accepts the whole dialog
** Arrow keys move the focus away from the control

Once the dialog is activated:

* When the input field has focus, you can't tell, there's no cursor
* When you type, the first result is not highlighted, and of you press
enter, nothing is changed. If you press down arrow, it goes right to
the second entry, and you have to go back to the first entry with up
arrow.

Ctrl-Backspace works nicely.

I can provide videos of anything now it's built, but might be a bit
slow to respond for the next couple of days.

Cheers,

John

On Wed, Oct 10, 2018 at 10:47 AM Jeff Young  wrote:
>
> Hi John,
>
> If you’re on Windows or GTK, I’d appreciate it if you could try out the Net 
> Selector (in Track & Via Properties or Pad Properties) from the keyboard and 
> tell me how it goes.  It’s all good on OSX, but that’s the only machine I 
> have.
>
> Cheers,
> Jeff.
>
>
> > On 10 Oct 2018, at 10:16, John Beard  wrote:
> >
> > Hi,
> >
> > I do (try to) use most dialogs with the keyboard (limited sensation in
> > my fingers make mice and especially touchpads less useful to me).
> >
> > Correct handling of focus, tab-traversal and so on is also important
> > for accessibility reasons, as well as being indicative of a coherent
> > UI in general. It's pretty annoying to be able to fill in almost all
> > of a dialog, but have controls fail to work at random.
> >
> > Especially a dialog with multiple fields, you don't want to force
> > users to a "hover+key to invoke, type, move mouse, click, type, enter"
> > workflow, when you could have a "hover+key, type, tab, type, enter"
> > workflow - you forced a hand to the mouse AND back which should be
> > entirely avoidable.
> >
> > Cheers,
> >
> > John
> > On Tue, Oct 9, 2018 at 7:59 PM Eeli Kaikkonen  
> > wrote:
> >>
> >>
> >>
> >> ti 9. lokak. 2018 klo 17.05 Jeff Young (j...@rokeby.ie) kirjoitti:
> >>>
> >>> I think you had the latest; the GAL branch should have been up-to-date as 
> >>> well.
> >>>
> >>> I’ve found a likely cause of the single-character-filter issue and pushed 
> >>> a “fix”.
> >>
> >>
> >> It works with the latest master (808a7d94833f1a). The remaining issues are 
> >> focus and selection related. I think accepting the selected net from the 
> >> list is more important because when the user uses filtering (s)he already 
> >> uses the keyboard. Selecting and opening the combobox with keyboard is 
> >> probably rare, I don't know if anyone wants to use KiCad's dialogs (other 
> >> than text and numbers) with keyboard. After all ECAD must be used with a 
> >> pointer device anyways.
> >>
> >> Eeli Kaikkonen
> >> ___
> >> 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] Net selector

[John Beard]

Hi,

I do (try to) use most dialogs with the keyboard (limited sensation in
my fingers make mice and especially touchpads less useful to me).

Correct handling of focus, tab-traversal and so on is also important
for accessibility reasons, as well as being indicative of a coherent
UI in general. It's pretty annoying to be able to fill in almost all
of a dialog, but have controls fail to work at random.

Especially a dialog with multiple fields, you don't want to force
users to a "hover+key to invoke, type, move mouse, click, type, enter"
workflow, when you could have a "hover+key, type, tab, type, enter"
workflow - you forced a hand to the mouse AND back which should be
entirely avoidable.

Cheers,

John
On Tue, Oct 9, 2018 at 7:59 PM Eeli Kaikkonen  wrote:
>
>
>
> ti 9. lokak. 2018 klo 17.05 Jeff Young (j...@rokeby.ie) kirjoitti:
>>
>> I think you had the latest; the GAL branch should have been up-to-date as 
>> well.
>>
>> I’ve found a likely cause of the single-character-filter issue and pushed a 
>> “fix”.
>
>
> It works with the latest master (808a7d94833f1a). The remaining issues are 
> focus and selection related. I think accepting the selected net from the list 
> is more important because when the user uses filtering (s)he already uses the 
> keyboard. Selecting and opening the combobox with keyboard is probably rare, 
> I don't know if anyone wants to use KiCad's dialogs (other than text and 
> numbers) with keyboard. After all ECAD must be used with a pointer device 
> anyways.
>
> Eeli Kaikkonen
> ___
> 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

[John Beard]

Hi Wayne,

No problems, I get it!

It's not needed for the fuzzing stuff, it's actually a pre-cursor for
a patch set to do with the dialog_page_settings dialog, but that is
now probably on hold for a bit due to being unable to now include
"class_drawpanel.h" from any common lib cpp.

However, it's also needed to be able to use unit testing for many
libcommon classes (TITLE_BLOCK is not the only one that ends up
sucking in tons of dependencies), so if anyone has any ideas about
what else is needed to get this to build, I'd appreciate pointers!

Cheers,

John
On Tue, Oct 9, 2018 at 3:04 PM Wayne Stambaugh  wrote:
>
> Hey John,
>
> I would like to help you out with this but I'm slammed at work and I'm
> not going to be able to help out.  Is this a patch a prerequisite for
> your fuzzing patch?
>
> Cheers,
>
> Wayne
>
> On 10/8/2018 1:11 PM, John Beard wrote:
> > 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:
> >

Re: [Kicad-developers] [PATCH] Fuzzable PCB parsing test harness

[John Beard]

Hi,

Here is an update patch that rebases over the commenting out of
pcb_test_window, polygon_triangulation and polygon_generator and fixes
a link error to do with base_screen.cpp.

Cheers,

John
On Mon, Oct 8, 2018 at 5:27 PM John Beard  wrote:
>
> 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
From 3ff4ee626860c81e48896a1b15ecc967d74e5e39 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 |  66 
 qa/pcb_parse_input/main.cpp   | 158 ++
 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, 386 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/cor

Re: [Kicad-developers] [PATCH]/Question TITLE_BLOCK tests

[John Beard]

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,

Re: [Kicad-developers] [PATCH] Fuzzable PCB parsing test harness

[John Beard]

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

[John Beard]

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.htm

Re: [Kicad-developers] [PATCH]/Question TITLE_BLOCK tests

[John Beard]

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
From d89cd6a36b9e595378123a4dd0177f7049b11201 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Fri, 5 Oct 2018 17:17:54 +0100
Subject: [PATCH] QA: Add TITLE_BLOCK tests

Add some unit tests on TITLE_BLOCK

This commit also requires some mocks so the libcommon stuff
can work:

* Needs a Kiface() function to be linkable
* Needs some stuff from common to be build specially
* Needs to define itself as one of the unit-having programs
  to appease the units defines.
---
 include/title_block.h  |  1 +
 qa/common/CMakeLists.txt   | 14 ++
 qa/common/common_mocks.cpp | 29 +++
 qa/common/test_title_block.cpp | 89 ++
 4 files changed, 133 insertions(+)
 create mode 100644 qa/common/test_title_block.cpp

diff --git a/include/title_block.h b/include/title_block.h
index 4d651b64d..62192574d 100644
--- a/include/title_block.h
+++ b/include/title_block.h
@@ -25,6 +25,7 @@
 #define TITLE_BLOCK_H
 
 #include 
+#include 
 #include 
 
 class OUTPUTFORMATTER;
diff --git a/qa/common/CMakeLists.txt b/qa/common/CMakeLists.txt
index e6c163296..f0b175295 100644
--- a/qa/common/CMakeLists.txt
+++ b/qa/common/CMakeLists.txt
@@ -32,7 +32,15 @@ add_executable( qa_common
 # The main test entry points
 test_module.cpp
 
+# stuff from common due to...units?
+../../common/eda_text.cpp
+
+# stuff from common which is needed...why?
+../../common/colors.cpp
+../../common/observable.cpp
+
 test_hotkey_store.cpp
+test_title_block.cpp
 test_utf8.cpp
 
 geometry/test_fillet.cpp
@@ -43,6 +51,7 @@ include_directories(
 ${CMAKE_SOURCE_DIR}/include
 ${CMAKE_SOURCE_DIR}/polygon
 ${Boost_INCLUDE_DIR}
+${INC_AFTER}
 )
 
 target_link_libraries( qa_common
@@ -53,6 +62,11 @@ target_link_libraries( qa_common
 ${wxWidgets_LIBRARIES}
 )
 
+# we need to pretend to be something to appease the units code
+target_compile_definitions( qa_common
+PRIVATE GERBVIEW
+)
+
 add_test( NAME common
 COMMAND qa_common
 )
\ No newline at end of file
diff --git a/qa/common/common_mocks.cpp b/qa/common/common_mocks.cpp
index 9b54ee6ec..1ac749693 100644
--- a/qa/common/common_mocks.cpp
+++ b/qa/common/common_mocks.cpp
@@ -27,6 +27,7 @@
  */
 
 #include 
+#include 
 
 
 struct PGM_TEST_FRAME : public PGM_BASE
@@ -39,4 +40,32 @@ PGM_BASE& Pgm()
 {
 static PGM_TEST_FRAME program;
 return program;
+}
+
+static struct IFACE : public KIFACE_I
+{
+bool OnKifaceStart( PGM_BASE* aP

[Kicad-developers] [PATCH]/Question TITLE_BLOCK tests

[John Beard]

Hi,

Here's a patch that adds some really basic tests of TITLE_BLOCK
(hopefully leading onto some more interesting changes to do with
avoiding the triple-compilation of the page settings dialog).

However, it did need some finagling to get it working, and I'd like to
ask about why some of it might be.

I can see when it has to specifically compile eda_text.cpp (units,
right?). However, why do I need to compile colours.cpp and
observable.cpp? Why don't they come with the libcommon linkage?

Also it adds a mock KIFACE_I, which seems to be needed to appease
linkage of things that need Kiface().

${INC_AFTER} is used for config.h, is that right?

Cheers,

John
From c6433cddefe70ae0250a3fc84b085e168585c8f0 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Fri, 5 Oct 2018 17:17:54 +0100
Subject: [PATCH 1/4] QA: Add TITLE_BLOCK tests

Add some unit tests on TITLE_BLOCK

This commit also requires some mocks so the libcommon stuff
can work:

* Needs a Kiface() function to be linkable
* Needs some stuff from common to be build specially
* Needs to define itself as one of the unit-having programs
  to appease the units defines.
---
 qa/common/CMakeLists.txt   | 14 ++
 qa/common/common_mocks.cpp | 29 +++
 qa/common/test_title_block.cpp | 89 ++
 3 files changed, 132 insertions(+)
 create mode 100644 qa/common/test_title_block.cpp

diff --git a/qa/common/CMakeLists.txt b/qa/common/CMakeLists.txt
index e6c163296..f0b175295 100644
--- a/qa/common/CMakeLists.txt
+++ b/qa/common/CMakeLists.txt
@@ -32,7 +32,15 @@ add_executable( qa_common
 # The main test entry points
 test_module.cpp
 
+# stuff from common due to...units?
+../../common/eda_text.cpp
+
+# stuff from common which is needed...why?
+../../common/colors.cpp
+../../common/observable.cpp
+
 test_hotkey_store.cpp
+test_title_block.cpp
 test_utf8.cpp
 
 geometry/test_fillet.cpp
@@ -43,6 +51,7 @@ include_directories(
 ${CMAKE_SOURCE_DIR}/include
 ${CMAKE_SOURCE_DIR}/polygon
 ${Boost_INCLUDE_DIR}
+${INC_AFTER}
 )
 
 target_link_libraries( qa_common
@@ -53,6 +62,11 @@ target_link_libraries( qa_common
 ${wxWidgets_LIBRARIES}
 )
 
+# we need to pretend to be something to appease the units code
+target_compile_definitions( qa_common
+PRIVATE GERBVIEW
+)
+
 add_test( NAME common
 COMMAND qa_common
 )
\ No newline at end of file
diff --git a/qa/common/common_mocks.cpp b/qa/common/common_mocks.cpp
index 9b54ee6ec..1ac749693 100644
--- a/qa/common/common_mocks.cpp
+++ b/qa/common/common_mocks.cpp
@@ -27,6 +27,7 @@
  */
 
 #include 
+#include 
 
 
 struct PGM_TEST_FRAME : public PGM_BASE
@@ -39,4 +40,32 @@ PGM_BASE& Pgm()
 {
 static PGM_TEST_FRAME program;
 return program;
+}
+
+static struct IFACE : public KIFACE_I
+{
+bool OnKifaceStart( PGM_BASE* aProgram, int aCtlBits ) override
+{
+return start_common( aCtlBits );
+}
+
+wxWindow* CreateWindow( wxWindow* aParent, int aClassId, KIWAY* aKiway, int aCtlBits = 0 ) override
+{
+return nullptr;
+}
+
+void* IfaceOrAddress( int aDataId ) override
+{
+return nullptr;
+}
+
+IFACE( const char* aDSOname, KIWAY::FACE_T aType ) :
+KIFACE_I( aDSOname, aType )
+{}
+
+} kiface( "common_test", KIWAY::KIWAY_FACE_COUNT );
+
+KIFACE_I& Kiface()
+{
+return kiface;
 }
\ No newline at end of file
diff --git a/qa/common/test_title_block.cpp b/qa/common/test_title_block.cpp
new file mode 100644
index 0..112194524
--- /dev/null
+++ b/qa/common/test_title_block.cpp
@@ -0,0 +1,89 @@
+/*
+ * This program source code file is part of KiCad, a free EDA CAD application.
+ *
+ * Copyright (C) 2018 KiCad Developers, see CHANGELOG.TXT for contributors.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, you may find one here:
+ * http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
+ * or you may search the http://www.gnu.org website for the version 2 license,
+ * or you may write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA
+ */
+
+#include 
+#include 
+
+#include 
+
+
+struct TitleBlockFixture
+{
+TitleBlockFixture()
+{
+m_tb.SetTitle( "title" );
+m_tb.SetDate( "date" );
+m_tb.SetCompany( "company" );
+
+// leave revis

[Kicad-developers] [PATCH] Expand testing documentation

[John Beard]

Hi,

Simple patch to give some more/updated details on how to use the unit tests.

Cheers,

John
From 67dcd2b9f7d7716a31b21e5e958f664ada1eaadc Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Thu, 4 Oct 2018 15:37:24 +0100
Subject: [PATCH 1/3] Update testing documentation

---
 Documentation/development/testing.md | 69 +++-
 1 file changed, 68 insertions(+), 1 deletion(-)

diff --git a/Documentation/development/testing.md b/Documentation/development/testing.md
index 8a80fd3f4..4726ca536 100644
--- a/Documentation/development/testing.md
+++ b/Documentation/development/testing.md
@@ -5,6 +5,69 @@
 KiCad has a limited number of unit tests, which can be used to
 check that certain functionality works.
 
+Tests are registered using [CTest][], part of CMake. CTest gathers all the
+disparate test programs and runs them. Most C++ unit
+tests are written using the [Boost Unit Test framework][], but this is not
+required to add a test to the testing suite.
+
+The test CMake targets generally start with `qa_`, the names of the tests
+within CTest are the same but without the `qa_` prefix.
+
+## Running tests ##
+
+You can run all tests after building with `make test` or `ctest`. The latter
+option allows many CTest options which can be useful, especially in automated
+or CI environments.
+
+### Running specific tests ##
+
+To run a specific test executable, you can just run with `ctest` or run
+the executable directly. Running directly is often the simplest way when
+working on a specific test and you want access to the test executable's
+arguments. For example:
+
+# run the libcommon tests
+cd /path/to/kicad/build
+qa/common/qa_common [parameters]
+
+For Boost unit tests, you can see the options for the test with ` --help`.
+Common useful patterns:
+
+* ` -t "Utf8/*"` runs all tests in the `Utf8` test suite.
+* ` -t "Utf8/UniIterNull"` runs only a single test in a specific suite.
+* ` -l all` adds more verbose debugging to the output.
+* ` --list_content` lists the test suites and test cases within the
+test program. You can use these for arguments to `-l`.
+
+You can rebuild just a specific test with CMake to avoid rebuilding
+everything when working on a small area, e.g. `make qa_common`.
+
+### Writing Boost tests ###
+
+Boost unit tests are straightforward to write. Individual test cases can be
+registered with:
+
+BOOST_AUTO_TEST_CASE( SomeTest )
+{
+BOOST_CHECK_EQUAL( 1, 1 );
+}
+
+There is a range of functions like `BOOST_CHECK`, which are documented
+[here][boost-test-functions]. Using the most specific function is preferred, as that
+allows Boost to provide more detailed failures: `BOOST_CHECK( foo == bar )` only
+reports a mismatch, `BOOST_CHECK_EQUAL( foo, bar )` will show the values of
+each.
+
+To output debug messages, you can use `BOOST_TEST_MESSAGE` in the unit tests,
+which will be visible only if you set the `-l` parameter to `message` or higher.
+This colours the text differently to make it stand out from other testing
+messages and standard output.
+
+You can also use `std::cout`, `printf`, `wxLogDebug` and so on for debug
+messages inside tested functions (i.e. where you don't have access to the Boost
+unit test headers). These will always be printed, so take care
+to remove them before committing, or they'll show up when KiCad runs normally!
+
 ## Python modules ##
 
 The Pcbnew Python modules have some test programs in the `qa` directory.
@@ -12,7 +75,7 @@ You must have the `KICAD_SCRIPTING_MODULES` option on in CMake to
 build the modules and enable this target.
 
 The main test script is `qa/test.py` and the test units are in
-`qa/testcases`. All the test units can by run using `make qa`, which
+`qa/testcases`. All the test units can by run using `ctest python`, which
 runs `test.py`.
 
 You can also run an individual case manually, by making sure the
@@ -39,3 +102,7 @@ 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.
+
+[CTest]: https://cmake.org/cmake/help/latest/module/CTest.html
+[Boost Unit Test framework]: https://www.boost.org/doc/libs/1_68_0/libs/test/doc/html/index.html
+[boost-test-functions]: https://www.boost.org/doc/libs/1_68_0/libs/test/doc/html/boost_test/utf_reference/testing_tool_ref.html
\ No newline at end of file
-- 
2.19.0

___
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] Enable cursor and pan keys in Gerbview

[John Beard]

Hi,

This patch puts the cursor and pan key actions and logic in the common
tool framework, rather than duplicating it between cvpcb and pcbnew as
current.

This then allows Gerbview (and any other panel with COMMON_TOOLS
registered) to benefit from these keys for free.

Cheers,

John
From ef48f45b333f383b5f878d1cf103a98c325824a9 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Wed, 3 Oct 2018 17:26:33 +0100
Subject: [PATCH] Put cursor and pan control in libcommon/tool, enable in
 Gerbview

Put the cursor and pan control TOOL_ACTIONs in ACTION,
and refer to them in that way.

The handlers are currently identical in Pcbnew and Cvpcb,
and Gerbview (and all canvases) can benefit from them as well
if they are in libcommon. Also saves duplicated code.

Fixes: lp:1795855
* https://bugs.launchpad.net/kicad/+bug/1795855
---
 common/tool/actions.cpp   |  60 
 common/tool/common_tools.cpp  | 122 +++
 cvpcb/tools/cvpcb_actions.h   |  19 
 cvpcb/tools/cvpcb_control.cpp | 151 -
 cvpcb/tools/cvpcb_control.h   |   3 -
 gerbview/tools/gerbview_actions.h |  18 +---
 include/tool/actions.h|  20 
 include/tool/common_tools.h   |   3 +
 pcbnew/tools/pcb_actions.h|  20 
 pcbnew/tools/pcbnew_control.cpp   | 156 --
 pcbnew/tools/pcbnew_control.h |   3 -
 11 files changed, 206 insertions(+), 369 deletions(-)

diff --git a/common/tool/actions.cpp b/common/tool/actions.cpp
index 06cb7b9e0..35ff69b65 100644
--- a/common/tool/actions.cpp
+++ b/common/tool/actions.cpp
@@ -47,6 +47,66 @@ TOOL_ACTION ACTIONS::centerContents( "common.Control.centerContents",
 AS_GLOBAL, 0,
 "", "" );
 
+// Cursor control
+TOOL_ACTION ACTIONS::cursorUp( "common.Control.cursorUp",
+AS_GLOBAL, WXK_UP,
+"", "", NULL, AF_NONE, (void*) CURSOR_UP );
+
+TOOL_ACTION ACTIONS::cursorDown( "common.Control.cursorDown",
+AS_GLOBAL, WXK_DOWN,
+"", "" , NULL, AF_NONE, (void*) CURSOR_DOWN );
+
+TOOL_ACTION ACTIONS::cursorLeft( "common.Control.cursorLeft",
+AS_GLOBAL, WXK_LEFT,
+"", "" , NULL, AF_NONE, (void*) CURSOR_LEFT );
+
+TOOL_ACTION ACTIONS::cursorRight( "common.Control.cursorRight",
+AS_GLOBAL, WXK_RIGHT,
+"", "" , NULL, AF_NONE, (void*) CURSOR_RIGHT );
+
+
+TOOL_ACTION ACTIONS::cursorUpFast( "common.Control.cursorUpFast",
+AS_GLOBAL, MD_CTRL + WXK_UP,
+"", "", NULL, AF_NONE, (void*) ( CURSOR_UP | CURSOR_FAST_MOVE ) );
+
+TOOL_ACTION ACTIONS::cursorDownFast( "common.Control.cursorDownFast",
+AS_GLOBAL, MD_CTRL + WXK_DOWN,
+"", "" , NULL, AF_NONE, (void*) ( CURSOR_DOWN | CURSOR_FAST_MOVE ) );
+
+TOOL_ACTION ACTIONS::cursorLeftFast( "common.Control.cursorLeftFast",
+AS_GLOBAL, MD_CTRL + WXK_LEFT,
+"", "" , NULL, AF_NONE, (void*) ( CURSOR_LEFT | CURSOR_FAST_MOVE ) );
+
+TOOL_ACTION ACTIONS::cursorRightFast( "common.Control.cursorRightFast",
+AS_GLOBAL, MD_CTRL + WXK_RIGHT,
+"", "" , NULL, AF_NONE, (void*) ( CURSOR_RIGHT | CURSOR_FAST_MOVE ) );
+
+
+TOOL_ACTION ACTIONS::cursorClick( "common.Control.cursorClick",
+AS_GLOBAL, TOOL_ACTION::LegacyHotKey( HK_LEFT_CLICK ),
+"", "", NULL, AF_NONE, (void*) CURSOR_CLICK );
+
+TOOL_ACTION ACTIONS::cursorDblClick( "common.Control.cursorDblClick",
+AS_GLOBAL, TOOL_ACTION::LegacyHotKey( HK_LEFT_DCLICK ),
+"", "", NULL, AF_NONE, (void*) CURSOR_DBL_CLICK );
+
+
+TOOL_ACTION ACTIONS::panUp( "common.Control.panUp",
+AS_GLOBAL, MD_SHIFT + WXK_UP,
+"", "", NULL, AF_NONE, (void*) CURSOR_UP );
+
+TOOL_ACTION ACTIONS::panDown( "common.Control.panDown",
+AS_GLOBAL, MD_SHIFT + WXK_DOWN,
+"", "" , NULL, AF_NONE, (void*) CURSOR_DOWN );
+
+TOOL_ACTION ACTIONS::panLeft( "common.Control.panLeft",
+AS_GLOBAL, MD_SHIFT + WXK_LEFT,
+"", "" , NULL, AF_NONE, (void*) CURSOR_LEFT );
+
+TOOL_ACTION ACTIONS::panRight( "common.Control.panRight",
+AS_GLOBAL, MD_SHIFT + WXK_RIGHT,
+"", "" , NULL, AF_NONE, (void*) CURSOR_RIGHT );
+
 // Grid control
 TOOL_ACTION ACTIONS::gridFast1( "common.Control.gridFast1",
 AS_GLOBAL, TOOL_ACTION::LegacyHotKey( HK_SWITCH_GRID_TO_FASTGRID1 ),
diff --git a/common/tool/common_tools.cpp b/common/tool/common_tools.cpp
index 727fcd336..9995c12a4 100644
--- a/common/tool/common_tools.cpp
+++ b/common/tool/common_tools.cpp
@@ -23,6 +23,7 @@
  */
 
 #include 
+#include 
 #include

Re: [Kicad-developers] [PATCH] Hotkey list dialog

[John Beard]

Hi Wayne,

In wxSizer, there is an option to use the "default border", which is
preferred to hardcoding a pixel value. This is preferred
apparently[1]. The WX method to do this,
wxSizerFlags::GetDefaultBorder(), is here.[2] (GNOME-HIG compliant 6px
on GTK, 5px on OSX, scaled otherwise).

If we stick with a hardcoded value (as all the wxFB stuff cannot use
the DPI-aware defaults, it just specifies '5' on all platforms and
displays), setting the wxSizerFlags is not very concise:

 wxSizerFlags flags = KIUI::GetStdSizerFlags(); // this can't set
a border as we don't know the directions yet

 sizer->Add( widget1, flags.Border( wxLEFT | wxTOP, 5 ) ); //
still need to feed the '5' in
 sizer->Add( widget2, flags.Border( wxRIGHT | wxTOP, 5 ) ); //
can't reuse the '5', have to call Border() again with new directions

Because you can't "pre-set" the "5", a putative
KIUI::GetStdSizerFlags() can't actually help us to avoid specifying
"5" for every subsequent use, and we'd still need a way to get the
"5". What would you like the API for this to look like?

Regardless of this, the first 3 commits stand alone, and this is not
required for them to be perfectly functional.

Cheers,

John

[1] 
https://docs.wxwidgets.org/3.1/classwx_sizer_flags.html#a2dc000b863b8580ae3f183c0e11c9944
[2] https://github.com/wxWidgets/wxWidgets/blob/master/include/wx/sizer.h#L107
On Wed, Oct 3, 2018 at 6:53 PM John Beard  wrote:
>
> Hi Wayne,
>
> I know the policy is not to convert wxFB dialogs, but in this case, I
> don't see how that dialog could be written neatly in wxFB without
> having the derived class tear half of the components down again if
> m_read_only is true. The alternative is to duplicate the entire
> dialog, which is a common tactic with making similar dialogs wxFB, but
> it's a shame to multiply code when you could divide it!
>
> Especially if you use a helper like the button row widget, you'd have
> two placeholders, so the wxFB project would be essentially a blank
> dialog with a single filter box at the top, and you'd have to have two
> workarounds like InstallOnPanel to place the widgets you actually
> wanted onto them.
>
> Re the common UI thing - that makes sense, I had forgotten about
> wxSizerFlags, even though I have done something similar in the past!
> Patch coming up.
>
> Cheers,
>
> John
>
> On Wed, Oct 3, 2018 at 6:40 PM Wayne Stambaugh  wrote:
> >
> > John,
> >
> > Your patch set looks good and works as advertised.  I have a few
> > nit-pick comments.
> >
> > I personally prefer making the hotkey list panel hard coded as you did
> > rather than using wxFB but not all developers share my preference in
> > this regard.  Since this makes the hotkey list panel more reusable, I'm
> > hoping no one will protest too loudly.
> >
> > Your common UI code (patch 4) probably should include support for a
> > wxSizerFlag object for the default border.  You might want to consider
> > using term border instead of margin to prevent confusion as that is how
> > it is defined in the wxwidgets documentation.  I'm fine either way.
> >
> > I will merge your if there are not objections.  You can just create
> > another patch.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 10/3/2018 11:20 AM, John Beard wrote:
> > > Hi,
> > >
> > > Here is a patch sequence for using the hotkey editor widget in a
> > > read-only mode to provide a filterable (and slightly prettier) hotkey
> > > list. This is a 5.1 milestone.
> > >
> > > Major details other than the main aim of the list widget:
> > >
> > > * There are some "common UI" elements introduced here that should be
> > > generally re-usable:
> > > ** BUTTON_ROW_PANEL provides an easy way to construct a row of buttons
> > > spaced out nicely
> > > ** A place to put "generic" UI stuff like the 5px constant very often
> > > used for margins
> > > * The editor/list panel is no longer a wxFB project, as I couldn't get
> > > it to play nice with optional elements: undoing half the construction
> > > in the derived class, unbinding events and changing various stuff in
> > > response to editabilty was not very tidy. It's substantially less code
> > > now, partly due to the re-usable widgets above.
> > >
> > > Also adds tooltips for the HK editor buttons via the new BUTTON_ROW_PANEL 
> > > class.
> > >
> > > Cheers,
> > >
> > > John
> > >
> > >
> > > ___
> > > Mailing list: https://launchpad.net/~kic

Re: [Kicad-developers] [PATCH] Hotkey list dialog

[John Beard]

Hi Wayne,

I know the policy is not to convert wxFB dialogs, but in this case, I
don't see how that dialog could be written neatly in wxFB without
having the derived class tear half of the components down again if
m_read_only is true. The alternative is to duplicate the entire
dialog, which is a common tactic with making similar dialogs wxFB, but
it's a shame to multiply code when you could divide it!

Especially if you use a helper like the button row widget, you'd have
two placeholders, so the wxFB project would be essentially a blank
dialog with a single filter box at the top, and you'd have to have two
workarounds like InstallOnPanel to place the widgets you actually
wanted onto them.

Re the common UI thing - that makes sense, I had forgotten about
wxSizerFlags, even though I have done something similar in the past!
Patch coming up.

Cheers,

John

On Wed, Oct 3, 2018 at 6:40 PM Wayne Stambaugh  wrote:
>
> John,
>
> Your patch set looks good and works as advertised.  I have a few
> nit-pick comments.
>
> I personally prefer making the hotkey list panel hard coded as you did
> rather than using wxFB but not all developers share my preference in
> this regard.  Since this makes the hotkey list panel more reusable, I'm
> hoping no one will protest too loudly.
>
> Your common UI code (patch 4) probably should include support for a
> wxSizerFlag object for the default border.  You might want to consider
> using term border instead of margin to prevent confusion as that is how
> it is defined in the wxwidgets documentation.  I'm fine either way.
>
> I will merge your if there are not objections.  You can just create
> another patch.
>
> Cheers,
>
> Wayne
>
> On 10/3/2018 11:20 AM, John Beard wrote:
> > Hi,
> >
> > Here is a patch sequence for using the hotkey editor widget in a
> > read-only mode to provide a filterable (and slightly prettier) hotkey
> > list. This is a 5.1 milestone.
> >
> > Major details other than the main aim of the list widget:
> >
> > * There are some "common UI" elements introduced here that should be
> > generally re-usable:
> > ** BUTTON_ROW_PANEL provides an easy way to construct a row of buttons
> > spaced out nicely
> > ** A place to put "generic" UI stuff like the 5px constant very often
> > used for margins
> > * The editor/list panel is no longer a wxFB project, as I couldn't get
> > it to play nice with optional elements: undoing half the construction
> > in the derived class, unbinding events and changing various stuff in
> > response to editabilty was not very tidy. It's substantially less code
> > now, partly due to the re-usable widgets above.
> >
> > Also adds tooltips for the HK editor buttons via the new BUTTON_ROW_PANEL 
> > class.
> >
> > 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
> >
>
> ___
> 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] Hotkey list dialog

[John Beard]

Hi,

Here's a screenshot of the list widget this creates.

I also forgot to mention that this also allows to remove the
"InstallOnPanel" workaround to installing the custom hotkey widget on
the wxFB panel's placeholder panel.

Cheers,

John
On Wed, Oct 3, 2018 at 4:20 PM John Beard  wrote:
>
> Hi,
>
> Here is a patch sequence for using the hotkey editor widget in a
> read-only mode to provide a filterable (and slightly prettier) hotkey
> list. This is a 5.1 milestone.
>
> Major details other than the main aim of the list widget:
>
> * There are some "common UI" elements introduced here that should be
> generally re-usable:
> ** BUTTON_ROW_PANEL provides an easy way to construct a row of buttons
> spaced out nicely
> ** A place to put "generic" UI stuff like the 5px constant very often
> used for margins
> * The editor/list panel is no longer a wxFB project, as I couldn't get
> it to play nice with optional elements: undoing half the construction
> in the derived class, unbinding events and changing various stuff in
> response to editabilty was not very tidy. It's substantially less code
> now, partly due to the re-usable widgets above.
>
> Also adds tooltips for the HK editor buttons via the new BUTTON_ROW_PANEL 
> class.
>
> 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] Hotkey list dialog

[John Beard]

Hi,

Here is a patch sequence for using the hotkey editor widget in a
read-only mode to provide a filterable (and slightly prettier) hotkey
list. This is a 5.1 milestone.

Major details other than the main aim of the list widget:

* There are some "common UI" elements introduced here that should be
generally re-usable:
** BUTTON_ROW_PANEL provides an easy way to construct a row of buttons
spaced out nicely
** A place to put "generic" UI stuff like the 5px constant very often
used for margins
* The editor/list panel is no longer a wxFB project, as I couldn't get
it to play nice with optional elements: undoing half the construction
in the derived class, unbinding events and changing various stuff in
response to editabilty was not very tidy. It's substantially less code
now, partly due to the re-usable widgets above.

Also adds tooltips for the HK editor buttons via the new BUTTON_ROW_PANEL class.

Cheers,

John
From 2e27dd083faef63b043e7f791014ec7ee089a45b Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Wed, 3 Oct 2018 11:02:43 +0100
Subject: [PATCH 4/5] Centralise some UI constants, use in hotkey lists

There are lot of places where constants are used in the KiCad UI
as "magic numbers". The most common one is "5", used in many
wxFormBuilder and manual UI constructions as the margin.

This commit provides a place for all UI to look up shared
constants and other functions, to help create a consistent UI using
functions that provide meaning and intent to these magic numbers.
---
 common/CMakeLists.txt   |  1 +
 common/dialogs/dialog_hotkey_list.cpp   |  7 +++--
 common/dialogs/panel_hotkeys_editor.cpp | 11 ---
 common/widgets/button_row_panel.cpp |  7 ++---
 common/widgets/ui_common.cpp| 27 
 include/widgets/ui_common.h | 41 +
 6 files changed, 83 insertions(+), 11 deletions(-)
 create mode 100644 common/widgets/ui_common.cpp
 create mode 100644 include/widgets/ui_common.h

diff --git a/common/CMakeLists.txt b/common/CMakeLists.txt
index 223225060..a2b9f2adf 100644
--- a/common/CMakeLists.txt
+++ b/common/CMakeLists.txt
@@ -196,6 +196,7 @@ set( COMMON_WIDGET_SRCS
 widgets/stepped_slider.cpp
 widgets/text_ctrl_eval.cpp
 widgets/two_column_tree_list.cpp
+widgets/ui_common.cpp
 widgets/unit_binder.cpp
 widgets/widget_hotkey_list.cpp
 widgets/wx_grid.cpp
diff --git a/common/dialogs/dialog_hotkey_list.cpp b/common/dialogs/dialog_hotkey_list.cpp
index e5a451cb9..340031172 100644
--- a/common/dialogs/dialog_hotkey_list.cpp
+++ b/common/dialogs/dialog_hotkey_list.cpp
@@ -24,6 +24,7 @@
 #include 
 
 #include 
+#include 
 
 #include 
 #include 
@@ -32,18 +33,20 @@
 DIALOG_LIST_HOTKEYS::DIALOG_LIST_HOTKEYS( EDA_BASE_FRAME* aParent, EDA_HOTKEY_CONFIG* aDescList ):
 DIALOG_SHIM( aParent, wxID_ANY, _( "Hotkey List" ) )
 {
+const auto margin = KIUI::GetStdMargin();
+
 auto main_sizer = new wxBoxSizer( wxVERTICAL );
 
 m_hk_list = new PANEL_HOTKEYS_EDITOR( aParent, this, true,
 aDescList, aDescList, {} );
 
-main_sizer->Add( m_hk_list, 1, wxTOP | wxLEFT | wxRIGHT | wxEXPAND, 5 );
+main_sizer->Add( m_hk_list, 1, wxTOP | wxLEFT | wxRIGHT | wxEXPAND, margin );
 
 auto sdb_sizer = new wxStdDialogButtonSizer;
 sdb_sizer->AddButton( new wxButton( this, wxID_OK ) );
 sdb_sizer->Realize();
 
-main_sizer->Add( sdb_sizer, 0, wxEXPAND | wxALL, 5 );
+main_sizer->Add( sdb_sizer, 0, wxEXPAND | wxALL, margin );
 
 SetSizer( main_sizer );
 
diff --git a/common/dialogs/panel_hotkeys_editor.cpp b/common/dialogs/panel_hotkeys_editor.cpp
index 4fd103d17..544d03153 100644
--- a/common/dialogs/panel_hotkeys_editor.cpp
+++ b/common/dialogs/panel_hotkeys_editor.cpp
@@ -30,12 +30,11 @@
 #include 
 
 #include 
+#include 
 
 
 static const wxSize default_dialog_size { 500, 350 };
 static const wxSize min_dialog_size { -1, 350 };
-static const int widget_margins = 5;
-static const int side_margins = 10;
 
 /**
  * Helper function to add a filter box to a panel, with some
@@ -70,18 +69,20 @@ PANEL_HOTKEYS_EDITOR::PANEL_HOTKEYS_EDITOR( EDA_BASE_FRAME* aFrame, wxWindow* aW
 m_nickname( aNickname ),
 m_hotkeyStore( aShowHotkeys )
 {
+const auto margin = KIUI::GetStdMargin();
 auto mainSizer = new wxBoxSizer( wxVERTICAL );
 
 // Sub-sizer for setting a wider side margin
 // TODO: Can this be set by the parent widget- doesn't seem to be
 // this panel's responsibility?
+const int side_margins = 10; // seems to be hardcoded in wxFB
 auto bMargins = new wxBoxSizer( wxVERTICAL );
 
 auto filterSearch = CreateTextFilterBox( this, _( "Type filter text" ) );
-bMargins->Add( filterSearch, 0, wxBOTTOM | wxEXPAND | wxTOP, widget_margins );
+bMargins->Add( filterSearch, 0, wxBOTTOM | wxEXPAND | wxTOP, margin );
 
 m_hotkeyListCtrl = new WIDGET_HOTKEY_LIS

[Kicad-developers] Nicknames for hotkey configs - should be translated?

[John Beard]

Hi,

Quick question about the "nicknames" parameter for the hotkey config
dialog. At all the call sites for the ShowPreferences() dialog, the
parameter aHotkeysNickname is constructed with _(). This parameter is
used to provide a default name for the hotkey file on export. Does
this string actually need to be translated?

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

Re: [Kicad-developers] [PATCH] Add KICAD_TEMPLATE_DIR to Configure Paths... help

[John Beard]

Hi Wayne,

Here's the updated patch. The only changes are comments and var names.

I'll keep looking at wxGrid cell tooltips. If anyone knows if we
already can do that (or WX has an easy way that's doesn't need to deal
with mouse events manually, please let me know!)

Cheers,

John
On Tue, Oct 2, 2018 at 10:04 PM Wayne Stambaugh  wrote:
>
> Hey John,
>
> No problem.  I'll hold off until you send the revised patch.  I'm fine
> with the current patch the way that it is.  It was just the tool tip
> code that threw me off.  I thought maybe there was something missing.
>
> Cheers,
>
> Wayne
>
> On 10/02/2018 04:45 PM, John Beard wrote:
> > Hi Wayne,
> >
> > Sorry about that, I actually started with the intention of providing
> > tooltips for the wxGrids in the library manager and the paths
> > configuration dialog. However, I found adding a tooltip to a wxGrid
> > cells is not very easy, so I retreated to just updating the help text
> > and centralising logic. I evidently neglected to update the comments
> > adequately.
> >
> > I haven't given up on the tooltips, but it'll need more work to do it
> > nicely in wx. On yt bright side, hopefully if I can do it, it will be
> > helpful for decorating other wxGrids with per cell tooltips.
> >
> > I'll update the commentary on this patch.
> >
> > Cheers,
> >
> > John
> >
> > On 1 October 2018 18:58:17 BST, Wayne Stambaugh 
> > wrote:
> >
> > Hey John,
> >
> > I like this solution to the translation issue better than some of the
> > other solutions that have been proposed.  I did notice that you added a
> > function to provide the tooltip for defined env variable but you did not
> > hook up the tooltip logic in the dialog.  Are you planning to do that at
> > some point in the future?
> >
> > I'm going to merge this patch if there are no objections.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 10/1/2018 5:35 AM, John Beard wrote:
> >
> > Hi,
> >
> > Small patch that:
> >
> > * Adds KICAD_TEMPLATE_DIR and KICAD_USER_TEMPLATE_DIR to the help
> > dialog in Configure Paths...
> > * Documents KICAD_PTEMPLATES as deprecated.
> > * Moves some generic functions to do with env variables to a
> > separate
> > file. This means env var help text is no longer embedded in a
> > block of
> > HTML and also we could use it to provide tool-tips or similar to
> > other
> > dialogs.
> >
> > Cheers,
> >
> > John
> > 
> > 
> > Mailing list: https://launchpad.net/~kicad-developers
> > <https://launchpad.net/%7Ekicad-developers>
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > <https://launchpad.net/%7Ekicad-developers>
> > More help : https://help.launchpad.net/ListHelp
> >
> > --------
> > Mailing list: https://launchpad.net/~kicad-developers
> > <https://launchpad.net/%7Ekicad-developers>
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > <https://launchpad.net/%7Ekicad-developers>
> > More help   : https://help.launchpad.net/ListHelp
> >
From c89ece074d54c7e1e85e669bfb9f6b8d71cbfd95 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Fri, 28 Sep 2018 22:08:31 +0100
Subject: [PATCH 1/4] Centralise utilities for env variables.

This puts generic logic for KiCad environment vars in
one place.

Also updates the DIALOG_CONFIGURE_PATHS help to document
the new KICAD_USER_TEMPLATE_DIR and KICAD_TEMPLATE_DIR.
---
 common/CMakeLists.txt |   1 +
 common/dialogs/dialog_configure_paths.cpp |  62 +++--
 common/env_vars.cpp   | 105 ++
 include/dialog_configure_paths.h  |   5 --
 include/env_vars.h|  59 
 5 files changed, 179 insertions(+), 53 deletions(-)
 create mode 100644 common/env_vars.cpp
 create mode 100644 include/env_vars.h

diff --git a/common/CMakeLists.txt b/common/CMakeLists.txt
index eccf7302f..0f1722b6b 100644
--- a/common/CMakeLists.txt
+++ b/common/CMakeLists.txt
@@ -271,6 +271,7 @@ set( COMMON_SRCS
 eda_pattern_match.cpp
 eda_size_ctrl.cpp
 env_paths.cpp
+env_vars.cpp
 exceptions.

Re: [Kicad-developers] [PATCH] Add KICAD_TEMPLATE_DIR to Configure Paths... help

[John Beard]

Hi Wayne,

Sorry about that, I actually started with the intention of providing tooltips 
for the wxGrids in the library manager and the paths configuration dialog. 
However, I found adding a tooltip to a wxGrid cells is not very easy, so I 
retreated to just updating the help text and centralising logic. I evidently 
neglected to update the comments adequately. 

I haven't given up on the tooltips, but it'll need more work to do it nicely in 
wx. On yt bright side, hopefully if I can do it, it will be helpful for 
decorating other wxGrids with per cell tooltips.

I'll update the commentary on this patch.

Cheers,

John

On 1 October 2018 18:58:17 BST, Wayne Stambaugh  wrote:
>Hey John,
>
>I like this solution to the translation issue better than some of the
>other solutions that have been proposed.  I did notice that you added a
>function to provide the tooltip for defined env variable but you did
>not
>hook up the tooltip logic in the dialog.  Are you planning to do that
>at
>some point in the future?
>
>I'm going to merge this patch if there are no objections.
>
>Cheers,
>
>Wayne
>
>On 10/1/2018 5:35 AM, John Beard wrote:
>> Hi,
>> 
>> Small patch that:
>> 
>> * Adds KICAD_TEMPLATE_DIR and KICAD_USER_TEMPLATE_DIR to the help
>> dialog in Configure Paths...
>> * Documents KICAD_PTEMPLATES as deprecated.
>> * Moves some generic functions to do with env variables to a separate
>> file. This means env var help text is no longer embedded in a block
>of
>> HTML and also we could use it to provide tool-tips or similar to
>other
>> dialogs.
>> 
>> 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
>> 
>
>___
>Mailing list: https://launchpad.net/~kicad-developers
>Post to : kicad-developers@lists.launchpad.net
>Unsubscribe : https://launchpad.net/~kicad-developers
>More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [PATCH] Add KICAD_TEMPLATE_DIR to Configure Paths... help

[John Beard]

Hi,

Small patch that:

* Adds KICAD_TEMPLATE_DIR and KICAD_USER_TEMPLATE_DIR to the help
dialog in Configure Paths...
* Documents KICAD_PTEMPLATES as deprecated.
* Moves some generic functions to do with env variables to a separate
file. This means env var help text is no longer embedded in a block of
HTML and also we could use it to provide tool-tips or similar to other
dialogs.

Cheers,

John
From 7ff43f092fb36b788f570ac8614978d16d424eec Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Fri, 28 Sep 2018 22:08:31 +0100
Subject: [PATCH] Centralise utilities for env variables.

This puts generic logic for KiCad environment vars in
one place.

Also updates the DIALOG_CONFIGURE_PATHS help to document
the new KICAD_USER_TEMPLATE_DIR and KICAD_TEMPLATE_DIR.
---
 common/CMakeLists.txt |   1 +
 common/dialogs/dialog_configure_paths.cpp |  62 +++--
 common/env_vars.cpp   | 105 ++
 include/dialog_configure_paths.h  |   5 --
 include/env_vars.h|  56 
 5 files changed, 176 insertions(+), 53 deletions(-)
 create mode 100644 common/env_vars.cpp
 create mode 100644 include/env_vars.h

diff --git a/common/CMakeLists.txt b/common/CMakeLists.txt
index eccf7302f..0f1722b6b 100644
--- a/common/CMakeLists.txt
+++ b/common/CMakeLists.txt
@@ -271,6 +271,7 @@ set( COMMON_SRCS
 eda_pattern_match.cpp
 eda_size_ctrl.cpp
 env_paths.cpp
+env_vars.cpp
 exceptions.cpp
 executable_names.cpp
 filename_resolver.cpp
diff --git a/common/dialogs/dialog_configure_paths.cpp b/common/dialogs/dialog_configure_paths.cpp
index 5266a47a0..eb641a2f7 100644
--- a/common/dialogs/dialog_configure_paths.cpp
+++ b/common/dialogs/dialog_configure_paths.cpp
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -549,60 +550,25 @@ void DIALOG_CONFIGURE_PATHS::OnHelp( wxCommandEvent& event )
   "level.  Environment variables defined at the system or user level "
   "take precedence over the ones defined in this table.  This means the "
   "values in this table are ignored." );
-msg << wxT( "" );
+msg << "";
 msg << _( "To ensure environment variable names are valid on all platforms, the name field "
   "will only accept upper case letters, digits, and the underscore characters." );
-msg << wxT( "" );
-msg << _( "KICAD_SYMBOL_DIR is the base path of the locally installed symbol libraries." );
-msg << wxT( "" );
-msg << _( "KIGITHUB is used by KiCad to define the URL of the repository "
-  "of the official KiCad footprint libraries." );
-msg << wxT( "" );
-msg << _( "KISYS3DMOD is the base path of system footprint 3D "
-  "shapes (.3Dshapes folders)." );
-msg << wxT( "" );
-msg << _( "KISYSMOD is the base path of locally installed system "
-  "footprint libraries (.pretty folders)." );
-msg << wxT( "" );
-msg << _( "KIPRJMOD is internally defined by KiCad (cannot be edited) and is set "
-  "to the absolute path of the currently loaded project file.  This environment "
-  "variable can be used to define files and paths relative to the currently loaded "
-  "project.  For instance, ${KIPRJMOD}/libs/footprints.pretty can be defined as a "
-  "folder containing a project specific footprint library named footprints.pretty." );
-msg << wxT( "" );
-msg << _( "KICAD_PTEMPLATES is optional and can be defined if you want to "
-  "create your own project templates folder." );
+msg << "";
 
-HTML_MESSAGE_BOX dlg( GetParent(), _( "Environment Variable Help" ) );
-dlg.SetDialogSizeInDU( 400, 250 );
+for( const auto& var: GetPredefinedEnvVars() )
+{
+msg << "" << var << "";
 
-dlg.AddHTML_Text( msg );
-dlg.ShowModal();
-}
+const auto desc = LookUpEnvVarHelp( var );
 
+if( desc.size() > 0 )
+msg << ": " << desc;
 
-bool DIALOG_CONFIGURE_PATHS::IsEnvVarImmutable( const wxString aEnvVar )
-{
-/*
- * TODO - Instead of defining these values here,
- * extract them from elsewhere in the program
- * (where they are originally defined)
- */
-
-static const wxString immutable[] = {
-"KIGITHUB",
-"KISYS3DMOD",
-"KISYSMOD",
-"KIPRJMOD",
-"KICAD_PTEMPL

[Kicad-developers] [PATCH] Fix leaks in DL_Dxf::test

[John Beard]

Hi,

There is a resource leak in DL_Dxf::test().

This function is never actually used and only provides some kind of
manual test case. However, the leaks set off static analysers like
Coverity (6 times), so we might as well fix it since it's easy?

Cheers,

John
From 2e4bdc2e93cc577b6d37592e077b897f71ba6d6f Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Fri, 28 Sep 2018 18:21:20 +0100
Subject: [PATCH] Dxf: Fix leaks in DL_Dxf::test

This function is never actually used, but the resource leaks
set off static analysers.

Fixes: coverity:131460-131465
---
 dxflib_qcad/dl_dxf.cpp | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/dxflib_qcad/dl_dxf.cpp b/dxflib_qcad/dl_dxf.cpp
index d99286189..4f43db9a2 100644
--- a/dxflib_qcad/dl_dxf.cpp
+++ b/dxflib_qcad/dl_dxf.cpp
@@ -6392,4 +6392,11 @@ void DL_Dxf::test()
 std::cout << "1 buf6: '" << buf6 << "'\n";
 stripWhiteSpace(  );
 std::cout << "2 buf6: '" << buf6 << "'\n";
+
+delete( buf1 );
+delete( buf2 );
+delete( buf3 );
+delete( buf4 );
+delete( buf5 );
+delete( buf6 );
 }
-- 
2.19.0

___
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] Fix resource leak in chamfer test

[John Beard]

Hi,

Small patch here to fix a small leak in a unit test.

While the leak is not very exciting here, the other function of unit
tests is to "document" interfaces by using them correctly. So this
uses a unique_ptr to make the ownership explicit.

Fixes coverity defect 183869.

Cheers,

John
From 53e1c92fbdf204d7070258cf27b30e156ddc37e5 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Fri, 28 Sep 2018 17:59:42 +0100
Subject: [PATCH] QA: Fix ownership of new CPolyline in
 qa_shape_poly_set_refactor

CPolyLine::Chamfer returns a newly allocated object. The current
test of this doesn't take ownership, leading to memory leaks.

Use a std::unique_ptr to:

* Fix the leak, and
* Document the expected semantics of the interface in the test

Fixes coverity:183869
---
 qa/shape_poly_set_refactor/test_chamfer.cpp | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/qa/shape_poly_set_refactor/test_chamfer.cpp b/qa/shape_poly_set_refactor/test_chamfer.cpp
index 22dc245c4..7d8a16859 100644
--- a/qa/shape_poly_set_refactor/test_chamfer.cpp
+++ b/qa/shape_poly_set_refactor/test_chamfer.cpp
@@ -99,23 +99,24 @@ void TestLineChainEqualCPolyLine(SHAPE_LINE_CHAIN& lineChain, CPolyLine& polyLin
 BOOST_AUTO_TEST_CASE( Chamfer )
 {
 SHAPE_POLY_SET::POLYGON actual;
-CPolyLine expected;
 
 // Test different distances, up to the half of the minimum segment longitude
-for (int distance = 0; distance < 5; distance++) {
+for( int distance = 0; distance < 5; distance++ )
+{
 // Chamfered polygon to be tested.
 actual = common.holeyPolySet.ChamferPolygon( distance, 0 );
 
 // Chamfered polygon assumed to be right.
-expected = *legacyPolyLine.Chamfer( distance );
+// CPolyline::Chamfer returns new CPolyline - take ownership
+std::unique_ptr expected( legacyPolyLine.Chamfer( distance ) );
 
 // Double check that there are no repeated corners in the legacy shape.
-expected.RemoveNullSegments();
+expected->RemoveNullSegments();
 
 // Test equality
-for (size_t contourIdx = 0; contourIdx < actual.size(); contourIdx++)
+for( size_t contourIdx = 0; contourIdx < actual.size(); contourIdx++ )
 {
-TestLineChainEqualCPolyLine(actual[contourIdx], expected, contourIdx);
+TestLineChainEqualCPolyLine(actual[contourIdx], *expected, contourIdx);
 }
 }
 }
-- 
2.19.0

___
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] Hotkey edit dialog filter + fixes

[John Beard]

Hi Wayne,

I understand - my question is what would be the better resolution for
lp:1778374 for 5.1 (not 5.0.1)?

I have not done any work on the list dialog yet on any branch, as I
don't want to waste time making a read-only widget if that's not the
preferred method.

My feeling is that it would be better to kill off the list dialog and
redirect the Ctrl+F1 action to the hotkey editor (which has the filter
now). In future, when the legacy hotkey system is killed off and we
port the hotkey dialog to the GAL-style tool actions (lp:1663896),
then we could look at a slicker hotkey list widget if that has
anything to add at that time.

In the meantime, lp:1792159 (listing hotkeys in tooltips, also a 5.1
target) is probably the biggest positive impact we could have on
hotkey deliverability.

Cheers,

John
On Fri, Sep 28, 2018 at 4:16 PM Wayne Stambaugh  wrote:
>
> Thanks for the clarification.  Wishlist bugs are always tagged for the
> next release version so there is no need to make any hotkey list dialog
> changes for 5.0.1.
>
> On 09/28/2018 10:42 AM, John Beard wrote:
> > Hi Wayne,
> >
> > I was only planning to make changes to the list dialog (as opposed to
> > the editor dialog) in the master branch. I'm not planning to backport
> > any of the filter stuff to 5.0.1.
> >
> > The aim is to check off https://bugs.launchpad.net/kicad/+bug/1778374
> > (Wishlist: add search box to Help --> List Hotkeys menu), which is
> > milestoned for 5.1.
> >
> > The patches just merged would provide good groundwork for that (even
> > if the list dialog used totally different widgets, the underlying
> > HOTKEY_STORE would be re-usable), but don't actually complete that
> > bug.
> >
> > Cheers,
> >
> > John
> > On Fri, Sep 28, 2018 at 3:32 PM Wayne Stambaugh  
> > wrote:
> >>
> >> Hey John,
> >>
> >> Given that 5.1 is pretty far along and the delta between the 5.0 and
> >> development branches, I would rather you didn't spent a lot of time
> >> trying to back port the dialog fixes which are low priority.  I want to
> >> get 5.0.1 tagged as soon as possible and merge the eeschema-gal stuff so
> >> we can get some wider testing on that.  Having all hands on deck to fix
> >> any issue we find in the eeschema-gal code will be more beneficial.
> >>
> >> Cheers,
> >>
> >> Wayne
> >>
> >> On 09/28/2018 10:23 AM, John Beard wrote:
> >>> Hi Wayne,
> >>>
> >>> Do you have any preference on the hotkey list dialog? I'm happy to go
> >>> either way, but I'd like to know the preferred direction before I
> >>> spend too much time on it!
> >>>
> >>> Cheers,
> >>>
> >>> John
> >>> On Fri, Sep 28, 2018 at 3:11 PM Wayne Stambaugh  
> >>> wrote:
> >>>>> Hey John,
> >>>>
> >>>> Nice work!  I merged your patch into the development branch.  I do have
> >>>> one favor to ask if you have the time.  Patch 6 does not apply to the
> >>>> 5.0 branch which also suffers from the crash bug.  If you could merge it
> >>>> into the 5.0 branch and send me a separate patch I would appreciate it.
> >>>> If you don't have the time please let me know because this needs to be
> >>>> fixed for the 5.0.1 release.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Wayne
> >>>>
> >>>> On 09/28/2018 07:53 AM, John Beard wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Here is a patch set for adding a filter control to the hotkey editor
> >>>>> dialog. Preview video: https://sendvid.com/je0cyg87
> >>>>>
> >>>>> Most of the work in the first commit is separating out the hotkey data
> >>>>> from the UI widget code.
> >>>>>
> >>>>> This also fixes a couple of other bugs (one crashing, and one able to
> >>>>> get the HK configs into a mess with conflicts) in that dialog, and
> >>>>> adds some mock objects to the common QA tests, which will make it
> >>>>> easier to get more of libcommon under test.
> >>>>>
> >>>>> A 5.0 series fix for the crashing bug will follow.
> >>>>>
> >>>>> This is also useful as groundwork for
> >>>>> https://bugs.launchpad.net/kicad/+bug/1778374 (a 5.1 milestone), but
> >>>>> that will need a further decision to choose between:
> >>>&

Re: [Kicad-developers] [PATCH] Hotkey edit dialog filter + fixes

[John Beard]

Hi Wayne,

I was only planning to make changes to the list dialog (as opposed to
the editor dialog) in the master branch. I'm not planning to backport
any of the filter stuff to 5.0.1.

The aim is to check off https://bugs.launchpad.net/kicad/+bug/1778374
(Wishlist: add search box to Help --> List Hotkeys menu), which is
milestoned for 5.1.

The patches just merged would provide good groundwork for that (even
if the list dialog used totally different widgets, the underlying
HOTKEY_STORE would be re-usable), but don't actually complete that
bug.

Cheers,

John
On Fri, Sep 28, 2018 at 3:32 PM Wayne Stambaugh  wrote:
>
> Hey John,
>
> Given that 5.1 is pretty far along and the delta between the 5.0 and
> development branches, I would rather you didn't spent a lot of time
> trying to back port the dialog fixes which are low priority.  I want to
> get 5.0.1 tagged as soon as possible and merge the eeschema-gal stuff so
> we can get some wider testing on that.  Having all hands on deck to fix
> any issue we find in the eeschema-gal code will be more beneficial.
>
> Cheers,
>
> Wayne
>
> On 09/28/2018 10:23 AM, John Beard wrote:
> > Hi Wayne,
> >
> > Do you have any preference on the hotkey list dialog? I'm happy to go
> > either way, but I'd like to know the preferred direction before I
> > spend too much time on it!
> >
> > Cheers,
> >
> > John
> > On Fri, Sep 28, 2018 at 3:11 PM Wayne Stambaugh  
> > wrote:
> >>> Hey John,
> >>
> >> Nice work!  I merged your patch into the development branch.  I do have
> >> one favor to ask if you have the time.  Patch 6 does not apply to the
> >> 5.0 branch which also suffers from the crash bug.  If you could merge it
> >> into the 5.0 branch and send me a separate patch I would appreciate it.
> >> If you don't have the time please let me know because this needs to be
> >> fixed for the 5.0.1 release.
> >>
> >> Cheers,
> >>
> >> Wayne
> >>
> >> On 09/28/2018 07:53 AM, John Beard wrote:
> >>> Hi,
> >>>
> >>> Here is a patch set for adding a filter control to the hotkey editor
> >>> dialog. Preview video: https://sendvid.com/je0cyg87
> >>>
> >>> Most of the work in the first commit is separating out the hotkey data
> >>> from the UI widget code.
> >>>
> >>> This also fixes a couple of other bugs (one crashing, and one able to
> >>> get the HK configs into a mess with conflicts) in that dialog, and
> >>> adds some mock objects to the common QA tests, which will make it
> >>> easier to get more of libcommon under test.
> >>>
> >>> A 5.0 series fix for the crashing bug will follow.
> >>>
> >>> This is also useful as groundwork for
> >>> https://bugs.launchpad.net/kicad/+bug/1778374 (a 5.1 milestone), but
> >>> that will need a further decision to choose between:
> >>>
> >>> * Use a read-only variant of the hotkey editor TreeListView for the
> >>> hotkey list dialog (needs more code: a new dialog and adding a
> >>> read-only mode to the current widget), or
> >>> * Remove the hotkey list dialog altogether and bind the "show hotkey
> >>> list" command to simply opening the prefs dialog to the hotkey panel
> >>>
> >>> 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
> >>>
> >>
> >> ___
> >> 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] Hotkey edit dialog filter + fixes

[John Beard]

Hi Wayne,

Do you have any preference on the hotkey list dialog? I'm happy to go
either way, but I'd like to know the preferred direction before I
spend too much time on it!

Cheers,

John
On Fri, Sep 28, 2018 at 3:11 PM Wayne Stambaugh  wrote:
>> Hey John,
>
> Nice work!  I merged your patch into the development branch.  I do have
> one favor to ask if you have the time.  Patch 6 does not apply to the
> 5.0 branch which also suffers from the crash bug.  If you could merge it
> into the 5.0 branch and send me a separate patch I would appreciate it.
> If you don't have the time please let me know because this needs to be
> fixed for the 5.0.1 release.
>
> Cheers,
>
> Wayne
>
> On 09/28/2018 07:53 AM, John Beard wrote:
> > Hi,
> >
> > Here is a patch set for adding a filter control to the hotkey editor
> > dialog. Preview video: https://sendvid.com/je0cyg87
> >
> > Most of the work in the first commit is separating out the hotkey data
> > from the UI widget code.
> >
> > This also fixes a couple of other bugs (one crashing, and one able to
> > get the HK configs into a mess with conflicts) in that dialog, and
> > adds some mock objects to the common QA tests, which will make it
> > easier to get more of libcommon under test.
> >
> > A 5.0 series fix for the crashing bug will follow.
> >
> > This is also useful as groundwork for
> > https://bugs.launchpad.net/kicad/+bug/1778374 (a 5.1 milestone), but
> > that will need a further decision to choose between:
> >
> > * Use a read-only variant of the hotkey editor TreeListView for the
> > hotkey list dialog (needs more code: a new dialog and adding a
> > read-only mode to the current widget), or
> > * Remove the hotkey list dialog altogether and bind the "show hotkey
> > list" command to simply opening the prefs dialog to the hotkey panel
> >
> > 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
> >
>
> ___
> 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] Hotkey edit dialog filter + fixes

[John Beard]

HI Wayne,

Yes, here is a separate patch for the 5.0 series.

Cheers,

John
On Fri, Sep 28, 2018 at 3:11 PM Wayne Stambaugh  wrote:
>
> Hey John,
>
> Nice work!  I merged your patch into the development branch.  I do have
> one favor to ask if you have the time.  Patch 6 does not apply to the
> 5.0 branch which also suffers from the crash bug.  If you could merge it
> into the 5.0 branch and send me a separate patch I would appreciate it.
> If you don't have the time please let me know because this needs to be
> fixed for the 5.0.1 release.
>
> Cheers,
>
> Wayne
>
> On 09/28/2018 07:53 AM, John Beard wrote:
> > Hi,
> >
> > Here is a patch set for adding a filter control to the hotkey editor
> > dialog. Preview video: https://sendvid.com/je0cyg87
> >
> > Most of the work in the first commit is separating out the hotkey data
> > from the UI widget code.
> >
> > This also fixes a couple of other bugs (one crashing, and one able to
> > get the HK configs into a mess with conflicts) in that dialog, and
> > adds some mock objects to the common QA tests, which will make it
> > easier to get more of libcommon under test.
> >
> > A 5.0 series fix for the crashing bug will follow.
> >
> > This is also useful as groundwork for
> > https://bugs.launchpad.net/kicad/+bug/1778374 (a 5.1 milestone), but
> > that will need a further decision to choose between:
> >
> > * Use a read-only variant of the hotkey editor TreeListView for the
> > hotkey list dialog (needs more code: a new dialog and adding a
> > read-only mode to the current widget), or
> > * Remove the hotkey list dialog altogether and bind the "show hotkey
> > list" command to simply opening the prefs dialog to the hotkey panel
> >
> > 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
> >
>
> ___
> 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 7b4692552f6bc03dff62d036ad0543a76dd11309 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Thu, 27 Sep 2018 14:44:03 +0100
Subject: [PATCH] Prevent segfault when undoing or resetting non-hotkey rows

This is caused by:

* Not checking the hotkey data is not null when performing a
  hotkey action
* Allowing hotkey actions on non-hotkey rows.

This fixes both of these, and adds an assert to warn if someone
does manage to fire a hotkey action on a non-hotkey row (but it
won't crash).

This is a ported version of commit 704615721 on the master branch.

Fixes: lp:1794756
* https://bugs.launchpad.net/kicad/+bug/1794756
---
 common/widgets/widget_hotkey_list.cpp | 47 ---
 include/widgets/widget_hotkey_list.h  |  7 
 2 files changed, 43 insertions(+), 11 deletions(-)

diff --git a/common/widgets/widget_hotkey_list.cpp b/common/widgets/widget_hotkey_list.cpp
index 66b38ad04..74c3f59b7 100644
--- a/common/widgets/widget_hotkey_list.cpp
+++ b/common/widgets/widget_hotkey_list.cpp
@@ -253,6 +253,18 @@ WIDGET_HOTKEY_CLIENT_DATA* WIDGET_HOTKEY_LIST::GetSelHKClientData()
 }
 
 
+WIDGET_HOTKEY_CLIENT_DATA* WIDGET_HOTKEY_LIST::getExpectedHkClientData( wxTreeListItem aItem )
+{
+const auto hkdata = GetHKClientData( aItem );
+
+// This probably means a hotkey-only action is being attempted on
+// a row that is not a hotkey (like a section heading)
+wxASSERT_MSG( hkdata != nullptr, "No hotkey data found for list item" );
+
+return hkdata;
+}
+
+
 void WIDGET_HOTKEY_LIST::UpdateFromClientData()
 {
 for( wxTreeListItem i = GetFirstItem(); i.IsOk(); i = GetNextItem( i ) )
@@ -285,13 +297,10 @@ void WIDGET_HOTKEY_LIST::LoadSection( EDA_HOTKEY_CONFIG* aSection )
 
 void WIDGET_HOTKEY_LIST::EditItem( wxTreeListItem aItem )
 {
-WIDGET_HOTKEY_CLIENT_DATA* hkdata = GetHKClientData( aItem );
+WIDGET_HOTKEY_CLIENT_DATA* hkdata = getExpectedHkClientData( aItem );
 
 if( !hkdata )
-{
-// Activated item was not a hotkey row
 return;
-}
 
 wxStringname = GetItemText( aItem, 0 );
 wxStringcurrent_key = GetItemText( aItem, 1 );
@@ -299,7 +308,7 @@ void WIDGET_HOTKEY_LIST::EditItem( wxTreeListItem aItem )
 wxKeyEvent key_event = HK_PROMPT_DIALOG::PromptForKey( GetParent(), name, current_key );
 long key = MapKeypressToKeycode( key_event );
 
-if( hkdata && key )
+   

[Kicad-developers] [PATCH] Hotkey edit dialog filter + fixes

[John Beard]

Hi,

Here is a patch set for adding a filter control to the hotkey editor
dialog. Preview video: https://sendvid.com/je0cyg87

Most of the work in the first commit is separating out the hotkey data
from the UI widget code.

This also fixes a couple of other bugs (one crashing, and one able to
get the HK configs into a mess with conflicts) in that dialog, and
adds some mock objects to the common QA tests, which will make it
easier to get more of libcommon under test.

A 5.0 series fix for the crashing bug will follow.

This is also useful as groundwork for
https://bugs.launchpad.net/kicad/+bug/1778374 (a 5.1 milestone), but
that will need a further decision to choose between:

* Use a read-only variant of the hotkey editor TreeListView for the
hotkey list dialog (needs more code: a new dialog and adding a
read-only mode to the current widget), or
* Remove the hotkey list dialog altogether and bind the "show hotkey
list" command to simply opening the prefs dialog to the hotkey panel

Cheers,

John
From 6f219fc68c17d0648c0f32fd468174b34210a078 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Thu, 27 Sep 2018 15:48:52 +0100
Subject: [PATCH 2/6] Add some hotkey store tests

This also adds some mocks to the libcommon test executable, which
hopefully will allow it to work with more of libcommon.
---
 common/hotkey_store.cpp |  25 ++
 include/hotkey_store.h  |   7 ++
 qa/common/CMakeLists.txt|   6 ++
 qa/common/common_mocks.cpp  |  42 +
 qa/common/test_hotkey_store.cpp | 148 
 5 files changed, 228 insertions(+)
 create mode 100644 qa/common/common_mocks.cpp
 create mode 100644 qa/common/test_hotkey_store.cpp

diff --git a/common/hotkey_store.cpp b/common/hotkey_store.cpp
index 62e9fc424..479d9c67a 100644
--- a/common/hotkey_store.cpp
+++ b/common/hotkey_store.cpp
@@ -53,6 +53,30 @@ std::vector& HOTKEY_STORE::GetSections()
 }
 
 
+CHANGED_HOTKEY* HOTKEY_STORE::FindHotkey( const wxString& aTag, int aCmdId )
+{
+CHANGED_HOTKEY* found_key = nullptr;
+
+for( auto& section: m_hk_sections )
+{
+if( *section.m_section.m_SectionTag != aTag)
+continue;
+
+for( auto& hotkey: section.m_hotkeys )
+{
+auto& curr_hk = hotkey.GetCurrentValue();
+if( curr_hk.m_Idcommand == aCmdId )
+{
+found_key = 
+break;
+}
+}
+}
+
+return found_key;
+}
+
+
 void HOTKEY_STORE::SaveAllHotkeys()
 {
 for( auto& section: m_hk_sections )
@@ -98,6 +122,7 @@ bool HOTKEY_STORE::CheckKeyConflicts( long aKey, const wxString& aSectionTag,
 for( auto& section: m_hk_sections )
 {
 const auto& sectionTag = *section.m_section.m_SectionTag;
+
 if( aSectionTag != g_CommonSectionTag
 && sectionTag != g_CommonSectionTag
 && sectionTag != aSectionTag )
diff --git a/include/hotkey_store.h b/include/hotkey_store.h
index 13b985b36..cbeb58d34 100644
--- a/include/hotkey_store.h
+++ b/include/hotkey_store.h
@@ -126,6 +126,13 @@ public:
  */
 SECTION_LIST& GetSections();
 
+
+/**
+ * Find a hotkey with the given command ID and in the given section
+ * @return pointer to the hotkey if found.
+ */
+CHANGED_HOTKEY* FindHotkey( const wxString& aTag, int aCmdId );
+
 /**
  * Persist all changes to hotkeys in the store to the underlying
  * data structures.
diff --git a/qa/common/CMakeLists.txt b/qa/common/CMakeLists.txt
index b5aae6c3c..e6c163296 100644
--- a/qa/common/CMakeLists.txt
+++ b/qa/common/CMakeLists.txt
@@ -26,8 +26,13 @@ find_package( wxWidgets 3.0.0 COMPONENTS gl aui adv html core net base xml stc R
 add_definitions(-DBOOST_TEST_DYN_LINK)
 
 add_executable( qa_common
+# This is needed for the global mock objects
+common_mocks.cpp
+
+# The main test entry points
 test_module.cpp
 
+test_hotkey_store.cpp
 test_utf8.cpp
 
 geometry/test_fillet.cpp
@@ -43,6 +48,7 @@ include_directories(
 target_link_libraries( qa_common
 common
 polygon
+bitmaps
 ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY}
 ${wxWidgets_LIBRARIES}
 )
diff --git a/qa/common/common_mocks.cpp b/qa/common/common_mocks.cpp
new file mode 100644
index 0..9b54ee6ec
--- /dev/null
+++ b/qa/common/common_mocks.cpp
@@ -0,0 +1,42 @@
+/*
+ * This program source code file is part of KiCad, a free EDA CAD application.
+ *
+ * Copyright (C) 2018 KiCad Developers, see AUTHORS.txt for contributors.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *

[Kicad-developers] [PATCH] Make generic 'common' test and add UTF8 tests

[John Beard]

Hi,

These patches make a place for unit tests of stuff in /common under
/qa. This has to move some existing stuff around a little bit:

* /qa/common -> /qa/qa_utils
* /qa/geometry is now part of the new /qa/common

This makes a place to put libcommon tests and keeps /qa as an analogue
of the main tree, just under /qa.

Followed up by the first (non-geom) unit test of common code - UTF8,
which replaces some very old and ad-hoc manual testing code in
common/utf8.cpp with a proper Boost unit test.

This should not change any aspect of production code, as all changes
are to #if 0 code and /qa.

The alternative to this method is to distribute tests into the various
subdirs. In this case, creating /common/qa. This is how eeschema
currently does it. It would be functionally the same to do it that
way, just needs to move files around. `make test` would still work the
same. Let me know if that way is preferred.

Cheers,

John
From 1f9a290604bf0dd8f2ee5d47d58ed34504dc36de Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Tue, 25 Sep 2018 12:11:10 +0100
Subject: [PATCH 1/2] QA: Make a generic common test suite

* Renames /qa/common to /qa/qa_utils, as it is not to do with /common
* Renames /qa/geometry to /qa/common
* Put existing geometry tests into a subdirectory of /qa/common, to
  echo the layout of the main tree.

The intention is to provide a place to put tests of other libcommon
code in the /qa/common suite.
---
 qa/CMakeLists.txt  |  2 +-
 qa/{geometry => common}/CMakeLists.txt | 10 +-
 qa/{ => common}/geometry/geom_test_utils.h |  0
 qa/{ => common}/geometry/test_fillet.cpp   |  2 +-
 qa/{geometry => common}/test_module.cpp|  2 +-
 qa/pcb_test_window/CMakeLists.txt  |  6 +++---
 qa/polygon_generator/CMakeLists.txt|  2 +-
 qa/polygon_triangulation/CMakeLists.txt|  2 +-
 qa/{common => qa_utils}/mocks.cpp  |  0
 qa/{common => qa_utils}/pcb_test_frame.cpp |  0
 qa/{common => qa_utils}/pcb_test_frame.h   |  0
 11 files changed, 13 insertions(+), 13 deletions(-)
 rename qa/{geometry => common}/CMakeLists.txt (91%)
 rename qa/{ => common}/geometry/geom_test_utils.h (100%)
 rename qa/{ => common}/geometry/test_fillet.cpp (99%)
 rename qa/{geometry => common}/test_module.cpp (95%)
 rename qa/{common => qa_utils}/mocks.cpp (100%)
 rename qa/{common => qa_utils}/pcb_test_frame.cpp (100%)
 rename qa/{common => qa_utils}/pcb_test_frame.h (100%)

diff --git a/qa/CMakeLists.txt b/qa/CMakeLists.txt
index e82afcd73..a932b8754 100644
--- a/qa/CMakeLists.txt
+++ b/qa/CMakeLists.txt
@@ -12,7 +12,7 @@ if( KICAD_SCRIPTING_MODULES )
 
 endif()
 
-add_subdirectory( geometry )
+add_subdirectory( common )
 add_subdirectory( shape_poly_set_refactor )
 add_subdirectory( pcb_test_window )
 add_subdirectory( polygon_triangulation )
diff --git a/qa/geometry/CMakeLists.txt b/qa/common/CMakeLists.txt
similarity index 91%
rename from qa/geometry/CMakeLists.txt
rename to qa/common/CMakeLists.txt
index 031c02b3a..293532c18 100644
--- a/qa/geometry/CMakeLists.txt
+++ b/qa/common/CMakeLists.txt
@@ -25,9 +25,9 @@ find_package( wxWidgets 3.0.0 COMPONENTS gl aui adv html core net base xml stc R
 
 add_definitions(-DBOOST_TEST_DYN_LINK)
 
-add_executable( qa_geometry
+add_executable( qa_common
 test_module.cpp
-test_fillet.cpp
+geometry/test_fillet.cpp
 )
 
 include_directories(
@@ -37,13 +37,13 @@ include_directories(
 ${Boost_INCLUDE_DIR}
 )
 
-target_link_libraries( qa_geometry
+target_link_libraries( qa_common
 common
 polygon
 ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY}
 ${wxWidgets_LIBRARIES}
 )
 
-add_test( NAME geometry
-COMMAND qa_geometry
+add_test( NAME common
+COMMAND qa_common
 )
\ No newline at end of file
diff --git a/qa/geometry/geom_test_utils.h b/qa/common/geometry/geom_test_utils.h
similarity index 100%
rename from qa/geometry/geom_test_utils.h
rename to qa/common/geometry/geom_test_utils.h
diff --git a/qa/geometry/test_fillet.cpp b/qa/common/geometry/test_fillet.cpp
similarity index 99%
rename from qa/geometry/test_fillet.cpp
rename to qa/common/geometry/test_fillet.cpp
index c7d758ec6..119db6b19 100644
--- a/qa/geometry/test_fillet.cpp
+++ b/qa/common/geometry/test_fillet.cpp
@@ -29,7 +29,7 @@
 
 #include 
 
-#include 
+#include "geom_test_utils.h"
 
 struct FilletFixture
 {
diff --git a/qa/geometry/test_module.cpp b/qa/common/test_module.cpp
similarity index 95%
rename from qa/geometry/test_module.cpp
rename to qa/common/test_module.cpp
index 6fb45de1f..38f18fd03 100644
--- a/qa/geometry/test_module.cpp
+++ b/qa/common/test_module.cpp
@@ -26,7 +26,7 @@
  */
 
 #define BOOST_TEST_MAIN
-#define BOOST_TEST_MODULE "Geometry module tests"
+#define BOOST_TEST_MODULE "Common library module tests"
 
 
 #include 
diff --git a/qa/pcb_test_window/CMakeLists.txt b/qa/pcb_test_window/CMakeLists.txt
index 3bcc664dc..af9f01f81 100644
--- a/qa/pcb_test_w

Re: [Kicad-developers] GAL canvas strategy - testers needed!

[John Beard]

Hi,

The rendering of unclosed polyline in symbols is different in GAL.

See the attached (standard libs potentiometer symbol) - in the legacy
canvas, the arrow doesn't have a missing lower side.

Is this a bug in GAL, or is it actually intended and the symbol is
wrong (but happened to work before by accident)?

Cheers,

John
On Tue, Sep 18, 2018 at 12:35 AM Jeff Young  wrote:
>
> There’s a setting for that (Always show crosshairs).  You probably have it on 
> in Pcbnew/Display Options but not in Eeschema/Display Options.
>
> > On 18 Sep 2018, at 00:30, Wayne Stambaugh  wrote:
> >
> > I don't know if this is intentional or not but I noticed (at least on
> > windows) that the cursor is no longer displayed when the select tool is
> > active.  This is different than the old canvas where the cursor always
> > tracked the mouse point for all tools.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 9/17/2018 7:21 PM, Jeff Young wrote:
> >> I pushed fixes for sheet pins and the cursor.  (It also removes a bunch of 
> >> legacy grid and cursor colour stuff that is no longer needed.)
> >>
> >> Cheers,
> >> Jeff.
> >>
> >>
> >>> On 17 Sep 2018, at 20:03, mdoes...@xs4all.nl wrote:
> >>>
> >>> I don't think I mailed the list, but also found another issue.
> >>>
> >>> I noticed the sheet text is the same color as "notes", and not "sheet
> >>> label".
> >>>
> >>> The cursor cross-hair is always black.
> >>>
> >>> Otherwise it works fine for me on a quick test.
> >>>
> >>> regards,
> >>>
> >>> Mark.
> >>
> >>
> >> ___
> >> 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] GAL canvas strategy - testers needed!

[John Beard]

Hi,

Here are a handful of tiny fixes for warnings in the eeschema GAL
branch. Nothing really controversial, I think (though the second one
fixes quite a verbose tranche of warnings - one for almost every type
of object :-).

Cheers,

John
On Tue, Sep 18, 2018 at 12:35 AM Jeff Young  wrote:
>
> There’s a setting for that (Always show crosshairs).  You probably have it on 
> in Pcbnew/Display Options but not in Eeschema/Display Options.
>
> > On 18 Sep 2018, at 00:30, Wayne Stambaugh  wrote:
> >
> > I don't know if this is intentional or not but I noticed (at least on
> > windows) that the cursor is no longer displayed when the select tool is
> > active.  This is different than the old canvas where the cursor always
> > tracked the mouse point for all tools.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 9/17/2018 7:21 PM, Jeff Young wrote:
> >> I pushed fixes for sheet pins and the cursor.  (It also removes a bunch of 
> >> legacy grid and cursor colour stuff that is no longer needed.)
> >>
> >> Cheers,
> >> Jeff.
> >>
> >>
> >>> On 17 Sep 2018, at 20:03, mdoes...@xs4all.nl wrote:
> >>>
> >>> I don't think I mailed the list, but also found another issue.
> >>>
> >>> I noticed the sheet text is the same color as "notes", and not "sheet
> >>> label".
> >>>
> >>> The cursor cross-hair is always black.
> >>>
> >>> Otherwise it works fine for me on a quick test.
> >>>
> >>> regards,
> >>>
> >>> Mark.
> >>
> >>
> >> ___
> >> 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
From 062377a66836c02b38f58fd6daa6fc12b4b624f3 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Tue, 18 Sep 2018 14:41:06 +0100
Subject: [PATCH 2/3] Add default case in edit_label.cpp (-Wswitch)

This should never ben hit as it's defended against above,
but lack of a default causes lots of -Wswitch warnings, so
add an assert and a return.
---
 eeschema/edit_label.cpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/eeschema/edit_label.cpp b/eeschema/edit_label.cpp
index 8fca11b0e..b6da029b3 100644
--- a/eeschema/edit_label.cpp
+++ b/eeschema/edit_label.cpp
@@ -186,6 +186,10 @@ void SCH_EDIT_FRAME::OnConvertTextType( wxCommandEvent& aEvent )
 case SCH_TEXT_T:
 newtext = new SCH_TEXT( position, txt );
 break;
+
+default:
+wxASSERT_MSG( false, wxString::Format( "Invalid text type: %d.", type ) );
+return;
 }
 
 /* Copy the old text item settings to the new one.  Justifications are not copied because
-- 
2.18.0

From e1e4a9ff307bbe01bb60ecee673b717fd51e2e32 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Tue, 18 Sep 2018 14:45:52 +0100
Subject: [PATCH 3/3] Fix -Wreorder warning in common view-overlay.cpp

Simple fix - m_radius comes after m_{start,end}Angle in the class member list.
---
 common/view/view_overlay.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/view/view_overlay.cpp b/common/view/view_overlay.cpp
index a09734985..78543a156 100644
--- a/common/view/view_overlay.cpp
+++ b/common/view/view_overlay.cpp
@@ -77,9 +77,9 @@ struct VIEW_OVERLAY::COMMAND_ARC : public VIEW_OVERLAY::COMMAND
 {
 COMMAND_ARC( const VECTOR2D& aCenter, double aRadius, double aStartAngle, double aEndAngle ) :
 m_center(aCenter),
-m_radius(aRadius),
 m_startAngle( aStartAngle ),
-m_endAngle( aEndAngle )
+m_endAngle( aEndAngle ),
+m_radius(aRadius)
 {}
 
 virtual void Execute( VIEW* aView ) const override
-- 
2.18.0

From 9b14e5fc6577e2b08252281d9960b8198c62f008 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Tue, 18 Sep 2018 14:30:23 +0100
Subject: [PATCH 1/3] Remove unused variable from pcbnew/onrightclick.cpp

---
 pcbnew/onrightclick.cpp | 2 --
 1 file changed, 2 deletions(-)

d

Re: [Kicad-developers] GAL canvas strategy - testers needed!

[John Beard]

Hi,

Quick bug report on fb748be43 (eeschema GAL HEAD) on Linux: Undoing a
global label doesn't refresh.

1) Make a global label
2) Undo it
3) Nothing happens
4) Refresh (F3): Label disappears

Otherwise, looking quite slick.

Cheers,

John
On Fri, Sep 14, 2018 at 10:30 AM Jeff Young  wrote:
>
> I pushed JP’s patches.
>
> What’s our plan for getting this branch merged to master?
>
> Cheers,
> Jeff.
>
>
> > On 14 Sep 2018, at 10:15, jp charras  wrote:
> >
> > Le 12/09/2018 à 17:01, Jeff Young a écrit :
> >> I just pushed a fix for a segfault while routing.  
> >> (https://bugs.launchpad.net/kicad/+bug/1792037)
> >>
> >> Cheers,
> >> Jeff.
> >
> > Hi Jeff,
> >
> > Attached 2 other patches for Eeschema GAL.
> >
> > The first allows switching between Cairo and Opengl.
> > The second fixes Zoom issues (with hotkeys and popup menu).
> >
> > I am seeing an other annoying issue: the scroll bars are not shown in
> > Gal Canvas (both in Eeschema and Pcbnew), but I have no idea why they
> > are not displayed (although they are displayed in the pad properties
> > dialog).
> >
> > Perhaps a GAL guru could have a look into this issue.
> >
> > I also saw a few minor other issues, depending on the selected canvas.
> >
> > Cheers,
> >
> > --
> > Jean-Pierre CHARRAS
> > <0001-add-option-to-switch-between-opengl-and-cairo-in-ees.patch><0002-Fix-zoom-issues-in-Eeschema-F1-to-F4-and-popup-zoom-.patch>___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
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] Remove obsolete fillet refactor tests

[John Beard]

Hi,

The fillet refactor tests that were previous disabled are removed by
this patch. These tests are pretty useless, as the two compared fillet
methods have different meanings now.

This also fixes https://bugs.launchpad.net/kicad/+bug/1785377, as the
test exclusion syntax in Boost Unit Test only works from Boost 1.59,
and Ubuntu 16 evidently uses 1.58.

Cheers,

John
From 5378f576008abd7cbe5ddb46616488a5b8df66be Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Sun, 5 Aug 2018 19:16:55 +0100
Subject: [PATCH] QA: Remove obsolete fillet refactor tests

These tests are fundamentally broken as they test two fillet
implementations against each other, but the two implementations
no longer have the same interface or meaning (one has a fixed
segment count, one has a fixed error).

This also allows the tests to run on Boost <1.59, which do not
provide the !-syntax for excluding tests. Ubuntu 16 uses
Boost 1.58, so this causes build failures.

Fixes: 1785377
https://bugs.launchpad.net/kicad/+bug/1785377
---
 qa/shape_poly_set_refactor/CMakeLists.txt |  4 +-
 ...st_chamfer_fillet.cpp => test_chamfer.cpp} | 38 +--
 2 files changed, 3 insertions(+), 39 deletions(-)
 rename qa/shape_poly_set_refactor/{test_chamfer_fillet.cpp => test_chamfer.cpp} (78%)

diff --git a/qa/shape_poly_set_refactor/CMakeLists.txt b/qa/shape_poly_set_refactor/CMakeLists.txt
index 3100328b5..d6b72aeb0 100644
--- a/qa/shape_poly_set_refactor/CMakeLists.txt
+++ b/qa/shape_poly_set_refactor/CMakeLists.txt
@@ -28,7 +28,7 @@ add_definitions(-DBOOST_TEST_DYN_LINK)
 
 add_executable( qa_shape_poly_set_refactor
 test_module.cpp
-test_chamfer_fillet.cpp
+test_chamfer.cpp
 test_collision.cpp
 test_iterator.cpp
 test_segment.cpp
@@ -56,5 +56,5 @@ target_link_libraries( qa_shape_poly_set_refactor
 add_dependencies( qa_shape_poly_set_refactor pcbnew )
 
 add_test( NAME shape_poly_set_refactor
-COMMAND qa_shape_poly_set_refactor --run_test=!ChamferFillet/Fillet
+COMMAND qa_shape_poly_set_refactor
 )
diff --git a/qa/shape_poly_set_refactor/test_chamfer_fillet.cpp b/qa/shape_poly_set_refactor/test_chamfer.cpp
similarity index 78%
rename from qa/shape_poly_set_refactor/test_chamfer_fillet.cpp
rename to qa/shape_poly_set_refactor/test_chamfer.cpp
index 8d5c9f475..22dc245c4 100644
--- a/qa/shape_poly_set_refactor/test_chamfer_fillet.cpp
+++ b/qa/shape_poly_set_refactor/test_chamfer.cpp
@@ -34,7 +34,7 @@
 /**
  * Declares the ChamferFilletFixture struct as the boost test fixture.
  */
-BOOST_FIXTURE_TEST_SUITE( ChamferFillet, ChamferFilletFixture )
+BOOST_FIXTURE_TEST_SUITE( Chamfer, ChamferFilletFixture )
 
 /**
  * Function lexicographicOrder
@@ -120,40 +120,4 @@ BOOST_AUTO_TEST_CASE( Chamfer )
 }
 }
 
-/**
- * Tests the SHAPE_POLY_SET::FilletPolygon, which has been refactored into
- * SHAPE_POLY_SET from CPolyLine::Fillet.
- * Assuming the code in CPolyLine is right, this test ensures the behaviour of the new
- * refactored code does not change anything.
- */
-BOOST_AUTO_TEST_CASE( Fillet )
-{
-SHAPE_POLY_SET::POLYGON actual;
-CPolyLine expected;
-
-// Test different radius, up to the half of the minimum segment longitude
-for (int radius = 1; radius < 5; radius++)
-{
-// Test different number of segments
-for (size_t segments = 1; segments < 100; segments++)
-{
-// Chamfered polygon to be tested.
-actual = common.holeyPolySet.FilletPolygon( radius, segments, 0 );
-
-// Chamfered polygon assumed to be right.
-expected = *legacyPolyLine.Fillet( radius, segments );
-
-// Double check that there are no repeated corners in the legacy shape.
-expected.RemoveNullSegments();
-
-// Test equality
-for (size_t contourIdx = 0; contourIdx < actual.size(); contourIdx++)
-{
-TestLineChainEqualCPolyLine(actual[contourIdx], expected, contourIdx);
-}
-}
-}
-}
-
-
 BOOST_AUTO_TEST_SUITE_END()
-- 
2.17.1

___
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] Update doxygen logo

[John Beard]

Hi,

Eagle-eyed (is that an offensive slur on a KiCad list?) Nick noticed
that the doxygen header logo is actually slightly incorrect.
Presumably I used the wrong file for a source, not sure where it came
from!

Attached are the two versions: spot the difference!

Cheers,

John
From e761d36462181a706dca187920e36cea58101d39 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Sun, 5 Aug 2018 13:10:30 +0100
Subject: [PATCH] Docs: update doxygen docs logo

The logo used was subtly different to the official KiCad
logo - different font weight and corner rounds.
---
 Documentation/kicad_doxygen_logo.png | Bin 8907 -> 1512 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/Documentation/kicad_doxygen_logo.png b/Documentation/kicad_doxygen_logo.png
index 84bd84ff931a22a05ebd908e57a9ab2689da85de..68f058a7ef1a91daa6c8e582fc0c983f55f75d52 100644
GIT binary patch
delta 1494
zcmV;{1u6Q=Md%BVB!2{RLP=Bz2nYy#2xN!=000SaNLh0L01m_e01m_fl`9S#P
zbVXQnQ*UN;cVTj60C#tHE@^ISb7Ns}WiD@WXPfRk8UO$VWl2OqRA_@GyX>3zXYJ=6(ST$|5UeOk?8h;5b#R5@l(%4w3_Q@Ip
zPg;v0D#<)5BLEDWuy{6@#^_C7~P9}P<#!*=uzYX#adE@T2|dL6%x|7
zmQpB1pfKq%(0_?2BEXJ*=V>Y2=uj&*TIIl+w1w*wt1A#7uoFmC9SxtCx(%d9ttpg3
ze}DpjyqGq^fC2zaGdhqL(>4-u6ebF#=+W}AE~W?qfT+afnh$hhB1nlG5L!JSI}1?(
z%hA(*5uOf_Sd}JKl#(u2lyLsvcSRFWqH5=#U;wTRWPf8o4q=vC!y7v;EB%8`)$#*7GRSK$
zB?{Ydx)dBa*+kEN(@NdnzPB#H-))h2C;BWhLT&*7>IYL%-MtzXo0;1l6YS`zM!J0I
zGbF@cbFGvG1psl;>~M0+;Z(4*^k@2OLpSv-YZx+PM|+8|4Noyg-Dh>6wWD9y
zz}1GHaf5NoJbOA8XYiANqEPHVd|egF7jfM*6%Y1wF$P+E{7N$N>!RG*$~
zqL+TWrzsR50JGU-VTU%GtonWP8Z$8`MR4n$zkk$8PoHbi910MC$%?p7g^st$SrAP&
zu1?{)%F_H0<;Q;01q#q1-N!}+<6vPH;e}vt-!O_Qt||_vqILJ9VrIq1k-3!G9?3|JcQ_X=-=(#6Z9-2-gy74HTuJm#%6qd;>9eYz05q9n32~t)+nq^xncdR-
z5M`g$dlg;^rTD7$PoF~3XRyFP11gFaNnxP@Oq?p3hHlbv3r^7nAVEf)pCv)ep
z*DI$>LD47Il&&7zgxa;))z?RF?A)dUlOnl>|rF;hKA9SMhXua_Cv~OEFNt_ktYj<8tlR5Uw&2C!rEq{j*5@f{3
z?`KLz!F8Ti(yWK6cKAfuggBy|(At>9ENv4MfYJb`F_7yG|8nb^0u89#tA1Z%3J?bq?IX)V{e*3uYtNyoOW77(O9TXeKQ=iYk3A9zV|_1
zQY1yG^z@$pELO3}n+*_%I1PX_`+xrXnE{2%fHxS^POL+ef~W^osIYV
z{TK4w5gqo!9?}s`W2h@X_0{;Qba66bi_si>P2-yL
zMEkhtmh0}geSc0zi+uFk7k+v_eYnSJD8Bi52PNvu9bZBV%P>YhOhzqeMBdxt?sMCH
z-gK2GFUOhQaWjqLPhaM{gMah}gy3X199xK}A6>*xOk<)k1VnEz^#Wdac-Y@eZ
zZ+_$tS;z>c8|F#}yB*IhMsh!LE8KAooR@4g_9+cl*6Rj@h-W7n;{qdKvkS>(XN
zIpSCupH9nth<-2vE+xO5IgCvRnZc=E&*qxq?zuks=P=O1KqQK$Ff=W61}nxy{*+kB
zp`JpDCZ&{9Nj0_9bI38LoO8*-s9r*eC6!!Csil=(Lya}nTuZIB)!uvyKv-(I71L^K
zt#=;Uxpn92J3jXcVzqm4dEpBZPGd6rpcn|=8e7UjS4DrVKyR^M)uN;~ef
z^DevYw)-L1PB`(TlTSJIwA0^5?KP^ON6md1x!;ePdySe#EZ+0Vk5S`rDQ~xMf|H~%
zW5j%PjCj!qkkDRZW~+#-8z=1AeeL3;zy4`{^}%w>kLVXY
z>nD^m!d_!;V9brPOQLrKe)m|q>nC-y{F$Nk5>rp9O`_W4YHkov=Q8DJ!N#>+%!PZ*
z6V@K}z*(~fY8w@wXaj@=pIl)B$1FW0tj=z*aO^x{AyHc3V6%+iiJ1dr
zYE1mGZ7`lNrUI_z5yPPX*McKb;&+}0Fzcq&1aVw-hggRd2Ik0p=<_@-ol5_WODkoD
zqt6i;tFS;HOV+so1!a#j`bXgrkv6
zJB-&+y5n*WYZ=>jhRM=sXSMrrTs(u3IGa{J2k#+jdg(id8H7IJun$+7KfKf(l7m>y
zK+j9~(KtR;^Oh++eAnc#`v`WlN`g@`Co|f_N1u{whtY}8LC)6UY07=Fj?-OWCs^ub
z&9f(s>G|HcZha@D^*PM>`ap;IU59%%L8Tr@oEd*Pfc6JN0w_zwhZ=r=C6;3ND{G
zhpy*rDzUUS#vCN}ah1{pG?s7K0a$UZ+QFO^INGB)d`)t-t#OA+WggF4^2
zY-%r0Qps_5GMHRTs}q@-fj{4+XHqWY-8eCry&>@kmG?c3ve$|aq>!xKoAxF!
z4iU9Br9#J-zazN#FV_@HG0van^73=kwT81Jt5UYj8L}$?PxhWZZ341^*F%s>2|JX*
z$kH8Zn5NHWjvo`e8Y8qt6Hny>mZkP98++MCiU*t(r-l-wQzu@RFKof!QR
zu>yJK7VHc@_2GzR%wYiU1KI#pGE_jMMznoys+Lh^ERLRcHll>;x0MDn4k!1M1DH1u
zDh$i28KHlsgIj23ISu3*)%RH;JVC^033x(Su9n6$fZjr$miP0Pi=<$;yFhTq17J|H
z+YyS`mTaO2q_?Gcq~hzUdc1i~OpPI8w4u>^|L<;JxQUw^Dto(Yc%4UWRRflMdc3uN
z)PT1$-&gT(N_=#4>6O2kF;`U5ry(v@SpjNDF8a<9CM`GVPG=
zD(-Z<_aRXCY46OlEVYF)qtZy15$h5kr!+c$Wr;1sG?K3P
z-V-*jV5SKib|E4D!gf?Ya8}WKNHlU>?LFJ~f$mQfc@eZVXd9B}6g^yIfL7cdc=L1Z!~Sq$fep=$-{@1JeO4TNy-x~dxv9Q
zJqMNFzS7v=4ZoeyW`I-Y0WAsT2*G%AV`wMc+A
z`kfNZ)?+XVRabd1*5UwqB{#dO@v6(*byF&{L~<`%R0NTlMB#8;WXqW#lFcr
z=nvOaWID^@QOVRg(T)As4MlboC%UsXnvV6r#uUh;F>di77gCYTrb?xG`=W&_2Egi+
z)SiTN(t$!AGzkiux@{YZDp{xq;e!JVq0{^Vuu7-Pgqo1&8!NM~+(6cFU$kY|2?w)O
z;b%+CXV~^C6JT>o3y^jl?K99Ad%1$L06+%XSsq{+!b{Sk5;C$~xsV#8n16%r
zn^ziFYS9^N0D-3Qtw7Jvc#JqZ%mYQcvW|t{|Wv~X9(9e6$`zffl=ajb-+6L$x
zlAI(U(HXv|}9V
zsJeNlgJ_*!P(T8cO1H`E0kl^V`tYP4kx-@J0QIRbfU+ku+#*Ahw0n`tgd=`yWvb-lPlpr>fx|l-BaW#{UW+Hcav}y750Ukgib{W_V
zP(+|t(n6R7n#cHv?3s9a%4oKp9~K##0@QEV=?eCzqg+E0k#tNT;{}?#>%k
zSS5C`peqtoy!l2%4MQOkH4u|$(0oU^C87?RU<)zwDEWNAzD@RqkyQDGzibuO41BC#
zjLJBMvd0y8Ts>_F65|C8M-E@bfRTt6TW<21iX~9tMnYD2{0p1YVn2?pvMoF;nCD0
z2a3{mWbS$D7%t*w1sR>R$VH>AldrU5W2{u6?e&*SR@02e$I#IMB?f%8|UzCYjcf
zN)p~L8x6e6{o^g%Rsrud9s?!BJ@=~DHS(9PJgtkb%lPwk5k-4+4MxXFlU*SeIvCcb
zS3|-^5WpqP^OGb28{&3K_I5JG`iTqf!fE10`QV6B@gNT_
zOp*+4bgt(JWKeY*@8CxTk6^RyY`jL!^FNA3lVed%j`DGtes{bbXoENa0p%?qcW5?q
zN}1%UKgOfZ@xc-GFAYghedG$w@T92ed(xS)E9;8Zo{{Njo(cjc{6fbGgWBFYBM*x(
z>YG9%e6~+eb=u>GX(`2!IQ0hv%`S~WT%)*KFQP4kpzx8F`X@ss{kM)1sxpH9+mCt}usB*4l^|2!X?x6i5c
zdj@xSowF_KVEVZrl$rf{vfI1ytw}J-*I)aDpFjO%6haPnIuO=H9*_K{k#@!Is6DmZ

Re: [Kicad-developers] [PATCH] Add Insert hotkey to add a zone/segment corner

[John Beard]

Hi Seth,

Sorry about that, I think I've checked the right thing here.

I suppose many global TOOL_ACTIONs are actually unsafe to call from a
global context but are defended implicitly by not providing a hotkey
or menu item when the action isn't ready to get called.

Cheers,

John

On Wed, Aug 1, 2018 at 6:23 PM, Seth Hillbrand  wrote:
> Hi John-
>
> I get a segfault when trying to use the hotkey to insert a point on a zone
> when it is not selected.
>
> -Seth
>
>
> Am Di., 24. Juli 2018 um 10:00 Uhr schrieb John Beard
> :
>>
>> This patch adds a hotkey for adding a corner to a zone or segment.
>> This is an action I have really struggled without a hotkey for! I have
>> used Insert, as:
>>
>> 1) it's available and
>> 2) it's what Inkscape uses (but Inkscape adds the point at the
>> midpoint of the segment, this adds at the cursor).
>>
>> It doesn't work on polygons, as that is still unimplemented in the
>> underlying action.
>>
>> 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
From 3dea08d584e56e2fa65a01844aa4a425557704ff Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Tue, 24 Jul 2018 16:15:05 +0100
Subject: [PATCH] Add hotkey (Insert) for zone create corner

Adds a hotkey to the TOOL_ACTION, and also checks for
action validity prior to running the actions (previously
implicitly gated by  the enablement of the menu item).
---
 pcbnew/hotkeys.cpp|  6 ++
 pcbnew/hotkeys.h  |  3 ++-
 pcbnew/tools/point_editor.cpp | 28 ++--
 pcbnew/tools/point_editor.h   |  3 +++
 4 files changed, 33 insertions(+), 7 deletions(-)

diff --git a/pcbnew/hotkeys.cpp b/pcbnew/hotkeys.cpp
index 25a93e694..32fcc3192 100644
--- a/pcbnew/hotkeys.cpp
+++ b/pcbnew/hotkeys.cpp
@@ -310,6 +310,9 @@ static EDA_HOTKEY HkToggleCursor( _HKI( "Toggle Cursor Display (Modern Toolset o
 static EDA_HOTKEY HkMeasureTool( _HKI( "Measure Distance (Modern Toolset only)" ),
  HK_MEASURE_TOOL, 'M' + GR_KB_SHIFTCTRL );
 
+static EDA_HOTKEY HkInsertCorner( _HKI( "Insert Corner (Modern Toolset only)" ),
+ HK_INSERT_CORNER, WXK_INSERT );
+
 // List of common hotkey descriptors
 EDA_HOTKEY* common_Hotkey_List[] =
 {
@@ -384,6 +387,9 @@ EDA_HOTKEY* board_edit_Hotkey_List[] =
 ,
 ,
 
+// Point editor (zones and segments)
+,
+
 // Highlight and display
 ,
 ,
diff --git a/pcbnew/hotkeys.h b/pcbnew/hotkeys.h
index f4e6fa446..b22817675 100644
--- a/pcbnew/hotkeys.h
+++ b/pcbnew/hotkeys.h
@@ -133,7 +133,8 @@ enum hotkey_id_commnand {
 HK_DP_DIMENSIONS,
 HK_VIA_SIZE_INC,
 HK_VIA_SIZE_DEC,
-HK_HIGHLIGHT_NET_SELECTION
+HK_HIGHLIGHT_NET_SELECTION,
+HK_INSERT_CORNER
 };
 
 // Full list of hotkey descriptors for board editor and footprint editor
diff --git a/pcbnew/tools/point_editor.cpp b/pcbnew/tools/point_editor.cpp
index 9d994479e..8fcc3f420 100644
--- a/pcbnew/tools/point_editor.cpp
+++ b/pcbnew/tools/point_editor.cpp
@@ -50,7 +50,7 @@ using namespace std::placeholders;
 
 // Point editor
 TOOL_ACTION PCB_ACTIONS::pointEditorAddCorner( "pcbnew.PointEditor.addCorner",
-AS_GLOBAL, 0,
+AS_GLOBAL, WXK_INSERT,
 _( "Create Corner" ), _( "Create a corner" ), add_corner_xpm );
 
 TOOL_ACTION PCB_ACTIONS::pointEditorRemoveCorner( "pcbnew.PointEditor.removeCorner",
@@ -850,17 +850,25 @@ void POINT_EDITOR::setTransitions()
 }
 
 
+bool POINT_EDITOR::canAddCorner( const EDA_ITEM& aItem )
+{
+const auto type = aItem.Type();
+
+// Works only for zones and line segments
+return type == PCB_ZONE_AREA_T ||
+   ( ( type == PCB_LINE_T || type == PCB_MODULE_EDGE_T ) &&
+   static_cast( aItem ).GetShape() == S_SEGMENT );
+}
+
+
 bool POINT_EDITOR::addCornerCondition( const SELECTION& aSelection )
 {
 if( aSelection.Size() != 1 )
 return false;
 
-auto item = aSelection.Front();
+const EDA_ITEM* item = aSelection.Front();
 
-// Works only for zones and line segments
-return item->Type() == PCB_ZONE_AREA_T ||
-   ( ( item->Type() == PCB_LINE_T || item->Type() == PCB_MODULE_EDGE_T ) &&
-   static_cast( item )->GetShape() == S_SEGMENT );
+return ( item != nullptr ) && canAddCorner( *item );
 }
 
 
@@ -916,9 +924,17 @@ bool POINT_EDITOR::removeCornerCondition( const SELECTION& )
 
 int POINT_EDITOR::addCorner( const TOOL_EVENT& aEvent )
 {
+if( !m_editPoints )
+return 0;
+
 EDA_ITEM* 

Re: [Kicad-developers] "Make Gerbers and drills zip"

[John Beard]

I was working on a program to do this (over the Python API) because I
wanted to be able to drive deliverable generation from a makefile.

Code is here: https://github.com/johnbeard/kiplot

An example plot config (generates nearly all the possible outputs all
at once) is here:
https://github.com/johnbeard/kiplot/blob/master/docs/samples/generic_plot.kiplot.yaml

I got distracted by real life, but it's at least somewhat functional.

Interestingly, it can also be used to generate plots and run QA tests
on them (e.g. ensure Gerbers are sane, etc).

Cheers,

John

On Tue, Jul 31, 2018 at 5:25 PM, Jon Evans  wrote:
> It would be nice if this were more formally supported instead of just being
> a thing that people figure out how to do :)  Python scripting is certainly
> one way.
> Altium has this capability -- they don't use a real script like Python, but
> more of a configuration file.
> But the key point is that it is often different for each project, so you
> want a nice way to take each script and customize it for the given PCB
> project, and then check it in with version control alongside the other
> design files.
> For example, you might have a "standard" output generation script, but then
> for a certain design you tweak it to turn off certain layers or to name the
> files a certain way.
>
> On Tue, Jul 31, 2018 at 12:23 PM Adam Wolf 
> wrote:
>>
>> I actually worked with the OSHPark folks to do this for KiCad back in
>> the V4 days so they could accept .kicad_pcb files.
>> On Tue, Jul 31, 2018 at 11:20 AM jp charras  wrote:
>> >
>> > Le 31/07/2018 à 16:52, Jon Evans a écrit :
>> > > It would be nice to have a fully-scriptable "output job" system so
>> > > that you can save all the Gerber
>> > > generation settings, all the drill generation settings, etc together,
>> > > and set up a workflow of
>> > > generating files, naming them a certain way, packaging them in a ZIP,
>> > > etc.
>> >
>> > It could be made by a Python script.
>> > Attached a basic python script to create gerber and drill files from a
>> > board file.
>> >
>> > Some latest options (creating a job file or a drill file in gerber
>> > format) are not available for
>> > python scripts, but it should be easy (famous words) to add them to the
>> > Python scripting stuff.
>> >
>> > >
>> > > On Tue, Jul 31, 2018 at 10:24 AM Ben Hest > > > > wrote:
>> > >
>> > > I'd give that a thumbs up from as a single user's opinion.
>> > >
>> > > On Tue, Jul 31, 2018 at 8:58 AM Adam Wolf
>> > > > > > > wrote:
>> > >
>> > > 100% percent of the time when I make drill files, I also want
>> > > to make
>> > > gerbers, and I want a zip file for uploading as well.
>> > >
>> > > Is there any interest in adding some way to do this
>> > > automatically?  It
>> > > may be a little tricky since drills and Gerbers are two
>> > > different
>> > > windows, but if this is considered a bad idea I will just stop
>> > > thinking about it now.
>> > >
>> > > Adam
>> >
>> > --
>> > Jean-Pierre CHARRAS
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > Post to : kicad-developers@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > More help   : https://help.launchpad.net/ListHelp
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

Re: [Kicad-developers] wxFormBuilder documentation

[John Beard]

On Tue, Jul 31, 2018 at 4:51 PM, Seth Hillbrand  wrote:
> wxFormBuilder isn't perfect but it solves many of
> the tedious issues.

I find wxFB to be much more tedious than code.

If dialog code *is* unbearably tedious, IMO that means there is not
enough abstraction, and too much repetitive UI is being expressed
directly in terms of "raw" UI widgets, rather than at a more
"semantic" level. This is a natural consequence when using a form
builder, where anything not made of a simple primitive widgets or
subclass is impossible without a blank placeholder. Even special
subclasses (say the pin type drop down) are not actually usefully
expressed in wxFB, you just see a dummy lookalike.

A good example: DC sweep sources 1 and 2 in dialog_sim_settings_base:
total duplication of a entire panel of 13 widgets and a sub-sizer.
Within that panel, three instances of identical "voltage" inputs,
which are manually arranged triplets of {title, control, unit label},
all with identical manually set flags and so on. These triplets are
also used in the Transient and AC panels in the same dialog. The
tedious nature of these dialogs, in both code and wxFB, is a sign that
there is redundant UI here. wxFB may make the tedium more bearable
(I'd argue it doesn't), but doesn't help fix the root cause.

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] wxFormBuilder documentation

[John Beard]

Hi,

According to the Kicad UI Guidelines [1]:

"KiCad's dialogs must be designed with wxFormBuilder. 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 to avoid
version mismatch."

>From Wayne's email of the 7th Feb 2017, "After the next stable
release, we should not be using wxFormbuilder for new code."

I propose that the requirement is removed from the Development
documentation and replaced with something that says something like:

* wxFB is used for existing wxFB dialogs
* It is {required|permitted|recommended} to not use it for new dialogs
* It is permitted to convert wxFB dialogs (carefully and tidily!) to
normal dialogs
* Existing generated wxFB code should not be manually changed, unless
the dialog is converted to no longer use wxFB at all, and the wxFB
files removed.

Or whatever is current policy, if that's incorrect.

Furthermore, we should also move towards a more complete and
consistent set of re-usable UI widgets. Particularly the margins/sizer
stuff which is currently hardcoded all the place in wxFB files. These
should also be described in the developer documentation.

Cheers,

John

[1]: 
http://docs.kicad-pcb.org/doxygen/md_Documentation_development_ui-policy.html#dialogs

___
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] Rename lang_catalan and lang_chinese SVGs

[John Beard]

Flag icons are also (ab)used in the About dialog for the translator
credits. According to `git grep "lang_.*_xpm`, that's the only other
use.

As expected, I don't see them in the menu on Arch Linux, but I do have
other menu icons.

Cheers,

John

On Tue, Jul 31, 2018 at 12:24 PM, jp charras  wrote:
> Le 31/07/2018 à 13:16, Jeff Young a écrit :
>> I don’t see the flag icons in my languages menu (OSX).  Is this 
>> platform-specific?
>>
>
> wxMenuItems with type = wxITEM_CHECK do not display icons on all platforms or 
> window managers.
>
> They are displayed on Windows, and not on my Linux Ubuntu / KDE install.
> (On my Linux Ubuntu / Unity install, icons in menus are never displayed.)
>
>>
>>
>>> On 31 Jul 2018, at 08:35, Iñigo >> > wrote:
>>>
>>> There are some issues there.
>>> There is Spanish and Castilian. Castilian is the Spanish spoken in Spain, 
>>> and is the actual
>>> Spanish used in KiCad. So, technically, the KiCad language menu should show 
>>> Castilian as an option
>>> and not Spanish.
>>>
>>> Iñigo.
>
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Op-amp symbol icons

[John Beard]

Hi,

Here are 6a and 6b options, including the DeMorgan icons.

Cheers,

John

On Thu, Jul 26, 2018 at 5:40 PM, Jeff Young  wrote:
> I actually agree that 6a looks better on it’s own, but 6b matches the 
> DeMorgan icons better.
>
> (Of course we could always update those to match the opamp….)
>
> Cheers,
> Jeff.
>
>> On 26 Jul 2018, at 17:37, Wayne Stambaugh  wrote:
>>
>> Maybe it's my old eyes but 6a looks better to me.  6b seems a bit
>> crowded with the additional line thickness.  I can live with it either way.
>>
>> On 7/26/2018 5:26 AM, Jeff Young wrote:
>>> 6B is my new fave.
>>>

>>>
>>>
>>>
>>> ___
>>> 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] [RFC] Op-amp symbol icons

[John Beard]

While we're at it, new_cvpcb looks like it's also unused: it's built
and listed in bitmaps.h, but nothing ever uses it.

Cheers,

John

On Sat, Jul 28, 2018 at 11:28 PM, Jeff Young  wrote:
> No, looks like I just missed deleting it.
>
>> On 28 Jul 2018, at 23:01, John Beard  wrote:
>>
>> Hi Jeff,
>>
>> Thanks for the heads up, makes life easier with fewer icons!
>>
>> Looks like bitmaps_png/sources/edit_component.svg still exists,
>> though. Is that intentional?
>>
>> Cheers,
>>
>> John
>>
>> On Fri, Jul 27, 2018 at 11:39 AM, Jeff Young  wrote:
>>> Hi John,
>>>
>>> Just an update on the opamp icon list.  These icons:
>>>
>>> copycomponent.svg
>>> edit_component.svg
>>> edit_part.svg
>>> import_cmp_from_lib.svg
>>> save_part.svg
>>> save_part_in_mem.svg
>>>
>>>
>>> no longer exist.
>>>
>>> Cheers,
>>> Jeff.
>>>
>>>
>>> On 26 Jul 2018, at 09:33, Jeff Young  wrote:
>>>
>>> Hi John,
>>>
>>> Most other icons use a heavier pen width (see the DeMorgan symbols, pin
>>> graphics, etc.), which would favour the B column.
>>>
>>> I like the wider stance of the input pins in row 4.
>>>
>>> BTW, the new black-and-white 16x16 icons for the dialog buttons also suffer
>>> from slight blurryness.  I don’t know if they’re worth fixing or not, but if
>>> you’re so inclined….
>>>
>>> Cheers,
>>> Jeff.
>>>
>>>
>>> On 25 Jul 2018, at 15:05, John Beard  wrote:
>>>
>>> Hi,
>>>
>>> The pixel alignment of the op-amp icons looks a bit fuzzy compared to
>>> the other newer icons. These are not the only misaligned icons, but
>>> they are a very prominent set of them.
>>>
>>> The problem is that both:
>>>
>>> 1) The lines are not on the pixel grid
>>> 2) The lines are not a whole number of pixels wide.
>>>
>>> If this *were* to be changed so horizontal lines are sharp, the icons
>>> have to be modified. However, going up to 2px or down to 1px line
>>> width changes the feel a bit.
>>>
>>> Attached are some options (for the full size op-amp icons at 26px). If
>>> a consensus or executive decision ever emerges, I will produce a patch
>>> for the op-amp icons in that style.
>>>
>>> Personally, my "vote" is 2A, or 5A for icons where the symbol is
>>> smaller, like "copycomponent".
>>>
>>> List of icons affected for reference:
>>>
>>> add_component.svg
>>> copycomponent.svg
>>> edit_cmp_symb_links.svg
>>> edit_comp_footprint.svg
>>> edit_comp_ref.svg
>>> edit_comp_value.svg
>>> edit_component.svg
>>> edit_part.svg
>>> export_part.svg
>>> field_properties.svg
>>> hidden_pin.svg
>>> icon_libedit.svg
>>> import_cmp_from_lib.svg
>>> import_part.svg
>>> libedit.svg
>>> new_component.svg
>>> new_cvpcb.svg
>>> part_properties.svg
>>> save_part.svg
>>> save_part_in_mem.svg
>>>
>>> Yours, bike-sheddingly,
>>>
>>> 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
>>>
>>>
>>>
>

___
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] MacOS build issue with new geometry tests

[John Beard]

Hi Adam,

Sorry, this in my stuff - I though that was a way to get PI without
having to guess the setting of _USE_MATH_DEFINES or do #ifdefs like at
the top of dl_codes.h, but obviously not.

The attached patch might work, but I can't test on a Mac, so all I can
say is "it builds for me and the tests pass". Specifically,
_USE_MATH_DEFINES may need to be set for qa_geometry if not already.

Cheers,

John


On Sun, Jul 29, 2018 at 1:38 PM, Adam Wolf
 wrote:
> Hi folks!
>
> There's a build failure on the new geometry test stuff with MacOS.
>
> qa/geometry/geom_test_utils.h:33:18: error: constexpr variable 'PI'
> must be initialized by a constant expression
> constexpr double PI = atan(1.0) * 4.0;
> ^ ~~~
> qa/geometry/geom_test_utils.h:33:23: note: non-constexpr function
> 'atan' cannot be used in a constant expression
> constexpr double PI = atan(1.0) * 4.0;
>
> There are a few others, all which look about the same.  I am on my way
> out of town today so I don't have time to look for a solution, but a
> user actually reported it to me due to using the new MacOS build
> scripts! :D
>
> Adam Wolf
>
> ___
> 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 28d23f2c73a7f824ddb3474e46ea79071fe075a9 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Sun, 29 Jul 2018 16:29:02 +0100
Subject: [PATCH] Use M_PI for Pi, not constexpr calculation

Constexpr evaluation breaks Clang compilation.

Use math.h M_PI, as elsewhere.
---
 qa/geometry/geom_test_utils.h | 11 +--
 qa/geometry/test_fillet.cpp   |  3 ++-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/qa/geometry/geom_test_utils.h b/qa/geometry/geom_test_utils.h
index cb4e9721f..d598a24df 100644
--- a/qa/geometry/geom_test_utils.h
+++ b/qa/geometry/geom_test_utils.h
@@ -24,15 +24,14 @@
 #ifndef GEOM_TEST_UTILS_H
 #define GEOM_TEST_UTILS_H
 
+#include 
+
 /**
  * @brief Utility functions for testing geometry functions.
  */
 namespace GEOM_TEST
 {
 
-constexpr double PI = atan(1.0) * 4.0;
-constexpr double PI_2 = atan(1.0) * 2.0;
-
 /**
  * @brief Check if a value is within a tolerance of a nominal value
  *
@@ -159,12 +158,12 @@ bool ArePerpendicular( const VECTOR2& a, const VECTOR2& b, double aToleran
 auto angle = std::abs( a.Angle() - b.Angle() );
 
 // Normalise: angles of 3*pi/2 are also perpendicular
-if (angle > PI)
+if (angle > M_PI)
 {
-angle -= PI;
+angle -= M_PI;
 }
 
-return IsWithin( angle, PI_2, aTolerance );
+return IsWithin( angle, M_PI / 2.0, aTolerance );
 }
 
 /**
diff --git a/qa/geometry/test_fillet.cpp b/qa/geometry/test_fillet.cpp
index 10a7fe725..c7d758ec6 100644
--- a/qa/geometry/test_fillet.cpp
+++ b/qa/geometry/test_fillet.cpp
@@ -68,8 +68,9 @@ void TestFilletSegmentConstraints( const SEG& aSeg, VECTOR2I aRadCentre,
 ( diffC.EuclideanNorm() )( aRadius )( aError + 1 ) );
 
 // Check 3: Mid-point -> radius centre perpendicular
+const auto perpendularityMaxError = ( M_PI / 2 ) / 10;
 BOOST_CHECK_PREDICATE( ArePerpendicular,
-( diffC )( aSeg.A - aSeg.B )( PI_2 / 10 ) );
+( diffC )( aSeg.A - aSeg.B )( perpendularityMaxError ) );
 }
 
 
-- 
2.17.1

___
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] Op-amp symbol icons

[John Beard]

Hi Jeff,

Thanks for the heads up, makes life easier with fewer icons!

Looks like bitmaps_png/sources/edit_component.svg still exists,
though. Is that intentional?

Cheers,

John

On Fri, Jul 27, 2018 at 11:39 AM, Jeff Young  wrote:
> Hi John,
>
> Just an update on the opamp icon list.  These icons:
>
> copycomponent.svg
> edit_component.svg
> edit_part.svg
> import_cmp_from_lib.svg
> save_part.svg
> save_part_in_mem.svg
>
>
> no longer exist.
>
> Cheers,
> Jeff.
>
>
> On 26 Jul 2018, at 09:33, Jeff Young  wrote:
>
> Hi John,
>
> Most other icons use a heavier pen width (see the DeMorgan symbols, pin
> graphics, etc.), which would favour the B column.
>
> I like the wider stance of the input pins in row 4.
>
> BTW, the new black-and-white 16x16 icons for the dialog buttons also suffer
> from slight blurryness.  I don’t know if they’re worth fixing or not, but if
> you’re so inclined….
>
> Cheers,
> Jeff.
>
>
> On 25 Jul 2018, at 15:05, John Beard  wrote:
>
> Hi,
>
> The pixel alignment of the op-amp icons looks a bit fuzzy compared to
> the other newer icons. These are not the only misaligned icons, but
> they are a very prominent set of them.
>
> The problem is that both:
>
> 1) The lines are not on the pixel grid
> 2) The lines are not a whole number of pixels wide.
>
> If this *were* to be changed so horizontal lines are sharp, the icons
> have to be modified. However, going up to 2px or down to 1px line
> width changes the feel a bit.
>
> Attached are some options (for the full size op-amp icons at 26px). If
> a consensus or executive decision ever emerges, I will produce a patch
> for the op-amp icons in that style.
>
> Personally, my "vote" is 2A, or 5A for icons where the symbol is
> smaller, like "copycomponent".
>
> List of icons affected for reference:
>
> add_component.svg
> copycomponent.svg
> edit_cmp_symb_links.svg
> edit_comp_footprint.svg
> edit_comp_ref.svg
> edit_comp_value.svg
> edit_component.svg
> edit_part.svg
> export_part.svg
> field_properties.svg
> hidden_pin.svg
> icon_libedit.svg
> import_cmp_from_lib.svg
> import_part.svg
> libedit.svg
> new_component.svg
> new_cvpcb.svg
> part_properties.svg
> save_part.svg
> save_part_in_mem.svg
>
> Yours, bike-sheddingly,
>
> 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
>
>
>

___
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] Board setup icon

[John Beard]

Hi Andrey,

I am inclined to agree, but the priority for me is to get *an* icon
there what doesn't overload an exciting metaphor, and wire it in to
the relevant places in the code. The icon can be further modified.

With respect to the options icons, you could do something like the
attached? Having a more distinct outline (i.e. not just a square) is
good.

I am also happy to take other people's SVGs and generate patches!

Cheers,

John

On Tue, Jul 24, 2018 at 8:59 PM, Andrey Kuznetsov  wrote:
> John, I don't think the gear icon stands out very much and results in a
> complex jumble image that's hard to interpret easily.
>
> On Tue, Jul 24, 2018 at 4:35 AM, John Beard  wrote:
>>
>> Hi,
>>
>> Here is a new icon for the board setup toolbar and menu item. The
>> generic gear icon is no clear, as it looks like "Preferences" rather
>> than board setup.
>>
>> PNG included for reference only.
>>
>> 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
>>
>
>
>
> --
> Remember The Past, Live The Present, Change The Future
> Those who look only to the past or the present are certain to miss the
> future [JFK]
>
> kandre...@gmail.com
> Live Long and Prosper,
> Andrey
___
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] -Wcatch-value in kicad2step.cpp

[John Beard]

Hi,

Another -Wcatch-value warning, this time in kicad2step.cpp.

Cheers,

John
From 7f1b0be567101647a31f1b4cc69c0d05cf441d40 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Thu, 26 Jul 2018 13:37:44 +0100
Subject: [PATCH] Fix -Wcatch-value in kicad2step.cpp

---
 utils/kicad2step/kicad2step.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utils/kicad2step/kicad2step.cpp b/utils/kicad2step/kicad2step.cpp
index 51d0eb57e..9574d43eb 100644
--- a/utils/kicad2step/kicad2step.cpp
+++ b/utils/kicad2step/kicad2step.cpp
@@ -296,7 +296,7 @@ int KICAD2MCAD::OnRun()
 if( !res )
 return -1;
 }
-catch( Standard_Failure e )
+catch( const Standard_Failure& e )
 {
 e.Print( std::cerr );
 return -1;
-- 
2.17.1

___
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] Rename lang_catalan and lang_chinese SVGs

[John Beard]

Hi,

The SVGs for Catalan and Chinese did not match the XPM constant names,
so there were linking errors.

I'm not sure how this hasn't been causing breakages since 7841f8a466,
but presumably it only breaks if you have MAINTAIN_PNGs on *and* clean
something in a way most people don't, as the old CPPs persist.

Cheers,

John
From 2a6103b313ae567377dc20f9ea9fa6bbf004535c Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Thu, 26 Jul 2018 15:43:31 +0100
Subject: [PATCH] Update CA and ZH source svg filename

These were updated in 7841f8a466, but the source
files seem to have not been changed.
---
 bitmaps_png/CMakeLists.txt| 4 ++--
 bitmaps_png/cpp_26/{lang_catalan.cpp => lang_ca.cpp}  | 0
 bitmaps_png/cpp_26/{lang_chinese.cpp => lang_zh.cpp}  | 0
 bitmaps_png/sources/{lang_catalan.svg => lang_ca.svg} | 0
 bitmaps_png/sources/{lang_chinese.svg => lang_zh.svg} | 0
 5 files changed, 2 insertions(+), 2 deletions(-)
 rename bitmaps_png/cpp_26/{lang_catalan.cpp => lang_ca.cpp} (100%)
 rename bitmaps_png/cpp_26/{lang_chinese.cpp => lang_zh.cpp} (100%)
 rename bitmaps_png/sources/{lang_catalan.svg => lang_ca.svg} (100%)
 rename bitmaps_png/sources/{lang_chinese.svg => lang_zh.svg} (100%)

diff --git a/bitmaps_png/CMakeLists.txt b/bitmaps_png/CMakeLists.txt
index 91b21d43f..6778a00a7 100644
--- a/bitmaps_png/CMakeLists.txt
+++ b/bitmaps_png/CMakeLists.txt
@@ -314,8 +314,7 @@ set( BMAPS_MID
 label2glabel
 label2text
 label
-lang_catalan
-lang_chinese
+lang_ca
 lang_bg
 lang_cs
 lang_def
@@ -336,6 +335,7 @@ set( BMAPS_MID
 lang_sk
 lang_sl
 lang_lt
+lang_zh
 language
 layers_manager
 leave_sheet
diff --git a/bitmaps_png/cpp_26/lang_catalan.cpp b/bitmaps_png/cpp_26/lang_ca.cpp
similarity index 100%
rename from bitmaps_png/cpp_26/lang_catalan.cpp
rename to bitmaps_png/cpp_26/lang_ca.cpp
diff --git a/bitmaps_png/cpp_26/lang_chinese.cpp b/bitmaps_png/cpp_26/lang_zh.cpp
similarity index 100%
rename from bitmaps_png/cpp_26/lang_chinese.cpp
rename to bitmaps_png/cpp_26/lang_zh.cpp
diff --git a/bitmaps_png/sources/lang_catalan.svg b/bitmaps_png/sources/lang_ca.svg
similarity index 100%
rename from bitmaps_png/sources/lang_catalan.svg
rename to bitmaps_png/sources/lang_ca.svg
diff --git a/bitmaps_png/sources/lang_chinese.svg b/bitmaps_png/sources/lang_zh.svg
similarity index 100%
rename from bitmaps_png/sources/lang_chinese.svg
rename to bitmaps_png/sources/lang_zh.svg
-- 
2.17.1

___
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] Op-amp symbol icons

[John Beard]

OK, that is style 6.

Note that the opamp is a bit taller in 6B. This is because the versions
with the 2px output lead have the body 0.5px lower to keep alignment. The
alternative remedy is 6D, where the - is moved down 1px.

Cheers,

John

On Thu, Jul 26, 2018 at 9:58 AM, Andrey Kuznetsov 
wrote:

> Can you do B4 body and C2 or B2 +-? except make sure +- don't look like
> they're touching the body.
>
> On Thu, Jul 26, 2018 at 1:33 AM, Jeff Young  wrote:
>
>> Hi John,
>>
>> Most other icons use a heavier pen width (see the DeMorgan symbols, pin
>> graphics, etc.), which would favour the B column.
>>
>> I like the wider stance of the input pins in row 4.
>>
>> BTW, the new black-and-white 16x16 icons for the dialog buttons also
>> suffer from slight blurryness.  I don’t know if they’re worth fixing or
>> not, but if you’re so inclined….
>>
>> Cheers,
>> Jeff.
>>
>>
>> On 25 Jul 2018, at 15:05, John Beard  wrote:
>>
>> Hi,
>>
>> The pixel alignment of the op-amp icons looks a bit fuzzy compared to
>> the other newer icons. These are not the only misaligned icons, but
>> they are a very prominent set of them.
>>
>> The problem is that both:
>>
>> 1) The lines are not on the pixel grid
>> 2) The lines are not a whole number of pixels wide.
>>
>> If this *were* to be changed so horizontal lines are sharp, the icons
>> have to be modified. However, going up to 2px or down to 1px line
>> width changes the feel a bit.
>>
>> Attached are some options (for the full size op-amp icons at 26px). If
>> a consensus or executive decision ever emerges, I will produce a patch
>> for the op-amp icons in that style.
>>
>> Personally, my "vote" is 2A, or 5A for icons where the symbol is
>> smaller, like "copycomponent".
>>
>> List of icons affected for reference:
>>
>> add_component.svg
>> copycomponent.svg
>> edit_cmp_symb_links.svg
>> edit_comp_footprint.svg
>> edit_comp_ref.svg
>> edit_comp_value.svg
>> edit_component.svg
>> edit_part.svg
>> export_part.svg
>> field_properties.svg
>> hidden_pin.svg
>> icon_libedit.svg
>> import_cmp_from_lib.svg
>> import_part.svg
>> libedit.svg
>> new_component.svg
>> new_cvpcb.svg
>> part_properties.svg
>> save_part.svg
>> save_part_in_mem.svg
>>
>> Yours, bike-sheddingly,
>>
>> 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
>>
>>
>>
>> ___
>> 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
>>
>>
>
>
> --
> Remember The Past, Live The Present, Change The Future
> Those who look only to the past or the present are certain to miss the
> future [JFK]
>
> kandre...@gmail.com
> Live Long and Prosper,
> Andrey
>
___
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] Icon for "Update PCB from Schematic"

[John Beard]

Hi,

Another icon! (Groan)

This one is the update PCB from Schematic icon. Currently, this
re-uses the "Import PCB board file" icon from the file menu.

I think this is a bit non-obvious, because the action isn't an
"import", it's an update, and the icon makes no reference to the
schematic nature of the action.

I have used a metaphor of schematic -> PCB, with an left-to-right
arrow indicating forward action.

I considered the update double arrow/circle, but it's not really a
bidirectional action between PCB and Schematic. If that's preferred, I
will do it that way. I personally don't really care what the icon is,
as long as it's clearly distinguished in context from any other
action.

As usual, PNG is for reference.

Cheers,

John
From fa555f19ef8a115cca2365ea88da010f1202c541 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Wed, 25 Jul 2018 23:44:57 +0100
Subject: [PATCH] Add icon for update PCB from Schematic

This previously used the "import board file" icon, which is a bit
confusing, as the action is not importing into a PCB.
---
 bitmaps_png/CMakeLists.txt  |   1 +
 bitmaps_png/cpp_26/update_pcb_from_sch.cpp  |  60 ++
 bitmaps_png/sources/update_pcb_from_sch.svg | 939 
 eeschema/menubar.cpp|   2 +-
 include/bitmaps.h   |   1 +
 pcbnew/menubar_pcb_editor.cpp   |   2 +-
 pcbnew/tool_pcb_editor.cpp  |   2 +-
 7 files changed, 1004 insertions(+), 3 deletions(-)
 create mode 100644 bitmaps_png/cpp_26/update_pcb_from_sch.cpp
 create mode 100644 bitmaps_png/sources/update_pcb_from_sch.svg

diff --git a/bitmaps_png/CMakeLists.txt b/bitmaps_png/CMakeLists.txt
index 645a804f4..91b21d43f 100644
--- a/bitmaps_png/CMakeLists.txt
+++ b/bitmaps_png/CMakeLists.txt
@@ -569,6 +569,7 @@ set( BMAPS_MID
 up
 update_fields
 update_module_board
+update_pcb_from_sch
 use_3D_copper_thickness
 via
 via_buried
diff --git a/bitmaps_png/cpp_26/update_pcb_from_sch.cpp b/bitmaps_png/cpp_26/update_pcb_from_sch.cpp
new file mode 100644
index 0..d6e2dc0ef
--- /dev/null
+++ b/bitmaps_png/cpp_26/update_pcb_from_sch.cpp
@@ -0,0 +1,60 @@
+
+/* Do not modify this file, it was automatically generated by the
+ * PNG2cpp CMake script, using a *.png file as input.
+ */
+
+#include 
+
+static const unsigned char png[] = {
+ 0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d, 0x49, 0x48, 0x44, 0x52,
+ 0x00, 0x00, 0x00, 0x1a, 0x00, 0x00, 0x00, 0x1a, 0x08, 0x02, 0x00, 0x00, 0x00, 0x26, 0x28, 0xdb,
+ 0x99, 0x00, 0x00, 0x02, 0xae, 0x49, 0x44, 0x41, 0x54, 0x48, 0xc7, 0x63, 0x30, 0x26, 0x0b, 0xa8,
+ 0xdb, 0xab, 0x33, 0xa4, 0x30, 0x60, 0x41, 0x40, 0xb9, 0x4f, 0xa8, 0x60, 0x01, 0x03, 0xc3, 0xe7,
+ 0xa7, 0x47, 0x81, 0xe4, 0x27, 0xdc, 0xc0, 0xab, 0xdf, 0x8b, 0x6a, 0xc6, 0x9d, 0xbd, 0x73, 0x96,
+ 0x29, 0x95, 0x89, 0x6a, 0xc6, 0xc5, 0xcc, 0x8a, 0xc1, 0x6e, 0x16, 0x56, 0xe3, 0x96, 0xf2, 0xf3,
+ 0x01, 0xcd, 0x02, 0x92, 0x58, 0xcd, 0xba, 0xf9, 0xf8, 0x06, 0x5b, 0x06, 0x1b, 0x09, 0xc6, 0x01,
+ 0x81, 0xdf, 0x2c, 0x36, 0x5c, 0x4e, 0xdb, 0x7d, 0x78, 0x1e, 0x44, 0x67, 0xc1, 0x44, 0xd7, 0xfb,
+ 0x7b, 0xbb, 0xd0, 0x10, 0x61, 0xe3, 0xbe, 0x7c, 0xf9, 0xf2, 0xe3, 0xc7, 0x0f, 0x20, 0x09, 0x64,
+ 0xbf, 0x7b, 0xf7, 0xea, 0xc1, 0x81, 0x09, 0xc8, 0xfa, 0x6f, 0xef, 0x6e, 0xdf, 0xb9, 0xae, 0xf8,
+ 0xea, 0xce, 0x16, 0x62, 0x8d, 0xfb, 0xfb, 0xf7, 0xef, 0xbc, 0x79, 0xf3, 0x80, 0xc6, 0x7d, 0xfb,
+ 0xf6, 0xad, 0x79, 0x63, 0xd3, 0xec, 0x45, 0x09, 0x70, 0xb3, 0x4e, 0x6c, 0xa9, 0x51, 0x2a, 0x96,
+ 0xe0, 0xcc, 0x60, 0x17, 0xcc, 0xe1, 0x59, 0xbd, 0x22, 0x0b, 0x61, 0x5c, 0x7a, 0x46, 0x6a, 0x68,
+ 0x78, 0x30, 0x10, 0x01, 0xd9, 0x17, 0x1e, 0x1c, 0x00, 0x1a, 0x77, 0xe1, 0xc1, 0x41, 0x48, 0x38,
+ 0xfe, 0xff, 0xff, 0x9f, 0x81, 0x81, 0x41, 0x53, 0x4f, 0xf5, 0xee, 0xdd, 0xbb, 0xf3, 0xf7, 0xce,
+ 0xe4, 0xc8, 0x60, 0xe7, 0xcf, 0xe2, 0x84, 0x20, 0xce, 0x0c, 0x36, 0xdf, 0xc9, 0xbe, 0x7f, 0xff,
+ 0xfd, 0x6d, 0xdd, 0xda, 0x6a, 0x51, 0xa3, 0x8e, 0xdd, 0x75, 0x8d, 0xdb, 0x02, 0x56, 0x9f, 0xef,
+ 0xfc, 0xf3, 0xf7, 0xf7, 0x7f, 0x18, 0x00, 0x1a, 0xe7, 0x56, 0x2f, 0xc0, 0x2f, 0xc4, 0xbd, 0x7e,
+ 0xfd, 0xfa, 0xfd, 0x37, 0xf6, 0x8b, 0x15, 0x8a, 0x41, 0x82, 0x8f, 0x39, 0x95, 0x39, 0x62, 0x66,
+ 0x04, 0x50, 0xc1, 0xc4, 0x3d, 0x13, 0x4d, 0xaa, 0x55, 0xa0, 0xc6, 0x41, 0xdc, 0x85, 0xe4, 0xba,
+ 0x83, 0xbf, 0xff, 0xfe, 0xe4, 0xe3, 0xe7, 0x65, 0x80, 0x01, 0x2e, 0x3e, 0xd6, 0xe2, 0x4b, 0x62,
+ 0x11, 0x0b, 0x05, 0x85, 0x24, 0x79, 0xea, 0x1a, 0x6a, 0x7e, 0x7e, 0xfb, 0x70, 0xeb, 0xf8, 0xdc,
+ 0x0b, 0xdb, 0x1b, 0xb7, 0xac, 0x29, 0x10, 0xcb, 0x13, 0x90, 0x2d, 0x91, 0xe2, 0xca, 0xe4, 0x58,
+ 0xb0, 0x24, 0x19, 0x67, 0xd8, 0x41, 0x5c, 0x04, 0x34, 0x02, 0x0d, 0x65, 0x1d, 0x14, 0x51, 0xb1,
+ 0x10, 0x74, 0xf1, 0x70, 0x7c, 0xf3, 0xe6, 0xd5, 0xf3, 0x6b, 0xdb, 0x81, 0xfa, 0xaf, 0xec, 0x68,
+ 0x5e, 0xb6, 0x2c, 0xfd, 0xd4, 0x96, 0x5a, 0x7c, 0x51, 0x81, 0xcb, 0x38, 0x20, 0x2a, 0x3c, 0x2f,
+ 0x66, 0x99, 0x2c, 0x20, 0xa7, 0x24, 0x75, 0

[Kicad-developers] [RFC] Op-amp symbol icons

[John Beard]

Hi,

The pixel alignment of the op-amp icons looks a bit fuzzy compared to
the other newer icons. These are not the only misaligned icons, but
they are a very prominent set of them.

The problem is that both:

1) The lines are not on the pixel grid
2) The lines are not a whole number of pixels wide.

If this *were* to be changed so horizontal lines are sharp, the icons
have to be modified. However, going up to 2px or down to 1px line
width changes the feel a bit.

Attached are some options (for the full size op-amp icons at 26px). If
a consensus or executive decision ever emerges, I will produce a patch
for the op-amp icons in that style.

Personally, my "vote" is 2A, or 5A for icons where the symbol is
smaller, like "copycomponent".

List of icons affected for reference:

 add_component.svg
 copycomponent.svg
 edit_cmp_symb_links.svg
 edit_comp_footprint.svg
 edit_comp_ref.svg
 edit_comp_value.svg
 edit_component.svg
 edit_part.svg
 export_part.svg
 field_properties.svg
 hidden_pin.svg
 icon_libedit.svg
 import_cmp_from_lib.svg
 import_part.svg
 libedit.svg
 new_component.svg
 new_cvpcb.svg
 part_properties.svg
 save_part.svg
 save_part_in_mem.svg

Yours, bike-sheddingly,

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

Re: [Kicad-developers] Hotkeys in GAL

[John Beard]

On Wed, Jul 25, 2018 at 8:45 AM, Maciej Sumiński
 wrote:
>
> I would not mind adding more hotkeys, I think the primary reason is that
> not every action is executed often enough to justify a hotkey. Even with
> the current configuration it might be challenging to find a free hotkey
> for an action.
>
> The initial idea was to list all TOOL_ACTIONs in the hotkey editor, so
> the user may decide for himself which actions should have a hotkey
> assigned.

That is what I was thinking too - have the more esoteric ones
unassigned by default.

> It might be somewhat tricky to implement with legacy canvas
> still in place, so perhaps the right moment will come when legacy canvas
> is out.

OK, that makes sense.

> I imagine we could have subsections in
> the editor that are specific to tools and these would be acceptable
> duplicates with global and other contexts hotkeys.

That sounds sensible. If the hotkey dialog knew which TOOL_ACTIONs
were AS_GLOBAL and AS_CONTEXT, it could then only disallow multiple
AS_GLOBAL bindings of the same key, or multiple AS_CONTEXTs actions
within the same tool group (eg. pcbnew.InteractiveRouter).

This probably can't be easily done while the legacy code also uses the
dialog, as it requires each hotkey binding to know the global/context
aspect and the tool group.

I'll hold off doing much more until the legacy canvas is on the way out.

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

Re: [Kicad-developers] Board setup icon

[John Beard]

Hi Fabrizio,

I agree with the principle, and I am happy that we have lost the huge
number of item-specific icons in GAL menus compared to Legacy.

To be honest, I don't care what the metaphor for "board properties"
is. However, I think it is unhelpful to use a generic "properties"
icon in the "global" context (on the menubar), as it is very unclear
what that icon does. Doubly so when the icon is historically and
currently also used for "Preferences".

Ditto for the two icons Jeff requested: the old icons both exist and
mean something totally different elsewhere. For the "T" icon, it's
even on the same screen.

If an icon is used in a specific context (e.g. you're in a text editor
dialog), then the generic icon should be used as that's the simpler
metaphor).

As I said to Andrey, I will generate patches for any proposed SVG
source files, as I am set up to do it, and I know it's a bit of a
fiddle.

Cheers,

John

On Wed, Jul 25, 2018 at 2:05 PM, Fabrizio Tappero
 wrote:
> Hi Guys,
> I just wold like to remind you that if you decide to personalize kicad
> icons, kicad will end up with a lot of icons to maintain.
>
> Currently kicad is using really a lot of icons and few years ago we
> tried to simplified them so that icons could be reused. This is useful
> when you try to give consistancy to the overall looks of KiCad GUI.
>
> What you guys are doing is maybe going back to what was kicad few
> years ago. I am not saying that this is a bad thing, mine is just a
> very generic comment and might not even apply to these icons in
> particular. I just would like to give you guys a larger overview of
> the icon situation.
>
> The "property" option is (often) defined with a cog wheel. It is not
> unusual for open source projects to quickly develop 25 property icons
> made with a smaller cog wheel overlaid an other icon. How, this visual
> technique might not be the best option. Overlay tiny images to convey
> specific meaning might not lead to a present use of the GUI.
>
> Also, I will not enter into tiny image pixel alignment problem because
> we did it so many time in the last 5 years here but instead I would
> love to propose to begin talking about the use of vector format icons
> and possible the use of script to combine icons.
>
> Just my 2c
>
> Cheers
> Fabrizio
>
> On Wed, Jul 25, 2018 at 12:45 PM John Beard  wrote:
>>
>> Hi Jeff,
>>
>> Sure thing! Here they are.
>>
>> I have modified part_properties (patch 1) and create field_properties
>> and used in the menu and toolbar (patch 2).
>>
>> Attached are the PNGs for reference.
>>
>> Cheers,
>>
>> John
>>
>> On Tue, Jul 24, 2018 at 8:35 PM, Jeff Young  wrote:
>> > Hi John,
>> >
>> > When you get a chance could you also edit the part_properties_xpm icon to 
>> > be the op-amp with a gear over it?
>> >
>> > Oh, and a new icon with the op-amp with a little ’T’ in the bottom right 
>> > corner would be great.
>> >
>> > (Both are for the symbol editor.  They’re currently just a generic gear 
>> > and a generic ’T’.)
>> >
>> > Thanks,
>> > Jeff.
>> >
>> >
>> >> On 24 Jul 2018, at 16:56, Jeff Young  wrote:
>> >>
>> >> I’ve merged your icon, John.  Thanks for your contribution!
>> >>
>> >>> On 24 Jul 2018, at 12:35, John Beard  wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> Here is a new icon for the board setup toolbar and menu item. The
>> >>> generic gear icon is no clear, as it looks like "Preferences" rather
>> >>> than board setup.
>> >>>
>> >>> PNG included for reference only.
>> >>>
>> >>> Cheers,
>> >>>
>> >>> John
>> >>> <0001-Pcbnew-add-new-icon-for-board-setup.patch>___
>> >>> Mailing list: https://launchpad.net/~kicad-developers
>> >>> Post to : kicad-developers@lists.launchpad.net
>> >>> Unsubscribe : https://launchpad.net/~kicad-developers
>> >>> More help   : https://help.launchpad.net/ListHelp
>> >>
>> >>
>> >> ___
>> >> Mailing list: https://launchpad.net/~kicad-developers
>> >> Post to : kicad-developers@lists.launchpad.net
>> >> Unsubscribe : https://launchpad.net/~kicad-developers
>> >> More help   : https://help.launchpad.net/ListHelp
>> >
>> ___
>> 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] Board setup icon

[John Beard]

Hi Jeff,

Sure thing! Here they are.

I have modified part_properties (patch 1) and create field_properties
and used in the menu and toolbar (patch 2).

Attached are the PNGs for reference.

Cheers,

John

On Tue, Jul 24, 2018 at 8:35 PM, Jeff Young  wrote:
> Hi John,
>
> When you get a chance could you also edit the part_properties_xpm icon to be 
> the op-amp with a gear over it?
>
> Oh, and a new icon with the op-amp with a little ’T’ in the bottom right 
> corner would be great.
>
> (Both are for the symbol editor.  They’re currently just a generic gear and a 
> generic ’T’.)
>
> Thanks,
> Jeff.
>
>
>> On 24 Jul 2018, at 16:56, Jeff Young  wrote:
>>
>> I’ve merged your icon, John.  Thanks for your contribution!
>>
>>> On 24 Jul 2018, at 12:35, John Beard  wrote:
>>>
>>> Hi,
>>>
>>> Here is a new icon for the board setup toolbar and menu item. The
>>> generic gear icon is no clear, as it looks like "Preferences" rather
>>> than board setup.
>>>
>>> PNG included for reference only.
>>>
>>> Cheers,
>>>
>>> John
>>> <0001-Pcbnew-add-new-icon-for-board-setup.patch>___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
From ea68d50ce9aa3305d0ae180e3a47c3837ef3504d Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Wed, 25 Jul 2018 11:29:04 +0100
Subject: [PATCH 1/2] New part properties icon: opamp + gear

This was just the gear, which is conflated with general preferences.
Adding the opamp makes the connection to "symbol/part" clearer.
---
 bitmaps_png/cpp_26/part_properties.cpp  | 103 
 bitmaps_png/sources/part_properties.svg | 121 ++--
 2 files changed, 153 insertions(+), 71 deletions(-)

diff --git a/bitmaps_png/cpp_26/part_properties.cpp b/bitmaps_png/cpp_26/part_properties.cpp
index 689490ffd..54a97d4f3 100644
--- a/bitmaps_png/cpp_26/part_properties.cpp
+++ b/bitmaps_png/cpp_26/part_properties.cpp
@@ -8,46 +8,69 @@
 static const unsigned char png[] = {
  0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d, 0x49, 0x48, 0x44, 0x52,
  0x00, 0x00, 0x00, 0x1a, 0x00, 0x00, 0x00, 0x1a, 0x08, 0x06, 0x00, 0x00, 0x00, 0xa9, 0x4a, 0x4c,
- 0xce, 0x00, 0x00, 0x02, 0x60, 0x49, 0x44, 0x41, 0x54, 0x48, 0xc7, 0xbd, 0x96, 0x3b, 0x6e, 0x22,
- 0x41, 0x10, 0x86, 0x49, 0x58, 0x12, 0x02, 0x03, 0x02, 0x0e, 0x00, 0x27, 0x41, 0xe2, 0x19, 0x92,
- 0x71, 0x01, 0x62, 0x96, 0x80, 0x1c, 0x24, 0x5e, 0x47, 0x20, 0x43, 0xa4, 0x48, 0x48, 0x10, 0x92,
- 0x8d, 0x78, 0x07, 0x04, 0x0e, 0x91, 0x10, 0x43, 0x00, 0x04, 0xbe, 0x01, 0x09, 0xe5, 0xf9, 0x5a,
- 0xd3, 0xa3, 0x91, 0x3d, 0x6b, 0x63, 0xaf, 0x4d, 0x4b, 0x65, 0xda, 0xdd, 0xf5, 0xff, 0xd5, 0xf5,
- 0xea, 0x1e, 0x9f, 0xef, 0xce, 0x21, 0x22, 0xcf, 0xf2, 0x7e, 0x3c, 0xfb, 0x7e, 0x72, 0x58, 0x84,
- 0x7f, 0x2c, 0xb9, 0xf5, 0xfb, 0x7d, 0x09, 0x04, 0x02, 0x4a, 0x98, 0xb3, 0xc6, 0xde, 0x77, 0x49,
- 0x07, 0x96, 0xbc, 0x58, 0x32, 0xb5, 0xe4, 0xc9, 0x5e, 0x2b, 0xc2, 0x5a, 0x2a, 0x95, 0xa4, 0xd1,
- 0x68, 0x28, 0x61, 0x6e, 0x8f, 0xa2, 0xad, 0xf3, 0x64, 0x63, 0xc0, 0x0e, 0x3e, 0x33, 0x62, 0x80,
- 0xdc, 0xef, 0xf7, 0x72, 0xbb, 0x71, 0x58, 0xb9, 0x5a, 0xf2, 0xd7, 0x92, 0x15, 0xff, 0x24, 0x12,
- 0x09, 0x19, 0x0e, 0x87, 0x4a, 0x92, 0xc9, 0xa4, 0x36, 0xc4, 0x5e, 0x05, 0x5d, 0x30, 0x60, 0xed,
- 0x61, 0x7c, 0xe4, 0x89, 0xf4, 0x7a, 0x3d, 0xf1, 0xfb, 0xfd, 0x92, 0x4a, 0xa5, 0xe4, 0x70, 0x38,
- 0x38, 0xc9, 0x80, 0x20, 0x18, 0x0c, 0xca, 0x66, 0xb3, 0x51, 0xc2, 0xdc, 0x45, 0xaa, 0x74, 0xc1,
- 0x80, 0x85, 0xc3, 0x1e, 0x03, 0x2f, 0x43, 0x2f, 0xbb, 0xdd, 0x4e, 0x29, 0x8e, 0xc7, 0x63, 0xa9,
- 0x56, 0xab, 0x12, 0x0e, 0x87, 0x55, 0x98, 0xd2, 0xe9, 0xb4, 0x84, 0x42, 0x21, 0x29, 0x97, 0xcb,
- 0xb2, 0x5a, 0xad, 0x94, 0x30, 0x67, 0x8d, 0x3d, 0x74, 0xd0, 0x05, 0x03, 0x16, 0x0e, 0xb8, 0xe0,
- 0xf4, 0x32, 0x34, 0xc5, 0x75, 0x4e, 0x05, 0x60, 0xbb, 0xdd, 0xca, 0x68, 0x34, 0x92, 0x6c, 0x36,
- 0x2b, 0xb5, 0x5a, 0x4d, 0x0c, 0xc3, 0x90, 0xf9, 0x7c, 0x2e, 0xb3, 0xd9, 0x4c, 0x09, 0x73, 0xd6,
- 0xd8, 0x43, 0x07, 0x5d, 0x30, 0x60, 0xe1, 0xb0, 0x43, 0x3f, 0xf5, 0x32, 0x44, 0x32, 0xaf, 0xc7,
- 0xe3, 0x51, 0x22, 0x91, 0x88, 0x02, 0xae, 0xd7, 0x6b, 0x59, 0x2c, 0x16, 0x0e, 0x31, 0x73, 0xb7,
- 0x68, 0xc3, 0xcc, 0xd1, 0xc5, 0x1b, 0xb0, 0x76, 0x48, 0xaf, 0xba, 0x98, 0xbc, 0x8c, 0x91, 0x54,
- 0x27, 0x5c, 0x

[Kicad-developers] Hotkeys in GAL

[John Beard]

Hi,

I have a few questions about hotkeys in GAL tools:

1) Is there are reason so many GAL tools don't get hotkeys?

Very many TOOL_ACTIONS have a hotkey set to '0'. Most others that do
have a hotkey have a LegacyHotkey definition. Only a very few have the
GAL-style keys (e.g. rotate CW).

I think nearly all GAL tools should have a hotkey assignable, even if
they default to unassigned. It's quite limiting to not be able to
access some tools except by the menu. (This may mean some tools need
defences against being called even when the menu item is disabled.)

2) Is it/will it be supported to have the same hotkey for multiple
contexts? For example, say there's an AS_GLOBAL action using "G".
However, when you're in a tool mode, that could be overridden by a
AS_CONTEXT action that only makes sense in that tool.

This already sort of works, *but* the hotkey dialog does not like
duplicate keys, even when one is global and one is contextual. Can
this be changed, or is it pending removal of the legacy canvas and
hotkey system first?

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] Add Insert hotkey to add a zone/segment corner

[John Beard]

This patch adds a hotkey for adding a corner to a zone or segment.
This is an action I have really struggled without a hotkey for! I have
used Insert, as:

1) it's available and
2) it's what Inkscape uses (but Inkscape adds the point at the
midpoint of the segment, this adds at the cursor).

It doesn't work on polygons, as that is still unimplemented in the
underlying action.

Cheers,

John
From 9a4da96b7df9941e6dcbb61201adfeaed70bea95 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Tue, 24 Jul 2018 16:15:05 +0100
Subject: [PATCH 1/2] Add hotkey (Insert) for zone create corner

Adds a hotkey to the TOOL_ACTION, and also checks for
action validity prior to running the actions (previously
implicitly gated by  the enablement of the menu item).
---
 pcbnew/hotkeys.cpp|  6 ++
 pcbnew/hotkeys.h  |  3 ++-
 pcbnew/tools/point_editor.cpp | 23 +--
 pcbnew/tools/point_editor.h   |  3 +++
 4 files changed, 28 insertions(+), 7 deletions(-)

diff --git a/pcbnew/hotkeys.cpp b/pcbnew/hotkeys.cpp
index 25a93e694..32fcc3192 100644
--- a/pcbnew/hotkeys.cpp
+++ b/pcbnew/hotkeys.cpp
@@ -310,6 +310,9 @@ static EDA_HOTKEY HkToggleCursor( _HKI( "Toggle Cursor Display (Modern Toolset o
 static EDA_HOTKEY HkMeasureTool( _HKI( "Measure Distance (Modern Toolset only)" ),
  HK_MEASURE_TOOL, 'M' + GR_KB_SHIFTCTRL );
 
+static EDA_HOTKEY HkInsertCorner( _HKI( "Insert Corner (Modern Toolset only)" ),
+ HK_INSERT_CORNER, WXK_INSERT );
+
 // List of common hotkey descriptors
 EDA_HOTKEY* common_Hotkey_List[] =
 {
@@ -384,6 +387,9 @@ EDA_HOTKEY* board_edit_Hotkey_List[] =
 ,
 ,
 
+// Point editor (zones and segments)
+,
+
 // Highlight and display
 ,
 ,
diff --git a/pcbnew/hotkeys.h b/pcbnew/hotkeys.h
index f4e6fa446..b22817675 100644
--- a/pcbnew/hotkeys.h
+++ b/pcbnew/hotkeys.h
@@ -133,7 +133,8 @@ enum hotkey_id_commnand {
 HK_DP_DIMENSIONS,
 HK_VIA_SIZE_INC,
 HK_VIA_SIZE_DEC,
-HK_HIGHLIGHT_NET_SELECTION
+HK_HIGHLIGHT_NET_SELECTION,
+HK_INSERT_CORNER
 };
 
 // Full list of hotkey descriptors for board editor and footprint editor
diff --git a/pcbnew/tools/point_editor.cpp b/pcbnew/tools/point_editor.cpp
index 9d994479e..a63bdb944 100644
--- a/pcbnew/tools/point_editor.cpp
+++ b/pcbnew/tools/point_editor.cpp
@@ -50,7 +50,7 @@ using namespace std::placeholders;
 
 // Point editor
 TOOL_ACTION PCB_ACTIONS::pointEditorAddCorner( "pcbnew.PointEditor.addCorner",
-AS_GLOBAL, 0,
+AS_GLOBAL, WXK_INSERT,
 _( "Create Corner" ), _( "Create a corner" ), add_corner_xpm );
 
 TOOL_ACTION PCB_ACTIONS::pointEditorRemoveCorner( "pcbnew.PointEditor.removeCorner",
@@ -850,17 +850,25 @@ void POINT_EDITOR::setTransitions()
 }
 
 
+bool POINT_EDITOR::canAddCorner( const EDA_ITEM& aItem )
+{
+const auto type = aItem.Type();
+
+// Works only for zones and line segments
+return type == PCB_ZONE_AREA_T ||
+   ( ( type == PCB_LINE_T || type == PCB_MODULE_EDGE_T ) &&
+   static_cast( aItem ).GetShape() == S_SEGMENT );
+}
+
+
 bool POINT_EDITOR::addCornerCondition( const SELECTION& aSelection )
 {
 if( aSelection.Size() != 1 )
 return false;
 
-auto item = aSelection.Front();
+const EDA_ITEM* item = aSelection.Front();
 
-// Works only for zones and line segments
-return item->Type() == PCB_ZONE_AREA_T ||
-   ( ( item->Type() == PCB_LINE_T || item->Type() == PCB_MODULE_EDGE_T ) &&
-   static_cast( item )->GetShape() == S_SEGMENT );
+return ( item != nullptr ) && canAddCorner( *item );
 }
 
 
@@ -921,6 +929,9 @@ int POINT_EDITOR::addCorner( const TOOL_EVENT& aEvent )
 const VECTOR2I& cursorPos = getViewControls()->GetCursorPosition();
 BOARD_COMMIT commit( frame );
 
+if( !canAddCorner( *item ) )
+return 0;
+
 if( item->Type() == PCB_ZONE_AREA_T )
 {
 ZONE_CONTAINER* zone = static_cast( item );
diff --git a/pcbnew/tools/point_editor.h b/pcbnew/tools/point_editor.h
index 230a6f5c7..6ebcb1787 100644
--- a/pcbnew/tools/point_editor.h
+++ b/pcbnew/tools/point_editor.h
@@ -129,6 +129,9 @@ private:
 ///> Condition to display "Create corner" context menu entry.
 static bool addCornerCondition( const SELECTION& aSelection );
 
+///> Determine if the tool can currently add a corner to the given item
+static bool canAddCorner( const EDA_ITEM& aItem );
+
 ///> Condition to display "Remove corner" context menu entry.
 bool removeCornerCondition( const SELECTION& aSelection );
 
-- 
2.17.1

___
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] Board setup icon

[John Beard]

Hi,

Here is a new icon for the board setup toolbar and menu item. The
generic gear icon is no clear, as it looks like "Preferences" rather
than board setup.

PNG included for reference only.

Cheers,

John
From 329eda7c68c0ca56f1d8095342000fdc72868955 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Tue, 24 Jul 2018 11:57:07 +0100
Subject: [PATCH] Pcbnew: add new icon for board setup

Previously, the generic "options" gear was used, which was
confusing.

This commit add a new icon, options_board, specifically for
board-wide options.
---
 bitmaps_png/CMakeLists.txt|   1 +
 bitmaps_png/cpp_26/options_board.cpp  |  93 +++
 bitmaps_png/sources/options_board.svg | 226 ++
 include/bitmaps.h |   1 +
 pcbnew/menubar_pcb_editor.cpp |   2 +-
 pcbnew/tool_pcb_editor.cpp|   2 +-
 6 files changed, 323 insertions(+), 2 deletions(-)
 create mode 100644 bitmaps_png/cpp_26/options_board.cpp
 create mode 100644 bitmaps_png/sources/options_board.svg

diff --git a/bitmaps_png/CMakeLists.txt b/bitmaps_png/CMakeLists.txt
index 320df94c5..09c7b6b88 100644
--- a/bitmaps_png/CMakeLists.txt
+++ b/bitmaps_png/CMakeLists.txt
@@ -420,6 +420,7 @@ set( BMAPS_MID
 options_all_tracks
 options_all_vias
 options_arc
+options_board
 options_circle
 options_generic
 options_module
diff --git a/bitmaps_png/cpp_26/options_board.cpp b/bitmaps_png/cpp_26/options_board.cpp
new file mode 100644
index 0..7e02513fa
--- /dev/null
+++ b/bitmaps_png/cpp_26/options_board.cpp
@@ -0,0 +1,93 @@
+
+/* Do not modify this file, it was automatically generated by the
+ * PNG2cpp CMake script, using a *.png file as input.
+ */
+
+#include 
+
+static const unsigned char png[] = {
+ 0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d, 0x49, 0x48, 0x44, 0x52,
+ 0x00, 0x00, 0x00, 0x1a, 0x00, 0x00, 0x00, 0x1a, 0x08, 0x06, 0x00, 0x00, 0x00, 0xa9, 0x4a, 0x4c,
+ 0xce, 0x00, 0x00, 0x04, 0xbf, 0x49, 0x44, 0x41, 0x54, 0x48, 0xc7, 0xed, 0x56, 0x7b, 0x4c, 0xdb,
+ 0x55, 0x14, 0x66, 0x6a, 0x5c, 0xd4, 0x39, 0xe7, 0xb2, 0x04, 0x8d, 0xdb, 0x12, 0x43, 0x42, 0x16,
+ 0x13, 0x27, 0x7f, 0xd8, 0x31, 0x67, 0x44, 0x09, 0x96, 0x57, 0x61, 0xf2, 0x0c, 0xaf, 0x66, 0x29,
+ 0xc4, 0x81, 0xc2, 0xb6, 0x32, 0xcb, 0x43, 0x87, 0x7b, 0xf1, 0x1a, 0x20, 0xb0, 0x31, 0x60, 0x2d,
+ 0xac, 0x40, 0x69, 0x69, 0xb3, 0x09, 0x61, 0x29, 0x2f, 0xd9, 0x60, 0x2b, 0x0d, 0x14, 0xac, 0x64,
+ 0x9a, 0x98, 0x4d, 0xf4, 0x0f, 0xd4, 0x84, 0x01, 0x15, 0xe8, 0x5c, 0xcb, 0x0a, 0xcb, 0x18, 0x7c,
+ 0xfe, 0xce, 0x95, 0x16, 0x2a, 0x4c, 0xc1, 0xc4, 0xff, 0x6c, 0x72, 0xfa, 0xeb, 0xf9, 0x7a, 0xef,
+ 0xfd, 0xee, 0x39, 0xe7, 0x3b, 0xbf, 0x7b, 0x5d, 0x44, 0x45, 0xef, 0x88, 0x82, 0x72, 0x3c, 0xda,
+ 0xbb, 0xae, 0xa4, 0x9d, 0xfa, 0xf9, 0x46, 0x61, 0x7a, 0x6a, 0x19, 0x5f, 0x41, 0x7e, 0x9e, 0x3c,
+ 0xac, 0x92, 0xfc, 0x5a, 0x55, 0xfc, 0x17, 0xe4, 0x0b, 0x0b, 0xf7, 0x35, 0x92, 0x4f, 0x46, 0xfe,
+ 0x6a, 0x73, 0x1e, 0x67, 0xc4, 0xe1, 0xb2, 0x3f, 0xd7, 0xa3, 0xcd, 0xe5, 0x43, 0x17, 0x5c, 0x6d,
+ 0x96, 0xe0, 0x97, 0xeb, 0x45, 0x10, 0x64, 0xbf, 0x01, 0xf2, 0xc5, 0xe7, 0xf8, 0xcc, 0xaf, 0xac,
+ 0x13, 0x32, 0xdf, 0x5d, 0xe2, 0xca, 0x7c, 0x32, 0xf2, 0xc9, 0xae, 0x2d, 0xce, 0x09, 0xcc, 0xde,
+ 0xed, 0xc0, 0x56, 0x33, 0xc6, 0xf1, 0x3f, 0xd1, 0x6a, 0x44, 0x41, 0x8b, 0x73, 0xfe, 0x73, 0x22,
+ 0x9d, 0x36, 0x03, 0xae, 0x87, 0x37, 0x33, 0x8c, 0x9e, 0x39, 0xb2, 0x50, 0xe4, 0x57, 0x85, 0x3b,
+ 0xac, 0x52, 0x21, 0x2c, 0xfd, 0x57, 0x44, 0x4f, 0x27, 0x3e, 0xc5, 0xb0, 0xa8, 0x33, 0x7b, 0x30,
+ 0x7c, 0xbd, 0xd0, 0x41, 0xf6, 0x51, 0xc9, 0x7b, 0xec, 0x69, 0x1f, 0x67, 0x37, 0x52, 0xe6, 0x9a,
+ 0x89, 0x76, 0xa6, 0x6e, 0x75, 0x2c, 0x7a, 0xfc, 0x42, 0xb0, 0x23, 0xaa, 0xe5, 0x64, 0xcb, 0xed,
+ 0xca, 0x97, 0x87, 0x70, 0xb6, 0x26, 0x1a, 0x37, 0xdb, 0x4f, 0xae, 0x8d, 0x48, 0xdb, 0x78, 0x18,
+ 0x1b, 0x0e, 0x6e, 0x60, 0xd8, 0x81, 0xc2, 0x7d, 0x8e, 0x85, 0xf2, 0xb9, 0x0d, 0x98, 0x2c, 0x26,
+ 0x3c, 0x7c, 0xf4, 0x10, 0x16, 0xdb, 0xef, 0x50, 0x35, 0x1e, 0x65, 0x9b, 0x22, 0x8b, 0x3a, 0xe3,
+ 0x89, 0xad, 0x47, 0xb6, 0xc0, 0xab, 0xe0, 0x6d, 0xb8, 0x1e, 0x79, 0x11, 0x9d, 0xcd, 0x47, 0x4f,
+ 0xaf, 0x20, 0xb2, 0x17, 0xf6, 0xad, 0x2c, 0x37, 0x0c, 0x5d, 0xcb, 0x63, 0xd8, 0x29, 0xe9, 0x07,
+ 0x0c, 0x73, 0xfb, 0xcc, 0x0d, 0x9f, 0x72, 0x39, 0x27, 0xcc, 0x32, 0xf2, 0x2d, 0x54, 0x2a, 0x15,
+ 0xf8, 0x7c, 0x3e, 0x64, 0x32, 0x19, 0x94, 0xfd, 0x4a, 0x36, 0x66, 0x5b, 0xea, 0x36, 0x78, 0x9c,
+ 0xf6, 0x40, 0xfb, 0xf7, 0xed, 0xa0, 0x8f, 0x7f, 0xc9, 0xfb, 0x10, 0x16, 0xed, 0x6d, 0x5a, 0x41,
+ 0x24, 0xab, 0x3f, 0x80, 0x27, 0x0f, 0x3e, 0xc1, 0x26, 0xed, 0x3d, 0xe6, 0x86, 0x5b, 0x9d, 0x39,
+ 0x0c, 0xef, 0x34, 0xaa, 0x61, 0x36, 0x9b, 0x61, 0xb3, 0xd9, 0x60, 0xbc, 0xf5, 0x15, 0xe6, 0x66,
+ 0x2d, 0x48, 0x48, 0x48, 0x40, 0x6f, 0x6f, 0x2f, 0x84, 0x42, 0x21, 0x26, 0xb8, 0xe8, 0x34, 0x86,
+ 0x3a, 0xcc, 0xcc, 0xce, 0x60, 0x72, 0x72, 0x12, 0x5d, 0xb7, 0xbb, 0xa0, 0xfb, 0x51, 0x87, 0x57,
+ 0x24, 0x2f, 0x51, 0xaa, 0xab, 0x56, 0x10, 0x91, 0x5d, 0x54, 0x8a, 0x

Re: [Kicad-developers] [PATCH] qa_geometry tests

[John Beard]

I think the first three of these patches are still worth committing
now. That will allow "make test" to be used to collect all our
(working) tests and give us somewhere to hang new tests so that they
can used.

We can discuss whether or not we want "make test" to also rebuild the
tests separately, as well as thoughts on the fillet tests.

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] Another -Wcatch-value fix

[John Beard]

Hi,

Another small fix for a -Wcatch-value warning that I noticed during a
clean build.

Cheers,

John
From eebe86ea52c028b42389db6139b3b2b4f9bd Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Thu, 19 Jul 2018 17:15:36 +0100
Subject: [PATCH] Fix -Wcatch-value in sexpr.cpp

This is fixed by catching bty const-ref, rather than by value.

Also a few trailing space deletions.
---
 utils/kicad2step/sexpr/sexpr.cpp | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/utils/kicad2step/sexpr/sexpr.cpp b/utils/kicad2step/sexpr/sexpr.cpp
index 8620ab7fa..a5d72c75c 100644
--- a/utils/kicad2step/sexpr/sexpr.cpp
+++ b/utils/kicad2step/sexpr/sexpr.cpp
@@ -43,7 +43,7 @@ namespace SEXPR
 
 return _cast< SEXPR_LIST const * >(this)->m_children;
 }
-
+
 SEXPR* SEXPR::GetChild( size_t aIndex ) const
 {
 if( m_type != SEXPR_TYPE::SEXPR_TYPE_LIST )
@@ -208,12 +208,12 @@ namespace SEXPR
 
 m_children.clear();
 }
-
+
 SEXPR_LIST& operator<< ( SEXPR_LIST& list, const ISEXPRABLE& obj )
 {
 SEXPR* sobj = obj.SerializeSEXPR();
 list.AddChild( sobj );
-
+
 return list;
 }
 
@@ -252,7 +252,7 @@ namespace SEXPR
 list.AddChild( obj );
 return list;
 }
-
+
 SEXPR_LIST& operator<< ( SEXPR_LIST& list, const _OUT_STRING setting )
 {
 SEXPR *res;
@@ -469,7 +469,7 @@ namespace SEXPR
 	throw std::invalid_argument( "unsupported argument type, this shouldn't have happened" );
 }
 			}
-			catch( INVALID_TYPE_EXCEPTION )
+			catch( const INVALID_TYPE_EXCEPTION& )
 			{
 return i;
 			}
-- 
2.17.1

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

Re: [Kicad-developers] eeschema GAL renderer (with old tools)

[John Beard]

Hi Tom,

Understood. Is there anything I can help with? Or will that just get in the way?

Otherwise, what should I be looking for when test-driving (i.e. what's
helpful to report)? So far:

* Some tools seem to work \o/
* Some tools don't (global labels, for example)
* As noted, some colours aren't right (especially bus and graphic
lines, symbol texts)
* Graphic lines aren't dashed
* Opening the symbol editor asserts and segfaults.
* Assert on Escape
* Assert on place component
* Segfault on image insert

I assume most of these are known.

Cheers,

John


On Mon, Jul 23, 2018 at 11:54 AM, Tomasz Wlostowski
 wrote:
> On 23/07/18 12:48, John Beard wrote:
>> Hi Tom,
>>
>> It's now building on 621206fdd, thanks!
>>
>> I get the following asserts. Let me know if you rather I reported this
>> kind of thing in separate emails/threads/on another platform!
>>
>
> Hi John,
>
> It's a work in progress, I'm aware of this assert (I messed something up
> with cursor shape switching).
>
> Tom
>
>> 1) When pressing Escape:
>>
>> ASSERT INFO:
>> ./src/gtk/cursor.cpp(234): assert "Assert failure" failed in
>> InitFromStock(): unsupported cursor type
>>
>> BACKTRACE:
>> [1] wxCursor::InitFromStock(wxStockCursor)
>> [2] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase
>> const&, wxEvtHandler*, wxEvent&)
>> [3] wxEvtHandler::SearchDynamicEventTable(wxEvent&)
>> [4] wxEvtHandler::TryHereOnly(wxEvent&)
>> [5] wxEvtHandler::ProcessEventLocally(wxEvent&)
>> [6] wxEvtHandler::ProcessEvent(wxEvent&)
>> [7] wxScrollHelperEvtHandler::ProcessEvent(wxEvent&)
>> [8] wxEvtHandler::SafelyProcessEvent(wxEvent&)
>> [9] g_closure_invoke
>> [10] g_signal_emit_valist
>> [11] g_signal_emit
>> [12] gtk_window_propagate_key_event
>> [13] g_closure_invoke
>> [14] g_signal_emit_valist
>> [15] g_signal_emit
>> [16] gtk_propagate_event
>> [17] gtk_main_do_event
>> [18] g_main_context_dispatch
>> [19] g_main_loop_run
>> [20] gtk_main
>> [21] wxGUIEventLoop::DoRun()
>> [22] wxEventLoopBase::Run()
>> [23] wxAppConsoleBase::MainLoop()
>> [24] wxEntry(int&, wchar_t**)
>> [25] __libc_start_main
>> [26] _start
>>
>> 2) When opening the component picker (from eeschema in a build
>> environment, it's not installed, so perhaps this is my fault):
>>
>> ASSERT INFO:
>> /home/john/src/kicad-alt/eeschema/eeschema_config.cpp(780): assert
>> "!prjPath.empty()" failed in SchSymbolLibTable().
>>
>> BACKTRACE:
>> [1] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase
>> const&, wxEvtHandler*, wxEvent&)
>> [2] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
>> [3] wxEvtHandler::TryHereOnly(wxEvent&)
>> [4] wxEvtHandler::DoTryChain(wxEvent&)
>> [5] wxEvtHandler::ProcessEvent(wxEvent&)
>> [6] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase
>> const&, wxEvtHandler*, wxEvent&)
>> [7] wxEvtHandler::SearchDynamicEventTable(wxEvent&)
>> [8] wxEvtHandler::TryHereOnly(wxEvent&)
>> [9] wxEvtHandler::ProcessEventLocally(wxEvent&)
>> [10] wxEvtHandler::ProcessEvent(wxEvent&)
>> [11] wxScrollHelperEvtHandler::ProcessEvent(wxEvent&)
>> [12] wxEvtHandler::SafelyProcessEvent(wxEvent&)
>> [13] wxWindow::GTKDoInsertTextFromIM(char const*)
>> [14] g_closure_invoke
>> [15] g_signal_emit_valist
>> [16] g_signal_emit_by_name
>> [17] g_closure_invoke
>> [18] g_signal_emit_valist
>> [19] g_signal_emit
>> [20] g_closure_invoke
>> [21] g_signal_emit_valist
>> [22] g_signal_emit
>> [23] gtk_window_propagate_key_event
>> [24] g_closure_invoke
>> [25] g_signal_emit_valist
>> [26] g_signal_emit
>> [27] gtk_propagate_event
>> [28] gtk_main_do_event
>> [29] g_main_context_dispatch
>> [30] g_main_loop_run
>> [31] gtk_main
>> [32] wxGUIEventLoop::DoRun()
>> [33] wxEventLoopBase::Run()
>> [34] wxAppConsoleBase::MainLoop()
>> [35] wxEntry(int&, wchar_t**)
>> [36] __libc_start_main
>> [37] _start
>>
>>
>> Cheers,
>>
>> John
>>
>> On Mon, Jul 23, 2018 at 11:01 AM, John Beard  wrote:
>>> Hi Tom,
>>>
>>> I tried to build this (commit 4eb9a3c51), and CMake failed with a
>>> missing file (eeschema/libedit/controller.cpp).
>>>
>>> Removing that from the CMakeLists.txt resulted in (predictably enough)
>>> a link failure:
>>>
>>> CMakeFiles/eeschema_kiface.dir/libedit/lib_edit_frame.cpp

Re: [Kicad-developers] eeschema GAL renderer (with old tools)

[John Beard]

Hi Tom,

It's now building on 621206fdd, thanks!

I get the following asserts. Let me know if you rather I reported this
kind of thing in separate emails/threads/on another platform!

1) When pressing Escape:

ASSERT INFO:
./src/gtk/cursor.cpp(234): assert "Assert failure" failed in
InitFromStock(): unsupported cursor type

BACKTRACE:
[1] wxCursor::InitFromStock(wxStockCursor)
[2] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase
const&, wxEvtHandler*, wxEvent&)
[3] wxEvtHandler::SearchDynamicEventTable(wxEvent&)
[4] wxEvtHandler::TryHereOnly(wxEvent&)
[5] wxEvtHandler::ProcessEventLocally(wxEvent&)
[6] wxEvtHandler::ProcessEvent(wxEvent&)
[7] wxScrollHelperEvtHandler::ProcessEvent(wxEvent&)
[8] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[9] g_closure_invoke
[10] g_signal_emit_valist
[11] g_signal_emit
[12] gtk_window_propagate_key_event
[13] g_closure_invoke
[14] g_signal_emit_valist
[15] g_signal_emit
[16] gtk_propagate_event
[17] gtk_main_do_event
[18] g_main_context_dispatch
[19] g_main_loop_run
[20] gtk_main
[21] wxGUIEventLoop::DoRun()
[22] wxEventLoopBase::Run()
[23] wxAppConsoleBase::MainLoop()
[24] wxEntry(int&, wchar_t**)
[25] __libc_start_main
[26] _start

2) When opening the component picker (from eeschema in a build
environment, it's not installed, so perhaps this is my fault):

ASSERT INFO:
/home/john/src/kicad-alt/eeschema/eeschema_config.cpp(780): assert
"!prjPath.empty()" failed in SchSymbolLibTable().

BACKTRACE:
[1] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase
const&, wxEvtHandler*, wxEvent&)
[2] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[3] wxEvtHandler::TryHereOnly(wxEvent&)
[4] wxEvtHandler::DoTryChain(wxEvent&)
[5] wxEvtHandler::ProcessEvent(wxEvent&)
[6] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase
const&, wxEvtHandler*, wxEvent&)
[7] wxEvtHandler::SearchDynamicEventTable(wxEvent&)
[8] wxEvtHandler::TryHereOnly(wxEvent&)
[9] wxEvtHandler::ProcessEventLocally(wxEvent&)
[10] wxEvtHandler::ProcessEvent(wxEvent&)
[11] wxScrollHelperEvtHandler::ProcessEvent(wxEvent&)
[12] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[13] wxWindow::GTKDoInsertTextFromIM(char const*)
[14] g_closure_invoke
[15] g_signal_emit_valist
[16] g_signal_emit_by_name
[17] g_closure_invoke
[18] g_signal_emit_valist
[19] g_signal_emit
[20] g_closure_invoke
[21] g_signal_emit_valist
[22] g_signal_emit
[23] gtk_window_propagate_key_event
[24] g_closure_invoke
[25] g_signal_emit_valist
[26] g_signal_emit
[27] gtk_propagate_event
[28] gtk_main_do_event
[29] g_main_context_dispatch
[30] g_main_loop_run
[31] gtk_main
[32] wxGUIEventLoop::DoRun()
[33] wxEventLoopBase::Run()
[34] wxAppConsoleBase::MainLoop()
[35] wxEntry(int&, wchar_t**)
[36] __libc_start_main
[37] _start


Cheers,

John

On Mon, Jul 23, 2018 at 11:01 AM, John Beard  wrote:
> Hi Tom,
>
> I tried to build this (commit 4eb9a3c51), and CMake failed with a
> missing file (eeschema/libedit/controller.cpp).
>
> Removing that from the CMakeLists.txt resulted in (predictably enough)
> a link failure:
>
> CMakeFiles/eeschema_kiface.dir/libedit/lib_edit_frame.cpp.o:(.data.rel.ro._ZTV14LIB_EDIT_FRAME[_ZTV14LIB_EDIT_FRAME]+0x958):
> undefined reference to `LIB_EDIT_FRAME::GeneralControl(wxDC*, wxPoint
> const&, unsigned int)'
> collect2: error: ld returned 1 exit status
>
> Cheers,
>
> John
>
>
> On Sat, Jun 9, 2018 at 2:32 PM, firewalker  wrote:
>> Any hint on the linking failure reported?
>>
>> On Tue, May 29, 2018 at 12:43 AM, Tomasz Wlostowski
>>  wrote:
>>>
>>> Hi all,
>>>
>>> This is to inform that I'm working on it (as the XOR-based rendering
>>> doesn't work under GTK3). I wrote a hacked GAL canvas which uses the
>>> legacy eeschema tool code. It's non-functional yet (editing-wise), but
>>> draws the schematics and the selection rectangles.
>>>
>>> I'll publish the code as soon as it is in usable state.
>>>
>>> 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
>>

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

Re: [Kicad-developers] eeschema GAL renderer (with old tools)

[John Beard]

Hi Tom,

I tried to build this (commit 4eb9a3c51), and CMake failed with a
missing file (eeschema/libedit/controller.cpp).

Removing that from the CMakeLists.txt resulted in (predictably enough)
a link failure:

CMakeFiles/eeschema_kiface.dir/libedit/lib_edit_frame.cpp.o:(.data.rel.ro._ZTV14LIB_EDIT_FRAME[_ZTV14LIB_EDIT_FRAME]+0x958):
undefined reference to `LIB_EDIT_FRAME::GeneralControl(wxDC*, wxPoint
const&, unsigned int)'
collect2: error: ld returned 1 exit status

Cheers,

John


On Sat, Jun 9, 2018 at 2:32 PM, firewalker  wrote:
> Any hint on the linking failure reported?
>
> On Tue, May 29, 2018 at 12:43 AM, Tomasz Wlostowski
>  wrote:
>>
>> Hi all,
>>
>> This is to inform that I'm working on it (as the XOR-based rendering
>> doesn't work under GTK3). I wrote a hacked GAL canvas which uses the
>> legacy eeschema tool code. It's non-functional yet (editing-wise), but
>> draws the schematics and the selection rectangles.
>>
>> I'll publish the code as soon as it is in usable state.
>>
>> 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
>

___
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] Branches

[John Beard]

On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh  wrote:
> Unless we are going to prohibit new features (new file formats, new tool
> framework for eeschema, etc.) from being merged into the dev branch
> until 5.1 is released, I disagree.  If we want to only work on 5.1 in
> the dev branch, then I'm OK with this proposal.

This is essentially my proposal - limit dev branch changes to 5.1
features, uncontroversial maintenance and bugfixes.

If people want to work on features for 6 now, that can be done in
separate branches, and the onus for keeping it rebased onto the 5.1
changes is on them, rather than forcing the 5.1 workers to deal with
conflicts. Otherwise, whoever is working on 5.1 features like the
GTK3/GAL stuff and printing, will have to continually port their work
between the two branches.

If 5.1 changes are unlikely to be substantially affected by 6.0-facing
changes, then perhaps this limitation is not useful.

> There should be nothing in the 5.1 branch that is not also in the dev
> branch so everything in the 5.1 branch should be tested in the dev
> branch builds.

In theory, yes, but if fixes need to be manually ported as the
branches diverge, it's possible to fail to fix, or break in new ways,
one branch or the other. If a 5.1 branch exists in parallel to 6.0,
someone will have to take responsibility to ensure the appropriate
fixes are identified, ported and tested as needed. In the Linux world,
this is the unglamorous, arduous (and vital) job of the stable branch
maintainers.

I'm not against parallel branches if someone is willing to step up to
be a stable branch maintainer for 5.1. In fact, I'd be thrilled to get
nice new stuff dropping into the dev branch. However, changes that
need to be in both branches are not trivially rebasable, that job will
soon become decidedly not-fun.

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

Re: [Kicad-developers] Branches

[John Beard]

I agree with Orson. It's unfortunate for people to not be able to dump
new features onto master after such a long freeze. However, if 5.1 and
master/6-dev diverge, there will be a lot of pain in porting bugs,
especially if one branch has work that very is invasive and touches a
lot of code, and one does not.

Moreover, testing efforts will be split, with some people only on
5.1-dev and some only using master. This can easily allow bugs to slip
by into one branch or the other.

I think there should only be master, which is the 5.1-dev branch. When
that splits to become a release, 6.0-dev can start.

Big features that don't suit 5.1 will just have to wait for the start
of 6, being maintained in separate branches if necessary, either under
the KiCad aegis in the main repo, or less formally in any other Git
repo. A list of ongoing known dev branches somewhere would be helpful
(eeschema GAL and Cairo printing being two I can think would be useful
to document).

Of course, people with new features can always petition the project
lead for permission to put stuff into 5.1! Otherwise, focussing on 5.1
issues now will get both 5.1 done and out of the way sooner (important
to fix Python), and also get us to the state where 6.0-dev can receive
the full attention from devs, lead and interested users.

Cheers,

John


On Thu, Jul 19, 2018 at 10:25 AM, Maciej Sumiński
 wrote:
> I wonder if there is a point in keeping 5.1 and master branches
> separated. In 5.1 there is a lot of new code that will need patches, and
> they need to be applied to both branches now. If we keep adding more
> features to the master branch, then at one point the branch may diverge
> significantly enough to make patch porting non trivial.
>
> What do you think about replacing the current master branch with 5.1?
> This way we can focus on the wxGTK3 problem, fix issues that we discover
> and once 5.1 is out - keep adding new features to 6.0-dev? For the time
> being new features might be developed in private branches.
>
> BTW. I really like 5.1 UI improvements, good job Jeff!
>
> Cheers,
> Orson
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

[Kicad-developers] Launchpad tags

[John Beard]

Hi,

I think it would be helpful to have a couple more official tags on launchpad:

* testing - anything related to issues with the test programs
* legacy - anything related the old canvases (which might be only of
limited importance to fix going forward towards a GAL-only future)

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

Re: [Kicad-developers] [PATCH] qa_geometry tests

[John Beard]

Hi Wayne,

(Feel free to tell me to come back to this later if busy with v5!)

On closer inspection, qa_geometry is NOT a general test of geometry
code, but rather a few tests to ensure that some refactored code
(SHAPE_POLY_SET) matches the original CPolyLine-based code.

As for the fillet code testing, I had a go at making some actual tests
for the SHAPE_POLY_SET. It basically does the following for a few
combinations of radius/error:

1) Make a square shape
2) Fillet it
3) Check there's a single resulting polygon
4) Look at the segments generated by the code and ensure that:
a) The end points are the right distance from the radius centre
b) The mid point error from the ideal arc is within tolerance
c) The line is (roughly, due to rounding) perpendicular to the
line joining midpoint and radius centre
5) Check the fillet is at least one segment

These tests do appear to pass for the SHAPE_POLY_SET code.

You could also do testing against expected co-ordinate results, but
that requires that the Fillet code contracts to return exact,
reproducible result, not just "good enough to fit the given error, but
with latitude within that brief".

Attached are some patches to illustrate what I am talking about. I'm
not asking to merge before v5, though I believe the first three are
generally harmless in that respect, as they just enable ctest, add the
working qa_geometry tests (renamed to qa_shape_poly_set_refactor) and
add the Python tests.

The fourth is the new fillet tests, which are still just a concept,
though feedback is welcome.

Cheers,

John

On Tue, Jul 10, 2018 at 4:12 PM, Wayne Stambaugh  wrote:
> I'm not sure what bothers me more, the fact the test fails or the fact
> that the test used  different fillet code as the pass/fail criteria
> rather than a hard coded known correct test.  Which fillet code was/is
> correct?  We really do need to start doing a better job with our
> geometry tests and testing in general.  Is the fillet code we use to
> generate polygons and other geometry actually correct?
>
> As far as fixing qa tests, I don't think that will impact the v5 release
> but pushing it off to 5.0.1 or 5.1 probably makes more sense at this
> point.  I do agree that there should be an easier way to run tests.
>
> Cheers,
>
> Wayne
>
> On 7/9/2018 5:35 AM, John Beard wrote:
>> Note to Wayne: Nothing here concerns v5 release, I was just trying to
>> get a geom test working for future.
>>
>> On Mon, Jul 9, 2018 at 9:12 AM, John Beard  wrote:
>>> Hi,
>>>
>>> Let's come back to the make test behaviour after v5, I think we'll
>>> need to discuss that separately. However, I think this does illustrate
>>> why we need the tests to be runnable easily, otherwise they suffer
>>> bit-rot, and then the tests are useless.
>>>
>>> Looking at that change, the test is now iterating the second parameter
>>> which is now "max error", not "number of segments". Does this test
>>> still make any sense? It's now comparing:
>>>
>>> SHAPE_POLY_SET::Fillet( radius, error );
>>>
>>> with
>>>
>>> CPolyLine::Fillet( radius, segments );
>>>
>>> The original test was designed to ensure SHAPE_POLY_SET::Fillet and
>>> CPolyLine::Fillet were the same, but they now have different
>>> interfaces and semantics. Wouldn't it be better to check
>>> SHAPE_POLY_SET::Fillet (and Chamfer) against some ground truth?
>>>
>>> Cheers,
>>>
>>> John
>>>
>>> On Fri, Jul 6, 2018 at 8:40 PM, Nick Østergaard  wrote:
>>>> Hi
>>>>
>>>> I guess we could add it to the qa target somehow? What I don't 
>>>> particularyly
>>>> like with this patch is that executing "make test" does not check for
>>>> dependency changes.
>>>>
>>>> Back to the status about qa_geometry... it did pass a long time ago, doing 
>>>> a
>>>> bit of git bisect points at this commit as the one breaking the test.
>>>>
>>>> fbf10e941bdf26bb3618aba0a1b7c44fd0bafed2 is the first bad commit
>>>> commit fbf10e941bdf26bb3618aba0a1b7c44fd0bafed2
>>>> Author: Jeff Young
>>>> Date:   Thu Mar 22 18:02:45 2018 +
>>>>
>>>> Switch zone fillets to absolute-error algorithm.
>>>>
>>>> And some general cleanup to related constants, etc.
>>>>
>>>> :04 04 8b6ad8d44a7b38e0355ce5c8897f823d6255f811
>>>> 8d54d43a9bd6e5062d6b804890a779e785e430cc Mcommon
>>>> :04 04 5a90dc20fe7cb3f74ae1768a5b5024a902c9354d
>>>> a2be92ebd64fd46ad1

Re: [Kicad-developers] [PATCH] qa_geometry tests

[John Beard]

Note to Wayne: Nothing here concerns v5 release, I was just trying to
get a geom test working for future.

On Mon, Jul 9, 2018 at 9:12 AM, John Beard  wrote:
> Hi,
>
> Let's come back to the make test behaviour after v5, I think we'll
> need to discuss that separately. However, I think this does illustrate
> why we need the tests to be runnable easily, otherwise they suffer
> bit-rot, and then the tests are useless.
>
> Looking at that change, the test is now iterating the second parameter
> which is now "max error", not "number of segments". Does this test
> still make any sense? It's now comparing:
>
> SHAPE_POLY_SET::Fillet( radius, error );
>
> with
>
> CPolyLine::Fillet( radius, segments );
>
> The original test was designed to ensure SHAPE_POLY_SET::Fillet and
> CPolyLine::Fillet were the same, but they now have different
> interfaces and semantics. Wouldn't it be better to check
> SHAPE_POLY_SET::Fillet (and Chamfer) against some ground truth?
>
> Cheers,
>
> John
>
> On Fri, Jul 6, 2018 at 8:40 PM, Nick Østergaard  wrote:
>> Hi
>>
>> I guess we could add it to the qa target somehow? What I don't particularyly
>> like with this patch is that executing "make test" does not check for
>> dependency changes.
>>
>> Back to the status about qa_geometry... it did pass a long time ago, doing a
>> bit of git bisect points at this commit as the one breaking the test.
>>
>> fbf10e941bdf26bb3618aba0a1b7c44fd0bafed2 is the first bad commit
>> commit fbf10e941bdf26bb3618aba0a1b7c44fd0bafed2
>> Author: Jeff Young
>> Date:   Thu Mar 22 18:02:45 2018 +
>>
>> Switch zone fillets to absolute-error algorithm.
>>
>> And some general cleanup to related constants, etc.
>>
>> :04 04 8b6ad8d44a7b38e0355ce5c8897f823d6255f811
>> 8d54d43a9bd6e5062d6b804890a779e785e430cc Mcommon
>> :04 04 5a90dc20fe7cb3f74ae1768a5b5024a902c9354d
>> a2be92ebd64fd46ad17427e8e3c12da7f10df699 Minclude
>> :04 04 af9f333c0f56dca3a90fb7b04f385dbf39425e8d
>> 99b5f9757c78216a08220b7eb056f343658b961d Mpcbnew
>>
>>
>> Den tor. 5. jul. 2018 kl. 12.13 skrev John Beard :
>>>
>>> Hi,
>>>
>>> Are the qa_geometry test supposed to all work?
>>>
>>> When I run `qa_geometry`, I get 1160 errors like this:
>>>
>>> error: in "ChamferFillet/Fillet": check { chainPoints.begin(),
>>> chainPoints.end() } == { polyPoints.begin(), polyPoints.end() } has
>>> failed.
>>>
>>> Mismatch at position 0: [ 40 | 14 ] != [ 40 | 12 ]
>>> Mismatch at position 1: [ 40 | 15 ] != [ 40 | 13 ]
>>> Mismatch at position 2: [ 44 | 10 ] != [ 40 | 14 ]
>>> Mismatch at position 3: [ 44 | 18 ] != [ 40 | 15 ]
>>> Mismatch at position 4: [ 50 | 10 ] != [ 40 | 16 ]
>>> Mismatch at position 5: [ 51 | 14 ] != [ 40 | 17 ]
>>> Collections size mismatch: 6 != 25
>>>
>>> Attached is a patch that enabled CTest tests and adds qa_geometry as a
>>> test. Then you can run `make test` or `ctest` to run all tests. I
>>> think it would be good to have a single unambigous and easily
>>> understood command to be able to run unit tests?
>>>
>>> This patch explicitly excludes the "ChamferFillet/Fillet" tests as
>>> they are failing, but if those tests can be fixed, it would be good to
>>> run them too.
>>>
>>> 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

___
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] qa_geometry tests

[John Beard]

Hi,

Let's come back to the make test behaviour after v5, I think we'll
need to discuss that separately. However, I think this does illustrate
why we need the tests to be runnable easily, otherwise they suffer
bit-rot, and then the tests are useless.

Looking at that change, the test is now iterating the second parameter
which is now "max error", not "number of segments". Does this test
still make any sense? It's now comparing:

SHAPE_POLY_SET::Fillet( radius, error );

with

CPolyLine::Fillet( radius, segments );

The original test was designed to ensure SHAPE_POLY_SET::Fillet and
CPolyLine::Fillet were the same, but they now have different
interfaces and semantics. Wouldn't it be better to check
SHAPE_POLY_SET::Fillet (and Chamfer) against some ground truth?

Cheers,

John

On Fri, Jul 6, 2018 at 8:40 PM, Nick Østergaard  wrote:
> Hi
>
> I guess we could add it to the qa target somehow? What I don't particularyly
> like with this patch is that executing "make test" does not check for
> dependency changes.
>
> Back to the status about qa_geometry... it did pass a long time ago, doing a
> bit of git bisect points at this commit as the one breaking the test.
>
> fbf10e941bdf26bb3618aba0a1b7c44fd0bafed2 is the first bad commit
> commit fbf10e941bdf26bb3618aba0a1b7c44fd0bafed2
> Author: Jeff Young
> Date:   Thu Mar 22 18:02:45 2018 +
>
> Switch zone fillets to absolute-error algorithm.
>
> And some general cleanup to related constants, etc.
>
> :04 04 8b6ad8d44a7b38e0355ce5c8897f823d6255f811
> 8d54d43a9bd6e5062d6b804890a779e785e430cc Mcommon
> :04 04 5a90dc20fe7cb3f74ae1768a5b5024a902c9354d
> a2be92ebd64fd46ad17427e8e3c12da7f10df699 Minclude
> :04 04 af9f333c0f56dca3a90fb7b04f385dbf39425e8d
> 99b5f9757c78216a08220b7eb056f343658b961d Mpcbnew
>
>
> Den tor. 5. jul. 2018 kl. 12.13 skrev John Beard :
>>
>> Hi,
>>
>> Are the qa_geometry test supposed to all work?
>>
>> When I run `qa_geometry`, I get 1160 errors like this:
>>
>> error: in "ChamferFillet/Fillet": check { chainPoints.begin(),
>> chainPoints.end() } == { polyPoints.begin(), polyPoints.end() } has
>> failed.
>>
>> Mismatch at position 0: [ 40 | 14 ] != [ 40 | 12 ]
>> Mismatch at position 1: [ 40 | 15 ] != [ 40 | 13 ]
>> Mismatch at position 2: [ 44 | 10 ] != [ 40 | 14 ]
>> Mismatch at position 3: [ 44 | 18 ] != [ 40 | 15 ]
>> Mismatch at position 4: [ 50 | 10 ] != [ 40 | 16 ]
>> Mismatch at position 5: [ 51 | 14 ] != [ 40 | 17 ]
>> Collections size mismatch: 6 != 25
>>
>> Attached is a patch that enabled CTest tests and adds qa_geometry as a
>> test. Then you can run `make test` or `ctest` to run all tests. I
>> think it would be good to have a single unambigous and easily
>> understood command to be able to run unit tests?
>>
>> This patch explicitly excludes the "ChamferFillet/Fillet" tests as
>> they are failing, but if those tests can be fixed, it would be good to
>> run them too.
>>
>> 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

___
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] qa_geometry tests

[John Beard]

Hi,

Are the qa_geometry test supposed to all work?

When I run `qa_geometry`, I get 1160 errors like this:

error: in "ChamferFillet/Fillet": check { chainPoints.begin(),
chainPoints.end() } == { polyPoints.begin(), polyPoints.end() } has
failed.

Mismatch at position 0: [ 40 | 14 ] != [ 40 | 12 ]
Mismatch at position 1: [ 40 | 15 ] != [ 40 | 13 ]
Mismatch at position 2: [ 44 | 10 ] != [ 40 | 14 ]
Mismatch at position 3: [ 44 | 18 ] != [ 40 | 15 ]
Mismatch at position 4: [ 50 | 10 ] != [ 40 | 16 ]
Mismatch at position 5: [ 51 | 14 ] != [ 40 | 17 ]
Collections size mismatch: 6 != 25

Attached is a patch that enabled CTest tests and adds qa_geometry as a
test. Then you can run `make test` or `ctest` to run all tests. I
think it would be good to have a single unambigous and easily
understood command to be able to run unit tests?

This patch explicitly excludes the "ChamferFillet/Fillet" tests as
they are failing, but if those tests can be fixed, it would be good to
run them too.

Cheers,

John
From a6b98ecfd06529d7722a2834083d67a011741e63 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Thu, 5 Jul 2018 11:11:57 +0100
Subject: [PATCH] Enable CTest tests and add qa_geometry as a test

This allows the use of `make test` or `ctest` to run all registered
tests.

The ChamferFillet/Fillet test is disabled for now as it fails.
---
 CMakeLists.txt | 1 +
 qa/geometry/CMakeLists.txt | 4 
 2 files changed, 5 insertions(+)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index f2ea761f9..60c22c2f4 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -912,6 +912,7 @@ if( UNIX AND NOT APPLE )
 endif()
 
 #include( CTest )
+enable_testing()
 
 if( UNIX AND NOT APPLE )
 
diff --git a/qa/geometry/CMakeLists.txt b/qa/geometry/CMakeLists.txt
index b932bfb74..19ca8b91b 100644
--- a/qa/geometry/CMakeLists.txt
+++ b/qa/geometry/CMakeLists.txt
@@ -54,3 +54,7 @@ target_link_libraries(qa_geometry
 )
 
 add_dependencies( qa_geometry pcbnew )
+
+add_test( NAME geometry
+COMMAND qa_geometry --run_test=!ChamferFillet/Fillet
+)
\ No newline at end of file
-- 
2.17.1

___
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/QUESTION] Fix -Wshadow warnings in sch_sheet_path.cpp

[John Beard]

Hi,

Simple patch to fix a trio of -Wshadow warnings in SCH_SHEET_PATH.

Apparently, these shadow declarations from the STL vector header:

/home/john/src/kicad/eeschema/sch_sheet_path.cpp: In member
function ‘void SCH_SHEET_PATH::GetComponents(SCH_REFERENCE_LIST&,
bool, bool)’:
/home/john/src/kicad/eeschema/sch_sheet_path.cpp:202:42: warning:
declaration of ‘reference’ shadows a previous local [-Wshadow]
 SCH_REFERENCE reference( component, part, *this );
  ^
In file included from /usr/include/c++/8.1.1/vector:64,
 from /home/john/src/kicad/include/macros.h:34,
 from /home/john/src/kicad/eeschema/./sch_screen.h:33,
 from /home/john/src/kicad/eeschema/sch_sheet_path.cpp:34:
/usr/include/c++/8.1.1/bits/stl_vector.h:367:50: note: shadowed
declaration is here
   typedef typename _Alloc_traits::reference  reference;

I'm unclear on how that has come about, as I can't see anything
obviously allowing std::vector::reference to be shadowed here.

The only use of a using or typedef called "reference" seems to be in
iterator.h, but it's private and looks unrelated anyway:

using reference = typename DLIST_ITERATOR::reference;

With this code, I get no errors:

#include 

int main() {
int reference = 0;
return reference;
}

Even with this code, I don't get the same error:

#include 
using reference = std::vector::reference;

int main() {
int reference = 0;
return reference;
}

$ g++ -Wall -Wextra -Wshadow wshadow.cpp -o wshadow.o
wshadow.cpp: In function ‘int main()’:
wshadow.cpp:9:9: warning: declaration of ‘reference’ shadows a
global declaration [-Wshadow]
 int reference = 0;

The patch fixes the error by renaming the offending variables to
"schReference", but I think it would be nicer to see if we can avoid
the vector typedef leaking out so it can even be shadowed in the first
place?

Compiler is GCC 8.1.1, which might have a bearing on reproducibility.

Cheers,

John
From 0a716288c7877f239c907ea360632a6778914b49 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Thu, 28 Jun 2018 14:36:14 +0100
Subject: [PATCH] Fix -Wshadow warning in sch_sheet_path.cpp
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Three instances of variables named "reference" shadow a typedef
within std::vector producing:

warning: declaration of ‘reference’ shadows a previous local [-Wshadow]
 note: shadowed declaration is here
   typedef typename _Alloc_traits::reference  reference;

This patch works around by renaming "reference" to "schReference".
---
 eeschema/sch_sheet_path.cpp | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/eeschema/sch_sheet_path.cpp b/eeschema/sch_sheet_path.cpp
index b0b34cb6b..2be088f7b 100644
--- a/eeschema/sch_sheet_path.cpp
+++ b/eeschema/sch_sheet_path.cpp
@@ -199,10 +199,10 @@ void SCH_SHEET_PATH::GetComponents( SCH_REFERENCE_LIST& aReferences, bool aInclu
 
 if( part || aForceIncludeOrphanComponents )
 {
-SCH_REFERENCE reference( component, part, *this );
+SCH_REFERENCE schReference( component, part, *this );
 
-reference.SetSheetNumber( m_pageNumber );
-aReferences.AddItem( reference );
+schReference.SetSheetNumber( m_pageNumber );
+aReferences.AddItem( schReference );
 }
 }
 }
@@ -229,15 +229,15 @@ void SCH_SHEET_PATH::GetMultiUnitComponents( SCH_MULTI_UNIT_REFERENCE_MAP& aRefL
 
 if( part && part->GetUnitCount() > 1 )
 {
-SCH_REFERENCE reference = SCH_REFERENCE( component, part, *this );
-reference.SetSheetNumber( m_pageNumber );
-wxString reference_str = reference.GetRef();
+SCH_REFERENCE schReference = SCH_REFERENCE( component, part, *this );
+schReference.SetSheetNumber( m_pageNumber );
+wxString reference_str = schReference.GetRef();
 
 // Never lock unassigned references
 if( reference_str[reference_str.Len() - 1] == '?' )
 continue;
 
-aRefList[reference_str].AddItem( reference );
+aRefList[reference_str].AddItem( schReference );
 }
 }
 }
@@ -536,8 +536,8 @@ void SCH_SHEET_LIST::AnnotatePowerSymbols()
 
 if( part )
 {
-SCH_REFERENCE reference( component, part, spath );
-references.AddItem( reference );
+SCH_REFERENCE schReference( component, part, spath );
+references.AddItem( schReference );
 }
 }
 }
-- 
2.17.1

___
Mailing list: https://launch

Re: [Kicad-developers] [PATCH] GAL: Draw hole even if pad has no layer

[John Beard]

Hi,

I think with this kind of thing, KiCad should be strict with what it will 
accept. Otherwise you might find people rely on broken or undefined behaviour 
and de facto defaults and it all goes wrong when it's fixed or changed on 
KiCad's end in future. That's how you get "quirks modes". 

However, this should be enforced by the parser, which should reject the file, 
with a useful UI (not asserts), preferably including a reason and a line 
number. The file shouldn't make it far enough to cause defects within the 
program. Defective data in the main program can be checked with asserts, the 
triggering of which implies that either the parser is missing a check, or the 
internal logic is defective. Either way there should be no way for an end user 
to trigger one, no matter what they feed in. 

Ideally, there would be tests on that interface to ensure the parser catches 
malformed data, particularly when that data is shown to cause defects though 
bug reports. 

Thus a user can't get bad data into the main program, and also doesn't see 
asserts (which aren't present in the release code and should never be relied on 
for anything but development).

Cheers, 

John



On 25 June 2018 19:25:41 BST, Wayne Stambaugh  wrote:
>Hey Seth,
>
>I would agree with you if this was our error.  If I'm reading JP's
>analysis correctly, he could not create this board error using KiCad so
>I'm working on the assumption that this was not our board file output
>formatter causing the problem.  Using defensive measures such as
>assertions and test cases to ensure our board file output formatter is
>correct makes sense.  Adding code to our parser to fix board files that
>are broken due to manual editing or broken scripts is a slippery slope.
>Where do we draw the line?  This isn't the first time this has
>happened.
> In the past, we have chosen not to allow this so I am leaning in that
>direction.  It would be nice if the submitter of the broken board would
>confirm if the board was manually edited with a text editor or
>manipulated with a script.  I'm not completely dismissing the patch but
>it would be easier to make an informed decision if I knew how the
>broken
>board was created.
>
>Cheers,
>
>Wayne
>
>On 6/25/2018 10:25 AM, Seth Hillbrand wrote:
>> ​Hi Wayne-
>> 
>> I would view this patch more as defensive coding than trying to fix
>> others' errors.  The alternatives are to refuse to parse the file or
>(as
>> we currently do) parse as written and encounter errors in display and
>> routing.  JP's approach provides a clear and predictable response to
>a
>> modified file.
>> 
>> -Seth​
>> 
>> 
>> Am Mo., 25. Juni 2018 um 06:16 Uhr schrieb Wayne Stambaugh
>> mailto:stambau...@gmail.com>>:
>> 
>> On 6/25/2018 8:12 AM, jp charras wrote:
>> > Le 24/06/2018 à 21:52, Wayne Stambaugh a écrit :
>> >> Are we planning on fixing this for rc3?  If so, what is
>> required.  I'm fine with waiting a day or
>> >> two to tag rc3.
>> >>
>> >
>> > Attached a possible fix.
>> >
>> > The board test file shows really broken layer set in a few
>pads:
>> > - no layers for some pads (the layers section is empty).
>> > This make no sense for me.
>> >
>> > After tests, It is not possible to create this empty layer set
>> from Pcbnew (even with old 2013
>> > stable version).
>> >
>> > My opinion is the board (or the footprints) was modified by
>hand
>> (or by a script).
>> 
>> If this is the case, then I'm not thrilled about applying this
>patch
>> even if it does solve the problem.  We should not be modifying
>KiCad to
>> fix other people's coding errors.
>> 
>> >
>> > This patch is short and fixes silently this kind of issues.
>> > (I am not sure it is worth to try a better fix, because this
>issue
>> cannot happens when editing a
>> > board from pcbnew)
>> >
>> >
>> >
>> > ___
>> > 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

[Kicad-developers] [PATCH] Fix pad arrays for SDIP and micromatch plugins

[John Beard]

Hi,

This fixes some broken PadArray __init__ functions in the SDIP and
MicroMatch plugins.

Cheers,

John
From e7ee6a943d5c7be36500bb66e994cecd46978030 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Wed, 13 Jun 2018 19:16:01 +0100
Subject: [PATCH] Pcbnew python plugins: fix some pad arrays

Fixes some pad array init functions that were not calling the
calss hierarcy's init functions correctly.
---
 pcbnew/python/plugins/microMatch_connectors.py | 6 ++
 pcbnew/python/plugins/sdip_wizard.py   | 3 +++
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/pcbnew/python/plugins/microMatch_connectors.py b/pcbnew/python/plugins/microMatch_connectors.py
index fbf07fee9..e8134bdca 100644
--- a/pcbnew/python/plugins/microMatch_connectors.py
+++ b/pcbnew/python/plugins/microMatch_connectors.py
@@ -42,10 +42,8 @@ class PadStaggeredZGridArray(PA.PadArray):
 @param aCentre  Center position
 
 """
-PA.PadArray.__init__(self)
-# this pad is more of a "context", we will use it as a source of
-# pad data, but not actually add it
-self.pad = aPad
+super(PadStaggeredZGridArray, self).__init__(aPad)
+
 self.padCount = int(aPadCount)
 self.lineCount = int(aLineCount)
 self.linePitch = aLinePitch
diff --git a/pcbnew/python/plugins/sdip_wizard.py b/pcbnew/python/plugins/sdip_wizard.py
index ce7afb393..dfb9a0fcc 100644
--- a/pcbnew/python/plugins/sdip_wizard.py
+++ b/pcbnew/python/plugins/sdip_wizard.py
@@ -23,6 +23,9 @@ import PadArray as PA
 
 class RowedGridArray(PA.PadGridArray):
 
+def __init__(self, *args, **kwargs):
+super(RowedGridArray, self).__init__(*args, **kwargs)
+
 def NamingFunction(self, x, y):
 pad_cnt = self.nx*self.ny
 
-- 
2.17.1

___
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] Add logo to documentation

[John Beard]

Here is a patch for the Ki logo and a screenshot.

Cheers,

John



On Tue, Jun 19, 2018 at 1:30 PM, Wayne Stambaugh 
wrote:

> I concur.  The small KiCad logo would look better.
>
> https://github.com/KiCad/kicad-source-mirror/blob/
> master/bitmaps_png/sources/kicad_logo_small.svg
>
> On 6/18/2018 6:06 AM, Nick Østergaard wrote:
> > Mmm, I think I would prefer the Ki logo
> >
> > man. 18. jun. 2018 10.11 skrev John Beard  > <mailto:john.j.be...@gmail.com>>:
> >
> > In that case, here is the patch with the 48px app logo in the top
> > left. Doxygen recommends 55px max height, so 48px seems a handy size.
> >
> > Screenshot for reference.
> >
> > Cheers,
> >
> > John
> >
> > On Sun, Jun 17, 2018 at 5:58 PM, Wayne Stambaugh
> > mailto:stambau...@gmail.com>> wrote:
> >
> > I'm OK with the short logo image.  This would probably look
> > better than
> > the redundant KiCad.
> >
> > On 06/17/2018 08:53 AM, John Beard wrote:
> > > Sadly I don't think there is a way to set the logo alt text in
> doxygen
> > > (so it would still read "KiCad" when the image is not
> displayed, for
> > > screen readers, when copy-pasted and it when search engines
> index it).
> > >
> > > Alternatively, use the square icon rather than the text logo
> and keep
> > > the title as it is?
> > >
> > > Cheers,
> > >
> > > John
> > >
> > > On Wed, Jun 13, 2018 at 11:18 PM, Wayne Stambaugh <
> stambau...@gmail.com <mailto:stambau...@gmail.com>
> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
> wrote:
> > >
> > > I agree.  The double KiCad does look a bit odd but I do
> like the
> > > KiCad logo embedded in the docs.
> > >
> > > On 06/13/2018 06:00 PM, Nick Østergaard wrote:
> > >
> > > Maybe we need to remove the word KiCad from the title,
> as  it
> > > essentially reads  "[KiCad] KiCad Pcbnew Python
> Scripting"
> > >
> > >
> > > 2018-06-13 21:12 GMT+02:00 John Beard <
> john.j.be...@gmail.com <mailto:john.j.be...@gmail.com>
> > > <mailto:john.j.be...@gmail.com
> > <mailto:john.j.be...@gmail.com>> <mailto:john.j.be...@gmail.com
> > <mailto:john.j.be...@gmail.com>
> > > <mailto:john.j.be...@gmail.com  john.j.be...@gmail.com>>>>:
> > >
> > > Sorry, I had a line commented in a local commit to
> avoid a
> > > costly
> > > re-build of the docstrings when I didn't need them
> to be
> > > (the doc
> > > dependencies aren't managed by CMake, it just
> always runs the
> > > targets, which is fine for CI).
> > >
> > > The attached should be better (difference is a
> lack of a "#
> > > " before
> > > DEPENDS xml-to-docstrings)
> > >
> > > Cheers,
> > >
> > > John
> > >
> > > On Wed, Jun 13, 2018 at 8:04 PM, Wayne Stambaugh
> > > mailto:stambau...@gmail.com
> >
> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>
> > > <mailto:stambau...@gmail.com
> > <mailto:stambau...@gmail.com> <mailto:stambau...@gmail.com
> > <mailto:stambau...@gmail.com>>>> wrote:
> > >
> > > John,
> > >
> > > I am getting the following error when I try to
> > apply
> > > your patch:
> > >
> > > $ git am --ignore-whitespace <
> > >
> > >
> >  /c/Users/wstambaugh/Documents/Archive/temp/kicad/
> patches/0001-Documentation-add-logo-to-Doxygen-pages.patch
> > > Applying: Documentation: add logo to Doxygen
> pages
> >

Re: [Kicad-developers] [PATCH] Add logo to documentation

[John Beard]

In that case, here is the patch with the 48px app logo in the top left.
Doxygen recommends 55px max height, so 48px seems a handy size.

Screenshot for reference.

Cheers,

John

On Sun, Jun 17, 2018 at 5:58 PM, Wayne Stambaugh 
wrote:

> I'm OK with the short logo image.  This would probably look better than
> the redundant KiCad.
>
> On 06/17/2018 08:53 AM, John Beard wrote:
> > Sadly I don't think there is a way to set the logo alt text in doxygen
> > (so it would still read "KiCad" when the image is not displayed, for
> > screen readers, when copy-pasted and it when search engines index it).
> >
> > Alternatively, use the square icon rather than the text logo and keep
> > the title as it is?
> >
> > Cheers,
> >
> > John
> >
> > On Wed, Jun 13, 2018 at 11:18 PM, Wayne Stambaugh  > <mailto:stambau...@gmail.com>> wrote:
> >
> > I agree.  The double KiCad does look a bit odd but I do like the
> > KiCad logo embedded in the docs.
> >
> > On 06/13/2018 06:00 PM, Nick Østergaard wrote:
> >
> > Maybe we need to remove the word KiCad from the title, as  it
> > essentially reads  "[KiCad] KiCad Pcbnew Python Scripting"
> >
> >
> > 2018-06-13 21:12 GMT+02:00 John Beard  > <mailto:john.j.be...@gmail.com> <mailto:john.j.be...@gmail.com
> > <mailto:john.j.be...@gmail.com>>>:
> >
> > Sorry, I had a line commented in a local commit to avoid a
> > costly
> > re-build of the docstrings when I didn't need them to be
> > (the doc
> > dependencies aren't managed by CMake, it just always runs the
> > targets, which is fine for CI).
> >
> > The attached should be better (difference is a lack of a "#
> > " before
> > DEPENDS xml-to-docstrings)
> >
> > Cheers,
> >
> > John
> >
> > On Wed, Jun 13, 2018 at 8:04 PM, Wayne Stambaugh
> > mailto:stambau...@gmail.com>
> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
> wrote:
> >
> > John,
> >
> > I am getting the following error when I try to apply
> > your patch:
> >
> > $ git am --ignore-whitespace <
> >
> > /c/Users/wstambaugh/Documents/Archive/temp/kicad/patches/
> 0001-Documentation-add-logo-to-Doxygen-pages.patch
> > Applying: Documentation: add logo to Doxygen pages
> > error: patch failed: pcbnew/CMakeLists.txt:533
> > error: pcbnew/CMakeLists.txt: patch does not apply
> > Patch failed at 0001 Documentation: add logo to Doxygen
> > pages
> > Use 'git am --show-current-patch' to see the failed patch
> > When you have resolved this problem, run "git am
> > --continue".
> > If you prefer to skip this patch, run "git am --skip"
> > instead.
> > To restore the original branch and stop patching, run
> > "git am
> > --abort".
> >
> > It appears to be choking on the pcbnew/CMakeFile.txt.
> Is it
> > possible
> > that you have other changes to this file that are not in
> the
> > master branch?
> >
> > Cheers,
> >
> > Wayne
> >
> > On 6/13/2018 1:50 PM, John Beard wrote:
> >  > Hi,
> >  >
> >  > This patch adds a small KiCad logo to the three
> doxygen
> > documentation
> >  > targets (C++, dev docs and Python docs) for a little
> > bit more
> > flair.
> >  >
> >  > The image itself is put in the /Documentation dir,
> > but it's
> > not really
> >  > important to the process where it goes.
> >  >
> >  > Cheers,
> >  >
> >  > John
> >  >
> >  >
> >  > ___
> >  > Mailing list: https://launchpad.net/~kicad-developers

Re: [Kicad-developers] [PATCH] Add logo to documentation

[John Beard]

Sadly I don't think there is a way to set the logo alt text in doxygen (so
it would still read "KiCad" when the image is not displayed, for screen
readers, when copy-pasted and it when search engines index it).

Alternatively, use the square icon rather than the text logo and keep the
title as it is?

Cheers,

John

On Wed, Jun 13, 2018 at 11:18 PM, Wayne Stambaugh 
wrote:

> I agree.  The double KiCad does look a bit odd but I do like the KiCad
> logo embedded in the docs.
>
> On 06/13/2018 06:00 PM, Nick Østergaard wrote:
>
>> Maybe we need to remove the word KiCad from the title, as  it essentially
>> reads  "[KiCad] KiCad Pcbnew Python Scripting"
>>
>>
>> 2018-06-13 21:12 GMT+02:00 John Beard > john.j.be...@gmail.com>>:
>>
>> Sorry, I had a line commented in a local commit to avoid a costly
>> re-build of the docstrings when I didn't need them to be (the doc
>> dependencies aren't managed by CMake, it just always runs the
>> targets, which is fine for CI).
>>
>> The attached should be better (difference is a lack of a "# " before
>> DEPENDS xml-to-docstrings)
>>
>> Cheers,
>>
>> John
>>
>> On Wed, Jun 13, 2018 at 8:04 PM, Wayne Stambaugh
>> mailto:stambau...@gmail.com>> wrote:
>>
>> John,
>>
>> I am getting the following error when I try to apply your patch:
>>
>> $ git am --ignore-whitespace <
>> /c/Users/wstambaugh/Documents/Archive/temp/kicad/patches/000
>> 1-Documentation-add-logo-to-Doxygen-pages.patch
>> Applying: Documentation: add logo to Doxygen pages
>> error: patch failed: pcbnew/CMakeLists.txt:533
>> error: pcbnew/CMakeLists.txt: patch does not apply
>> Patch failed at 0001 Documentation: add logo to Doxygen pages
>> Use 'git am --show-current-patch' to see the failed patch
>> When you have resolved this problem, run "git am --continue".
>> If you prefer to skip this patch, run "git am --skip" instead.
>> To restore the original branch and stop patching, run "git am
>> --abort".
>>
>> It appears to be choking on the pcbnew/CMakeFile.txt.  Is it
>> possible
>> that you have other changes to this file that are not in the
>> master branch?
>>
>> Cheers,
>>
>> Wayne
>>
>> On 6/13/2018 1:50 PM, John Beard wrote:
>>  > Hi,
>>  >
>>  > This patch adds a small KiCad logo to the three doxygen
>> documentation
>>  > targets (C++, dev docs and Python docs) for a little bit more
>> flair.
>>  >
>>  > The image itself is put in the /Documentation dir, but it's
>> not really
>>  > important to the process where it goes.
>>  >
>>  > Cheers,
>>  >
>>  > John
>>  >
>>  >
>>  > ___
>>  > Mailing list: https://launchpad.net/~kicad-developers
>> <https://launchpad.net/~kicad-developers>
>>  > Post to : kicad-developers@lists.launchpad.net
>> <mailto:kicad-developers@lists.launchpad.net>
>>  > Unsubscribe : https://launchpad.net/~kicad-developers
>> <https://launchpad.net/~kicad-developers>
>>  > More help   : https://help.launchpad.net/ListHelp
>> <https://help.launchpad.net/ListHelp>
>>  >
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@lists.launchpad.net
>> <mailto:kicad-developers@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp
>> <https://help.launchpad.net/ListHelp>
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@lists.launchpad.net
>> <mailto:kicad-developers@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp
>> <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] Add logo to documentation

[John Beard]

Sorry, I had a line commented in a local commit to avoid a costly re-build
of the docstrings when I didn't need them to be (the doc dependencies
aren't managed by CMake, it just always runs the targets, which is fine for
CI).

The attached should be better (difference is a lack of a "# " before
DEPENDS xml-to-docstrings)

Cheers,

John

On Wed, Jun 13, 2018 at 8:04 PM, Wayne Stambaugh 
wrote:

> John,
>
> I am getting the following error when I try to apply your patch:
>
> $ git am --ignore-whitespace <
> /c/Users/wstambaugh/Documents/Archive/temp/kicad/patches/
> 0001-Documentation-add-logo-to-Doxygen-pages.patch
> Applying: Documentation: add logo to Doxygen pages
> error: patch failed: pcbnew/CMakeLists.txt:533
> error: pcbnew/CMakeLists.txt: patch does not apply
> Patch failed at 0001 Documentation: add logo to Doxygen pages
> Use 'git am --show-current-patch' to see the failed patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
>
> It appears to be choking on the pcbnew/CMakeFile.txt.  Is it possible
> that you have other changes to this file that are not in the master branch?
>
> Cheers,
>
> Wayne
>
> On 6/13/2018 1:50 PM, John Beard wrote:
> > Hi,
> >
> > This patch adds a small KiCad logo to the three doxygen documentation
> > targets (C++, dev docs and Python docs) for a little bit more flair.
> >
> > The image itself is put in the /Documentation dir, but it's not really
> > important to the process where it goes.
> >
> > 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
> >
>
> ___
> 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 48479b55392b2ba51f6ed16deccd9953f0e96688 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Wed, 13 Jun 2018 12:51:49 +0100
Subject: [PATCH 1/3] Documentation: add logo to Doxygen pages

This adds a small KiCad logo in the top left of the Doxygen pages.

For the main docs and the dev docs, this is easily done in the Doxyfile,
for the Python docs, as that is run from the binary dir, the source dir
is passed as an Environment variable.
---
 Documentation/development/Doxyfile   |   2 +-
 Documentation/kicad_doxygen_logo.png | Bin 0 -> 2793 bytes
 Doxyfile |   2 +-
 pcbnew/CMakeLists.txt|   5 -
 pcbnew/Doxyfile_python   |   2 +-
 5 files changed, 7 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/kicad_doxygen_logo.png

diff --git a/Documentation/development/Doxyfile b/Documentation/development/Doxyfile
index f005d917d..02d6b3e83 100644
--- a/Documentation/development/Doxyfile
+++ b/Documentation/development/Doxyfile
@@ -46,7 +46,7 @@ PROJECT_BRIEF  =
 # exceed 55 pixels and the maximum width should not exceed 200 pixels.
 # Doxygen will copy the logo to the output directory.
 
-PROJECT_LOGO   =
+PROJECT_LOGO   = ../kicad_doxygen_logo.png
 
 # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
 # base path where the generated documentation will be put.
diff --git a/Documentation/kicad_doxygen_logo.png b/Documentation/kicad_doxygen_logo.png
new file mode 100644
index ..c7a1b0f85136811ebc095ee5dee7f684f394b834
GIT binary patch
literal 2793
zcmV000H>0l?8FWQhbW?9;ba!ELWdL_~cP?peYja~^
zaAhuUa%Y?FJQ@H13T8<}K~#9!?VJmA6xA7k7qoiNwx@@x!0rTWp_tv74GC$XAeESM
zjtKH>R$hY1%xnmFh*p6Bt!D96s3KTJc?eoc5kwFokHae{sH9dzgo8rB1W3c9NFIc+
zd63)x=+F>~+i+I9sufT_EZ?!-OkK-PRLrsIVUfTv~*9Dm)Ff~Ur|kt-?j}sNn_3J}
zFhU1ChYMvN$cN={zCpU#1pA)S!b;;ZC-vypH(PB@q>8>YJ!?`fWrw
zJYy%o{Vr|<)b;$!Kj+i0i}*yg_4GBFyXk-;21b!H7fd}
ztxYf*a@wJ19?A9{J9MK72ccOVQWD2YIRqIWGjL!@8SxLad2%YMnQ_YxV4QrSE1EX$
z>89gMIEd{|e(H~Hym-OJOGsVhkEq~~X6;8a=Y38kDdV=OkN+sjq`&^prhqUZ?-?
zwaAtBH#B(Eiq_v7grl21vkP=wI&{z*FnTt@>u2!(8=D{<@V%Fx21~cy5kmK;Rkv
z*VcIe9mtZR@ucp}wQ?^jnx9;ot;01v+ILNWFHaHHvt_
z>JVS;lpy~iHsO#KF@Xbj`d7!kCn|K-U;nMCIM1tJQh~90)5+kcADwV;y(ZcG76Jt+
zwKhRqX^VHqR07WCkY8X1#|Jx$iAsG)+Nr9vd(*a{l5U|j5)59aM@3p${h5g2%y
z`8<~V5TO{z|on{aKOV~)uH$^AO#Su9D&#

[Kicad-developers] [PATCH] Add logo to documentation

[John Beard]

Hi,

This patch adds a small KiCad logo to the three doxygen documentation
targets (C++, dev docs and Python docs) for a little bit more flair.

The image itself is put in the /Documentation dir, but it's not really
important to the process where it goes.

Cheers,

John
From 3579685855ce1f022ce50fbed5294b67d730510f Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Wed, 13 Jun 2018 12:51:49 +0100
Subject: [PATCH] Documentation: add logo to Doxygen pages

This adds a small KiCad logo in the top left of the Doxygen pages.

For the main docs and the dev docs, this is easily done in the Doxyfile,
for the Python docs, as that is run from the binary dir, the source dir
is passed as an Environment variable.
---
 Documentation/development/Doxyfile   |   2 +-
 Documentation/kicad_doxygen_logo.png | Bin 0 -> 2793 bytes
 Doxyfile |   2 +-
 pcbnew/CMakeLists.txt|   5 -
 pcbnew/Doxyfile_python   |   2 +-
 5 files changed, 7 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/kicad_doxygen_logo.png

diff --git a/Documentation/development/Doxyfile b/Documentation/development/Doxyfile
index f005d917d..02d6b3e83 100644
--- a/Documentation/development/Doxyfile
+++ b/Documentation/development/Doxyfile
@@ -46,7 +46,7 @@ PROJECT_BRIEF  =
 # exceed 55 pixels and the maximum width should not exceed 200 pixels.
 # Doxygen will copy the logo to the output directory.
 
-PROJECT_LOGO   =
+PROJECT_LOGO   = ../kicad_doxygen_logo.png
 
 # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
 # base path where the generated documentation will be put.
diff --git a/Documentation/kicad_doxygen_logo.png b/Documentation/kicad_doxygen_logo.png
new file mode 100644
index ..c7a1b0f85136811ebc095ee5dee7f684f394b834
GIT binary patch
literal 2793
zcmV000H>0l?8FWQhbW?9;ba!ELWdL_~cP?peYja~^
zaAhuUa%Y?FJQ@H13T8<}K~#9!?VJmA6xA7k7qoiNwx@@x!0rTWp_tv74GC$XAeESM
zjtKH>R$hY1%xnmFh*p6Bt!D96s3KTJc?eoc5kwFokHae{sH9dzgo8rB1W3c9NFIc+
zd63)x=+F>~+i+I9sufT_EZ?!-OkK-PRLrsIVUfTv~*9Dm)Ff~Ur|kt-?j}sNn_3J}
zFhU1ChYMvN$cN={zCpU#1pA)S!b;;ZC-vypH(PB@q>8>YJ!?`fWrw
zJYy%o{Vr|<)b;$!Kj+i0i}*yg_4GBFyXk-;21b!H7fd}
ztxYf*a@wJ19?A9{J9MK72ccOVQWD2YIRqIWGjL!@8SxLad2%YMnQ_YxV4QrSE1EX$
z>89gMIEd{|e(H~Hym-OJOGsVhkEq~~X6;8a=Y38kDdV=OkN+sjq`&^prhqUZ?-?
zwaAtBH#B(Eiq_v7grl21vkP=wI&{z*FnTt@>u2!(8=D{<@V%Fx21~cy5kmK;Rkv
z*VcIe9mtZR@ucp}wQ?^jnx9;ot;01v+ILNWFHaHHvt_
z>JVS;lpy~iHsO#KF@Xbj`d7!kCn|K-U;nMCIM1tJQh~90)5+kcADwV;y(ZcG76Jt+
zwKhRqX^VHqR07WCkY8X1#|Jx$iAsG)+Nr9vd(*a{l5U|j5)59aM@3p${h5g2%y
z`8<~V5TO{z|on{aKOV~)uH$^AO#Su9D&#

Re: [Kicad-developers] Stable release update.

[John Beard]

Hi Wayne,

Great news!

I have one suggestion for a currently-un-milestoned bug that I'd (partly
selfishly) really like to see fixed for v5:
https://bugs.launchpad.net/kicad/+bug/1518694

This is the one where you can't shift posture when routing to a pad in the
PNS router. It's certainly not a critical bug, and can be worked around by
routing "backwards". However, if it's an easy fix (I'm trying to find it,
but I don't know anything about the router code, so I have so far only
managed to add a ton of trace and confuse myself), it would be shame IMO to
leave it in for release. It's something that pretty much all users of the
PNS router would run into almost as soon as they try to use it. If it's a
harder fix or introduces unacceptably risky changes to the router, then it
can wait.

Cheers,

John

On Tue, Jun 12, 2018 at 1:56 PM, Wayne Stambaugh 
wrote:

> I apologize for being absent the last few days but I had out of town
> guests visiting and I didn't want to be rude and spend a lot of time in
> front of my computer.
>
> Things seem to be coming along nicely for the v5 stable release and it
> appears that all of the critical bugs have been fixed.  Hopefully no new
> critical bugs will surface between now and release time and we can get
> some good testing on the critical bugs that were recently fixed.  I
> would *really* like to get the stable release out before I go on
> vacation during the week of July 4th.  Are there any known issues that
> anyone can think of that would prevent this from happening?  If so,
> please speak up.  If not, let's try to shoot for a June 29th release date.
>
> Thank you to everyone for 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
>
___
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] Python FP wizard helper: docstrings and rounded/chamfered rects

[John Beard]

Hi Nick,

It's a related concept, certainly. The drawing helper stuff acts as a
"buffer" between the Pcbnew API and the plugin writer, but this isn't
really a design aim, it's just a side effect. It certainly does not totally
insulate the writer from the Pcbnew API as it's a very limited subset of
functionality. Thus the user is still vulnerable to Pcbnew internal API
changes (and as Python is not a compiled language, they won't find out
until it all explodes at runtime!). It's better than calling on the Pcbnew
API directly (as there's only one place of breakage), but it's not a
panacea, and was never really designed to be.

However, these helpers also add some stuff that isn't just an API
translation layer, it adds stuff like a transform stack and helpers for
shapes like boxes and so on that would otherwise be repetitive in plugin
code. All this can (and should) be transplanted onto a new "stable" Python
interface in future.

Cheers,

John

On Tue, Jun 12, 2018 at 2:47 PM, Nick Østergaard  wrote:

> I am not sure if this will slightly derail this patch's topic. Sorry if
> that is the case and tell me to back off.
>
> There have been multiple attempts on getting the python API in better
> shape. Originally it was Ajo and some others with
> https://github.com/kicad/kicad-python
>
> But the most recent work is on
> https://github.com/pointhi/kicad-python
>
> Which is different from the initial work. I don't really know the state of
> that work.
>
> I would like to see a supported API, but I guess this could be blocked
> slightly because of the wxpython phoenix story.
>
>
>
> 2018-06-12 15:34 GMT+02:00 John Beard :
>
>> Hi Nick and Wayne,
>>
>> The patches as they are don't hook into the existing Python API doxygen
>> stuff as it's not exactly the same as the Python API, it's a helper layer
>> on top of that, and I was't sure if that would be OK.
>>
>> I will take a look at adding it to the existing Python doc generation if
>> that's an acceptable way to present it.
>>
>> Cheers,
>>
>> John
>>
>> On Tue, Jun 12, 2018 at 2:11 PM, Nick Østergaard 
>> wrote:
>>
>>> We already have doxygen generation for the python API, although people
>>> say that it is easier to read the C++ one. It is generated with
>>> the doxygen-python make target. See http://docs.kicad-pcb.org/
>>> doxygen-python/
>>>
>>> Does the additions in 0002 add to the normal python docs?
>>>
>>> 2018-06-12 15:07 GMT+02:00 Wayne Stambaugh :
>>>
>>>> Hey John,
>>>>
>>>> I like the idea of using doxygen to document the python plugins.  The
>>>> current Doxyfile does not include .py files so that would need to
>>>> change.  Before we do that, I would like to see a new section (maybe
>>>> "Python Plugins") added to the documentation to separate the python
>>>> plugin code from the c++ source documentation.  I can commit your patch
>>>> as is and you can make the doxygen changes in a later patch or I can
>>>> wait for you to create a new patch with all of the changes.  I'm fine
>>>> either way.
>>>>
>>>> Cheers,
>>>>
>>>> Wayne
>>>>
>>>> On 6/4/2018 7:33 AM, John Beard wrote:
>>>> > Hi,
>>>> >
>>>> > Here is a simple patch sequence for the Python Footprint Wizard
>>>> helpers:
>>>> >
>>>> > 1) Minor spelling and formatting tidy-up
>>>> > 2) Add docstrings for the wizard base. As this is intended to be used
>>>> > by writers of new plugins, having the functions documented is probably
>>>> > a Good Idea (TM)
>>>> > 3) Add rounded rectangle and chamfered rectangle helpers. Useful for
>>>> > some footprints or even board outlines.
>>>> >
>>>> > I used Doxygen-style docstrings, but I haven't actually done anything
>>>> > about building actual output docs with it. Any thoughts of if that
>>>> > should be done, and if so, where to put it?
>>>> >
>>>> > There shouldn't be anything here that will break existing plugins, the
>>>> > only API changes are additions.
>>>> >
>>>> > Cheers,
>>>> >
>>>> > John
>>>> >
>>>> >
>>>> >
>>>> > ___
>>>> > Mailing list: https://launchpad.net/~kicad-developers
>>>> > Post to : kicad-developers@lists.launchpad.net
>

Re: [Kicad-developers] [PATCH] Python FP wizard helper: docstrings and rounded/chamfered rects

[John Beard]

Hi Nick and Wayne,

The patches as they are don't hook into the existing Python API doxygen
stuff as it's not exactly the same as the Python API, it's a helper layer
on top of that, and I was't sure if that would be OK.

I will take a look at adding it to the existing Python doc generation if
that's an acceptable way to present it.

Cheers,

John

On Tue, Jun 12, 2018 at 2:11 PM, Nick Østergaard  wrote:

> We already have doxygen generation for the python API, although people say
> that it is easier to read the C++ one. It is generated with
> the doxygen-python make target. See http://docs.kicad-pcb.org/
> doxygen-python/
>
> Does the additions in 0002 add to the normal python docs?
>
> 2018-06-12 15:07 GMT+02:00 Wayne Stambaugh :
>
>> Hey John,
>>
>> I like the idea of using doxygen to document the python plugins.  The
>> current Doxyfile does not include .py files so that would need to
>> change.  Before we do that, I would like to see a new section (maybe
>> "Python Plugins") added to the documentation to separate the python
>> plugin code from the c++ source documentation.  I can commit your patch
>> as is and you can make the doxygen changes in a later patch or I can
>> wait for you to create a new patch with all of the changes.  I'm fine
>> either way.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 6/4/2018 7:33 AM, John Beard wrote:
>> > Hi,
>> >
>> > Here is a simple patch sequence for the Python Footprint Wizard helpers:
>> >
>> > 1) Minor spelling and formatting tidy-up
>> > 2) Add docstrings for the wizard base. As this is intended to be used
>> > by writers of new plugins, having the functions documented is probably
>> > a Good Idea (TM)
>> > 3) Add rounded rectangle and chamfered rectangle helpers. Useful for
>> > some footprints or even board outlines.
>> >
>> > I used Doxygen-style docstrings, but I haven't actually done anything
>> > about building actual output docs with it. Any thoughts of if that
>> > should be done, and if so, where to put it?
>> >
>> > There shouldn't be anything here that will break existing plugins, the
>> > only API changes are additions.
>> >
>> > 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
>> >
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [PATCH] Fix -Wparentheses warning in track_cleaner.cpp

[John Beard]

Hi,

This is a very simple patch to address a -Wparentheses warning in
pcbnew/track_cleaner.cpp.

It was "wxBusyCursor( dummy );", it is now "wxBusyCursor dummy;"

Cheers,

John
From 60b4e54c733934f42f1911c8c8a08d7c2ecf011a Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Tue, 12 Jun 2018 10:49:08 +0100
Subject: [PATCH] Fix -Wparentheses in track_cleaner.cpp
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Changes "wxBusyCursor( dummy );" to just "wxBusyCursor dummy;"

Fixes warning: ../pcbnew/tracks_cleaner.cpp:155:17:
warning: unnecessary parentheses in declaration of ‘dummy’ [-Wparentheses]
 wxBusyCursor( dummy )
---
 pcbnew/tracks_cleaner.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pcbnew/tracks_cleaner.cpp b/pcbnew/tracks_cleaner.cpp
index a291c1533..b853e02cc 100644
--- a/pcbnew/tracks_cleaner.cpp
+++ b/pcbnew/tracks_cleaner.cpp
@@ -152,7 +152,7 @@ void PCB_EDIT_FRAME::Clean_Pcb()
 // Old model has to be refreshed, GAL normally does not keep updating it
 Compile_Ratsnest( NULL, false );
 
-wxBusyCursor( dummy );
+wxBusyCursor dummy;
 BOARD_COMMIT commit( this );
 TRACKS_CLEANER cleaner( GetBoard(), commit );
 
-- 
2.17.0

___
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] Fix 'catching polymorphic type by value' warnings

[John Beard]

Hi,

Sorry, I missed one out in kicad/import_project.cpp

Cheers,

John

On Tue, Jun 5, 2018 at 8:43 AM, John Beard  wrote:

> Hi,
>
> Small patch to fix some warnings (GCC 8.1.0) like this:
>
> warning: catching polymorphic type ‘class std::out_of_range’ by value
> [-Wcatch-value=]
>  catch( std::out_of_range )
>  ^~~~
>
> Fixed by changing to catch-by-reference: "catch( const std:::out_of_range&
> )"
>
> C.f. recent commit ff1802d7a "Fix Coverity "Big parameter passed by value"
> warnings".
>
> As one of these fixes is in view.h, the warning came up a fair bit.
>
> Cheers,
>
> John
>
From dfe24f872bcc9665efbddd949e19a538258b5e12 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Tue, 5 Jun 2018 08:38:49 +0100
Subject: [PATCH] Common: Fix -Wcatch-value warnings (catching exceptions by
 value)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This fixes some warnings on GCC 8.1:

warning: catching polymorphic type ‘class std::out_of_range’ by value [-Wcatch-value=]
 catch( std::out_of_range )
 ^~~~

This fix is along the same lines as:

* ff1802d7a "Fix Coverity "Big parameter passed by value" warnings"
---
 common/view/view.cpp | 4 ++--
 include/view/view.h  | 2 +-
 kicad/import_project.cpp | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/common/view/view.cpp b/common/view/view.cpp
index d4e22ff6b..84f848cd4 100644
--- a/common/view/view.cpp
+++ b/common/view/view.cpp
@@ -207,7 +207,7 @@ private:
 {
 new_layer = aReorderMap.at( orig_layer );
 }
-catch( std::out_of_range ) {}
+catch( const std::out_of_range& ) {}
 
 m_groups[i].first = new_layer;
 }
@@ -665,7 +665,7 @@ void VIEW::ReorderLayerData( std::unordered_map aReorderMap )
 {
 new_idx = aReorderMap.at( orig_idx );
 }
-catch( std::out_of_range )
+catch( const std::out_of_range& )
 {
 new_idx = orig_idx;
 }
diff --git a/include/view/view.h b/include/view/view.h
index 1397b4d54..3938bfdf8 100644
--- a/include/view/view.h
+++ b/include/view/view.h
@@ -590,7 +590,7 @@ public:
 {
 return m_layers.at( aLayer ).target == TARGET_CACHED;
 }
-catch( std::out_of_range )
+catch( const std::out_of_range& )
 {
 return false;
 }
diff --git a/kicad/import_project.cpp b/kicad/import_project.cpp
index 4f9d04360..3bcc7bb9f 100644
--- a/kicad/import_project.cpp
+++ b/kicad/import_project.cpp
@@ -165,7 +165,7 @@ void KICAD_MANAGER_FRAME::OnImportEagleFiles( wxCommandEvent& event )
 {
 pcbframe = Kiway.Player( FRAME_PCB, true );
 }
-catch( IO_ERROR err )
+catch( const IO_ERROR& err )
 {
 wxMessageBox( _( "Pcbnew failed to load:\n" ) + err.What(), _( "KiCad Error" ),
 wxOK | wxICON_ERROR, this );
-- 
2.17.1

___
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] Fix 'catching polymorphic type by value' warnings

[John Beard]

Hi,

Small patch to fix some warnings (GCC 8.1.0) like this:

warning: catching polymorphic type ‘class std::out_of_range’ by value
[-Wcatch-value=]
 catch( std::out_of_range )
 ^~~~

Fixed by changing to catch-by-reference: "catch( const std:::out_of_range&
)"

C.f. recent commit ff1802d7a "Fix Coverity "Big parameter passed by value"
warnings".

As one of these fixes is in view.h, the warning came up a fair bit.

Cheers,

John
From 24c862577174450ba2a591797e2f6dd6b188e87c Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Tue, 5 Jun 2018 08:38:49 +0100
Subject: [PATCH] Common: Fix -Wcatch-value warnings (catching exceptions by
 value)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This fixes some warnings on GCC 8.1:

warning: catching polymorphic type ‘class std::out_of_range’ by value [-Wcatch-value=]
 catch( std::out_of_range )
 ^~~~

This fix is along the same lines as:

* ff1802d7a "Fix Coverity "Big parameter passed by value" warnings"
---
 common/view/view.cpp | 4 ++--
 include/view/view.h  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/common/view/view.cpp b/common/view/view.cpp
index d4e22ff6b..84f848cd4 100644
--- a/common/view/view.cpp
+++ b/common/view/view.cpp
@@ -207,7 +207,7 @@ private:
 {
 new_layer = aReorderMap.at( orig_layer );
 }
-catch( std::out_of_range ) {}
+catch( const std::out_of_range& ) {}
 
 m_groups[i].first = new_layer;
 }
@@ -665,7 +665,7 @@ void VIEW::ReorderLayerData( std::unordered_map aReorderMap )
 {
 new_idx = aReorderMap.at( orig_idx );
 }
-catch( std::out_of_range )
+catch( const std::out_of_range& )
 {
 new_idx = orig_idx;
 }
diff --git a/include/view/view.h b/include/view/view.h
index 1397b4d54..3938bfdf8 100644
--- a/include/view/view.h
+++ b/include/view/view.h
@@ -590,7 +590,7 @@ public:
 {
 return m_layers.at( aLayer ).target == TARGET_CACHED;
 }
-catch( std::out_of_range )
+catch( const std::out_of_range& )
 {
 return false;
 }
-- 
2.17.1

___
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] Python FP wizard helper: docstrings and rounded/chamfered rects

[John Beard]

Hi,

Here is a simple patch sequence for the Python Footprint Wizard helpers:

1) Minor spelling and formatting tidy-up
2) Add docstrings for the wizard base. As this is intended to be used
by writers of new plugins, having the functions documented is probably
a Good Idea (TM)
3) Add rounded rectangle and chamfered rectangle helpers. Useful for
some footprints or even board outlines.

I used Doxygen-style docstrings, but I haven't actually done anything
about building actual output docs with it. Any thoughts of if that
should be done, and if so, where to put it?

There shouldn't be anything here that will break existing plugins, the
only API changes are additions.

Cheers,

John
From 6073d002d607d0ba2ba9dac778997db0f93c6cb4 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Fri, 1 Jun 2018 12:19:31 +0100
Subject: [PATCH 1/3] Pcbnew FP wizard: minor style fixes

This contains only a few minor style fixes according to PEP8
for FootprintWizardBase.py, and some spelling fixes
---
 pcbnew/python/plugins/FootprintWizardBase.py | 89 +++-
 1 file changed, 48 insertions(+), 41 deletions(-)

diff --git a/pcbnew/python/plugins/FootprintWizardBase.py b/pcbnew/python/plugins/FootprintWizardBase.py
index 158128aea..023ee33a8 100644
--- a/pcbnew/python/plugins/FootprintWizardBase.py
+++ b/pcbnew/python/plugins/FootprintWizardBase.py
@@ -18,20 +18,21 @@ from __future__ import division
 import pcbnew
 import math
 
+
 # Base class for creating footprint wizards
 # Inherit this class to make a new wizard
 class FootprintWizard(pcbnew.FootprintWizardPlugin):
 
 # Copy units from pcbnew
-uMM = pcbnew.uMM
-uMils   = pcbnew.uMils
-uFloat  = pcbnew.uFloat
-uInteger= pcbnew.uInteger
-uBool   = pcbnew.uBool
-uRadians= pcbnew.uRadians
-uDegrees= pcbnew.uDegrees
-uPercent= pcbnew.uPercent
-uString = pcbnew.uString
+uMM = pcbnew.uMM
+uMils = pcbnew.uMils
+uFloat = pcbnew.uFloat
+uInteger = pcbnew.uInteger
+uBool = pcbnew.uBool
+uRadians = pcbnew.uRadians
+uDegrees = pcbnew.uDegrees
+uPercent = pcbnew.uPercent
+uString = pcbnew.uString
 
 """
 A class to simplify many aspects of footprint creation, leaving only
@@ -52,7 +53,7 @@ class FootprintWizard(pcbnew.FootprintWizardPlugin):
 
 def GetName(self):
 """
-Retun the name of the footprint wizard
+Return the name of the footprint wizard
 """
 raise NotImplementedError
 
@@ -72,7 +73,7 @@ class FootprintWizard(pcbnew.FootprintWizardPlugin):
 """
 Footprint parameter specification is done here
 """
-	raise NotImplementedError
+raise NotImplementedError
 
 def CheckParameters(self):
 """
@@ -84,43 +85,46 @@ class FootprintWizard(pcbnew.FootprintWizardPlugin):
 """
 Draw the footprint.
 
-This is specific to each footprint class, you need to implment
+This is specific to each footprint class, you need to implement
 this to draw what you want
 """
 raise NotImplementedError
 
 # Do not override this method!
-def BuildFootprint( self ):
+def BuildFootprint(self):
 """
-Actually make the footprint. We defer all but the setup to
+Actually make the footprint. We defer all but the set-up to
 the implementing class
 """
 
 self.buildmessages = ""
 self.module = pcbnew.MODULE(None)  # create a new module
 
-# Perform default checks on all params
+# Perform default checks on all parameters
 for p in self.params:
 p.ClearErrors()
-p.Check() # use defaults
-
-self.CheckParameters() # User error checks
+p.Check()  # use defaults
 
+self.CheckParameters()  # User error checks
 
 if self.AnyErrors():  # Errors were detected!
 
-self.buildmessages = "Cannot build footprint: Parameters have errors:\n"
+self.buildmessages = ("Cannot build footprint: "
+  "Parameters have errors:\n")
 
 for p in self.params:
 if len(p.error_list) > 0:
-self.buildmessages +="['{page}']['{name}']:\n".format(page=p.page,name=p.name)
+self.buildmessages += "['{page}']['{name}']:\n".format(
+page=p.page, name=p.name)
 
 for error in p.error_list:
 self.buildmessages += "\t" + error + "\n"
 
 return
 
-self.buildmessages = ("Building new {name} footprint with the following parameters:\n".format(name=self.name))
+self.buildmessages = (
+ 

Re: [Kicad-developers] v5 timeline

[John Beard]

I would beg to differ (e.g. how can anyone build a package when the
milestone doesn't have a VCS branch/tag and isn't released), but I
realise I don't understand at all how Kicad releases are planned and
executed.

What /is/ the right way to track issues targeted for future
milestones, if not milestones in the issue tracker? Awful as Launchpad
is, I find it useful to be able to see what remains to be done.

On Sun, Apr 2, 2017 at 3:05 AM, Wayne Stambaugh <stambau...@gmail.com> wrote:
> It doesn't make any sense without a 5.0 source branch which isn't going
> to happen until the items that I listed are ready.  Once that happens,
> then I will create a 5.0 branch.  The problem is that you've assign a 5
> series without the associated code branch.  If you leave it, I promise
> you someone will build a 5.0-rc1 package which is completely false.
> Then users will assume that we are near to a v5 release which we are
> not.  None of this should have happened without at least some discussion.
>
> On 4/1/2017 2:09 PM, Chris Pavlina wrote:
>> I think having a milestone for use in the bug tracker is valuable, I
>> would urge you not to have that deleted. The v5 series can go ofc.
>>
>> On Apr 1, 2017 11:31 AM, "Wayne Stambaugh" <stambau...@gmail.com
>> <mailto:stambau...@gmail.com>> wrote:
>>
>> Only kicad-committers should be able to do this.  When I get a chance I
>> check the launchpad permissions.  Please remove it when you get a
>> chance.  I do not want users thinking this is an official rc1 candidate.
>>  It is not.  The symbol library table, stitching via, and revised
>> connection algorithm are all part of v5 rc1.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 3/31/2017 5:27 PM, John Beard wrote:
>> > Hi,
>> >
>> > I "accidentally" made a Launchpad series for v5:
>> >
>> > https://launchpad.net/kicad/5.0 <https://launchpad.net/kicad/5.0>
>> >
>> > I wasn't really expecting to have permissions to do that, but it went
>> > though, so here it is! I doubled down on it and so there's also a
>> > milestone for RC1. Project management people are of course welcome to
>> > assign themselves as managers as needed.
>> >
>> > I think we can use these to target important bugs/features to v5, so
>> > we can get visibiliy of what remains to do and people looking to pick
>> > off bugs can have a list of things to hit first.
>> >
>> > Cheers,
>> >
>> > John
>> >
>> > On Tue, Mar 28, 2017 at 11:07 PM, Chris Pavlina
>> <pavlina.ch...@gmail.com <mailto:pavlina.ch...@gmail.com>> wrote:
>> >> Sounds good.
>> >>
>> >> I've collected all the things I want to work on for 5.0 properly on
>> >> Launchpad now, assigned to myself. These are:
>> >>
>> >> - Fix remaining UI/UX issues with the component selector.
>> >> - Investigate possible footprint preview panel locale issues
>> >> - Implement footprint selection tags on history items
>> >> - Document the new component selector.
>> >> - Fix OpenGL compatibility test crash on startup [1]
>> >> - Implement clean OpenGL/Cairo fallback [2]
>> >>
>> >> Plus a few more minor things (all assigned to me on Launchpad).
>> >>
>> >> I'd like to get all these done before 5.0, is that okay? I'm not sure
>> >> how far off the geometry library and via stitching are so I don't
>> know
>> >> how much time that gives me.
>> >>
>> >> [1] https://bugs.launchpad.net/kicad/+bug/1676915
>> <https://bugs.launchpad.net/kicad/+bug/1676915>
>> >> [2] https://bugs.launchpad.net/kicad/+bug/1676916
>> <https://bugs.launchpad.net/kicad/+bug/1676916>
>> >>
>> >>
>> >> On Tue, Mar 28, 2017 at 10:47:19AM -0400, Wayne Stambaugh wrote:
>> >>> Hey Chris,
>> >>>
>> >>> The following items are holding up the v5 branch:
>> >>>
>> >>> Symbol library table (me).
>> >>> Unified geometry library (Tom).
>> >>> Stitching via support (Tom & Orson).
>> >>>
>> >>> I was hoping I would be done with the symbol library table by
>> now but
>> >>> I'm really having tr

Re: [Kicad-developers] v5 timeline

[John Beard]

Hi,

I "accidentally" made a Launchpad series for v5:

https://launchpad.net/kicad/5.0

I wasn't really expecting to have permissions to do that, but it went
though, so here it is! I doubled down on it and so there's also a
milestone for RC1. Project management people are of course welcome to
assign themselves as managers as needed.

I think we can use these to target important bugs/features to v5, so
we can get visibiliy of what remains to do and people looking to pick
off bugs can have a list of things to hit first.

Cheers,

John

On Tue, Mar 28, 2017 at 11:07 PM, Chris Pavlina  wrote:
> Sounds good.
>
> I've collected all the things I want to work on for 5.0 properly on
> Launchpad now, assigned to myself. These are:
>
> - Fix remaining UI/UX issues with the component selector.
> - Investigate possible footprint preview panel locale issues
> - Implement footprint selection tags on history items
> - Document the new component selector.
> - Fix OpenGL compatibility test crash on startup [1]
> - Implement clean OpenGL/Cairo fallback [2]
>
> Plus a few more minor things (all assigned to me on Launchpad).
>
> I'd like to get all these done before 5.0, is that okay? I'm not sure
> how far off the geometry library and via stitching are so I don't know
> how much time that gives me.
>
> [1] https://bugs.launchpad.net/kicad/+bug/1676915
> [2] https://bugs.launchpad.net/kicad/+bug/1676916
>
>
> On Tue, Mar 28, 2017 at 10:47:19AM -0400, Wayne Stambaugh wrote:
>> Hey Chris,
>>
>> The following items are holding up the v5 branch:
>>
>> Symbol library table (me).
>> Unified geometry library (Tom).
>> Stitching via support (Tom & Orson).
>>
>> I was hoping I would be done with the symbol library table by now but
>> I'm really having trouble finding the time to finish it up.  I'm not
>> sure where Tom and Orson stand.  I just saw an email from Tom the other
>> day so it looks like there is still a bit of work to do on his end with
>> the stitching via support.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 3/28/2017 10:45 AM, Chris Pavlina wrote:
>> > Hey Wayne,
>> >
>> > In the interest of prioritizing my own work - just curious if you have
>> > any idea how long it's going to be before declaring the v5 feature
>> > freeze, and what that's waiting on.
>> >
>>
>> ___
>> 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] CW/CCW rotation in GAL

[John Beard]

HI Orson,

Thanks! Credit where credit is due: I didn't notice, it was kaitrek on
IRC. I was just mashing R until I got what I wanted!

Cheers,

John

On Thu, Mar 30, 2017 at 10:15 PM, Maciej Sumiński
<maciej.sumin...@cern.ch> wrote:
> Hi John,
>
> Good catch, I have committed both patches. I guess it has not been
> noticed, as most people do not really pay attention to rotation
> direction, it is only up to 3 hotkey presses to get any of the 90*
> multiples.
>
> Anyway, it is surely better to perform what is written on the label.
>
> Cheers,
> Orson
>
> On 03/30/2017 01:48 PM, John Beard wrote:
>> This will all be moot when GAL hotkeys can be remapped, since users
>> that care can swap them over.
>>
>> In any case, the attached patch can be applied after the correction
>> above to also swap 'R' and 'Shift-R', so that R is CCW.
>>
>> Cheers,
>>
>> John
>>
>>
>> On Thu, Mar 30, 2017 at 7:32 PM, Clemens Koller <c...@embeon.de> wrote:
>>> Hello, Jon!
>>>
>>> On 2017-03-30 11:07, John Beard wrote:
>>>> Hi,
>>>> When CW/CCW rotation was added in GAL (7045ed92f), the tool actions
>>>> didn't correct for the internal represention of angles, so CW/CCW were
>>>> reversed. This patch fixes that. I failed to notice the comment "//
>>>> TODO rotate CCW" was wrong. On the other hand, it seems only one
>>>> person actually noticed since Feb 4th :-p, including myself.
>>>>
>>>> Now, eeschema standard rotate (R) is CW, but legacy Pcbnew "Rotate+"
>>>> (also R) is CCW.
>>>>
>>>> I have not changed the hotkey assignment for the GAL actions, so it
>>>> now matches eeschema, not legacy mode. I think that CW-default is the
>>>> better default?
>>>
>>> I would strongly prefer to use the mathematically positive rotation (CCW) 
>>> by default.
>>>
>>> R -> CCW (Rotate +)andShift-R -> CW (Rotate -)
>>>
>>> Simply because it's what the majority of applications use...
>>>
>>> Regards,
>>>
>>> Clemens
>>>
>>> ___
>>> 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] [PATCH] Measurement tool for GAL

[John Beard]

Ctrl is already used for angle snap.

I think there should be a generic way to turn grid snap on and off in
all GAL modes. Then it stays on or off until you toggle it again.

This is a little bit tricky to do as a global action due to how the
GAL tool manager keeps VIEW_CONTROL state for each tool. This is why
grid snapping in selection mode (for which there are several issues on
LP) is harder than it looks.

Having a loads of "else if (evt->IsAction( ToggleGridAction)) "
statements in every GAL event loop would be a pain.

On Thu, Mar 30, 2017 at 9:12 PM, Fabrizio Tappero
 wrote:
> I second this
>
> Regards
> Fabrizio
>
>
> On Wed, Mar 29, 2017 at 2:23 AM, Andrey Kuznetsov 
> wrote:
>>
>> Good point Kevin.
>>
>> Can we have "hold down CTRL" to disable snap to grip feature? That would
>> cover the caliper and other myriad of uses when snap to grid is unwanted.
>>
>> On Tue, Mar 28, 2017 at 7:07 AM, Kevin Cozens  wrote:
>>>
>>> On 2017-03-28 03:25 AM, Fabrizio Tappero wrote:

 this ruler (caliper icon) does look really good.
>>>
>>> [snip]

 It is often a good idea to have a way to measure footprint size.
>>>
>>>
>>> The caliper tool is a useful addition to Kicad. The only one thing I've
>>> noticed about it is it only lets you measure distances from one grid point
>>> to another. If you need to measure starting from the edge of a pad (for
>>> example) to some other point you can't unless you change the grid spacing.
>>>
>>> If there is a way to tell the caliper to not snap to grid points when you
>>> are using it to make a measurement I haven't figured out how to do that.
>>>
>>> --
>>> Cheers!
>>>
>>> Kevin.
>>>
>>> http://www.ve3syb.ca/   |"Nerds make the shiny things that
>>> distract
>>> Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why
>>> we're
>>> | powerful!"
>>> #include  | --Chris Hardwick
>>>
>>>
>>> ___
>>> 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
>>
>>
>>
>>
>> --
>> Remember The Past, Live The Present, Change The Future
>> Those who look only to the past or the present are certain to miss the
>> future [JFK]
>>
>> kandre...@gmail.com
>> Live Long and Prosper,
>> Andrey
>>
>> ___
>> 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] CW/CCW rotation in GAL

[John Beard]

This will all be moot when GAL hotkeys can be remapped, since users
that care can swap them over.

In any case, the attached patch can be applied after the correction
above to also swap 'R' and 'Shift-R', so that R is CCW.

Cheers,

John


On Thu, Mar 30, 2017 at 7:32 PM, Clemens Koller <c...@embeon.de> wrote:
> Hello, Jon!
>
> On 2017-03-30 11:07, John Beard wrote:
>> Hi,
>> When CW/CCW rotation was added in GAL (7045ed92f), the tool actions
>> didn't correct for the internal represention of angles, so CW/CCW were
>> reversed. This patch fixes that. I failed to notice the comment "//
>> TODO rotate CCW" was wrong. On the other hand, it seems only one
>> person actually noticed since Feb 4th :-p, including myself.
>>
>> Now, eeschema standard rotate (R) is CW, but legacy Pcbnew "Rotate+"
>> (also R) is CCW.
>>
>> I have not changed the hotkey assignment for the GAL actions, so it
>> now matches eeschema, not legacy mode. I think that CW-default is the
>> better default?
>
> I would strongly prefer to use the mathematically positive rotation (CCW) by 
> default.
>
> R -> CCW (Rotate +)andShift-R -> CW (Rotate -)
>
> Simply because it's what the majority of applications use...
>
> Regards,
>
> Clemens
>
> ___
> 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 27e19e9b0d417bde24c33a3911a2748f111a8420 Mon Sep 17 00:00:00 2001
From: John Beard <john.j.be...@gmail.com>
Date: Thu, 30 Mar 2017 19:49:47 +0800
Subject: [PATCH] Pcbnew GAL: Switch CW/CCW hotkeys to match legacy mode

---
 pcbnew/tools/edit_tool.cpp | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/pcbnew/tools/edit_tool.cpp b/pcbnew/tools/edit_tool.cpp
index 5dab27c24..6ff32b410 100644
--- a/pcbnew/tools/edit_tool.cpp
+++ b/pcbnew/tools/edit_tool.cpp
@@ -111,12 +111,12 @@ TOOL_ACTION PCB_ACTIONS::createArray( "pcbnew.InteractiveEdit.createArray",
 _( "Create Array" ), _( "Create array" ), array_module_xpm, AF_ACTIVATE );
 
 TOOL_ACTION PCB_ACTIONS::rotateCw( "pcbnew.InteractiveEdit.rotateCw",
-AS_GLOBAL, TOOL_ACTION::LegacyHotKey( HK_ROTATE_ITEM ),
+AS_GLOBAL, MD_SHIFT + 'R',
 _( "Rotate Clockwise" ), _( "Rotates selected item(s) clockwise" ),
 rotate_cw_xpm, AF_NONE, (void*) -1 );
 
 TOOL_ACTION PCB_ACTIONS::rotateCcw( "pcbnew.InteractiveEdit.rotateCcw",
-AS_GLOBAL, MD_SHIFT + 'R',
+AS_GLOBAL, TOOL_ACTION::LegacyHotKey( HK_ROTATE_ITEM ),
 _( "Rotate Counter-clockwise" ), _( "Rotates selected item(s) counter-clockwise" ),
 rotate_ccw_xpm, AF_NONE, (void*) 1 );
 
@@ -195,8 +195,8 @@ bool EDIT_TOOL::Init()
 // Add context menu entries that are displayed when selection tool is active
 CONDITIONAL_MENU& menu = m_selectionTool->GetToolMenu().GetMenu();
 menu.AddItem( PCB_ACTIONS::editActivate, SELECTION_CONDITIONS::NotEmpty );
-menu.AddItem( PCB_ACTIONS::rotateCw, SELECTION_CONDITIONS::NotEmpty );
 menu.AddItem( PCB_ACTIONS::rotateCcw, SELECTION_CONDITIONS::NotEmpty );
+menu.AddItem( PCB_ACTIONS::rotateCw, SELECTION_CONDITIONS::NotEmpty );
 menu.AddItem( PCB_ACTIONS::flip, SELECTION_CONDITIONS::NotEmpty );
 menu.AddItem( PCB_ACTIONS::remove, SELECTION_CONDITIONS::NotEmpty );
 menu.AddItem( PCB_ACTIONS::properties, SELECTION_CONDITIONS::Count( 1 )
-- 
2.12.0

___
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] CW/CCW rotation in GAL

[John Beard]

Hi,

When CW/CCW rotation was added in GAL (7045ed92f), the tool actions
didn't correct for the internal represention of angles, so CW/CCW were
reversed. This patch fixes that. I failed to notice the comment "//
TODO rotate CCW" was wrong. On the other hand, it seems only one
person actually noticed since Feb 4th :-p, including myself.

Now, eeschema standard rotate (R) is CW, but legacy Pcbnew "Rotate+"
(also R) is CCW.

I have not changed the hotkey assignment for the GAL actions, so it
now matches eeschema, not legacy mode. I think that CW-default is the
better default?

Cheers,

John
From 2a04337fd517d00c311b1cca4fd28cede1365330 Mon Sep 17 00:00:00 2001
From: John Beard <john.j.be...@gmail.com>
Date: Thu, 30 Mar 2017 16:48:00 +0800
Subject: [PATCH] Pcbnew: correct CW/CCW rotation.

These were backwards since internal angles are CCW due to the inverted Y
axis.

The hotkeys have NOT changed. This means 'R' is now clockwise and
'Shift+R' is anti-clockwise. This is the same as EEschema, but not the
same as Legacy mode.
---
 pcbnew/tools/edit_tool.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/pcbnew/tools/edit_tool.cpp b/pcbnew/tools/edit_tool.cpp
index 00d9e99a3..5dab27c24 100644
--- a/pcbnew/tools/edit_tool.cpp
+++ b/pcbnew/tools/edit_tool.cpp
@@ -113,12 +113,12 @@ TOOL_ACTION PCB_ACTIONS::createArray( "pcbnew.InteractiveEdit.createArray",
 TOOL_ACTION PCB_ACTIONS::rotateCw( "pcbnew.InteractiveEdit.rotateCw",
 AS_GLOBAL, TOOL_ACTION::LegacyHotKey( HK_ROTATE_ITEM ),
 _( "Rotate Clockwise" ), _( "Rotates selected item(s) clockwise" ),
-rotate_cw_xpm, AF_NONE, (void*) 1 );
+rotate_cw_xpm, AF_NONE, (void*) -1 );
 
 TOOL_ACTION PCB_ACTIONS::rotateCcw( "pcbnew.InteractiveEdit.rotateCcw",
 AS_GLOBAL, MD_SHIFT + 'R',
 _( "Rotate Counter-clockwise" ), _( "Rotates selected item(s) counter-clockwise" ),
-rotate_ccw_xpm, AF_NONE, (void*) -1 );
+rotate_ccw_xpm, AF_NONE, (void*) 1 );
 
 TOOL_ACTION PCB_ACTIONS::flip( "pcbnew.InteractiveEdit.flip",
 AS_GLOBAL, TOOL_ACTION::LegacyHotKey( HK_FLIP_ITEM ),
-- 
2.12.0

___
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] Flip around X or Y axis?

[John Beard]

That will be the reason then. It's baked into the combination of layer
+ orientation, so that's how the Flip() functions must be. Makes
sense.

The follow up then is what should the Flip TOOL_ACTION (not the Flip()
function) do? Horizontal flip (left-right) or vertical (top-bottom)?

On Thu, Mar 30, 2017 at 4:32 PM, Cirilo Bernardo
<cirilo.berna...@gmail.com> wrote:
> Beware the minefield. Aside from users complaining it doesn't work
> the way they like or the way they are accustomed to, how will this
> affect existing project files? It will certainly affect the various exporters
> (VRML, IDF, etc).
>
> On Thu, Mar 30, 2017 at 6:12 PM, John Beard <john.j.be...@gmail.com> wrote:
>> Hi,
>>
>> There's a small inconsistency with the way flipping works. If you flip
>> text, it is flipped about the Y axis, so it remains upright, but reads
>> from right-to-left. If you flip anything else, it is flipped about the
>> X axis, so left and right are unchanged, but it is upside down.
>>
>> Flipping the view is also done horizontally. This means a module flip
>> then a view flip does not produce the what you started with (the
>> module will be rotated 180).
>>
>> Is there a reason for this? It was reported as a bug in 2014 and
>> confirmed: https://bugs.launchpad.net/kicad/+bug/1374928
>>
>> Changing the Flip() functions to flip x, not y, across the board would
>> be pretty easy, but it would obviously be a change for people used to
>> it.
>>
>> I feel like since I have more pixels across than vertically, flip
>> horizontally make more sense, and it keeps the part the same way up in
>> the board, and it's consistent with text and view flips.
>>
>> 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

___
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] GAL coverity fixes: uninitialised members

[John Beard]

Hi,

Quick patch to init some GAL class members.

I think most (all?) of these would /eventually/ get set correctly in a
way Coverity doesn't see, but it's good to keep as much as possible in
a sane state!

Cheers,

John
From a25074f51aa5d94815fa581aeed27928d218e243 Mon Sep 17 00:00:00 2001
From: John Beard <john.j.be...@gmail.com>
Date: Thu, 30 Mar 2017 15:52:40 +0800
Subject: [PATCH] Init GAL class members (Coverity fixes)

Fixes: CID 157139 (GAL)
   CID 157138 (CAIRO_GAL)
---
 common/gal/cairo/cairo_gal.cpp| 19 ---
 common/gal/graphics_abstraction_layer.cpp |  1 +
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/common/gal/cairo/cairo_gal.cpp b/common/gal/cairo/cairo_gal.cpp
index 902624750..cd338d46e 100644
--- a/common/gal/cairo/cairo_gal.cpp
+++ b/common/gal/cairo/cairo_gal.cpp
@@ -52,11 +52,24 @@ CAIRO_GAL::CAIRO_GAL( GAL_DISPLAY_OPTIONS& aDisplayOptions,
 mouseListener = aMouseListener;
 paintListener = aPaintListener;
 
-// Initialize the flags
+// Initialise grouping
 isGrouping  = false;
-isInitialized   = false;
-validCompositor = false;
+isElementAdded  = false;
 groupCounter= 0;
+currentGroup= nullptr;
+
+// Initialise compositing state
+mainBuffer  = 0;
+overlayBuffer   = 0;
+validCompositor = false;
+SetTarget( TARGET_NONCACHED );
+
+// Initialise Cairo state
+cairo_matrix_init_identity (  );
+currentContext  = nullptr;
+context = nullptr;
+surface = nullptr;
+isInitialized   = false;
 
 // Connecting the event handlers
 Connect( wxEVT_PAINT,   wxPaintEventHandler( CAIRO_GAL::onPaint ) );
diff --git a/common/gal/graphics_abstraction_layer.cpp b/common/gal/graphics_abstraction_layer.cpp
index ea839b32a..af3d04b60 100644
--- a/common/gal/graphics_abstraction_layer.cpp
+++ b/common/gal/graphics_abstraction_layer.cpp
@@ -55,6 +55,7 @@ GAL::GAL( GAL_DISPLAY_OPTIONS& aDisplayOptions ) :
 SetFlip( false, false );
 SetLineWidth( 1.0 );
 computeWorldScale();
+SetAxesEnabled( false );
 
 // Set grid defaults
 SetGridVisibility( true );
-- 
2.12.0

___
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] Ruler tool asserts when mirrored text is visible

[John Beard]

Hi Orson,

I hit exactly the same thig with the arc assistant, so I made a little
function: GAL::ResetTextAttributes(), next to GAL::SetTextAttributes(
EDA_TEXT*).

This should be sufficient to make it easy to "reset" GAL state when in
a drawing call that doesn't depend on prior state. Also, if you add a
text attribute field in future, adding to this function is easy.

Also provides a handy way to init attributes in GAL::GAL().

Cheers,

John

On Thu, Mar 30, 2017 at 6:10 AM, Maciej Suminski
<maciej.sumin...@cern.ch> wrote:
> Hi,
>
> Thank you John, I have just committed your patch.
>
> There are basic Save()/Restore() functions, but IIRC they do not store
> the font settings, but are mostly used to maintain the transformation
> matrix.
>
> I am not sure about the best solution here. None of the drawing
> functions make any assumptions about the used drawing settings (color,
> line width, stroke/fill, etc.), so perhaps this should be the same for
> texts. Alternatively there could be a Reset() function, but anyway you
> are likely to set the text line width and size, so effectively you would
> just restore the attributes. I am open to discuss other ideas.
>
> Cheers,
> Orson
>
> On 03/29/2017 01:40 PM, John Beard wrote:
>> Sorry, that patch doesn't have the right comment. Please use this one.
>>
>> Thanks,
>>
>> John
>>
>> On Wed, Mar 29, 2017 at 7:37 PM, John Beard <john.j.be...@gmail.com> wrote:
>>> Hi,
>>>
>>> This resolves https://bugs.launchpad.net/kicad/+bug/1677210.
>>>
>>> This is caused because the GAL ruler tool didn't reset its text
>>> mirroring flag before drawing bitmap text. This means if the GAL had
>>> just drawn mirrored text, it would be set, but this is invalid for
>>> OpenGL bitmap fonts (and if it were, would still be incorrect).
>>>
>>> I also reset bold/italic, though bitmaps text doesn't seem to care
>>> about that at all.
>>>
>>> This fixes the bug. In the longer run, this is still not really ideal,
>>> as every draw-er on the GAL seems to need to reset every single
>>> parametert that it might need. If a parameter is added, all these
>>> "reset loci" need to be vetted for possibly adding or resetting that
>>> parameter.
>>>
>>> Would some kind of stack mechanism make sense here? Unrelated
>>> functions probably should start from a blank slate of some sort. Maybe
>>> a way to avoid unnecessary stack shuffling if you /know/ you don't
>>> need to reset GAL parameters and it's a performance hit to do so
>>> needlessly?
>>>
>>> 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
>
> ___
> 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 f60a13673be3bf30f84fcdb3dc2b634310ba3b6c Mon Sep 17 00:00:00 2001
From: John Beard <john.j.be...@gmail.com>
Date: Thu, 30 Mar 2017 15:44:38 +0800
Subject: [PATCH 1/2] Add reset text attributes function to GAL - use for arc
 tool

Independent drawing functions (that don't expect any particular state to
be set up fo them) on the GAL need to reset the GAL properties they
use. This adds GAL::ResetTextAttributes() to make this easier.

This is important, as failing to reset mirroring can cause asserts in
OpenGL.

This is used in the Ruler tool (which previously did it one attribute at
a time) and also the Arc layout assistant, which previously failed to
reset mirroring.

Also reset on GAL construction, as these members appear to be
uninitialised.
---
 common/gal/graphics_abstraction_layer.cpp | 18 ++
 common/preview_items/arc_assistant.cpp|  2 ++
 common/preview_items/ruler_item.cpp   |  5 ++---
 include/gal/graphics_abstraction_layer.h  |  8 
 4 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/common/gal/graphics_abstraction_layer.cpp b/common/gal/graphics_abstraction_layer.cpp
index cf9ae16f6..ea839b32a 100644
--- a/common/gal/graphics_abstraction_layer.cpp
+++ b/common/gal/graphics_abstraction_layer.cpp
@@ -69,6 +69,9 @@ GAL::GAL( GAL_DISPLAY_OPTIONS& aDisplayOptions ) :
 forceDisplayCursor = false;
 SetCursorEnabled( false );
 
+// Initialize text properties
+ResetT

[Kicad-developers] Flip around X or Y axis?

[John Beard]

Hi,

There's a small inconsistency with the way flipping works. If you flip
text, it is flipped about the Y axis, so it remains upright, but reads
from right-to-left. If you flip anything else, it is flipped about the
X axis, so left and right are unchanged, but it is upside down.

Flipping the view is also done horizontally. This means a module flip
then a view flip does not produce the what you started with (the
module will be rotated 180).

Is there a reason for this? It was reported as a bug in 2014 and
confirmed: https://bugs.launchpad.net/kicad/+bug/1374928

Changing the Flip() functions to flip x, not y, across the board would
be pretty easy, but it would obviously be a change for people used to
it.

I feel like since I have more pixels across than vertically, flip
horizontally make more sense, and it keeps the part the same way up in
the board, and it's consistent with text and view flips.

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

Re: [Kicad-developers] [PATCH] Ruler tool asserts when mirrored text is visible

[John Beard]

Sorry, that patch doesn't have the right comment. Please use this one.

Thanks,

John

On Wed, Mar 29, 2017 at 7:37 PM, John Beard <john.j.be...@gmail.com> wrote:
> Hi,
>
> This resolves https://bugs.launchpad.net/kicad/+bug/1677210.
>
> This is caused because the GAL ruler tool didn't reset its text
> mirroring flag before drawing bitmap text. This means if the GAL had
> just drawn mirrored text, it would be set, but this is invalid for
> OpenGL bitmap fonts (and if it were, would still be incorrect).
>
> I also reset bold/italic, though bitmaps text doesn't seem to care
> about that at all.
>
> This fixes the bug. In the longer run, this is still not really ideal,
> as every draw-er on the GAL seems to need to reset every single
> parametert that it might need. If a parameter is added, all these
> "reset loci" need to be vetted for possibly adding or resetting that
> parameter.
>
> Would some kind of stack mechanism make sense here? Unrelated
> functions probably should start from a blank slate of some sort. Maybe
> a way to avoid unnecessary stack shuffling if you /know/ you don't
> need to reset GAL parameters and it's a performance hit to do so
> needlessly?
>
> Cheers,
>
> John
From 3309e395a405eaeeaec80e2a36156fb2a0a25c03 Mon Sep 17 00:00:00 2001
From: John Beard <john.j.be...@gmail.com>
Date: Wed, 29 Mar 2017 19:35:03 +0800
Subject: [PATCH] Ruler tool: reset text mirror/bold/italic before painting

This is required as the OpenGL GAL doesn't support mirrored
text, and if the state is not cleared after painting other mirrored
text, this is what is attempted.

Fixes: lp:1677210
* https://bugs.launchpad.net/kicad/+bug/1677210
---
 common/preview_items/ruler_item.cpp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/common/preview_items/ruler_item.cpp b/common/preview_items/ruler_item.cpp
index c820f7f87..629fc1d94 100644
--- a/common/preview_items/ruler_item.cpp
+++ b/common/preview_items/ruler_item.cpp
@@ -238,6 +238,9 @@ void RULER_ITEM::ViewDraw( int aLayer, KIGFX::VIEW* aView ) const
 gal.SetIsStroke( true );
 gal.SetIsFill( false );
 gal.SetStrokeColor( PreviewOverlayDefaultColor() );
+gal.SetFontBold( false );
+gal.SetFontItalic( false );
+gal.SetTextMirrored( false );
 
 // draw the main line from the origin to cursor
 gal.DrawLine( origin, end );
-- 
2.12.0

___
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