Re: [Kicad-developers] [RFC] Logo Consolidation

Hi, I like the use of the schematic/pcb elements. It also looks much better at small scales I tried the scaling and made a mockup at icon resolutions from 16x16 to 64x64 with 8 pixel steps (16, 24, 32, etc.), see attachment. Scaling works good IMO, but cannot avoid bike-shedding: On the

[Kicad-developers] [PATCH] Add WithAlpha method to COLOR4D

Hi, Here's a patch to add a new method to COLOR4D: WithAlpha. This means you can do this: const COLOR4D color = getSomeColor(); //could be an argument or static const gal.SetStrokeColor( color.WithAlpha( 0.5 ) ); Rather than: const COLOR4D color = getSomeColor(); //could be an

Re: [Kicad-developers] RICHIO performance - 3 to 30 times slower than std::ifstream

Hi Wayne, Sorry for the delay, I've been a bit distracted by other things. The attached patch adds io_benchmark as a new target under tools. For now, it only includes LINE_READER input benchmarks. It currently supports: * Existing FILE_LINE_READERs * Raw std::ifstream reading (with getline, so

Re: [Kicad-developers] [PATCH] Add missing header

On Wed, Mar 1, 2017 at 11:40 PM, Simon Richter wrote: > > color_swatch.cpp uses std::unique_ptr Hi Simon, This must be because the compiler (MSVC on Jenkins) has set __cplusplus to something other than 201103L, so include/make_unique.h isn't doing the polyfill and also

[Kicad-developers] [RFC] Logo Consolidation

Hi all, One small thing that has bugged me for a while is the various icons that are considered "official" for Kicad. The application, website, forum and github all use different icons. Further, the application icon looks very cluttered when reduced to a small size e.g. on window title bar. I

Re: [Kicad-developers] RICHIO performance - 3 to 30 times slower than std::ifstream

On 2/19/2017 4:27 AM, John Beard wrote: > On Sat, Feb 18, 2017 at 1:08 AM, Nox wrote: >> What about wxFFileInputStream instead of wxFileInputStream? >> > > wxFFileInputStream appears to be about 5-6 times faster than > wxFileInputStream, but that's still much much slower

Re: [Kicad-developers] [Request for Tests] Experimental icon options in Kicad

On 2017-03-01 02:45 PM, Julius Schmidt wrote: Since it just scales the bitmaps it looks pretty terrible on this display (even on the lowest scaled setting, 1.5). Another approach is to have bitmaps for high DPI and scale them down to the size needed on smaller screens. -- Cheers! Kevin.

Re: [Kicad-developers] [RFC] 3D models repository

Preview of the 3D library (working closely with Rene and Maurice, this is coming together nicely). https://github.com/KiCad/packages3D On Mon, Feb 27, 2017 at 6:17 PM, Javier Serrano < javier.serrano.par...@gmail.com> wrote: > On Sun, Feb 26, 2017 at 11:55 PM, Cirilo Bernardo < >

Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault

My point is that threading could be used to implement a *drop-in replacement*...not that the tool framework should be structured around them, but that it continues to use coroutines, and we make a coroutine library that is implemented using threads... :P On Wed, Mar 01, 2017 at 04:32:39PM -0500,

Re: [Kicad-developers] [PATCH] Move ZoomFitScreen and ZoomPreset to common

Got it! Then I'm ok with the changes assuming they don't break anything else. On 3/1/2017 4:28 PM, Jon Evans wrote: > The caching was only used by the auto router before. Orson's patch > implements local caching in the auto router, and other sites just > regenerate the bbox when they need to

Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault

We all have our preferred solutions the problem at hand. I personally didn't see any reason to not use events. I have a sneaking suspicion that the context switching was done to isolate the coder from having to deal with events directly which on the surfaces seems like a good idea but causes

Re: [Kicad-developers] [PATCH] Move ZoomFitScreen and ZoomPreset to common

The caching was only used by the auto router before. Orson's patch implements local caching in the auto router, and other sites just regenerate the bbox when they need to retrieve it, which is the same behavior as before. We can't add a caching system that didn't exist before without the board

Re: [Kicad-developers] [PATCH] Move ZoomFitScreen and ZoomPreset to common

I thought we were retaining the cached behavior for existing code and implementing a secondary feature to always recalculate the bounding box. It looks to me as though the cached behavior has completely been removed unless I'm missing something. On 3/1/2017 9:07 AM, Jon Evans wrote: > It was in

Re: [Kicad-developers] [Request for Tests] Experimental icon options in Kicad

