the fp-info-cache files should be added to the
> > .gitignore file but Jeff would know for sure. I ignore them for my
> > projects without any issues.
> >
> >
> > On 11/12/2018 7:09 AM, John Beard wrote:
> >> Hi,
> >>
> >> Any time I open a demo p
ry/
> qa/pcb_parse_input/qa_pcb_parse_input
> qa/pcb_test_window/test_window
> qa/polygon_generator/test_polygon_generator
> qa/polygon_triangulation/test_polygon_triangulation
> qa/shape_poly_set_refactor/qa_shape_poly_set_refactor
>
> nothing added to commit but untracked files present (use
Hi,
A little technical query provoked by someone else's question, which I
was unable to answer.
Say one wanted to add a global mouse shortcut, for example, double
middle-click to do "zoom-to-fit" [1].
The current mouse events are handled on a contextual basis in the
event loops for each tool. Th
wn of WX prints some
glib stuff on GTK3 [2], but it should be harmless, and doing the
teardown keeps valgrind happier.
Cheers,
John
[1]: https://bugs.launchpad.net/kicad/+bug/1786515
[2]: http://trac.wxwidgets.org/ticket/18274
From 86529229172eab9af7cacbc0508d784cd058bccd Mon Sep 17 00:00:00 2
;Am 2018-11-23 08:26, schrieb John Beard:
>> Hi,
>>
>> This is a patch to refactor the zooming of WX_VIEW_CONTROL. This is
>> related to lp:1786515 [1], but it's not a fix, it's just a refactor
>to
>> help debug the problem, and also tidy the code.
>
>
VENT is
> supposed to fire an action.
>
> Cheers,
> Orson
>
> On 11/21/18 11:15 AM, John Beard wrote:
> > Hi,
> >
> > A little technical query provoked by someone else's question, which I
> > was unable to answer.
> >
> > Say one wanted to add
Hi Wayne, Seth,
Here is the patchset with:
* A default ctor param and get/setters
* Trace mask in the header. I somehow haven't noticed this file before, sorry!
Cheers,
John
On Sun, Nov 25, 2018 at 9:35 PM Wayne Stambaugh wrote:
>
> Hey John,
>
> On 11/23/2018 8:26 AM,
Hi,
Having just found the trace_helpers header (which I totally missed
when making a list of the trace strings...), I have a couple of ideas.
First: is there milage to add the strings to the trace variable docs?
This means you can easily see what you should be writing in WXTRACE
without having to
mmon or Git and invoke a re-link anyway!
Cheers,
John
From 5dc15d908b875e6dbe22a81a5d115d285f812e0e Mon Sep 17 00:00:00 2001
From: John Beard
Date: Mon, 26 Nov 2018 16:25:12 +
Subject: [PATCH] Document tracemask strings and add note in testing.md
Also make the examples in the testing.md docs
d.xml
From 12e3406c080d96a3dd1195c7c402832eab390145 Mon Sep 17 00:00:00 2001
From: John Beard
Date: Mon, 26 Nov 2018 21:14:21 +
Subject: [PATCH] Docs: add docset generation target
This is a CMake (non-ALL) target that will build a Zeal-compatible
docset from a version of the doxygen HTML.
To do this, doxytag2ze
available as a CMake target makes it much more accessible
to other developers to maintain the grammar. Tests allow to ensure
behaviour is not changed when not expected.
Cheers,
John
From 7feb9a01589a71d0a26bff6f58e221988b7aae35 Mon Sep 17 00:00:00 2001
From: John Beard
Date: Wed, 28 Nov 2018 13
verify this and I'm not a big fan of using pip on a system that uses a
> package manager. Is doxytag2zealdb packages for any distros? I would
> like a better picture of what this brings to the table and the
> availability of any dependencies before I commit it.
>
> Cheers,
No attachment went though, so here's a better video:
https://sendvid.com/lrzgrdmf
Cheers,
John
On Wed, Nov 28, 2018 at 4:36 PM John Beard wrote:
>
> Hi Wayne,
>
> It is not a replacement for the existing doxygen docs, which are
> unaffected by this patch.
>
> This
d useful enough to
become supported, it should be given UI and put into the existing
config files. Perhaps any set advanced config should be included in
the version info dump.ki
Cheers,
John
From a38059bc60daec5af906b85830b6ed6b74234ee6 Mon Sep 17 00:00:00 2001
From: John Beard
Date: Tue, 4 Dec 20
Hi Wayne,
I can take a look at doing that. I'm on gtk3, so it's easy to check.
On that note, how many people are actually using gtk3 for actual designs? I
know I am, but I've been stuck with fallback for a while due to lagging, which
I think is likely fixed now with the event stuff, but I have
ird patch does another one for disabling legacy canvas on GTK3.
Again, this is done at run-time to avoid conditionally compiling code.
Cheers,
John
From 149eaafc2b9dc8fc453b73d8ffb76cc4206311fe Mon Sep 17 00:00:00 2001
From: John Beard
Date: Mon, 10 Dec 2018 10:56:28 +
Subject: [PATCH] Run-time
Whoops: the 16kB 0001 patch should not be there, that's a very old draft!
Sorry,
John
On Thu, Dec 13, 2018 at 12:57 PM John Beard wrote:
>
> Hi,
>
> This is a patch for run time options, which are a more flexible alternative
> to compiler flags. Advantages include:
>
dvanced config from:
> C:\Users\wstambaugh\AppData\Roaming\kicad\kicad_advanced
> [1588] (KICAD_ADVANCED_CONFIG) AllowLegacyCanvasInGtk3: false
>
> I don't see the EnableSvgImport option and the AllowLegacyCanvasInGtk3
> option is being read as false when it's set to true in the
>
rot once these features are no longer run
>time options. As long as it's kept up to date, I'm fine with merging
>it. Anyone else have any objections or concerns?
>
>Cheers,
>
>Wayne
>
>On 12/17/2018 12:47 PM, John Beard wrote:
>> Hi Wayne,
>>
>>
code physically can't
depend on it. This isn't true for an ifdef, which can merrily lop out code when
forgotten.
Cheers,
John
On 17 December 2018 19:10:45 GMT, John Beard wrote:
>Hi Wayne,
>
>Absolutely. That's one of the reasons to keep them in a separate file
>an
> ___
> Mailing list: https://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 af0b16e
Sorry, I failed to rebase that over the newest changes. This should
apply better as a patch.
Cheers,
John
On Wed, Dec 19, 2018 at 3:15 PM John Beard wrote:
>
> Hi,
>
> I've added a few simple cases to the qa_common unit tests.
>
> I don't know if I will have co
Cheers,
John
On Wed, Dec 19, 2018 at 7:40 PM Seth Hillbrand wrote:
>
> Am 2018-12-19 10:19, schrieb John Beard:
> > Sorry, I failed to rebase that over the newest changes. This should
> > apply better as a patch.
>
> Hi John-
>
> Thanks for the really useful test ha
: 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.l
e well enough.
If this is deemed a good idea, then at least io_benckmark and the rest
of /tools could probably be swept up into this one. Plus any fuzz
testers of libcommon code.
Cheers,
John
From 321e15082b6b7a2bdcd901510ec8b54433cd6fc2 Mon Sep 17 00:00:00 2001
From: John Beard
Date: Mon, 24 Dec
Hi,
There is also a description of how you would write a tool in the development
documentation:
http://docs.kicad-pcb.org/doxygen/md_Documentation_development_tool-framework.html
As Thomas said, there is no pluggable C++ interface for plugins. Part of the
reason for this is that C++ does not p
Hi,
Disclaimer: I'm saying this all from a position of total ignorance on
the actual benchmarked cost of these computations (premature
optimisation and all that...), or even how the DRC does it.
I think most real components are easy: rects or circles. Generic
polygon collision tests are the harde
Hi Frank,
D'oh, of course, they're right there! Sorry for overlooking that!
I doubt either of these would produce radically slower DRC time,
though you might *perhaps* notice it if *all* components got "fancy"
courtyards. Really, the only thing to do if concerned is benchmark it.
It's probably st
https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
From e2045e82720d145a23af0e9de538173d56cdb831 Mon Sep 17 00:00:00 2001
From: John Beard
Date: Wed, 2 Jan 2019 01:05:32 +
Subject: [PATCH] Docs: Fix doxygen links
Doxygen is now at: http://w
Hi Frank,
There is no trivial way to test this right now, but I could probably
whip up a quick test program in the next week or so. The DRC code is
poorly exposed for instrumentation, so it might be a little bit tricky
without a little refactor (or hack) first! I imagine a dummy set of
several tho
I agree. The important thing is what is in the file. If nothing else, S-exp is
a concise way to express this concept during development. Exact format
representation in disk is, right now, bikeshedding.
When we get to that stage, all that is required is that the format is VCS
friendly and human
Note, this bug can only be triggered if you do have Lemon installed. Otherwise
the grammar.c file is just another file.
So make clean is safe unless you have lemon installed!
Cheers,
John
On 23 December 2018 21:32:50 GMT, John Beard wrote:
>Hi,
>
>It seems "make clean" m
Sorry - forwarding to the list. That's what happens when I do emails too late!
-- Forwarded message -
From: Andrew Lutsenko
Date: Fri, Jan 4, 2019 at 12:50 AM
Subject: Re: [Kicad-developers] [RFC] Symbol library file format
To: John Beard
Sorry, link to github:
if( ii.galType == canvasType )
> > > +if( item && ii.galType == canvasType )
> > > item->Check( true );
> > > }
> > > }
> >
> > I think that this is the same as [1] that John is working on. Are you using
> > GTK3?
> >
> > [1]https://bugs.
00:00 2001
From: John Beard
Date: Thu, 20 Dec 2018 14:14:53 +
Subject: [PATCH 1/3] QA: Add some more Boost version guards
Some functions aren't defined on Boost < 1.59, which is
sadly inclusive of the Ubuntu LTSs.
Make some guards so you can still use these on the newer
Boosts with so
On Sat, Jan 5, 2019 at 4:23 PM Seth Hillbrand wrote:
> Patch 0002 does not apply cleanly to qa/CMakeLists.txt even after
> applying 0001
Hmm, that's odd: I can apply this with "git am 0002". I'm applying
on top of 69fc301bf. Where are you applying it to? Do you still have
the triangulation t
Hi,
Here is a really silly (since it's in legacy code) small patch for
some unused code I was alerted to by Clang. But might as well get it
off my patch stack!
Cheers,
John
From 3f7aaef50dc0cc51d995450c6c6a7c5fca85f8d1 Mon Sep 17 00:00:00 2001
From: John Beard
Date: Fri, 4 Jan 2019 14:
Hi,
I'm not quite sure what happened here, but patch 0001 in the top email hasn't
been applied, but instead the RFC patch for the combined utilities tool program
has been applied (now commit 502306) instead.
If nothing else, this is unlikely to work on older boosts with that missing
first comm
Hillbrand wrote:
>
> Am 2019-01-06 15:14, schrieb John Beard:
> > Hi,
> >
> > I'm not quite sure what happened here, but patch 0001 in the top email
> > hasn't been applied, but instead the RFC patch for the combined
> > utilities tool program has bee
e failures.
Cheers,
John
On Mon, Jan 7, 2019 at 11:42 AM jp charras wrote:
>
> Le 07/01/2019 à 12:33, John Beard a écrit :
> > Hi Seth,
> >
> > The revert commit (8f11a2133efd95526d1a3783dbaca76f732b8efb) also
> > killed the CMake add_subdirectory (because the origina
h wrote:
>
> I just ran a 32 bit build on windows with commit 3f9230fa and I didn't
> have any build or test issues.
>
> Cheers,
>
> Wayne
>
> On 1/7/2019 8:00 AM, John Beard wrote:
> > Hi JP,
> >
> > Sorry, I thought that issue was just a side effe
On Mon, Jan 7, 2019 at 2:47 PM jp charras wrote:
> This patch works.
Great!
> make test works and shows only 3 tests:
Looks like you don't have the python scripting on, so you are missing
the qa_python target. The pcbnew target (this one) is there.
> So it can be a cmake issue and/or a operat
John
From cf87f505f6c5755e8db4cfe91b1455a04bd27d03 Mon Sep 17 00:00:00 2001
From: John Beard
Date: Tue, 8 Jan 2019 11:57:39 +
Subject: [PATCH 3/3] Wildcards: unify handling of all files wildcards
Use the AddFileExtListToFilter() to also generate the
wildcard for "all files". This is becau
Hi Seth,
Good idea - I was just moving what the code currently did, but sounds
like a sensible fix. I'll amend patch 0003.
Does it otherwise work on Windows?
Cheers,
John
On Tue, Jan 8, 2019 at 4:36 PM Seth Hillbrand wrote:
>
> Am 2019-01-08 09:16, schrieb John Beard:
> >
Seth Hillbrand wrote:
>
> Am 2019-01-08 11:46, schrieb John Beard:
> > Hi Seth,
> >
> > Good idea - I was just moving what the code currently did, but sounds
> > like a sensible fix. I'll amend patch 0003.
> >
> > Does it otherwise work on Windows?
&g
platforms, as it has been doing this
quietly since Feb 2018!
Cheers,
John
Ref: https://docs.wxwidgets.org/3.0/page_cppconst.html
From de2ea38e93b59e932a49d70e38eba05443b8b1aa Mon Sep 17 00:00:00 2001
From: John Beard
Date: Tue, 8 Jan 2019 17:50:06 +
Subject: [PATCH] __WXWINDOWS__ does not mean
ge the caused a conflict before
> I could get around to merging them.
>
> Thanks,
>
> Wayne
>
> On 1/8/2019 12:35 PM, John Beard wrote:
> > Hi Seth,
> >
> > Here are updated patches (only #3 is changed).
> >
> > I have still hardcoded the expected r
Hi Seth,
I'm not sure cxx_constexpr would be enough. This just checks the
"N2235" (2007) [1, p13] definition of constexpr is available. This
includes:
...constexpr specifier used in a non-static member function definition
declares that member function to be const...
This is the issue at hand - h
be good to get a review to check I've done
it correctly! Specifically: have I missed an important case in the
tests?
Also includes a couple of handy geometry test predicates for vectors and boxes.
Cheers,
John
From 89bbe29e721a2059a69f7205449dd51c8e5a2257 Mon Sep 17 00:00:00 2001
From: John B
On Wed, Jan 9, 2019 at 4:52 PM Wayne Stambaugh wrote:
>
> John,
>
> If I only apply patch 1, shouldn't the arc bounding box test fail? I
> just tried this and all of the tests passed.
>
> Wayne
>
> On 1/9/2019 11:14 AM, John Beard wrote:
> > Hi,
>
heers,
>
> Wayne
>
> On 12/19/2018 10:19 AM, John Beard wrote:
> > Sorry, I failed to rebase that over the newest changes. This should
> > apply better as a patch.
> >
> > Cheers,
> >
> > John
> > On Wed, Dec 19, 2018 at 3:15 PM John Beard wrote
ild docker image.
JP, could you check this works on whatever system threw the error for
you?
Cheers,
John
* Also, once min Boost is >=1.59, lots of other hackish macros to work
around missing functions become superfluous, which will be nice!
Notably, Ubuntu LTS 18.04 uses Boost 1.65.
From e02
Hi Frank,
I've got a very rough outline of the cost of courtyard calculations.
The timings are for "n" modules in various proportions of rectangular
and rounded rectangles.
The modules are each a single courtyard outline (no other features).
All are 1mm square and the round radius is 0.25mm. All
Hi,
A very gentle bump here. I'm thinking about a utility to assist in
debugging/benchmarking/testing/developing DRC routines (currently
working on some DRC unit testing, but the testing utils are easily
re-used into a small utility-style executable).
However, I am cognisant of the costs of addin
r applies cleanly. It looks useful so I
> don't see any reason not to merge it.
>
> Cheers,
>
> Wayne
>
> On 1/19/2019 9:30 AM, John Beard wrote:
> > Hi,
> >
> > A very gentle bump here. I'm thinking about a utility to assist in
> > debugging/ben
>
> I don't think there is any disadvantage to rolling the other tests into
> the qa test executable.
>
> Thanks,
>
> Wayne
>
> On 1/19/19 10:25 AM, John Beard wrote:
> > Hi Wayne,
> >
> > I'll rebase the patch. Would you like me to roll the o
On 19 January 2019 23:55:02 GMT, Tomasz Wlostowski
wrote:
>It's going to be a very useful tool. I wrote similar tests in the past
>for the P&S and connectivity (and GAL and some other things too), but
>they remain in my private branches because they're too low quality IMHO
>to be published, s
In the past, the ZONE_CONTAINER::GetPosition() member
returned a reference to a wxPoint, in accordance with the
BOARD_ITEM interface. This meant that ZONE_CONTAINER had
to reinterpret_cast a VECTOR2I (its internal position data) to wxPoint,
which was possible only due to fortunate memory layout.
D'oh, and I though I was being so clever with git send-email... Here
it is all in one piece.
Sorry!
John
On Wed, Jan 23, 2019 at 2:46 PM Seth Hillbrand wrote:
>
> Am 2019-01-23 08:46, schrieb John Beard:
> > In the past, the ZONE_CONTAINER::GetPosition() member
> > re
endency versions the Jenkins msys2 builder is
> using so that may have something to do with it. Either the gcc and/or
> boost versions are the likely culprit.
>
> In any event, your changes resolved the issue so I merged your patch set.
>
> Thanks,
>
> Wayne
>
> On
t have a closed-form solution), but haven't started the second
bit, and there's a refactor and a good think needed. So, submitting
this to close out the 5.1.0 bug and at least prevent invalid outputs.
Cheers,
John
From 37ffeb90c01dbd1a9c81e92333f993527f7fe517 Mon Sep 17 00:00:00 2001
From
things now should be:
* pcb_test_window: what is this for and can it be fixed? Can it be
made into a sub-tool, or does it need its own executable for the
wxApp?
Cheers,
John
From 8efadbfef50cd441f624f0ef3db9e2915924209e Mon Sep 17 00:00:00 2001
From: John Beard
Date: Thu, 24 Jan 2019 11:33:22
cent
> polygon changes which broke the previous polygon test. Does it make
> sense to merge this unit the test failures are resolved?
>
> Cheers,
>
> Wayne
>
> On 1/25/2019 10:48 AM, John Beard wrote:
> > Hi,
> >
> > Here are a few more patches to finish up
right now if the class its testing is having work
done on it!
Cheers,
John
From b8494711bf7c8dd1ec41863d58486651117c1e8d Mon Sep 17 00:00:00 2001
From: John Beard
Date: Tue, 29 Jan 2019 17:38:31 +
Subject: [PATCH] QA: Fix faulty test of SHAPE_POLY_SET Collision
This test assumed points on a ed
| --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.launch
-internal includes clearer.
(These tests do not concern, conflict with or affect the recent
SHAPE_POLY_SET Collision problems.)
Cheers,
John
From f2df038f45edc6c88ec0f506fe7d604002ea8701 Mon Sep 17 00:00:00 2001
From: John Beard
Date: Mon, 28 Jan 2019 10:36:54 +
Subject: [PATCH 2/2] QA: Tidy
:
>
> Patches merged.
>
> Thanks,
>
> Wayne
>
> On 1/29/2019 5:40 PM, John Beard wrote:
> > Hi,
> >
> > Following the QA patch set just merged, here are a couple more.
> >
> > 1) Add tests on SHAPE_POLY_SET::Distance and a few geometry helpers
> > f
cribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
From 7528b06c4e2fc0a4039c1ed10c59b861712405d8 Mon Sep 17 00:00:00 2001
From: John Beard
Date: Wed, 30 Jan 2019 09:37:15 +
Subject: [PATCH 2/3] QA: Account for eeschema tests unit rounding
---
qa/common/geom
e5a93bc431319e6fa3dcbcd2efc9845d5d32da77 Mon Sep 17 00:00:00 2001
From: John Beard
Date: Wed, 30 Jan 2019 16:48:09 +
Subject: [PATCH] Exit dialog: use Layout on the whole window
Prevents mislaignment in footpritn editor on close with unsaved
changes.
Fixes: lp:1813961
* https://bugs.launchpad.net/kicad/+bug
, with testable underpinning
refactoring.
Cheers,
John
On 30 January 2019 19:18:20 GMT, Wayne Stambaugh wrote:
>
>
>On 1/30/2019 1:01 PM, Seth Hillbrand wrote:
>> Am 2019-01-30 10:24, schrieb John Beard:
>>> Hi,
>>>
>>> Here are a bunch of refactors to fix some i
n still combine?
Cheers,
John
On 31 January 2019 14:38:33 GMT, Tomasz Wlostowski
wrote:
>On 31/01/2019 15:40, John Beard wrote:
>> Hi,
>>
>> Two patches for building these libs:
>>
>> 1) Make bitmaps a "Proper" library. By splitting it off like this,
1/2019 à 16:29, Wayne Stambaugh a écrit :
> >>> JP,
> >>>
> >>> On 1/31/2019 10:11 AM, jp charras wrote:
> >>>> Le 31/01/2019 à 15:40, John Beard a écrit :
> >>>>> Hi,
> >>>>>
> >>>>> Two patches fo
Hi JP,
On Thu, Jan 31, 2019 at 4:55 PM jp charras wrote:
>
> > Perhaps this:
> >
> > target_include_directories( pcbnew_kiface_objects PRIVATE
> >$
> > )
>
> Unfortunately, does not work.
Is it the same error?
Cheers,
John
___
Mailing list: http
Hi,
Some tests of the SEG class. Distance and Collide are essential
foundations of nearly all the other SHAPE collision tests (and
therefore DRC and routing). So a good thing to have tested.
Cheers,
John
From 526ce7a636c24645aed6baf7c2d1015b0ffbbebb Mon Sep 17 00:00:00 2001
From: John Beard
7ff70ac8e43585c6522a958bd6588fda85f55229 Mon Sep 17 00:00:00 2001
From: John Beard
Date: Sat, 2 Feb 2019 21:50:36 +
Subject: [PATCH 2/2] LIB_TABLE_BASE: Const and unsigned fixes
* Make LIB_TABLE_BASE::GetCount() return unsigned. This is more
consistent with the behaviour of STL containers (especially the
boost::ptr_vector
Hi Wayne and Team,
I'm really happy to have been extended this honour. I look forward to
being part of the great things coming!
Cheers,
John
On Thu, Feb 7, 2019 at 1:32 PM Wayne Stambaugh wrote:
>
> I am happy to announce that John Beard has accepted the offer to join
>
Hi,
I have a few questions about the plan of action for the start of the
v6 development window. I feel that since the 5.1.0 bug list[1] is
dwindling, there are probably a few people around who are just waiting
for a green light on v6.
So that they can organise any pending patches better, I'd like
Hi Nick,
I have committed your patch. Thank you for noticing and your contribution!
Cheers,
John
On Sun, Feb 10, 2019 at 9:01 PM Nick Østergaard wrote:
>
> Hello
>
> I would like to see the attached minor documentation change to be merged as
> it makes it easier to link to the section from th
scussion.
If anyone wishes to, feel free to modify as needed!
Cheers,
John
From 5668baa611bf952e402e5f104e9ba0b18aac84cd Mon Sep 17 00:00:00 2001
From: John Beard
Date: Sun, 10 Feb 2019 21:54:31 +
Subject: [PATCH] Docs: Advanced config is explicity experimental
Any advanced config
Hi Wayne,
Thanks, I have pushed it.
Cheers,
John
On Mon, Feb 11, 2019 at 12:31 AM Wayne Stambaugh wrote:
>
> John,
>
> The dire warnings make sense to me. Go ahead and merge it when you get
> a chance.
>
> Cheers,
>
> Wayne
>
>
> On 2/10/19 5:01 PM, John B
Hi Tom,
Thanks for looking at this - it's one of the last visible issues in
the new Eeschema GAL stuff that I notice regularly.
This appears to work well on Arch/i3.
I'd be in favour of at least attempting to get it into 5.1, as I think
the current eeschema look is likely to cause at least some
s to what
> >>>>> impact this merge will have.
> >>>>>
> >>>>> On 2/9/19 10:17 AM, Jon Evans wrote:
> >>>>>> Figuring this out is a good idea. Thanks for suggesting it, John!
> >>>>>>
> >>>>>> My bran
On Wed, Feb 13, 2019 at 2:28 PM Jeff Young wrote:
>
> >> I'm also not
> >> completely sure curved air wires will be necessary once we implement the
> >> coloring feature.
>
> I wonder if this is a digital vs. discrete thing? With transistors in
> particular, I often find several ratsnest lines g
Hi,
I plan to pixel align the module icons in Pcbnew, as they are
currently blurry (and not even consistently blurry) - they're probably
the worst offenders left for blurriness. Getting these aligned at 26px
will be a good step towards hiDPI-aware scalable icons, as they will
also be aligned at 2x
ther may eyes are totally gone or the icons on the
> right are the aligned ones.
>
> Cheers,
>
> Wayne
>
> On 3/19/2019 3:43 PM, John Beard wrote:
> > Hi,
> >
> > I plan to pixel align the module icons in Pcbnew, as they are
> > currently blurry (and not ev
54, Wayne Stambaugh
>wrote:
>>
>> Whew! I was starting worry about my vision there for minute :)
>>
>> On 3/19/2019 3:52 PM, John Beard wrote:
>>> D'oh, yes! Sorry, new ones on the right, I changed it and didn't
>>> change the text.
>&
9 Mar 2019, at 19:54, Wayne Stambaugh
>>> wrote:
>>>
>>> Whew! I was starting worry about my vision there for minute :)
>>>
>>> On 3/19/2019 3:52 PM, John Beard wrote:
>>>> D'oh, yes! Sorry, new ones on the right, I changed it and did
Hi Ruth,
Thanks for the feedback.
I'm not really proposing to change any icon metaphors or colours right
now. The module icon is probably one of the most distinctive KiCad
icons (in term of colour and form), so changes there are a whole new
topic. De-emphasising the background item in overlaid ic
to do to turn this on? I applied your patch,
>but the icons look identical to the way they did before.
>
>Cheers,
>Jeff.
>
>
>> On 20 Mar 2019, at 10:51, John Beard wrote:
>>
>> Hi Jeff,
>>
>> Moving off-topic from the module icons, can you have a
Hi,
Indentation is not defined well in the coding style documentation
(actually, lots of things are not mentioned in the document). Thus, by
the rules of thermodynamics, KiCad has a healthy mix of different
styles.
The clang-fomat file specifies the following:
* IndentWidth: 4 # This is the "blo
On 20 March 2019 13:58:41 GMT, Jeff Young wrote:
>
> Ahh… yes, OSX does its own upscale (my icon scale is set to 100%).
Hmm, there's not a lot we can do in that case until we can support 2x
resolution icons.
On the plus side, AFAIK, WX 3.0 on OSX *does* support scale detection
(GetContentScaleFa
On Wed, Mar 20, 2019 at 6:16 PM John Beard wrote:
> If this is "correct" KiCad style, we should change clang-format.
And update the coding policy documentation, of course.
> WRT to template spacing inside < >, again the policy says nothing.
> Clang format uses SpacesInA
On Wed, Mar 20, 2019 at 6:44 PM Wayne Stambaugh wrote:
> It looked like in the example that Brian posted the indent was more than
> eight spaces but that may have been a font spacing issue. I'm fine with
> eight spaces as the continuation indent.
Hmm, you're right, I didn't notice that. It seem
On Wed, Mar 20, 2019 at 7:04 PM John Beard wrote:
> The coding policy specifies 1 line spacing above declarations with
> Doxygen comments, and 2 above "bare" declarations like these. So this
> bug/quirk/feature should rarely be encountered. So the original code
> here is
On Wed, Mar 20, 2019 at 7:30 PM Wayne Stambaugh wrote:
>
> The moral of the story is "never trust the auto-formatter". Sounds
> suspiciously like "never trust the auto-router" :)
The good news is that you can defeat Skynet with some well-crafted C++
formatting. The bad news is self-driving cars
Hi,
Quick question about formatting: clang-format says
"AlwaysBreakTemplateDeclarations: false", which can produce things
like this:
template void function( int aParam )
template <> struct STRUCT_TYPE
I think it's clearer if the template declaration is always broken
after ("AlwaysBreakTemplate
Oops, missing newline in the "after" case: should be:
template <>
struct STRUCT_TYPE
On Tue, Mar 26, 2019 at 12:26 PM John Beard wrote:
>
> Hi,
>
> Quick question about formatting: clang-format says
> "AlwaysBreakTemplateDeclarations: false", which can
* be standalone compilable).
There are no policy changes .
Cheers,
John
From 1e6657cef8fb8345d17b7706a880de34448f43e1 Mon Sep 17 00:00:00 2001
From: John Beard
Date: Tue, 26 Mar 2019 13:25:01 +
Subject: [PATCH] Coding style: minor adjustments
There are no policy changes in this comm
Hi Konstantin,
I have applied this patch to both the development and the 5.1 branches.
Thank you for helping KiCad!
Cheers,
John
On Tue, Mar 26, 2019 at 8:15 PM Baranovskiy Konstantin
wrote:
>
> For now fields created in Fields Editor are placed at
> position (0, 0).
> Every new field must be
, Mar 27, 2019 at 1:32 PM Wayne Stambaugh wrote:
>
> I don't have a preference on this so I'm fine with the proposal. We
> have very few templates in the KiCad source so it's impact is low.
>
> On 3/26/2019 8:28 AM, John Beard wrote:
> > Oops, missing ne
301 - 400 of 464 matches
Mail list logo
