I have to say, I really agree about the worker threads. I'm not sure why we
even took the time to code that - it's almost never useful and, as Mark
says, can cause issues. Personally I'd love to see that ripped right out,
or at least the number of threads set to 1 by default. There's a reason
nobod
uot; above. I
do not recommend this approach, though I see how it could work.)
On Jan 11, 2016 09:24, "Wayne Stambaugh" wrote:
> On 1/11/2016 9:09 AM, Chris Pavlina wrote:
> > I have to say, I really agree about the worker threads. I'm not sure why
> > we even took the t
>
> On 1/10/2016 4:13 PM, Chris Pavlina wrote:
> > Just to clarify - Wayne, are you still having a look at this, or were
> > you just expecting me to merge my own patch when it's done? I think it's
> > ready to go in.
> >
> > On Fri, Jan 08, 2016 at
I want to take some time to think about
what the correct icons for each of those four items would be. I don't
like having the duplicated icons.
On Mon, Jan 11, 2016 at 05:32:48PM +0100, jp charras wrote:
> Le 11/01/2016 16:28, Chris Pavlina a écrit :
> > An updated version of the
thing, you might want to avoid is using bold characters in the
> hotkey capture dialog. They are getting truncated on my windows builds.
> The longer the description, the worse the truncation.
>
> Cheers,
>
> Wayne
>
> On 1/8/2016 1:16 PM, Chris Pavlina wrote:
> > Hi,
51:26PM -0500, Wayne Stambaugh wrote:
> On 1/11/2016 2:16 PM, Chris Pavlina wrote:
> > Had to change the capture method for both reasons. The old wxListCtrl
> > (IIRC) was the _only_ widget that captured them correctly.
>
> Maybe that's why the person who design the original
> On 1/11/2016 3:00 PM, Chris Pavlina wrote:
> > Well, yes, that would be why it was selected. I don't like the idea of
> > limiting ourselves so much (must be wxListCtrl, must be an otherwise
> > mostly empty dialog) just because of a quirk of the way wx processes
Committed in 6452. Thank you.
On Tue, Jan 12, 2016 at 02:58:53PM +1100, Cirilo Bernardo wrote:
> The attached patch fixes a logic defect in the IDF parser in which a valid
> IDF component outline is rejected if the .END_ELECTRICAL (or
> .END_MECHANICAL) statement was followed by an end-of-file rat
I think it's just a UI/usability thing. Drawing a new section of zone
intersecting the first is a significantly easier way to add area to a
zone than the alternative (which as far as I'm aware is just to "Create
Corner" a bunch of times and drag the corners).
TBH I've never personally needed ov
Simon,
This patch doesn't apply to the latest revision for me, at very least
the line numbers are off. Might have to rebase.
--
Chris
On Wed, Jan 13, 2016 at 01:21:23AM +0100, Simon Richter wrote:
>
> This is in anticipation of the introduction of icons -- retrieving all the
> icons and throw
Wow, the patch is indeed terribly hard to read.
Agreed, though, after rubbing my eyes a lot I don't see anything
dangerously different, and I'd like to keep it in sync while we're still
keeping a local copy.
Committed in 6456. Thank you.
--
Chris
On Tue, Jan 12, 2016 at 10:15:13PM +0100, Sim
That is a bizarre error from that! I didn't see anything that actually
affected the configuration when I went over the patch (most of it seemed
to be formatting and reporting), but I must have missed something.
In Simon's defense, it was sent out to the list, if you didn't see it. I
figured it
I concur. I probably shouldn't be inflammatory esp considering I just
became part of the commit team, but suggestions like this really are
just /stupid/ and detract from attempts to make KiCad actually usable.
Someone really needs to just bite the bullet, tell him the whole nginx
crap and half
Committed patches 1-3 in 6460-6462. Thank you.
Patch 4 has a small UI problem: with a lot of pins, the text field
listing defined pins overflows: https://misc.c4757p.com/overflow.png
Could you please correct this, perhaps by allowing the field to wrap,
before I apply the next two? A fifth, incr
Quick note to everything: I'm aware there are a couple missing files in
these, something messed up in my git->bzr workflow. Fixing that
immediately.
On Wed, Jan 13, 2016 at 02:13:19PM -0500, Chris Pavlina wrote:
> Committed patches 1-3 in 6460-6462. Thank you.
>
> Patch
I see that now, thanks. I misunderstood what that patch was supposed to
do. My next comment was going to be that it doesn't work ;)
Final two pushed in 6464 and 6465.
On Wed, Jan 13, 2016 at 08:16:59PM +0100, Simon Richter wrote:
> Hi,
>
> On 13.01.2016 20:13, Chris Pavlina wrote
Want me to commit this?
On Mon, Jan 11, 2016 at 09:27:49PM -0500, Chris Pavlina wrote:
> Looks like the text overflow was actually a wx bug - it insisted on
> computing the size of the wxStaticText based on the smaller default font
> instead of the larger one I had set.
>
> E
Purely out of curiosity, are we still supporting any systems /other/
than Ubuntu Geriatric Giraffe that don't support C++11?
On Thu, Jan 14, 2016 at 01:35:36AM +, Jon Neal wrote:
> Just read this the other day and figured it would be good to discuss before
> it happens.
>
> GCC is going to b
LTS users out there so leaving them out in the cold does
> not seem like a good option at the moment. There may be other distros
> (Debian Stable, Fedora 6?) that may also fall under this heading. I
> prefer to move cautiously when it comes to moving to C++11.
>
> On 1/14/2016
Yeah, I'll be difficult too - it looks Bad now, very distracting. The
legacy grid color was meant for use with a dot grid, not a line grid, so
it has to be brighter. When you use it for a line grid, it's really
garish.
I think that the grid color ought to be customizable like the layer
colors
I suppose the grid color _is_ customizable, in all my time using KiCad I
never noticed that! Everything else I said about unification stands,
though. ;)
On Thu, Jan 14, 2016 at 01:58:41PM -0500, Chris Pavlina wrote:
> Yeah, I'll be difficult too - it looks Bad now, very distract
Tom, there's a minor bug with the grid color - I'd fix it myself, but
I'm not familiar with the GAL stuff yet and don't want to go breaking
anything. When you change the grid color while GAL is active, the grid
doesn't refresh until you change the zoom level. I assume fixing that is
as simple a
the small button?
> >
> >
> > Nothing happens when I click there… but not only for grid, but also all the
> > other buttons...
> >
> >
> > Regards,
> > Bernhard
> >
> >> On 14 Jan 2016, at 20:04, Chris Pavlina >> <mail
/2016 1:58 PM, Chris Pavlina wrote:
> > Yeah, I'll be difficult too - it looks Bad now, very distracting. The
> > legacy grid color was meant for use with a dot grid, not a line grid, so
> > it has to be brighter. When you use it for a line grid, it's really
> > gar
For what it's worth...
https://gcc.gnu.org/gcc-4.8/cxx0x_status.html
As of GCC 4.8.1, C++11 is pretty much fully supported. They use the term
"experimental", but they do list everything and say "yes" to almost
everything. Is there some compatibility issue I'm missing here? It looks
to me like
pact on a HiDPI Retina display).
>
> Before my change the naive drawing (each line/circle in a single “call”) was
> really bad.
> Just a warning, but maybe this is not such a big deal on Linux/Windows...
>
>
> Regards,
> Bernhard
>
> > On 14.01.2016, at 20:40, Chris P
, and have a compiler flag for enabling C++11? Rather than ignoring
> C++11 entirely we could at least make sure that we don't have any errors
> that would make switching at a later time more difficult.
>
> I'd be happy to provide/set up the build on jenkins.
>
>
t 06:37:49PM -0500, Wayne Stambaugh wrote:
> On 1/14/2016 2:51 PM, Chris Pavlina wrote:
> > For what it's worth...
> >
> > https://gcc.gnu.org/gcc-4.8/cxx0x_status.html
> >
> > As of GCC 4.8.1, C++11 is pretty much fully supported. They use the term
> >
ase any code I missed is still trying to pass in (-1),
continue handling this in release builds. Fail with a helpful message
in debug builds.
>From 889732eb4857d889721671c9b622cc9ffcff55c9 Mon Sep 17 00:00:00 2001
From: Chris Pavlina
Date: Thu, 14 Jan 2016 17:11:03 -0500
Subject: [PATCH]
Ww, I just linked to C11.
Er... you can find the C++11 equivalent. And I shall seek new reading
glasses, or perhaps medication.
On Thu, Jan 14, 2016 at 06:48:22PM -0500, Chris Pavlina wrote:
> Fair enough.
>
> Once Ubuntu 16.04 hits, we'll have gcc >= 4.9 on all platf
Honestly, I really don't like :NICKNAME: or ::NICKNAME::. :NICKNAME: is
hard to read, and ::NICKNAME:: just looks kinda silly.
Two suggestions:
1. Either use just "NICKNAME:", to match the "library:footprint" that
we're already using - I don't like this really, but it's consistent,
or
2
Committed in 6470. Thank you.
On Thu, Jan 14, 2016 at 07:21:31PM +0100, Simon Richter wrote:
>
> Mostly cosmetic change, although there are compilers that choke on this.
>
> The C++ standard specifies that classes contain themselves as members,
> probably so they shadow any other definition of t
Committed in 6471. Thank you.
On Thu, Jan 14, 2016 at 07:21:32PM +0100, Simon Richter wrote:
>
> The C++ preprocessor is actually not required to process "true" and "false"
> correctly. This works in C if is included, because these are
> then macros themselves, and resolved correctly, but C++ re
be useful in the interim
> >>>
> >>> esspeically for those that don't have a 3-button mouse as there is no
> >>> other way
> >>>
> >>> On Fri, Jan 15, 2016 at 8:26 AM, Nick Østergaard
> >>> wrote:
> >>>> Y
Committed in 6472. Thank you. I also committed a minor fix to the coding
style in 6473.
On Wed, Jan 13, 2016 at 01:21:23AM +0100, Simon Richter wrote:
>
> This is in anticipation of the introduction of icons -- retrieving all the
> icons and throwing them away during sorting takes ages.
> ---
>
Committed in 6474. Thank you.
If you have submitted any more patches for the pin table that have been
missed, could you please dig them up again? They seem to get lost
easily.
On Wed, Jan 13, 2016 at 01:21:24AM +0100, Simon Richter wrote:
> ---
> eeschema/dialogs/dialog_lib_edit_pin_table.cpp
year and a half -
so if nobody says anything for a day or so, I'll go ahead and commit. On
the off chance someone's particularly attached to the code, feel free to
yell at me and I'll withhold the patch.
Thanks,
Chris
>From 3834d6261dcf6a71a8c26ac6a7ea02cd1f33be35 Mon Sep 17 00:00
n Eeschema is coming as
> > part of the current dev cycle. It wont start until after I finish up
> > with the Eeschema refactor. Trust me when I tell you, to do so would
> > not be a good idea.
> >
> >>
> >>
> >> Regards,
> >> Bernhard
It is a new(ish) decision. Cairo is an implementation that doesn't
require hardware features, but it is uselessly slow - even on my main
build machine which is quite snappy I'd completely refuse to work under
it. We need a GAL backend that works with minimal hardware at a usable
speed, and I gu
Okay, I merged this - I'm still not 100% clear whether or not you wanted
me to, but it's been quite a while and I've fixed what you told me to
fix - feel free to revert if I'm wrong.
On Wed, Jan 13, 2016 at 09:36:13PM -0500, Chris Pavlina wrote:
> Want me to commit th
Committed in 6480. Thank you.
On Sat, Jan 16, 2016 at 04:11:47AM +0100, Simon Richter wrote:
> ---
> pcbnew/autorouter/rect_placement/rect_placement.cpp | 1 -
> 1 file changed, 1 deletion(-)
>
___
Mailing list: https://launchpad.net/~kicad-developers
Committed in 6481. Thank you.
On Sat, Jan 16, 2016 at 04:22:23AM +0100, Simon Richter wrote:
>
> In the autorouter code, the value 0x80 is assigned to MATRIX_CELL, which is
> an overflow for a signed 8-bit type. As this type is used as a bit mask,
> there is no point in having a sign bit anyway.
Hi,
The next installment of my preferences work is simple, I pulled the
color configuration dialog into the eeschema preferences dialog. I
deleted the original color dialog, removing it from libedit as well
(it's just redundant there, it edits the same settings that are shared
across both).
U
016 at 8:26 AM, Nick Østergaard wrote:
> >>> Yeah, I also noticed this, except I did not think of scrolling, but
> >>> just switched to legacy and back.
> >>>
> >>> 2016-01-14 20:04 GMT+01:00 Chris Pavlina :
> >>>> Tom, there's a
Hmm. From my perspective, I didn't really think it was a policy
violation as such, as that is definitely not MSVC-specific. It's just
"portable", which is generally a good thing - if we were ever to change
the current policy in the future, the more portable the code is, the
easier that will be.
At the risk of sounding curt - search the mailing list archive, we've
been discussing this for a *long* time, including a thread that was
active in just the last couple days. We're looking into moving to git
(not necessaily github, but possibly), it's just a large task (and there
maay be a
MSVC. Devs who want to use MSVC should keep the MSVC
> >> specific code in their personal repos. Maybe some time I will be able
> >> to embrace MSVC. Today is not that day. We have much bigger issues to
> >> resolve than getting KiCad to build on MSVC.
> >>
Merged, since nobody objected - I'd like to get on with the more
important preferences work.
On Sat, Jan 16, 2016 at 12:54:38AM -0500, Chris Pavlina wrote:
> Hi,
>
> The next installment of my preferences work is simple, I pulled the
> color configuration dialog into the ees
Committed 1(v2)..3 in 6490..6492. Thank you.
On Sat, Jan 16, 2016 at 04:41:47AM +0100, Simon Richter wrote:
> Hi,
>
> these are portability patches, most of them derived from MSVC diagnostics.
>
> The MSVC standard library and compiler are a lot more picky about standards
> compliance, so a lot
Committed in 6493. Thank yuo.
On Sat, Jan 16, 2016 at 04:41:51AM +0100, Simon Richter wrote:
>
> The standard library requires iterators passed to functions that modify the
> container to be mutable iterators, but GCC's implementation accepts
> const_iterator in some places where these are only u
Hi,
I'd like to discuss the Save/Load Preferences feature a bit. I've never
quite exactly understood what it's supposed to be used for. Here's what
I gathered from the code:
- Save Preferences calls SaveProjectSettings(true), asking the user if
he wants to save the settings. This isn't the o
On Sun, Jan 17, 2016 at 06:46:25PM +0100, Martin Marmsoler wrote:
> Hello,
>
> I would ask how you debug KiCad,
Using gdb at the command line or the gdb plugin in emacs. :)
> because I tried to do it with QtCreator. I
> starts KiCad, I can also click on the pl editor and there I can do
> somethi
rl-I (well, it's not
> nice but not a show-stopper).
>
> Maybe you want to verify and fix these issues.
>
> Regards,
>
> Clemens
>
> On 2016-01-16 03:10, Chris Pavlina wrote:
> > Okay, I merged this - I'm still not 100% clear whether or not you wanted
> > m
#x27;ll be an
ld one, maybe since that bit was added.
If it *is* my fault, I don't want anyone spending a long time trying to
find it for me :)
On Mon, Jan 18, 2016 at 01:01:51AM +0100, Clemens Koller wrote:
> Hi, Chris!
>
> On 2016-01-18 00:47, Chris Pavlina wrote:
> > T
personal and project growth.
> I'm not naive enough to believe that this will necessarily happen but
> that doesn't mean I shouldn't try. It also gives me a chance to inform
> new developers what my expectations are for the development team. This
> is not directed a Chri
, 2016 at 05:05:51PM +0100, jp charras wrote:
> Le 17/01/2016 19:02, Chris Pavlina a écrit :
> > Hi,
> >
> > I'd like to discuss the Save/Load Preferences feature a bit. I've never
> > quite exactly understood what it's supposed to be used for. Here
I'm tempted to quip "a developers' mailing list", but the rest of you
are perhaps less gittish than I am :D
On Mon, Jan 18, 2016 at 09:56:13AM -0700, Andy Peters wrote:
> On Jan 18, 2016, at 8:32 AM, Chris Pavlina wrote:
> >
> >
> > I still think
7;m willing to check them over. I'd probably be much more
willing to use the github library system if it could do things like
that.
On Mon, Jan 18, 2016 at 01:11:08PM -0500, Wayne Stambaugh wrote:
> On 1/18/2016 11:56 AM, Andy Peters wrote:
> > On Jan 18, 2016, at 8:32 AM, Chris
Just ignore this patch.
On Jan 14, 2016 18:56, "Chris Pavlina" wrote:
> Hi,
>
> We have a few minor typing issues with the GR_KB_* constants in
> include/common.h:
>
> - Type is a signed int32 on most platforms, yet we use 0x8000
> (greater than INT_MAX
it more complex than they
should be.
I'm testing on Linux 64-bit and Windows 64-bit, that's all that's
available to me.
On Tue, Jan 19, 2016 at 05:03:34PM +0100, jp charras wrote:
> Le 19/01/2016 15:02, Chris Pavlina a écrit :
> > Just ignore this patch.
> > On J
Updated patch attached, tested on Linux 64 and Windows 64, works fine.
On Tue, Jan 19, 2016 at 11:06:18AM -0500, Chris Pavlina wrote:
> I made a few silly mistakes in the patch, I'm testing an updated one on
> multiple platforms currently.
>
> 1. I switched to uint32_t
Thanks. Since this particular bit has the potential to be
platform-dependent, I'd like if someone on OSX could test as well before
pushing.
On Tue, Jan 19, 2016 at 09:15:55PM +0100, jp charras wrote:
> Le 19/01/2016 18:33, Chris Pavlina a écrit :
> > Updated patch attached, test
s?
> I can give it a quick try then...
>
>
> Regards,
> Bernhard
>
> > On 19 Jan 2016, at 21:15, Chris Pavlina wrote:
> >
> > Thanks. Since this particular bit has the potential to be
> > platform-dependent, I'd like if someone on OSX could test
t.
> > Cmd+Left and Cmd+Shift+Left do delete/drag blcok as intended.
> > I checked on my normal version and it is the same there, so no regression.
> > I’ll put it on my todo list if nobody else has an idea how to fix this -
> > not in the near future, before that I will t
ndling.
Thanks for testing.
--
Chris
>From 86ed9ecfe6cdada8cae8ce6089e9fe2e600c2f18 Mon Sep 17 00:00:00 2001
From: Chris Pavlina
Date: Wed, 20 Jan 2016 21:10:46 -0500
Subject: [PATCH] Fix (Ctrl)+(ASCII control key) hotkey handling
wxWidgets has quirks with how it handles these keys. For exam
Hm, is this really something we want to get into? Nice to remove the
dependency, but when something breaks in the future, do we have any/many
developers who can support x86 assembly code?
I really think that if we're going to have to support this, it should be
something conceptually simpler, li
but will test your code asap
> next week, I hope. Thanks for taking care about that!
>
> On 2016-01-21 04:44, Chris Pavlina wrote:
> > - Hotkeys that are *not* handled by the main hotkey code (for example,
> > menu keys like Alt+F to call up the File menu) are not affecte
Fair enough, and it's nice to fix the boost issue. I suppose if support
ever becomes an issue we can consider replacing it _then_.
On Thu, Jan 21, 2016 at 03:21:41PM +0100, Tomasz Wlostowski wrote:
> On 21.01.2016 15:03, Chris Pavlina wrote:
> > Hm, is this really something we wa
16 04:44, Chris Pavlina a écrit :
> > There is an old bug that people turned up while testing my new hotkey
> > editor, attached is a patch that fixes it. This patch pokes into the
> > main hotkey handling code, so I really want as many people to test it as
> > possible
Regression fixed in 6505, feel free to continue testing :)
On Thu, Jan 21, 2016 at 12:05:51PM +0100, jp charras wrote:
> Le 21/01/2016 04:44, Chris Pavlina a écrit :
> > There is an old bug that people turned up while testing my new hotkey
> > editor, attached is a patch that
e thorough testing
even on those same platforms is welcome.
On Wed, Jan 20, 2016 at 10:44:36PM -0500, Chris Pavlina wrote:
> There is an old bug that people turned up while testing my new hotkey
> editor, attached is a patch that fixes it. This patch pokes into the
> main hotkey handl
Yeah, I don't have time to test it right now, but all of this. I really
don't like the netlist workflow, and the first version of this was
really nice when it was introduced last year.
On Fri, Jan 22, 2016 at 09:58:32PM +, Jon Neal wrote:
> Very interesting. I compiled it for a quick look, s
Committed in 6508. Thank you.
On Fri, Jan 22, 2016 at 05:12:44PM +0100, Martin d'Allens wrote:
> Using "Append Schematic Sheet" in Eeschema does not set the
> IsModified() flag, which prevents from saving until another change is
> made.
> This very simple patch fixes this.
>
> Initial report:
> h
Hi,
Revision 6504 changes the pcb_calculator accelerator key from Ctrl+C
to Ctrl+A, as "Ctrl+C cannot be used here as accelerator, because it
is captured by other widgets".
So is Ctrl+A, if the status messages box is focused, that's Select
All ;)
--
Chris
__
When I fix project file selection for this, how should I do it? Do we want to
ditch the file selection dialog and just save to the current project file, or
keep the selection dialog and respect the selection?
On Fri, Jan 22, 2016 at 03:47:31PM -0500, Wayne Stambaugh wrote:
> On 1/18/2016 1:59 PM,
Almost certainly a wx bug/quirk. Wx does really weird things on window
resize, at least on gtk - my other wx applications do things like this too.
On Jan 26, 2016 1:24 PM, "Kaspar Emanuel" wrote:
> Haha, I have had issues like this for a long time running XMonad. Never
> even thought about report
t
now, check whether that happens on an unpatched build - i.e., whether it is a
regression.
On Fri, Jan 22, 2016 at 04:04:44PM -0500, Chris Pavlina wrote:
> Updated patch - quite a few changes. First I noticed I was inadvertently
> trapping some keys I shouldn't (try using Ctrl+S w
Thanks to both of you. I'm sure it's not perfect yet, but it's a *massive*
improvement in the workflow, and should see more general testing. I'm sure we
can handle rough edges for a little while. :)
On Fri, Jan 29, 2016 at 04:01:30PM +0100, Maciej Sumiński wrote:
> After some extra testing and fix
one: don't say "Netlist update successful!" in the list of _proposed_
changes, it's a bit confusing as it seems to imply the changes have actually
been made.
On Fri, Jan 29, 2016 at 10:13:51AM -0500, Chris Pavlina wrote:
> Thanks to both of you. I'm sure it's
27;s very common.)
On Fri, Jan 29, 2016 at 04:47:38PM +0100, Tomasz Wlostowski wrote:
> On 29.01.2016 16:23, Chris Pavlina wrote:
> > Okay, after testing this, I actually have two "bug reports", one that I
> > consider fairly important, and one that's minor.
> >
people to figure out,
particularly if the summary of proposed changes automatically updates when the
state of that checkbox changes..
On Fri, Jan 29, 2016 at 05:16:34PM +0100, Tomasz Wlostowski wrote:
> On 29.01.2016 16:49, Chris Pavlina wrote:
> > Oh, it's definitely a dirty hack - but
indow gets closed, but no hotkey is assigned.
>
> Any other special case to test?
>
>
> Regards,
> Bernhard
>
>
> > On 29.01.2016, at 18:34, Bernhard Stegmaier wrote:
> >
> > I can try tomorrow…
> >
> >> On 29 Jan 2016, at 15:44, Chri
The wx documentation says:
"Note that since wxWidgets 2.9.0 you shouldn't use wxT() anymore in your
program sources (it was previously required if you wanted to support Unicode)."
http://docs.wxwidgets.org/trunk/group__group__funcmacro__string.html
*shouldn't* is definitely stronger than "mostly
I will test this - I'll override wxT() in my local builds and run kicad like
this for a week or so to make sure nothing bad pops up.
On Tue, Feb 02, 2016 at 02:58:31PM -0500, Wayne Stambaugh wrote:
> On 2/2/2016 11:21 AM, Chris Pavlina wrote:
> > The wx documentation says:
>
Committed in revision 6540. Thank you.
On Fri, Feb 05, 2016 at 07:34:02PM +, Tom Andrews wrote:
> Hi guys,
>
> Just a few basic spelling/grammar errors I came across whilst making a
> board.
>
> Patch attached.
>
> Cheers,
>
> Tom
___
Mailing li
Eh. I agree 100% about hidden pins being Bad, anyone using them surely should
be tarred and feathered. But I'm not sure it's our place to enforce good
schematic drawing practices. If people want to use KiCad to draw terrible,
horrible schematics, they'll find a way. Personally, I'm *strongly* again
+1 to this, this is the only one that's been working properly for me lately...
On Sat, Feb 06, 2016 at 07:44:14PM +, Jon Neal wrote:
> Mark Roszko forked wxFormBuilder to make building much easier and faster +
> has at least one new wxWidgets widget.
>
> https://github.com/marekr/wxFormBuilde
t; >>>
> >>> Accidentally, I just got a hand on a windows laptop.
> >>> The 3.5.1-rc1 really is usable on Windows… so much for being
> >>> cross-plattform… :)
> >>> At least for the files I need I could check and generate the
On Wed, Mar 02, 2016 at 06:31:50PM +0100, Nick Østergaard wrote:
> [snip]
> I guess that is just fine. I have some minor comments on the text inline
> below.
>
> Maybe write Dynamic Librarires?
> Is all this static? If so, maybe state that explicitly too?
...why? KiCad is always built the same w
Personally I agree with your assessment, and I like the looks of some of what
you're doing, though I only had a chance to give it a quick glance. Perhaps you
could get in touch directly with Tom Włostowski? This is pretty much 'his' code
for the time being.
On Mon, Mar 07, 2016 at 10:59:10PM +1300
It doesn't seem to me that enabling a config macro as well is really all that
much.
Since we're still in the heavy development phase of the cycle, I personally
think that this is the absolute _best_ time to do things like enabling C++11.
We're not making any major releases now, so we have plenty o
I feel like emphasizing here that our attempt at saving file size doesn't
actually do anything since we've changed defaults in our library standard
anyway. :\
On Thu, Mar 10, 2016 at 11:01:32PM +, Jon Neal wrote:
> Oh, I should add that to prevent breaking backwards compatibility the
> parser
You're doing it the wrong way around - if the documentation suggests doing it
this way, it should probably be changed.
First, place the hierarchical labels _inside_ the sheets (not the sheet symbols
- switch to that sheet and place them) using the "Place a hierarchical label"
button directly under
Hey, just wondering about something. PNS has had slightly different rounding
behavior than DRC since the beginning - when I use PNS heavily on a board, I
usually have to decrease my clearance very slightly (say from 0.2mm to 0.199mm)
to make DRC pass. Is this a known issue among the devs working on
people complaining about that,
especially since it's an "invisible" margin.
Hrm. This doesn't strike me as a particularly easy problem to solve.
On Sat, Mar 19, 2016 at 11:21:01PM +0100, Tomasz Wlostowski wrote:
> On 19.03.2016 19:11, Chris Pavlina wrote:
> >
viour of both dialogs and there is a single place
>where it needs to be modified.
>
> Regards,
>
> --
> Daniel Wilches
>
>
> On Wed, Mar 16, 2016 at 9:35 PM, Chris Pavlina
> wrote:
>
> > I can confirm this bug. Thanks for looking to contribute! I've a
Patch committed in r6634. Thank you.
On Mon, Mar 21, 2016 at 12:22:07PM +1100, Cirilo Bernardo wrote:
> The attached patch makes the following changes to import DXF:
>
> 1. correctly implements scaling based on DXF $INSUNITS -
> at least where INSUNITS is sensible. I ignore units like miles,
> gi
Someone should probably ask - apologies if someone already did: Do you have a
policy in mind for using C++11 features in new patches? It may be prudent to
let the patch settle for a few days just to make sure nobody else has build
trouble before we start making it harder to back out.
On Mon, Mar 2
Are we sure this isn't the issue where cmake forgets to rebuild
pcbnewPYTHON_wrap.cxx? I've been having that issue about once every couple
weeks for a while, just delete it and rebuild :P
On Mon, Mar 21, 2016 at 08:13:48PM +0100, Nick Østergaard wrote:
> 2016-03-21 20:10 GMT+01:00 jp charras :
> >
16.04 LTS will be released in April. Personally I think we should be free to
stop supporting 14.04 Geriatric Giraffe already in the development branch - why
should a devel branch of kicad support non-devel branches of Ubuntu? KiCad
stable runs on Ubuntu "stable" (LTS). But I seem to be in the minor
601 - 700 of 1122 matches
Mail list logo