On 3/1/2017 2:51 PM, Jon Evans wrote: > I think in the "real world" people usually solve this by either using > vector icons or (more commonly I think) using icon formats that store a > number of different resolutions (16x16, 32x32, 48x48, etc) and picking > the best one based on the screen DPI.

Re: [Kicad-developers] [Request for Tests] Experimental icon options in Kicad

On 3/1/2017 2:45 PM, Julius Schmidt wrote: > I have a 2560x1440 14" display here. I have no idea what wxWidgets queries > for "system dpi" (I'm running dwm), but I've tested the icon scaling > setting. Thank you for taking the time to test this Julius. > > Since it just scales the bitmaps it

Re: [Kicad-developers] [Request for Tests] Experimental icon options in Kicad

I think in the "real world" people usually solve this by either using vector icons or (more commonly I think) using icon formats that store a number of different resolutions (16x16, 32x32, 48x48, etc) and picking the best one based on the screen DPI. (This is how Android works). The upside is

Re: [Kicad-developers] [Request for Tests] Experimental icon options in Kicad

I have a 2560x1440 14" display here. I have no idea what wxWidgets queries for "system dpi" (I'm running dwm), but I've tested the icon scaling setting. Since it just scales the bitmaps it looks pretty terrible on this display (even on the lowest scaled setting, 1.5). Obviously vectorised

Re: [Kicad-developers] [PATCH] Add missing header

Hi, On 01.03.2017 18:26, Kevin Cozens wrote: >> +#include >> + > That looks like a typo. I think that should be No, that is correct. is a C header that pulls in , for memcpy() and friends. is a C++ header that defines std::unique_ptr and std::shared_ptr. Simon signature.asc

Re: [Kicad-developers] [PATCH] Add missing header

C++ standard library headers have no extension. On Wed, Mar 01, 2017 at 12:26:51PM -0500, Kevin Cozens wrote: > On 2017-03-01 10:40 AM, Simon Richter wrote: > > On the attached patch it says: > +#include > + > > That looks like a typo. I think that should be > > -- > Cheers! > > Kevin. >

Re: [Kicad-developers] [PATCH] Add missing header

On 2017-03-01 10:40 AM, Simon Richter wrote: On the attached patch it says: +#include + That looks like a typo. I think that should be -- Cheers! Kevin. http://www.ve3syb.ca/ |"Nerds make the shiny things that distract Owner of Elecraft K2 #2172 | the mouth-breathers, and

Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault

I know I've suggested this before and been shot down, but I'm still pretty convinced a coroutine library could be made that makes use of native threading support. This would be totally portable to all platforms! I don't have the time to POC it myself, I already have a kicad todo list miles long.

Re: [Kicad-developers] [Request for Tests] Experimental icon options in Kicad

On 3/1/2017 11:15 AM, jp charras wrote: > Le 01/03/2017 à 15:05, Wayne Stambaugh a écrit : >> I'm OK with making the menu icons a user option rather than a build time >> option. I really don't have a preference on this issue so give the >> people what they want. >> >> The bitmap scaling is a

Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault

That's the one is was thinking about! AArch64 is coming fast so we only do ourselves a disservice by not supporting it. In fact, there is now a aarch64 device available designed with KiCad. It would be ironic if KiCad couldn't run on it due to lack of support. SPARC and PPC may not be main

Re: [Kicad-developers] [Request for Tests] Experimental icon options in Kicad

Le 01/03/2017 à 15:05, Wayne Stambaugh a écrit : > I'm OK with making the menu icons a user option rather than a build time > option. I really don't have a preference on this issue so give the > people what they want. > > The bitmap scaling is a separate issue and needs to be tested by users >

Re: [Kicad-developers] [update] [PATCH] Differential pair DRC Errors

Le 01/03/2017 à 16:43, Tomasz Wlostowski a écrit : > On 13.02.2017 18:04, Tomasz Wlostowski wrote: >> On 13.02.2017 17:26, Jon Evans wrote: >>> I verified using Novak's test case on the Launchpad bug report. DRC >>> error is generated if the distance between the tracks is exactly equal >>> to the

Re: [Kicad-developers] [update] [PATCH] Differential pair DRC Errors

On 13.02.2017 18:04, Tomasz Wlostowski wrote: > On 13.02.2017 17:26, Jon Evans wrote: >> I verified using Novak's test case on the Launchpad bug report. DRC >> error is generated if the distance between the tracks is exactly equal >> to the clearance. >> If you increase the spacing by the

[Kicad-developers] [PATCH] Add missing header

color_swatch.cpp uses std::unique_ptr --- common/widgets/color_swatch.cpp | 2 ++ 1 file changed, 2 insertions(+) diff --git a/common/widgets/color_swatch.cpp b/common/widgets/color_swatch.cpp index 745537d4b..354ed5df3 100644 --- a/common/widgets/color_swatch.cpp +++

Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault

On 01.03.2017 16:19, Chris Pavlina wrote: > Wayne *please* tell me you won't block something that fixes macOS > support and eliminates future boost API problems (which we've had > SEVERAL problems with in the past) because of a lack of support for > bloody *SPARC and PPC*. If there is a single

Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault

Ah, crap. Missed that. Don't think I have one lying about anymore to volunteer... :( On Wed, Mar 01, 2017 at 04:21:56PM +0100, Tomasz Wlostowski wrote: > On 01.03.2017 16:19, Chris Pavlina wrote: > > Wayne *please* tell me you won't block something that fixes macOS > > support and eliminates

Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault

Wayne *please* tell me you won't block something that fixes macOS support and eliminates future boost API problems (which we've had SEVERAL problems with in the past) because of a lack of support for bloody *SPARC and PPC*. If there is a single user using KiCad on these platforms I would like to

Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault

On 01.03.2017 15:58, Wayne Stambaugh wrote: > I am in favor of this if and only if we have equivalent or better > architecture coverage compared to the boost context library. If not, > than I am opposed to it. > Hi Wayne, Libcontext currently supports x86/x86_64/ARM32 on all OSes. I could not

Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault

I am in favor of this if and only if we have equivalent or better architecture coverage compared to the boost context library. If not, than I am opposed to it. On 3/1/2017 9:32 AM, Chris Pavlina wrote: > I am in favor of this. > > On Wed, Mar 01, 2017 at 02:03:37PM +0100, Maciej Sumiński wrote:

Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault

I am in favor of this. On Wed, Mar 01, 2017 at 02:03:37PM +0100, Maciej Sumiński wrote: > I will do my best, but I really cannot promise any time slot for looking > into the issue. Perhaps it is the time to revisit Tom's libcontext [1]? > The number of #ifdefs in tge current coroutine code makes

Re: [Kicad-developers] [PATCH]: Calculator: Simplify color code tolerance chooser + typo

Hi! Agree... It makes sense to reduce the options to 3-band and 4-band resistors... as the tolerance information is then implicit/redundant/irrelevant. It might be even sufficient to simply mark the 4th band as "optional". :-) This dialog could be much more nice/useful if we could simply

Re: [Kicad-developers] [Request for Tests] Experimental icon options in Kicad

I'm OK with making the menu icons a user option rather than a build time option. I really don't have a preference on this issue so give the people what they want. The bitmap scaling is a separate issue and needs to be tested by users with high dpi displays. I don't recall anyone reporting back

Re: [Kicad-developers] [PATCH] Move ZoomFitScreen and ZoomPreset to common

It was in this thread; I've attached them both again for convenience. The "0001-Remove-BOARD-SetBoundingBox.patch" is applied after applying the other patch. On Wed, Mar 1, 2017 at 8:59 AM, Wayne Stambaugh wrote: > On 3/1/2017 8:54 AM, Jon Evans wrote: > > Wayne, Orson's

Re: [Kicad-developers] [PATCH] Move ZoomFitScreen and ZoomPreset to common

On 3/1/2017 8:54 AM, Jon Evans wrote: > Wayne, Orson's latest patch is basically Option 2 but implemented > another way. Can you check it out and let us know if you are OK merging > it as-is, or if we should change the implementation to be more like what > I described? I don't remember seeing

Re: [Kicad-developers] SCH_LEGACY_PLUGIN buffering

On 3/1/2017 4:38 AM, Maciej Sumiński wrote: > On 02/28/2017 05:20 PM, Wayne Stambaugh wrote: > [snip] > Regarding the second patch: I am looking for a way to store temporary > changes to libraries. Libraries are linked to files, and now the binding > is even stronger, as files are

Re: [Kicad-developers] [PATCH] Move ZoomFitScreen and ZoomPreset to common

Wayne, Orson's latest patch is basically Option 2 but implemented another way. Can you check it out and let us know if you are OK merging it as-is, or if we should change the implementation to be more like what I described? Thanks, Jon On Wed, Mar 1, 2017 at 8:43 AM, Wayne Stambaugh

Re: [Kicad-developers] [PATCH] Move ZoomFitScreen and ZoomPreset to common

Option 2 seems fine. It may be easier to just add an option argument to the existing GetBoundingBox() function to either return the cached bounding box or recalculate the bounding box on demand rather than create a different function for the cached vs. uncached version. On 3/1/2017 2:51 AM,

Re: [Kicad-developers] filename fun

On 2/28/2017 7:28 PM, Cirilo Bernardo wrote: > On Wed, Mar 1, 2017 at 11:13 AM, Wayne Stambaugh wrote: >> On 2/28/2017 7:07 PM, Cirilo Bernardo wrote: >>> On Wed, Mar 1, 2017 at 10:33 AM, Wayne Stambaugh >>> wrote: On 2/28/2017 4:08 PM, Cirilo

Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault

I will do my best, but I really cannot promise any time slot for looking into the issue. Perhaps it is the time to revisit Tom's libcontext [1]? The number of #ifdefs in tge current coroutine code makes eyes pop out, and I am afraid with the new issue we would be forced to add "#ifdef __APPLE__"

[Kicad-developers] Jenkins build is back to normal : linux-kicad-full-gcc-head #1857

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

Re: [Kicad-developers] [PATCH] eeschema pspice netlist exporter alternative list.

Hi Martin, I am sorry it has taken me so long to respond. Your patch looks reasonable, so I have just pushed it. Thank you for your contribution. Regards, Orson On 02/22/2017 03:24 AM, Martin Stoilov wrote: > Hello all, > > Ngspice requires four nodes for a MOSFET component - nd ng ns nb, but

[Kicad-developers] Jenkins build is back to normal : kicad-qa #2365

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

[Kicad-developers] Build failed in Jenkins: linux-kicad-full-gcc-head #1856

See Changes: [jean-pierre charras] GAL mode: Add small cross option to grid style (now: options are Dots, [jean-pierre charras] GAL: better progression between zoom in/zoom out (in/out/in sequence

[Kicad-developers] Build failed in Jenkins: kicad-qa #2364

See Changes: [jean-pierre charras] GAL mode: Add small cross option to grid style (now: options are Dots, [jean-pierre charras] GAL: better progression between zoom in/zoom out (in/out/in sequence

Re: [Kicad-developers] [Request for Tests] Experimental icon options in Kicad

Hi Guys, I do not have a HDPI monitor but I just would like to add that in my opinion it might be a good idea to have the option of showing and not showing menu icons. Regarding the resizing I have no opinion. Cheers Fabrizio On Mon, Feb 27, 2017 at 4:34 PM, Wayne Stambaugh

Re: [Kicad-developers] New addition to the lead developer team.

Congrats Tom! and thanks for the hard work. On Tue, Feb 28, 2017 at 11:37 AM, Tomasz Wlostowski < tomasz.wlostow...@cern.ch> wrote: > On 27.02.2017 22:52, Wayne Stambaugh wrote: > > I have just given product and stable branch commit privileges to Tomasz > > Wlostowski. Please join me in

Re: [Kicad-developers] SCH_LEGACY_PLUGIN buffering

On 02/28/2017 05:20 PM, Wayne Stambaugh wrote: [snip] Regarding the second patch: I am looking for a way to store temporary changes to libraries. Libraries are linked to files, and now the binding is even stronger, as files are reloaded upon a change [1]. It means that

[Kicad-developers] Build failed in Jenkins: linux-kicad-full-gcc-head #1855

See Changes: [Maciej Suminski] Store information about buffering & caching in properties [Maciej Suminski] Added missing PROPERTIES parameter to function calls in PART_LIB [Maciej Suminski] Register

[Kicad-developers] Build failed in Jenkins: kicad-qa #2363

See Changes: [Maciej Suminski] Store information about buffering & caching in properties [Maciej Suminski] Added missing PROPERTIES parameter to function calls in PART_LIB [Maciej Suminski] Register common tools in

Re: [Kicad-developers] [PATCH] Fix layer color swatches in Linux

Hi John, Thank you for the patches. I have tested them on Linux and Windows, and everything works as expected. I think the layer widget looks even better now, good job! Cheers, Orson On 03/01/2017 01:11 AM, John Beard wrote: > Hi Wayne, > > On Wed, Mar 1, 2017 at 2:06 AM, Wayne Stambaugh

Re: [Kicad-developers] [PATCH] Fix zoom controls in footprint viewer

Thank you Jon, I have just pushed your patch. Regards, Orson On 03/01/2017 03:59 AM, Jon Evans wrote: > This got overlooked in common_tools refactor > > -Jon > > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to :