Re: [Kicad-developers] Packaging question

[Carsten Schoenert]

Am 27.02.2018 um 00:41 schrieb Nick Østergaard:
> And I still think it is fine to talk about general packaging things
> on the dev list because packagers for multiple platforms are
> available here. Often it is also relevant for some development
> decisions.

I guess this is mostly addressed to me due my previous answer within
this thread.

Nick. I fully agree here with you, no doubt. General and "default"
questions should and need to be discussed in a broader audience like on
this ml for the reasons you describe.

For more in detail questions that are not in the main scope of this list
I'd like to see not more than the needed noise, the traffic on the list
is not that low most of the time and so I can't always follow some
topics every time.

The packaging formats in the different Linux distributions are differing
in details. So some feature that is possible in distro A isn't possible
in distro B. Related to this it's simple impossible to keep the same
package name layout in sync over the Linux distributions at the same
time. Also the strategy of some distributions for life circle and
updates are basically different. The rolling release based distros (like
Arch) are fundamentally different to major version releasing distros and
lower done the requirements on the underlying package manager.

To make it short, I assume it's impossible to let every distro have the
same packages with the same content.

-- 
Regards
Carsten Schoenert

___
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] Rework footprint selection filtering to improve behavior

[Jon Evans]

This patch changes the selection logic for footprints to fix a reported
issue[1] and to make the behavior more logical to me.

I know that correct selection behavior is something of a personal
preference, so I'm ready to be flamed :-)

The new behavior:

A footprint may be selected if:
1) The corresponding "Footprints" switch is on in the Items tab, AND
2) One or more of the layers that the footprint draws on is visible

This means that if all of the layers are turned off, footprints are not
selectable (fixes the bug), but it also means that now footprints can be
selected if any draw layers are visible (for example, if you have only
F.Mask enabled, you can select a footprint that has solder mask and is on
the front layer).

Before anyone complains, this is only if high-contrast mode is turned OFF.
When it is on, you can still only select items that *only* exist on that
layer (to make moving silkscreen around easier, for example)

Even though this adds some more for-loops to selection filtering, I have
not noticed any performance hits on some selection of large boards that I
tested.  More testing is welcome.

[1] https://bugs.launchpad.net/kicad/+bug/1751960

-Jon
From c6346d1042965957ff34baf514e4bea79776eca2 Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Mon, 26 Feb 2018 22:06:31 -0500
Subject: [PATCH] Rework footprint selection filtering to improve behavior

Fixes: lp:1751960
* https://bugs.launchpad.net/kicad/+bug/1751960
---
 pcbnew/class_module.cpp | 28 
 pcbnew/class_module.h   |  8 
 pcbnew/tools/selection_tool.cpp | 31 ++-
 3 files changed, 62 insertions(+), 5 deletions(-)

diff --git a/pcbnew/class_module.cpp b/pcbnew/class_module.cpp
index 9968991b4..eed3da407 100644
--- a/pcbnew/class_module.cpp
+++ b/pcbnew/class_module.cpp
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -924,6 +925,33 @@ void MODULE::RunOnChildren( const std::function& aFunction )
 }
 }

+
+void MODULE::GetAllDrawingLayers( int aLayers[], int& aCount ) const
+{
+std::unordered_set layers;
+
+for( BOARD_ITEM* item = m_Drawings; item; item = item->Next() )
+{
+layers.insert( static_cast( item->GetLayer() ) );
+}
+
+for( D_PAD* pad = m_Pads; pad; pad = pad->Next() )
+{
+int pad_layers[KIGFX::VIEW::VIEW_MAX_LAYERS], pad_layers_count;
+pad->ViewGetLayers( pad_layers, pad_layers_count );
+
+for( int i = 0; i < pad_layers_count; i++ )
+layers.insert( pad_layers[i] );
+}
+
+aCount = layers.size();
+int i = 0;
+
+for( auto layer : layers )
+aLayers[i++] = layer;
+}
+
+
 void MODULE::ViewGetLayers( int aLayers[], int& aCount ) const
 {
 aCount = 2;
diff --git a/pcbnew/class_module.h b/pcbnew/class_module.h
index 0af325301..5e06a2c5d 100644
--- a/pcbnew/class_module.h
+++ b/pcbnew/class_module.h
@@ -610,6 +610,14 @@ public:
  */
 void RunOnChildren( const std::function& aFunction );

+/**
+ * Returns a set of all layers that this module has drawings on
+ * similar to ViewGetLayers()
+ *
+ * @param aLayers is an array to store layer ids
+ * @param aCount is the number of layers stored in the array
+ */
+void GetAllDrawingLayers( int aLayers[], int& aCount ) const;

 virtual void ViewGetLayers( int aLayers[], int& aCount ) const override;

diff --git a/pcbnew/tools/selection_tool.cpp b/pcbnew/tools/selection_tool.cpp
index b8eb01f10..7222f6c05 100644
--- a/pcbnew/tools/selection_tool.cpp
+++ b/pcbnew/tools/selection_tool.cpp
@@ -1601,13 +1601,34 @@ bool SELECTION_TOOL::selectable( const BOARD_ITEM* aItem ) const
 if( viewArea > 0.0 && modArea / viewArea > 0.9 )
 return false;

-if( aItem->IsOnLayer( F_Cu ) && board()->IsElementVisible( LAYER_MOD_FR ) )
-return !m_editModules;
+// Allow selection of footprints if at least one draw layer is on and
+// the appropriate LAYER_MOD is on

-if( aItem->IsOnLayer( B_Cu ) && board()->IsElementVisible( LAYER_MOD_BK ) )
-return !m_editModules;
+bool layer_mod = ( ( aItem->IsOnLayer( F_Cu ) && board()->IsElementVisible( LAYER_MOD_FR ) ) ||
+   ( aItem->IsOnLayer( B_Cu ) && board()->IsElementVisible( LAYER_MOD_BK ) ) );

-return false;
+bool draw_layer_visible = false;
+int draw_layers[KIGFX::VIEW::VIEW_MAX_LAYERS], draw_layers_count;
+
+static_cast( aItem )->GetAllDrawingLayers( draw_layers,
+  draw_layers_count );
+
+for( int i = 0; i < draw_layers_count; ++i )
+{
+if( board()->IsLayerVisible( static_cast( draw_layers[i] ) ) )
+draw_layer_visible = true;
+}
+
+// And finally, the pads layers count as draw layers too, if the copper layer is on
+if( ( 

Re: [Kicad-developers] Packaging question

[Steven A. Falco]

On 02/26/2018 06:42 PM, Nick Østergaard wrote:
> Please submit your patch as a pull request.

Ok.  I added a pull request on github to pull the master branch of 
https://github.com/stevefalco/fedora-packaging/ into the master branch of 
https://github.com/KiCad/fedora-packaging.

This will replace the v4 library repo with the v5 symbol, footprint, and 3d 
repos.

Please let me know if there are any problems.

Steve


> 2018-02-26 4:48 GMT+01:00 Steven A. Falco  >:
> 
> On 02/25/2018 07:31 PM, Wayne Stambaugh wrote:
> >
> >
> > On 02/25/2018 07:25 PM, Rene Pöschl wrote:
> >> On 25/02/18 23:29, Wayne Stambaugh wrote:
> >>> Stephen,
> >>>
> >>> I would say that you should pull from HEAD of each library.  This will
> >>> probably be acceptable up to the stable release.  At this point we 
> will
> >>> have to tag each repo.  Are any of our library devs planning on doing
> >>> any major reorganization of the libraries between now and the stable
> >>> release?  If so, than we may want to tag the library repos for rc1.
> >>>
> >>> Cheers,
> >>>
> >>> Wayne
> >>>
> >>
> >> I asked a week or so ago if i should tag. Your response was that it is 
> unnecessary. Otherwise i would have tagged the libs back then.
> >> l
> >> As i do not yet plan to ban major changes, i tagged the repos with 
> "v5.0.0-rc1"
> >>
> >
> > Rene,
> >
> > I don't think there is a major issue here but tagging rc1 wont hurt 
> anything.  The main thing I am worried about is the stable release and that 
> the library layout structure and the library names remain constant throughout 
> the stable 5 release series unless the user specifically chooses to install 
> newer libraries.  Between now and the stable release, I do expect some 
> changes to the libraries but we can tag as we go if we need to.
> 
> There are a lot of issues here that I am not necessarily competent to 
> answer, so let me just propose a quick patch to get the copr builds to at 
> least use the v5 libraries instead of the v4 libraries.  That will 
> potentially enable more Fedora users to test with a consistent v5 of kicad, 
> so I see it as a step in the right direction.
> 
> I've attached the patch, and I've tested it in my copr repo here: 
> https://copr.fedorainfracloud.org/coprs/stevenfalco/kicad/ 
> 
> 
> Basically, this patch replaces the v4 kicad-library repo with the v5 
> kicad-footprints, kicad-packages3D, kicad-templates and kicad-symbols repos.  
> It also sets KICAD_VERSION_EXTRA to the git "commit-count.SHA" so the version 
> is more visible in the help:about dialog.
> 
> I received a pm from a developer off-list, who wants to split the package 
> into separate components, uncoupling the libs from the executables.  That 
> seems like a great idea to me, and lines up with the debian proposal, but 
> clearly that will take more effort to put in place.
> 
> Please let me know if this patch is acceptable, or if you need further 
> changes.
> 
>         Steve
> 
> 
> >
> > Cheers,
> >
> > Wayne
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers 
> 
> > Post to : kicad-developers@lists.launchpad.net 
> 
> > Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> > More help   : https://help.launchpad.net/ListHelp 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to     : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> 
> 


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

Re: [Kicad-developers] KiCad-from-scratch: GerbView/pcbnew: Startup-Dialog: Enable Acceleration only enables Modern Toolset (Fallback)

[Nick Østergaard]

What happen if you switch to accelerated in the prefs dialog?

2018-02-26 23:58 GMT+01:00 Clemens Koller :

> Hi!
>
> Minor bug / inconsistency:
>
> KFS: On the initial run of GerbView and Pcbnew, the Startup-Dialog to
> enable acceleration is shown. When I click on "Enable Acceleration" and
> check the Preferences, only the Modern Toolset (Fallback) is enabled, but
> not the Modern Toolset (Accelerated).
>
> 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

[Kicad-developers] pcbnew selection oddness

[Andy Peters]

This uses last night’s nightly (macOS).

I imported a DXF file into the Cmts.User layer (nothing else is on it) and I 
need to move it into a specific location. Since there is no “group all of this 
stuff into one thing” feature (which I admittedly hadn’t thought about until 
just now), my imported thing is a bunch of lines and arcs. 

To move it, I turned off all of the layers except Cmts.User and used the mouse 
to draw a selection box around the imported lines. But! The selection includes 
all sorts of other stuff which was invisible. Checking the “Items” visibility I 
see that most things are selected — Footprints, References, Pads, Tracks, Vias, 
Holes. But since their layers are turned off, they’re not visible. (which is 
the expected result.)

Shouldn’t the block-select logic select only stuff which is actually visible? 
That is, if the layer is not visible and I don’t see a thing, I should not be 
able to select that thing, period.

(Aside: is there any way to combine things like a mechanical outline DXF 
imported into an auxiliary layer? I designed a small board that goes behind a 
front panel and I went to check whether it would actually fit, and realized 
that while I can import the panel outline, moving it as one unit, with an 
anchor point like any regular footprint, doesn’t work.)

Thanks, and I have to say that Kicad is really working out here. The two boards 
I want to fab this week are my 9th and 10th Kicad designs.


Application: kicad
Version: (5.0.0-rc2-dev-16-g319b7cf), release build
Libraries:
wxWidgets 3.0.4
libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
Platform: Mac OS X (Darwin 17.4.0 x86_64), 64 bit, Little endian, wxMac
Build Info:
wxWidgets: 3.0.4 (UTF-8,STL containers,compatible with 2.8)
Boost: 1.61.0
Curl: 7.43.0
Compiler: Clang 7.3.0 with C++ ABI 1002

Build settings:
USE_WX_GRAPHICS_CONTEXT=ON
USE_WX_OVERLAY=ON
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_SPICE=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

Re: [Kicad-developers] Fabrication Outputs and Plot

[Wayne Stambaugh]

This looks fine to me.  Does anyone else have any objections to this change?

On 02/25/2018 03:17 PM, Diego Herranz wrote:
Thanks for your replies. I think there's a consensus that this needs 
improving and restructuring, but given your emails, it sounds like a big 
task :)


In the meantime, would you accept the attached patch to change the order 
in which "Fabrication Outputs" is listed in the menu?


Before:
Fabrication Outputs
Import
Export

After:
Import
Export
Fabrication Outputs


I think that "Fabrication Outputs" is conceptually very similar to 
"Export" and it belongs next to it better than having "Import" in 
between them.


Thanks,
Diego



On Sat, Feb 24, 2018 at 9:01 PM, Wayne Stambaugh > wrote:


I'm open to any solution that improves the current situation.  This
solution seems reasonable as well.  I also just noticed that wx
3.1.1 was just released and it looks like there have been a lot of
fixes the various device contexts so some of the work may have
already been done for us.

On 02/24/2018 03:31 PM, Jon Evans wrote:

I thought the idea was to write a backend for GAL that could
render onto a wxDC for printing?  It seems wise to use the
wxWidgets printing API rather than bypassing it; so we just need
to be able to render onto a DC (without using the old XOR tricks
from the legacy drawing code)

On Sat, Feb 24, 2018 at 3:26 PM, Jeff Young  >> wrote:

     On the other hand, if we don’t then we have to keep
carrying around
     a boat-load of Legacy rendering code (because we use that
for printing).

      > On 24 Feb 2018, at 20:16, Wayne Stambaugh

     >> wrote:
      >
      > There is no plan yet but it has been discussed.  The only
     downside is that we will have to write our own print
handling on
     windows and I'm guessing macos.  That's one of the reasons
no one
     has signed up yet because it will be a large undertaking.
      >
      > On 02/24/2018 02:02 PM, Jon Evans wrote:
      >> Yes I think that's the plan, just needs someone to sign
up to
     write it :)
      >> On Sat, Feb 24, 2018, 14:00 Andrzej Wolski
     
>
      >    Cairo have PDF, SVG and Postscript support. I was once
     wondering if
      >>    GAL/Cairo could be used for printing.
      >>    Andrzej
      >>    W dniu 2018-02-24 o 19:24, Jon Evans pisze:
      >>>    Yeah, there (at least) three different dialogs that
all present
      >>>    similar things (i.e. a list of layers to include,
settings,
     etc):
      >>>
      >>>    Export->SVG
      >>>    Print
      >>>    Plot
      >>>
      >>>    The Print code for Export->SVG seems to just use
the same SVG
      >>>    plotter, so maybe it's just mostly GUI cleanup that
is needed.
      >>>
      >>>    The main Print code does need an overhaul to use
something other
      >>>    than wxDC for graphics generation (and perhaps
adding some more
      >>>    features to PDF export)
      >>>
      >>>    -Jon
      >>>
      >>>    On Sat, Feb 24, 2018 at 1:16 PM, Jeff Young

     >
      >>>    
>>
      >>>        Plot SVG and Export SVG are different.  The
former goes
      >>>        through the Plot code while the later goes
through the Print
      >>>        code.
      >>>
      >>>        Do we need both?  I haven’t a clue.
      >>>
      >>>        It would be nice to clean this stuff up, if
there is in
     fact a
      >>>        clean way to present it.
      >>>
      >>>        Cheers,
      >>>        Jeff.
      >>>
      >>>
              On 24 Feb 2018, at 14:54, Jon Evans

Re: [Kicad-developers] GerbView: KiCad-rc2: Layer filenames mixed up in right tab view.

[Clemens Koller]

Hello, Jon!

I've tried the Gerber files from the KiCad source tree. The behaviour is also 
erratic and reproducible.
Try to load i.e. .../gerber_test_files/test-* files and then load aperture* 
files and then Ucamco*

It seems that filenames in the Tab View position 1 + 2 are stuck and new 
filenames are shown on position 3++.

Regards,

Clemens


On 2018-02-26 00:33, Jon Evans wrote:
> I'm having trouble reproducing this.  If you try opening some of the example 
> Gerber files in the kicad source tree, do you see the same issue?
> 
> On Sun, Feb 25, 2018 at 6:26 PM, Clemens Koller  > wrote:
> 
> Hi, Jon!
> 
> The files are newly generated proprietary %FSDAX33Y33*% (without X2 
> attributes AFAICT).
> *
> *
> G04 PADS VX.1.2 Build Number: 698008 generated Gerber (RS-274-X) file*
> G04 PC Version=2.1*
> *
> %IN ".pcb"*%
> *
> %MOMM*%
> *
> %FSDAX33Y33*%
> *
> ...
> 
> I opened from a directory by File - Load Gerber File... - Shift-Clicking 
> on the files in the order I want to load them - Open.
> 
> (I need to click #no of file times to dismiss the warning dialog box 
> because of the proprietary format "%FSDAX33Y33*%", which is annoying, btw.)
> 
> Regards,
> 
> Clemens
> 
> On 2018-02-26 00:18, Jon Evans wrote:
> > Hi Clemens, do these files have Gerber X2 attributes?  What process did 
> you use to load them? (i.e. did you load one at a time; use a Gerber job 
> file, load them all at once, etc)?
> >
> > Thanks,
> > Jon
> >
> > On Sun, Feb 25, 2018 at 6:15 PM, Clemens Koller   >> 
> wrote:
> >
> >     Hi!
> >
> >     I am not absolutely sure what's going on with the layer names in 
> Gerbview. It seems that the filenames in the right layers tab view are mixed 
> up.
> >
> >     Attached is an image of a 4 layer board where the filenames were 
> selected from copper layer 1 (top) 2 3 4 (bottom) ... etc.
> >     But in the tab view, the filenames get mixed up. The 4th line 
> toggles Layer 4 (bottom, blue) but gerber_solder_mask_bot.pho would look 
> completely different.
> >
> >     Is this a known bug/work in progress?
> >     Is there some mystic ordering applied here?
> >
> >     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

Re: [Kicad-developers] Windows Nightlies Installer - Unable to check components for instal

[Nick Østergaard]

I have only been waiting for the release to be tagged such that I know what
strategy would be used for the libs. My plan is to make a full installer
and a lite installer for the nightlies. I am not sure if it makes sense to
have a seperate installer (without the main programs) such that the noob
user have to install the main app and then in a seperate installer the rest
of the stuff.

2018-02-26 20:39 GMT+01:00 Wayne Stambaugh :

> We should remove or hide the optional items if they are no longer part
> of the installer to prevent confusion.
>
> On 2/26/2018 12:46 PM, Jon Evans wrote:
> > In the case that there is a separate installer for the libraries (which
> > I also think makes sense), maybe those line items should be removed from
> > the main installer instead of just disabled (if that is easy) to reduce
> > confusion?
> >
> > On Mon, Feb 26, 2018 at 12:42 PM, Wayne Stambaugh  > > wrote:
> >
> > On 2/26/2018 6:39 AM, Simon Richter wrote:
> > > Hi,
> > >
> > > On 25.02.2018 22 :52, Andrey Kuznetsov wrote:
> > >
> > >> The unchecked components in the image below cannot be checked.
> > >
> > > Yes, these are no longer in the nightly installer, because they are
> > > 600MB compressed, and most nightly users maintain their libraries
> > > themselves.
> > >
> > >Simon
> > >
> >
> > Simon,
> >
> > Are there any plans to package the libraries as a separate installer?
> > I'm sure there are some windows users are going to want to be able to
> > install libraries directly rather than deal with git repos.  First
> time
> > users are going to be bewildered by an EDA tool that appears to
> offer no
> > symbol, footprint and/or 3D model libraries.
> >
> > Wayne
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > 
> > Post to : kicad-developers@lists.launchpad.net
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > 
> > More help   : https://help.launchpad.net/ListHelp
> > 
> >
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Packaging question

[Nick Østergaard]

Please submit your patch as a pull request.

2018-02-26 4:48 GMT+01:00 Steven A. Falco :

> On 02/25/2018 07:31 PM, Wayne Stambaugh wrote:
> >
> >
> > On 02/25/2018 07:25 PM, Rene Pöschl wrote:
> >> On 25/02/18 23:29, Wayne Stambaugh wrote:
> >>> Stephen,
> >>>
> >>> I would say that you should pull from HEAD of each library.  This will
> >>> probably be acceptable up to the stable release.  At this point we will
> >>> have to tag each repo.  Are any of our library devs planning on doing
> >>> any major reorganization of the libraries between now and the stable
> >>> release?  If so, than we may want to tag the library repos for rc1.
> >>>
> >>> Cheers,
> >>>
> >>> Wayne
> >>>
> >>
> >> I asked a week or so ago if i should tag. Your response was that it is
> unnecessary. Otherwise i would have tagged the libs back then.
> >> l
> >> As i do not yet plan to ban major changes, i tagged the repos with
> "v5.0.0-rc1"
> >>
> >
> > Rene,
> >
> > I don't think there is a major issue here but tagging rc1 wont hurt
> anything.  The main thing I am worried about is the stable release and that
> the library layout structure and the library names remain constant
> throughout the stable 5 release series unless the user specifically chooses
> to install newer libraries.  Between now and the stable release, I do
> expect some changes to the libraries but we can tag as we go if we need to.
>
> There are a lot of issues here that I am not necessarily competent to
> answer, so let me just propose a quick patch to get the copr builds to at
> least use the v5 libraries instead of the v4 libraries.  That will
> potentially enable more Fedora users to test with a consistent v5 of kicad,
> so I see it as a step in the right direction.
>
> I've attached the patch, and I've tested it in my copr repo here:
> https://copr.fedorainfracloud.org/coprs/stevenfalco/kicad/
>
> Basically, this patch replaces the v4 kicad-library repo with the v5
> kicad-footprints, kicad-packages3D, kicad-templates and kicad-symbols
> repos.  It also sets KICAD_VERSION_EXTRA to the git "commit-count.SHA" so
> the version is more visible in the help:about dialog.
>
> I received a pm from a developer off-list, who wants to split the package
> into separate components, uncoupling the libs from the executables.  That
> seems like a great idea to me, and lines up with the debian proposal, but
> clearly that will take more effort to put in place.
>
> Please let me know if this patch is acceptable, or if you need further
> changes.
>
> Steve
>
>
> >
> > Cheers,
> >
> > Wayne
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Packaging question

[Nick Østergaard]

@Wayne, the copr nighlties we provide for fedora is maintained in
https://github.com/KiCad/fedora-packaging

Patches should of course be submitted to this as pull requests. I see
Aimylios submitted some changes a week or two ago, but I and clearly no one
else has reviewed it. I would advise both Aimylios and Steven to engage in
discussion on the github repo specific to packaging. And I still think it
is fine to talk about general packaging things on the dev list because
packagers for multiple platforms are available here. Often it is also
relevant for some development decisions.

2018-02-26 21:14 GMT+01:00 Aimylios :

> Am 26.02.2018 um 19:42 schrieb Wayne Stambaugh:
>
>>
>> Can someone please help Steve out here?  I don't know where our fedora
>> packages are being maintained so I would appreciate someone confirming
>> this patch.  I don't know that there is much we can do about the
>> upstream situation.
>>
>> Thanks,
>>
>> Wayne
>>
>>
>>>
>>>
 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

>>>
>
> Hi,
>
> I'm not involved in Fedora upstream packaging, but like Steve I have spent
> some time to set up a packaging environment for my own, personal nightly
> and release builds, as I am not very happy with the current state of the
> official nightly copr builds.
> I based my work on what is published in the fedora-packaging repository on
> GitHub. Unfortunately the SPEC file is in a poor shape and I ended up
> rewriting it almost completely. My private version of both the nightly [1]
> and release [2] packaging is available online.
>
> I also set up an unofficial KiCad release copr (aimylios/kicad-release)
> [3]. The build of 5.0.0-rc1 is still in progress and it might take a couple
> of hours until the package is available.
>
> One of the biggest changes I made is to move the libraries into separate
> packages (similar to what Carsten has done):
> kicad
> kicad-doc
> kicad-templates
> kicad-symbols
> kicad-footprints
> kicad-packages3D
> Hopefully this or a similar scheme will be adopted by upstream or at least
> for the nightlies.
>
> I would also like to help improving the nightly builds, but I'd prefer if
> this could be handled via pull requests over at the fedora-packaging
> repository [4]. No need to spam the developers mailing list with all this
> packaging stuff. In the end, we Fedora users are still a minority.
>
> Keep up the great work!
>
> Best regards,
> Marcus
>
> [1] https://github.com/aimylios/fedora-kicad-packaging/tree/develop
> [2] https://github.com/aimylios/fedora-kicad-packaging/tree/release
> [3] https://copr.fedorainfracloud.org/coprs/aimylios/kicad-release
> [4] https://github.com/KiCad/fedora-packaging
>
>
> ___
> 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] KiCad-from-scratch: GerbView/pcbnew: Startup-Dialog: Enable Acceleration only enables Modern Toolset (Fallback)

[Clemens Koller]

Hi!

Minor bug / inconsistency:

KFS: On the initial run of GerbView and Pcbnew, the Startup-Dialog to enable 
acceleration is shown. When I click on "Enable Acceleration" and check the 
Preferences, only the Modern Toolset (Fallback) is enabled, but not the Modern 
Toolset (Accelerated).

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

Re: [Kicad-developers] [PATCH] Fix Gerber job file bug and crash issue on MacOS

[Andy Peters]

On Feb 26, 2018, at 12:13 PM, Jon Evans  wrote:
> 
> Re-sending these since they may have gotten lost in the other thread.
> These fix some bugs Andy Peters found on GerbView MacOS.

Thanks for the quick fix. I will download a nightly build to verify. (I kinda 
gave up on building Kicad, long story, the nightlies work for me.)
___
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] Packaging question

[Wayne Stambaugh]

On 2/26/2018 3:14 PM, Aimylios wrote:
> Am 26.02.2018 um 19:42 schrieb Wayne Stambaugh:
>>
>> Can someone please help Steve out here?  I don't know where our fedora
>> packages are being maintained so I would appreciate someone confirming
>> this patch.  I don't know that there is much we can do about the
>> upstream situation.
>>
>> Thanks,
>>
>> Wayne
>>
>>>
>>>

 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
> 
> 
> Hi,
> 
> I'm not involved in Fedora upstream packaging, but like Steve I have
> spent some time to set up a packaging environment for my own, personal
> nightly and release builds, as I am not very happy with the current
> state of the official nightly copr builds.
> I based my work on what is published in the fedora-packaging repository
> on GitHub. Unfortunately the SPEC file is in a poor shape and I ended up
> rewriting it almost completely. My private version of both the nightly
> [1] and release [2] packaging is available online.
> 
> I also set up an unofficial KiCad release copr (aimylios/kicad-release)
> [3]. The build of 5.0.0-rc1 is still in progress and it might take a
> couple of hours until the package is available.
> 
> One of the biggest changes I made is to move the libraries into separate
> packages (similar to what Carsten has done):
> kicad
> kicad-doc
> kicad-templates
> kicad-symbols
> kicad-footprints
> kicad-packages3D
> Hopefully this or a similar scheme will be adopted by upstream or at
> least for the nightlies.
> 
> I would also like to help improving the nightly builds, but I'd prefer
> if this could be handled via pull requests over at the fedora-packaging
> repository [4]. No need to spam the developers mailing list with all
> this packaging stuff. In the end, we Fedora users are still a minority.
> 
> Keep up the great work!
> 
> Best regards,
> Marcus
> 
> [1] https://github.com/aimylios/fedora-kicad-packaging/tree/develop
> [2] https://github.com/aimylios/fedora-kicad-packaging/tree/release
> [3] https://copr.fedorainfracloud.org/coprs/aimylios/kicad-release
> [4] https://github.com/KiCad/fedora-packaging
> 

Marcus,

Thank you for packaging KiCad for Fedora.  Hopefully your changes will
be accepted upstream.  I don't have any issues with making KiCad more
package friendly.  The way I see it, the more potential users the
better.  So if we can make changes that improve life for package devs,
we will do our best to accommodate those changes.

Cheers,

Wayne

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

Re: [Kicad-developers] Packaging question

[Aimylios]

Am 26.02.2018 um 19:42 schrieb Wayne Stambaugh:


Can someone please help Steve out here?  I don't know where our fedora
packages are being maintained so I would appreciate someone confirming
this patch.  I don't know that there is much we can do about the
upstream situation.

Thanks,

Wayne






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



Hi,

I'm not involved in Fedora upstream packaging, but like Steve I have 
spent some time to set up a packaging environment for my own, personal 
nightly and release builds, as I am not very happy with the current 
state of the official nightly copr builds.
I based my work on what is published in the fedora-packaging repository 
on GitHub. Unfortunately the SPEC file is in a poor shape and I ended up 
rewriting it almost completely. My private version of both the nightly 
[1] and release [2] packaging is available online.


I also set up an unofficial KiCad release copr (aimylios/kicad-release) 
[3]. The build of 5.0.0-rc1 is still in progress and it might take a 
couple of hours until the package is available.


One of the biggest changes I made is to move the libraries into separate 
packages (similar to what Carsten has done):

kicad
kicad-doc
kicad-templates
kicad-symbols
kicad-footprints
kicad-packages3D
Hopefully this or a similar scheme will be adopted by upstream or at 
least for the nightlies.


I would also like to help improving the nightly builds, but I'd prefer 
if this could be handled via pull requests over at the fedora-packaging 
repository [4]. No need to spam the developers mailing list with all 
this packaging stuff. In the end, we Fedora users are still a minority.


Keep up the great work!

Best regards,
Marcus

[1] https://github.com/aimylios/fedora-kicad-packaging/tree/develop
[2] https://github.com/aimylios/fedora-kicad-packaging/tree/release
[3] https://copr.fedorainfracloud.org/coprs/aimylios/kicad-release
[4] https://github.com/KiCad/fedora-packaging

___
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] Windows Nightlies Installer - Unable to check components for instal

[Wayne Stambaugh]

We should remove or hide the optional items if they are no longer part
of the installer to prevent confusion.

On 2/26/2018 12:46 PM, Jon Evans wrote:
> In the case that there is a separate installer for the libraries (which
> I also think makes sense), maybe those line items should be removed from
> the main installer instead of just disabled (if that is easy) to reduce
> confusion?
> 
> On Mon, Feb 26, 2018 at 12:42 PM, Wayne Stambaugh  > wrote:
> 
> On 2/26/2018 6:39 AM, Simon Richter wrote:
> > Hi,
> >
> > On 25.02.2018 22 :52, Andrey Kuznetsov wrote:
> >
> >> The unchecked components in the image below cannot be checked.
> >
> > Yes, these are no longer in the nightly installer, because they are
> > 600MB compressed, and most nightly users maintain their libraries
> > themselves.
> >
> >    Simon
> >
> 
> Simon,
> 
> Are there any plans to package the libraries as a separate installer?
> I'm sure there are some windows users are going to want to be able to
> install libraries directly rather than deal with git repos.  First time
> users are going to be bewildered by an EDA tool that appears to offer no
> symbol, footprint and/or 3D model libraries.
> 
> 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] Fix Gerber job file bug and crash issue on MacOS

[Wayne Stambaugh]

Patches merged.  Thanks.

On 2/26/2018 2:13 PM, Jon Evans wrote:
> Re-sending these since they may have gotten lost in the other thread.
> These fix some bugs Andy Peters found on GerbView MacOS.
> 
> -Jon
> 
> 
> ___
> 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 Gerber job file bug and crash issue on MacOS

[Jon Evans]

Re-sending these since they may have gotten lost in the other thread.
These fix some bugs Andy Peters found on GerbView MacOS.

-Jon


0001-Fix-edge-case-GERBER_FILE_IMAGE-creation-logic.patch
Description: Binary data


0001-Use-proper-path-when-loading-files-from-Gerber-job-f (1).patch
Description: Binary data
___
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] GerbView performance optimizations

[Wayne Stambaugh]

I must have missed these patches in the noise.  They are now merged.

Thank,

Wayne

On 2/26/2018 10:54 AM, Jon Evans wrote:
> Hi Wayne, just a reminder there are two more patches here, sorry about
> the high volume of email.
> 
> Thanks,
> Jon
> 
> On Sun, Feb 25, 2018 at 7:23 PM, Wayne Stambaugh  > wrote:
> 
> Patch merged.  Thanks.
> 
> On 02/25/2018 04:07 PM, Jon Evans wrote:
> 
> One more performance patch for GerbView attached
> 
> On Sun, Feb 25, 2018 at 3:14 PM, Jon Evans    >> wrote:
> 
>     These patches improves redraw performance when toggling
>     sketch/filled draw modes.
> 
>     On Linux at least, the difference is quite noticeable on
> complicated
>     Gerber files.
> 
>     -Jon
> 
> 
> 
> 
> ___
> 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] How do I turn one of our .svg icons into a .cpp file?

[jp charras]

Le 26/02/2018 à 19:13, Wayne Stambaugh a écrit :
> On 2/26/2018 1:09 PM, Marco Ciampa wrote:
>> On Mon, Feb 26, 2018 at 12:44:57PM -0500, Wayne Stambaugh wrote:
>>> We should probably update the cmake file to include the -z option for
>>> inkscape on macos builds so macos can be used to update image files
>>> without having to fall back to entering commands by hand.
>>
>> -z should work on all platforms...no need to make a "special" cmake for
>> macos ... just add it to all
>>
>> (Linux) inkscape --help|grep "\-z" 
>>
>> -z, --without-guiDo not use X server (only process files from console)
> 
> Even better!  I like easy.
> 

--without-gui option (more meaningful than -z) also works fine on Windows

-- 
Jean-Pierre CHARRAS

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

Re: [Kicad-developers] Packaging question

[Wayne Stambaugh]

On 2/25/2018 10:48 PM, Steven A. Falco wrote:
> On 02/25/2018 07:31 PM, Wayne Stambaugh wrote:
>>
>>
>> On 02/25/2018 07:25 PM, Rene Pöschl wrote:
>>> On 25/02/18 23:29, Wayne Stambaugh wrote:
 Stephen,

 I would say that you should pull from HEAD of each library.  This will
 probably be acceptable up to the stable release.  At this point we will
 have to tag each repo.  Are any of our library devs planning on doing
 any major reorganization of the libraries between now and the stable
 release?  If so, than we may want to tag the library repos for rc1.

 Cheers,

 Wayne

>>>
>>> I asked a week or so ago if i should tag. Your response was that it is 
>>> unnecessary. Otherwise i would have tagged the libs back then.
>>> l
>>> As i do not yet plan to ban major changes, i tagged the repos with 
>>> "v5.0.0-rc1"
>>>
>>
>> Rene,
>>
>> I don't think there is a major issue here but tagging rc1 wont hurt 
>> anything.  The main thing I am worried about is the stable release and that 
>> the library layout structure and the library names remain constant 
>> throughout the stable 5 release series unless the user specifically chooses 
>> to install newer libraries.  Between now and the stable release, I do expect 
>> some changes to the libraries but we can tag as we go if we need to.
> 
> There are a lot of issues here that I am not necessarily competent to answer, 
> so let me just propose a quick patch to get the copr builds to at least use 
> the v5 libraries instead of the v4 libraries.  That will potentially enable 
> more Fedora users to test with a consistent v5 of kicad, so I see it as a 
> step in the right direction.
> 
> I've attached the patch, and I've tested it in my copr repo here: 
> https://copr.fedorainfracloud.org/coprs/stevenfalco/kicad/
> 
> Basically, this patch replaces the v4 kicad-library repo with the v5 
> kicad-footprints, kicad-packages3D, kicad-templates and kicad-symbols repos.  
> It also sets KICAD_VERSION_EXTRA to the git "commit-count.SHA" so the version 
> is more visible in the help:about dialog.
> 
> I received a pm from a developer off-list, who wants to split the package 
> into separate components, uncoupling the libs from the executables.  That 
> seems like a great idea to me, and lines up with the debian proposal, but 
> clearly that will take more effort to put in place.
> 
> Please let me know if this patch is acceptable, or if you need further 
> changes.
> 
>   Steve

Can someone please help Steve out here?  I don't know where our fedora
packages are being maintained so I would appreciate someone confirming
this patch.  I don't know that there is much we can do about the
upstream situation.

Thanks,

Wayne

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

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

Re: [Kicad-developers] Windows Nightlies Installer - Unable to check components for instal

[Wayne Stambaugh]

On 2/26/2018 12:58 PM, Andrey Kuznetsov wrote:
> OK, what about the help files? :)

The help files should be installed by the main KiCad installer.  I don't
so those as being optional.

> 
> I agree, the library installer should be provided, you can call me a
> thorough tester but a basic user (otherwise known as complainer ;-P )
> and I don't want to deal with github to get kicad libraries. A 50 year
> old hobbyist will give up on kicad in 10 minutes after not being able to
> figure out where the components are and that kicad appears baren after
> not being able to start designing even a simple circuit without
> reinventing the wheel.

I understand and your reasoning is perfectly valid.  I can't say we can
support every use case due to manpower limitations but at a minimum we
should provide a library installer with all of the symbol, footprint,
template, and 3D model libraries by version tag that installs the
libraries where they normally would be installed on windows.

> 
> On Mon, Feb 26, 2018 at 3:39 AM, Simon Richter  > wrote:
> 
> Hi,
> 
> On 25.02.2018 22 :52, Andrey Kuznetsov wrote:
> 
> > The unchecked components in the image below cannot be checked.
> 
> Yes, these are no longer in the nightly installer, because they are
> 600MB compressed, and most nightly users maintain their libraries
> themselves.
> 
>    Simon
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> 
> -- 
> 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

Re: [Kicad-developers] How do I turn one of our .svg icons into a .cpp file?

[Wayne Stambaugh]

On 2/26/2018 1:09 PM, Marco Ciampa wrote:
> On Mon, Feb 26, 2018 at 12:44:57PM -0500, Wayne Stambaugh wrote:
>> We should probably update the cmake file to include the -z option for
>> inkscape on macos builds so macos can be used to update image files
>> without having to fall back to entering commands by hand.
> 
> -z should work on all platforms...no need to make a "special" cmake for
> macos ... just add it to all
> 
> (Linux) inkscape --help|grep "\-z" 
> 
> -z, --without-guiDo not use X server (only process files from console)

Even better!  I like easy.

> 
> bye
> 
> --
> 
> 
> Marco Ciampa
> 
> I know a joke about UDP, but you might not get it.
> 
> 
> 
>  GNU/Linux User #78271
>  FSFE fellow #364
> 
> 
> 
> 
> ___
> 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] Pads front and F.Cu visibility, possible bugs?

[Wayne Stambaugh]

I kind of enjoy the French names.  It keeps me on my toes!  Besides,
AFAIK it's the last of the French strings in KiCad.  When I joined the
project most of the source code comments were in French.  I'm the one
who translated them all to English so I could work on the project.  I
actually thought about leaving one comment in French for sentimental
reasons so I'm actually fine with the French layer names in the demo
project. :)

On 2/26/2018 1:07 PM, Andrey Kuznetsov wrote:
> Yes Wayne, thanks.
> 
> JP, it's all your fault, demos shouldn't have proprietary Frenchy layer
> names. :D
> 
> I think the demos should have proper layer names, I forgot the layer
> names could be changed because I almost never go to Layer Setup.
> It would be confusing for beginners when looking at demo boards.
> 
> On Mon, Feb 26, 2018 at 5:42 AM, Wayne Stambaugh  > wrote:
> 
> Copper layers can be renamed so I only expect the layer names F.Cu and
> B.Cu when I have not renamed them.  I'm guessing you have one of the
> kicad demo projects open based on the French layer names which JP likes
> to use.
> 
> On 2/25/2018 8:59 PM, Andrey Kuznetsov wrote:
> > Not sure if this is the right thread that dealt with Layers tab, but
> > anyone else thinks the first 2 names should say:
> > F.Copper
> > B.Copper
> >
> > instead of:
> > Inline image 1
> >
> > On Sat, Feb 17, 2018 at 3:04 PM, Andrzej Wolski 
> 
> > >>
> wrote:
> >
> >     There is a simple fix to this problem, patch in attachment. It
> needs
> >     to be applied on top of this patch:
> >     https://bugs.launchpad.net/kicad/+bug/1743890
> 
> >      >
> >
> >     Witch this patch there is another issue: when all layers (in Layer
> >     tab) are hidden, anchors and invisible text are still displayed.
> >     I'm not sure what to do about it, maybe they also should be
> hidden?
> >
> >     Cheers,
> >     Andrzej
> >
> >
> >
> >     On 02/07/2018 04:24 PM, Kristoffer Ödmark wrote:
> >
> >         Hey!
> >
> >         Another confusion arised when I was speaking to a friend. When
> >         disabling the F.Cu layer, the pads are still visible. I can
> >         understand the need to be able to disable the pads on the
> front
> >         layer separate from everything else, to check for things under
> >         pads etc.
> >
> >         What I cannot understand is why the pads are visible if I want
> >         to disable the entire front layer in pcbnew, also if one wants
> >         transparent layers, one can actually se the compositioning for
> >         the front pads and front traces, and allowing them to be
> >         different colors also seem a bit confusing actually.
> >
> >         I could basically change the front pad colors to look like
> they
> >         belong to the back layer, I know its stupid, but this
> seems like
> >         the kind of thing one would not want to even be possible,
> except
> >         maybe for pranks.
> >
> >         TLDR;
> >
> >         Possible bugs:
> >         1. pads not affected by layer visibility setting
> >         2. pads and layer compositioning even when same setting
> >         3. pads and corresponding layer color setting
> >
> >         Possible solution:
> >         1. Both layer and pads setting must be enabled for pads to
> render.
> >         2. Seems hard, Dont know
> >         3. pads and layer share color setting, not necessarily opacity
> >         setting.
> >
> >         Comments on these?
> >
> >
> >
> >
> >     ___
> >     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] How do I turn one of our .svg icons into a .cpp file?

[Marco Ciampa]

On Mon, Feb 26, 2018 at 12:44:57PM -0500, Wayne Stambaugh wrote:
> We should probably update the cmake file to include the -z option for
> inkscape on macos builds so macos can be used to update image files
> without having to fall back to entering commands by hand.

-z should work on all platforms...no need to make a "special" cmake for
macos ... just add it to all

(Linux) inkscape --help|grep "\-z" 

-z, --without-guiDo not use X server (only process files from console)

bye

--


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364




___
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] Pads front and F.Cu visibility, possible bugs?

[Andrey Kuznetsov]

Yes Wayne, thanks.

JP, it's all your fault, demos shouldn't have proprietary Frenchy layer
names. :D

I think the demos should have proper layer names, I forgot the layer names
could be changed because I almost never go to Layer Setup.
It would be confusing for beginners when looking at demo boards.

On Mon, Feb 26, 2018 at 5:42 AM, Wayne Stambaugh 
wrote:

> Copper layers can be renamed so I only expect the layer names F.Cu and
> B.Cu when I have not renamed them.  I'm guessing you have one of the
> kicad demo projects open based on the French layer names which JP likes
> to use.
>
> On 2/25/2018 8:59 PM, Andrey Kuznetsov wrote:
> > Not sure if this is the right thread that dealt with Layers tab, but
> > anyone else thinks the first 2 names should say:
> > F.Copper
> > B.Copper
> >
> > instead of:
> > Inline image 1
> >
> > On Sat, Feb 17, 2018 at 3:04 PM, Andrzej Wolski  > > wrote:
> >
> > There is a simple fix to this problem, patch in attachment. It needs
> > to be applied on top of this patch:
> > https://bugs.launchpad.net/kicad/+bug/1743890
> > 
> >
> > Witch this patch there is another issue: when all layers (in Layer
> > tab) are hidden, anchors and invisible text are still displayed.
> > I'm not sure what to do about it, maybe they also should be hidden?
> >
> > Cheers,
> > Andrzej
> >
> >
> >
> > On 02/07/2018 04:24 PM, Kristoffer Ödmark wrote:
> >
> > Hey!
> >
> > Another confusion arised when I was speaking to a friend. When
> > disabling the F.Cu layer, the pads are still visible. I can
> > understand the need to be able to disable the pads on the front
> > layer separate from everything else, to check for things under
> > pads etc.
> >
> > What I cannot understand is why the pads are visible if I want
> > to disable the entire front layer in pcbnew, also if one wants
> > transparent layers, one can actually se the compositioning for
> > the front pads and front traces, and allowing them to be
> > different colors also seem a bit confusing actually.
> >
> > I could basically change the front pad colors to look like they
> > belong to the back layer, I know its stupid, but this seems like
> > the kind of thing one would not want to even be possible, except
> > maybe for pranks.
> >
> > TLDR;
> >
> > Possible bugs:
> > 1. pads not affected by layer visibility setting
> > 2. pads and layer compositioning even when same setting
> > 3. pads and corresponding layer color setting
> >
> > Possible solution:
> > 1. Both layer and pads setting must be enabled for pads to
> render.
> > 2. Seems hard, Dont know
> > 3. pads and layer share color setting, not necessarily opacity
> > setting.
> >
> > Comments on these?
> >
> >
> >
> >
> > ___
> > 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
>



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

Re: [Kicad-developers] Windows Nightlies Installer - Unable to check components for instal

[Wayne Stambaugh]

Yet another use case that I hadn't thought about.  Keep them coming.
Sometimes your focus gets so narrowed by how you do things that you
can't conceive of all possible ways other user work.  I know for a fact
that asking users to use git to maintain libraries is like asking them
to build from source to run KiCad.  I remember those days and I would
rather not go back there.

Wayne

On 2/26/2018 12:47 PM, Adam Wolf wrote:
> This is especially useful for our Chinese users and folks traveling to
> China for manufacturing support, as often Github and other common
> public git repositories are blocked.
> 
> Adam
> 
> On Mon, Feb 26, 2018 at 11:42 AM, Wayne Stambaugh  
> wrote:
>> On 2/26/2018 6:39 AM, Simon Richter wrote:
>>> Hi,
>>>
>>> On 25.02.2018 22:52, Andrey Kuznetsov wrote:
>>>
 The unchecked components in the image below cannot be checked.
>>>
>>> Yes, these are no longer in the nightly installer, because they are
>>> 600MB compressed, and most nightly users maintain their libraries
>>> themselves.
>>>
>>>Simon
>>>
>>
>> Simon,
>>
>> Are there any plans to package the libraries as a separate installer?
>> I'm sure there are some windows users are going to want to be able to
>> install libraries directly rather than deal with git repos.  First time
>> users are going to be bewildered by an EDA tool that appears to offer no
>> symbol, footprint and/or 3D model libraries.
>>
>> 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] Windows Nightlies Installer - Unable to check components for instal

[Andrey Kuznetsov]

OK, what about the help files? :)

I agree, the library installer should be provided, you can call me a
thorough tester but a basic user (otherwise known as complainer ;-P ) and I
don't want to deal with github to get kicad libraries. A 50 year old
hobbyist will give up on kicad in 10 minutes after not being able to figure
out where the components are and that kicad appears baren after not being
able to start designing even a simple circuit without reinventing the wheel.

On Mon, Feb 26, 2018 at 3:39 AM, Simon Richter 
wrote:

> Hi,
>
> On 25.02.2018 22:52, Andrey Kuznetsov wrote:
>
> > The unchecked components in the image below cannot be checked.
>
> Yes, these are no longer in the nightly installer, because they are
> 600MB compressed, and most nightly users maintain their libraries
> themselves.
>
>Simon
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>


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

Re: [Kicad-developers] Windows Nightlies Installer - Unable to check components for instal

[Adam Wolf]

This is especially useful for our Chinese users and folks traveling to
China for manufacturing support, as often Github and other common
public git repositories are blocked.

Adam

On Mon, Feb 26, 2018 at 11:42 AM, Wayne Stambaugh  wrote:
> On 2/26/2018 6:39 AM, Simon Richter wrote:
>> Hi,
>>
>> On 25.02.2018 22:52, Andrey Kuznetsov wrote:
>>
>>> The unchecked components in the image below cannot be checked.
>>
>> Yes, these are no longer in the nightly installer, because they are
>> 600MB compressed, and most nightly users maintain their libraries
>> themselves.
>>
>>Simon
>>
>
> Simon,
>
> Are there any plans to package the libraries as a separate installer?
> I'm sure there are some windows users are going to want to be able to
> install libraries directly rather than deal with git repos.  First time
> users are going to be bewildered by an EDA tool that appears to offer no
> symbol, footprint and/or 3D model libraries.
>
> 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] Windows Nightlies Installer - Unable to check components for instal

[Jon Evans]

In the case that there is a separate installer for the libraries (which I
also think makes sense), maybe those line items should be removed from the
main installer instead of just disabled (if that is easy) to reduce
confusion?

On Mon, Feb 26, 2018 at 12:42 PM, Wayne Stambaugh 
wrote:

> On 2/26/2018 6:39 AM, Simon Richter wrote:
> > Hi,
> >
> > On 25.02.2018 22:52, Andrey Kuznetsov wrote:
> >
> >> The unchecked components in the image below cannot be checked.
> >
> > Yes, these are no longer in the nightly installer, because they are
> > 600MB compressed, and most nightly users maintain their libraries
> > themselves.
> >
> >Simon
> >
>
> Simon,
>
> Are there any plans to package the libraries as a separate installer?
> I'm sure there are some windows users are going to want to be able to
> install libraries directly rather than deal with git repos.  First time
> users are going to be bewildered by an EDA tool that appears to offer no
> symbol, footprint and/or 3D model libraries.
>
> 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] How do I turn one of our .svg icons into a .cpp file?

[Wayne Stambaugh]

We should probably update the cmake file to include the -z option for
inkscape on macos builds so macos can be used to update image files
without having to fall back to entering commands by hand.

On 2/26/2018 12:39 PM, Seth Hillbrand wrote:
> In case this thread comes up in a search in the future, my commandline
> for exporting without the GUI is:
> 
> /Applications/Inkscape.app/Contents/Resources/bin/inkscape --export-area-snap 
> -e
> ${input}.png -f ${output}.svg -z
> 
> Inkscape version 0.48.5
> 
> 
> -S
> 
> 2018-02-26 9:26 GMT-08:00 Jeff Young  >:
> 
> I ended up running everything by hand:
> 
> Create png via Inkscpae GUI.
> 
> pngcrush refresh.png
> 
> cmake
> -DinputFile=/users/jeff/kicad_dev/kicad/bitmaps_png/png_16/refresh.png \
>      
> -DoutCppFile=/users/jeff/kicad_dev/kicad/bitmaps_png/cpp_16/refresh.cpp
> \
>       -P PNG2cpp.cmake
> 
> 
>> On 26 Feb 2018, at 17:21, jp charras > > wrote:
>>
>> Le 26/02/2018 à 18:04, Nick Østergaard a écrit :
>>> On linux it does not open a GUI, it just converts the images when
>>> I make.
>>
>> Same on Windows.
>> I remember some time ago a mail about issues with inkscape on OSX
>> to convert the svg file to a png file.
>>
>> And an other tool was mentioned to convert these svg files, but I
>> do not remember what tool.
>>
>>>
>>> 2018-02-26 18:01 GMT+01:00 Jeff Young >>  >:
>>>
>>>    When I do a build it opens the GUI inkscape (should it be
>>> doing that?) but then hangs.  (I can
>>>    use Inkscape, but my build just sits there.)
>>>
 On 26 Feb 2018, at 16:58, jp charras  >
 wrote:

 Le 26/02/2018 à 17:17, Nick Østergaard a écrit :
> I am not sure how well it works on macos, but it uses inkscape
> to export them to png and then
> something else to turn them to xpm which is turned into cpp as
> far as I remember. I may be wrong.
>
> 2018-02-26 17:16 GMT+01:00 Nick Østergaard   
>>>    >>:
>
>     Enable  MAINTAIN_PNGS with cmake.
>
>     2018-02-26 17:14 GMT+01:00 Jeff Young   
>>>    >>:
>
>         (Don’t worry; not for 5.0stable.)

 Once the svg file is converted to a png file, our PNG2cpp.cmake
 "script" convert the binary
>>>    file to
 a equivalent list of unsigned chars.

 Currently inkscape is used to convert the svg file to a png file
 containing metadata.
 This metadata is useless for us, and removed by pngcrush to
 reduce the size of the final .cpp
>>>    file.


 --
 Jean-Pierre CHARRAS
>>
>>
>> -- 
>> 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] Windows Nightlies Installer - Unable to check components for instal

[Wayne Stambaugh]

On 2/26/2018 6:39 AM, Simon Richter wrote:
> Hi,
> 
> On 25.02.2018 22:52, Andrey Kuznetsov wrote:
> 
>> The unchecked components in the image below cannot be checked.
> 
> Yes, these are no longer in the nightly installer, because they are
> 600MB compressed, and most nightly users maintain their libraries
> themselves.
> 
>Simon
> 

Simon,

Are there any plans to package the libraries as a separate installer?
I'm sure there are some windows users are going to want to be able to
install libraries directly rather than deal with git repos.  First time
users are going to be bewildered by an EDA tool that appears to offer no
symbol, footprint and/or 3D model libraries.

Wayne

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

Re: [Kicad-developers] How do I turn one of our .svg icons into a .cpp file?

[Seth Hillbrand]

In case this thread comes up in a search in the future, my commandline for
exporting without the GUI is:

/Applications/Inkscape.app/Contents/Resources/bin/inkscape
--export-area-snap -e
${input}.png -f ${output}.svg -z

Inkscape version 0.48.5


-S

2018-02-26 9:26 GMT-08:00 Jeff Young :

> I ended up running everything by hand:
>
> Create png via Inkscpae GUI.
>
> pngcrush refresh.png
>
> cmake -DinputFile=/users/jeff/kicad_dev/kicad/bitmaps_png/png_16/refresh.png
> \
>   -DoutCppFile=/users/jeff/kicad_dev/kicad/bitmaps_png/cpp_16/refresh.cpp
> \
>   -P PNG2cpp.cmake
>
>
> On 26 Feb 2018, at 17:21, jp charras  wrote:
>
> Le 26/02/2018 à 18:04, Nick Østergaard a écrit :
>
> On linux it does not open a GUI, it just converts the images when I make.
>
>
> Same on Windows.
> I remember some time ago a mail about issues with inkscape on OSX to
> convert the svg file to a png file.
>
> And an other tool was mentioned to convert these svg files, but I do not
> remember what tool.
>
>
> 2018-02-26 18:01 GMT+01:00 Jeff Young  mailto:j...@rokeby.ie >>:
>
>When I do a build it opens the GUI inkscape (should it be doing that?)
> but then hangs.  (I can
>use Inkscape, but my build just sits there.)
>
> On 26 Feb 2018, at 16:58, jp charras  mailto:jp.char...@wanadoo.fr >> wrote:
>
> Le 26/02/2018 à 17:17, Nick Østergaard a écrit :
>
> I am not sure how well it works on macos, but it uses inkscape to export
> them to png and then
> something else to turn them to xpm which is turned into cpp as far as I
> remember. I may be wrong.
>
> 2018-02-26 17:16 GMT+01:00 Nick Østergaard  mailto:oe.n...@gmail.com >
>
>  
>
> Enable  MAINTAIN_PNGS with cmake.
>
> 2018-02-26 17:14 GMT+01:00 Jeff Young  mailto:j...@rokeby.ie >
>
>  
>
> (Don’t worry; not for 5.0stable.)
>
>
> Once the svg file is converted to a png file, our PNG2cpp.cmake "script"
> convert the binary
>
>file to
>
> a equivalent list of unsigned chars.
>
> Currently inkscape is used to convert the svg file to a png file
> containing metadata.
> This metadata is useless for us, and removed by pngcrush to reduce the
> size of the final .cpp
>
>file.
>
>
>
> --
> Jean-Pierre CHARRAS
>
>
>
> --
> 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

Re: [Kicad-developers] How do I turn one of our .svg icons into a .cpp file?

[Jeff Young]

I ended up running everything by hand:

Create png via Inkscpae GUI.

pngcrush refresh.png

cmake -DinputFile=/users/jeff/kicad_dev/kicad/bitmaps_png/png_16/refresh.png \
  -DoutCppFile=/users/jeff/kicad_dev/kicad/bitmaps_png/cpp_16/refresh.cpp \
  -P PNG2cpp.cmake

> On 26 Feb 2018, at 17:21, jp charras  wrote:
> 
> Le 26/02/2018 à 18:04, Nick Østergaard a écrit :
>> On linux it does not open a GUI, it just converts the images when I make.
> 
> Same on Windows.
> I remember some time ago a mail about issues with inkscape on OSX to convert 
> the svg file to a png file.
> 
> And an other tool was mentioned to convert these svg files, but I do not 
> remember what tool.
> 
>> 
>> 2018-02-26 18:01 GMT+01:00 Jeff Young > >:
>> 
>>When I do a build it opens the GUI inkscape (should it be doing that?) 
>> but then hangs.  (I can
>>use Inkscape, but my build just sits there.)
>> 
>>> On 26 Feb 2018, at 16:58, jp charras >> > wrote:
>>> 
>>> Le 26/02/2018 à 17:17, Nick Østergaard a écrit :
 I am not sure how well it works on macos, but it uses inkscape to export 
 them to png and then
 something else to turn them to xpm which is turned into cpp as far as I 
 remember. I may be wrong.
 
 2018-02-26 17:16 GMT+01:00 Nick Østergaard 
>>>>:
 
 Enable  MAINTAIN_PNGS with cmake.
 
 2018-02-26 17:14 GMT+01:00 Jeff Young 
>>>>:
 
 (Don’t worry; not for 5.0stable.)
>>> 
>>> Once the svg file is converted to a png file, our PNG2cpp.cmake "script" 
>>> convert the binary
>>file to
>>> a equivalent list of unsigned chars.
>>> 
>>> Currently inkscape is used to convert the svg file to a png file containing 
>>> metadata.
>>> This metadata is useless for us, and removed by pngcrush to reduce the size 
>>> of the final .cpp
>>file.
>>> 
>>> 
>>> --
>>> Jean-Pierre CHARRAS
> 
> 
> -- 
> 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] How do I turn one of our .svg icons into a .cpp file?

[Seth Hillbrand]

Jeff-

Use the "-z" commandline option to execute things without the gui on Mac.

-S

2018-02-26 9:04 GMT-08:00 Nick Østergaard :

> On linux it does not open a GUI, it just converts the images when I make.
>
> 2018-02-26 18:01 GMT+01:00 Jeff Young :
>
>> When I do a build it opens the GUI inkscape (should it be doing that?)
>> but then hangs.  (I can use Inkscape, but my build just sits there.)
>>
>> > On 26 Feb 2018, at 16:58, jp charras  wrote:
>> >
>> > Le 26/02/2018 à 17:17, Nick Østergaard a écrit :
>> >> I am not sure how well it works on macos, but it uses inkscape to
>> export them to png and then
>> >> something else to turn them to xpm which is turned into cpp as far as
>> I remember. I may be wrong.
>> >>
>> >> 2018-02-26 17:16 GMT+01:00 Nick Østergaard  oe.n...@gmail.com>>:
>> >>
>> >>Enable  MAINTAIN_PNGS with cmake.
>> >>
>> >>2018-02-26 17:14 GMT+01:00 Jeff Young  j...@rokeby.ie>>:
>> >>
>> >>(Don’t worry; not for 5.0stable.)
>> >
>> > Once the svg file is converted to a png file, our PNG2cpp.cmake
>> "script" convert the binary file to
>> > a equivalent list of unsigned chars.
>> >
>> > Currently inkscape is used to convert the svg file to a png file
>> containing metadata.
>> > This metadata is useless for us, and removed by pngcrush to reduce the
>> size of the final .cpp file.
>> >
>> >
>> > --
>> > 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] How do I turn one of our .svg icons into a .cpp file?

[jp charras]

Le 26/02/2018 à 18:04, Nick Østergaard a écrit :
> On linux it does not open a GUI, it just converts the images when I make.

Same on Windows.
I remember some time ago a mail about issues with inkscape on OSX to convert 
the svg file to a png file.

And an other tool was mentioned to convert these svg files, but I do not 
remember what tool.

> 
> 2018-02-26 18:01 GMT+01:00 Jeff Young  >:
> 
> When I do a build it opens the GUI inkscape (should it be doing that?) 
> but then hangs.  (I can
> use Inkscape, but my build just sits there.)
> 
> > On 26 Feb 2018, at 16:58, jp charras  > wrote:
> >
> > Le 26/02/2018 à 17:17, Nick Østergaard a écrit :
> >> I am not sure how well it works on macos, but it uses inkscape to 
> export them to png and then
> >> something else to turn them to xpm which is turned into cpp as far as 
> I remember. I may be wrong.
> >>
> >> 2018-02-26 17:16 GMT+01:00 Nick Østergaard  
> >>:
> >>
> >>    Enable  MAINTAIN_PNGS with cmake.
> >>
> >>    2018-02-26 17:14 GMT+01:00 Jeff Young  
> >>:
> >>
> >>        (Don’t worry; not for 5.0stable.)
> >
> > Once the svg file is converted to a png file, our PNG2cpp.cmake 
> "script" convert the binary
> file to
> > a equivalent list of unsigned chars.
> >
> > Currently inkscape is used to convert the svg file to a png file 
> containing metadata.
> > This metadata is useless for us, and removed by pngcrush to reduce the 
> size of the final .cpp
> file.
> >
> >
> > --
> > Jean-Pierre CHARRAS


-- 
Jean-Pierre CHARRAS

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

Re: [Kicad-developers] How do I turn one of our .svg icons into a .cpp file?

[Jeff Young]

When I do a build it opens the GUI inkscape (should it be doing that?) but then 
hangs.  (I can use Inkscape, but my build just sits there.)

> On 26 Feb 2018, at 16:58, jp charras  wrote:
> 
> Le 26/02/2018 à 17:17, Nick Østergaard a écrit :
>> I am not sure how well it works on macos, but it uses inkscape to export 
>> them to png and then
>> something else to turn them to xpm which is turned into cpp as far as I 
>> remember. I may be wrong.
>> 
>> 2018-02-26 17:16 GMT+01:00 Nick Østergaard > >:
>> 
>>Enable  MAINTAIN_PNGS with cmake.
>> 
>>2018-02-26 17:14 GMT+01:00 Jeff Young > >:
>> 
>>(Don’t worry; not for 5.0stable.)
> 
> Once the svg file is converted to a png file, our PNG2cpp.cmake "script" 
> convert the binary file to
> a equivalent list of unsigned chars.
> 
> Currently inkscape is used to convert the svg file to a png file containing 
> metadata.
> This metadata is useless for us, and removed by pngcrush to reduce the size 
> of the final .cpp file.
> 
> 
> -- 
> 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] How do I turn one of our .svg icons into a .cpp file?

[jp charras]

Le 26/02/2018 à 17:17, Nick Østergaard a écrit :
> I am not sure how well it works on macos, but it uses inkscape to export them 
> to png and then
> something else to turn them to xpm which is turned into cpp as far as I 
> remember. I may be wrong.
> 
> 2018-02-26 17:16 GMT+01:00 Nick Østergaard  >:
> 
> Enable  MAINTAIN_PNGS with cmake.
> 
> 2018-02-26 17:14 GMT+01:00 Jeff Young  >:
> 
> (Don’t worry; not for 5.0stable.)

Once the svg file is converted to a png file, our PNG2cpp.cmake "script" 
convert the binary file to
a equivalent list of unsigned chars.

Currently inkscape is used to convert the svg file to a png file containing 
metadata.
This metadata is useless for us, and removed by pngcrush to reduce the size of 
the final .cpp file.


-- 
Jean-Pierre CHARRAS

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

Re: [Kicad-developers] How do I turn one of our .svg icons into a .cpp file?

[Seth Hillbrand]

Jeff-

On my mac, I use /Applications/Inkscape.app/Contents/Resources/bin/inkscape
for the command-line access.  It is installed with the standard GUI.

-S

2018-02-26 8:23 GMT-08:00 Jeff Young :

> Yeah, it looks like inkscape and pngcrush.
>
> I have the inkscape GUI app; does it need a separate command-line tool, or
> is the GUI app also a command-line tool?
>
> Thanks,
> Jeff.
>
>
> On 26 Feb 2018, at 16:17, Nick Østergaard  wrote:
>
> I am not sure how well it works on macos, but it uses inkscape to export
> them to png and then something else to turn them to xpm which is turned
> into cpp as far as I remember. I may be wrong.
>
> 2018-02-26 17:16 GMT+01:00 Nick Østergaard :
>
>> Enable  MAINTAIN_PNGS with cmake.
>>
>> 2018-02-26 17:14 GMT+01:00 Jeff Young :
>>
>>> (Don’t worry; not for 5.0stable.)
>>> ___
>>> 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] Don't use the RTREE in UpdateAllLayersOrder() / UpdateAllLayersColor()

[Maciej Sumiński]

Alright, thank you for quick verification. I have just committed the fix
to the master branch.

Cheers,
Orson

On 02/26/2018 05:12 PM, Jon Evans wrote:
> Sounds good to me.  1% hit should not cancel out the gains from not using
> the RTree in large worlds (I saw layer-switch time drop from ~80ms to ~30ms
> on my machine)
> We can consider revisiting this later to eliminate the need for
> dynamic_cast by ensuring that anything that VIEW calls on an item it owns
> is a member of that object.
> 
> -Jon
> 
> On Mon, Feb 26, 2018 at 11:03 AM, Maciej Sumiński 
> wrote:
> 
>> Apparently clang analyzer has been correct this time. It turns out that
>> PCB_PAINTER::Draw() and PCB_RENDER_SETTINGS::GetColor() assume that all
>> objects are EDA_ITEMs, which is not true for VIEW_GROUP class. When a
>> layer is changed, VIEW::UpdateAllLayersColor() iterates through all
>> VIEW_ITEMs and eventually calls PCB_RENDER_SETTINGS::GetColor() which
>> incorrectly casts VIEW_GROUP objects to EDA_ITEM.
>>
>> The attached patch uses dynamic_cast to verify the downcast results. I
>> measured performance drop at order of 1% in a debug build, so it does
>> not seem like a huge loss. I think we have not seen any problems as
>> RTree::Query() had never returned VIEW_GROUP objects as they had too
>> large bounding box.
>>
>> I would rather keep Jon's patch, as it makes sense to simply iterate
>> through a simple array of items during full world updates, rather than
>> using RTree algorithms to extract the same list.
>>
>> Cheers,
>> Orson
>>
>> On 02/26/2018 04:12 PM, Wayne Stambaugh wrote:
>>> Orson,
>>>
>>> That's what I was doing so it sounds like it might be something with
>>> your setup.
>>>
>>> Wayne
>>>
>>> On 2/26/2018 9:30 AM, Maciej Sumiński wrote:
 Wayne,

 I meant selecting any layer in the right-hand layer widget. Perhaps it
 is a false positive in clang analyzer, I will have a look at it. Pcbnew
 does not crash here when built with gcc (and no analyzer enabled).

 Cheers,
 Orson

 On 02/26/2018 03:02 PM, Wayne Stambaugh wrote:
> Orson,
>
> What do you mean by "any layer switching"?  I am not have any issues on
> windows when selecting a different layer in the layer manager using
> either canvas when launched from kicad or stand alone mode.
>
> Cheers,
>
> Wayne
>
> On 2/26/2018 5:01 AM, Maciej Sumiński wrote:
>> Jon,
>>
>> With this patch applied, any layer switching in pcbnew leads to a
>> crash,
>> even with no layout loaded. Can anyone else confirm this? See the the
>> attached address sanitizer report for details.
>>
>> Regards,
>> Orson
>>
>> On 02/25/2018 10:01 PM, Jon Evans wrote:
>>> This patch uses simple iteration instead of the RTREE search to
>> update the
>>> layer order and color in VIEW.  On my Linux system, this results in
>> a ~50%
>>> speedup in release build (less in debug build) and is most
>> noticeable when
>>> switching layers in GerbView with large Gerber files loaded (i.e.
>> high
>>> number of items in the view).
>>>
>>> -Jon
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>




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

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

Re: [Kicad-developers] How do I turn one of our .svg icons into a .cpp file?

[Jeff Young]

Yeah, it looks like inkscape and pngcrush.

I have the inkscape GUI app; does it need a separate command-line tool, or is 
the GUI app also a command-line tool?

Thanks,
Jeff.


> On 26 Feb 2018, at 16:17, Nick Østergaard  wrote:
> 
> I am not sure how well it works on macos, but it uses inkscape to export them 
> to png and then something else to turn them to xpm which is turned into cpp 
> as far as I remember. I may be wrong.
> 
> 2018-02-26 17:16 GMT+01:00 Nick Østergaard  >:
> Enable   MAINTAIN_PNGS with cmake.
> 
> 2018-02-26 17:14 GMT+01:00 Jeff Young  >:
> (Don’t worry; not for 5.0stable.)
> ___
> 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] How do I turn one of our .svg icons into a .cpp file?

[Nick Østergaard]

I am not sure how well it works on macos, but it uses inkscape to export
them to png and then something else to turn them to xpm which is turned
into cpp as far as I remember. I may be wrong.

2018-02-26 17:16 GMT+01:00 Nick Østergaard :

> Enable  MAINTAIN_PNGS with cmake.
>
> 2018-02-26 17:14 GMT+01:00 Jeff Young :
>
>> (Don’t worry; not for 5.0stable.)
>> ___
>> 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] How do I turn one of our .svg icons into a .cpp file?

[Nick Østergaard]

Enable  MAINTAIN_PNGS with cmake.

2018-02-26 17:14 GMT+01:00 Jeff Young :

> (Don’t worry; not for 5.0stable.)
> ___
> 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] How do I turn one of our .svg icons into a .cpp file?

[Jeff Young]

(Don’t worry; not for 5.0stable.)
___
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] Don't use the RTREE in UpdateAllLayersOrder() / UpdateAllLayersColor()

[Jon Evans]

Sounds good to me.  1% hit should not cancel out the gains from not using
the RTree in large worlds (I saw layer-switch time drop from ~80ms to ~30ms
on my machine)
We can consider revisiting this later to eliminate the need for
dynamic_cast by ensuring that anything that VIEW calls on an item it owns
is a member of that object.

-Jon

On Mon, Feb 26, 2018 at 11:03 AM, Maciej Sumiński 
wrote:

> Apparently clang analyzer has been correct this time. It turns out that
> PCB_PAINTER::Draw() and PCB_RENDER_SETTINGS::GetColor() assume that all
> objects are EDA_ITEMs, which is not true for VIEW_GROUP class. When a
> layer is changed, VIEW::UpdateAllLayersColor() iterates through all
> VIEW_ITEMs and eventually calls PCB_RENDER_SETTINGS::GetColor() which
> incorrectly casts VIEW_GROUP objects to EDA_ITEM.
>
> The attached patch uses dynamic_cast to verify the downcast results. I
> measured performance drop at order of 1% in a debug build, so it does
> not seem like a huge loss. I think we have not seen any problems as
> RTree::Query() had never returned VIEW_GROUP objects as they had too
> large bounding box.
>
> I would rather keep Jon's patch, as it makes sense to simply iterate
> through a simple array of items during full world updates, rather than
> using RTree algorithms to extract the same list.
>
> Cheers,
> Orson
>
> On 02/26/2018 04:12 PM, Wayne Stambaugh wrote:
> > Orson,
> >
> > That's what I was doing so it sounds like it might be something with
> > your setup.
> >
> > Wayne
> >
> > On 2/26/2018 9:30 AM, Maciej Sumiński wrote:
> >> Wayne,
> >>
> >> I meant selecting any layer in the right-hand layer widget. Perhaps it
> >> is a false positive in clang analyzer, I will have a look at it. Pcbnew
> >> does not crash here when built with gcc (and no analyzer enabled).
> >>
> >> Cheers,
> >> Orson
> >>
> >> On 02/26/2018 03:02 PM, Wayne Stambaugh wrote:
> >>> Orson,
> >>>
> >>> What do you mean by "any layer switching"?  I am not have any issues on
> >>> windows when selecting a different layer in the layer manager using
> >>> either canvas when launched from kicad or stand alone mode.
> >>>
> >>> Cheers,
> >>>
> >>> Wayne
> >>>
> >>> On 2/26/2018 5:01 AM, Maciej Sumiński wrote:
>  Jon,
> 
>  With this patch applied, any layer switching in pcbnew leads to a
> crash,
>  even with no layout loaded. Can anyone else confirm this? See the the
>  attached address sanitizer report for details.
> 
>  Regards,
>  Orson
> 
>  On 02/25/2018 10:01 PM, Jon Evans wrote:
> > This patch uses simple iteration instead of the RTREE search to
> update the
> > layer order and color in VIEW.  On my Linux system, this results in
> a ~50%
> > speedup in release build (less in debug build) and is most
> noticeable when
> > switching layers in GerbView with large Gerber files loaded (i.e.
> high
> > number of items in the view).
> >
> > -Jon
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
> 
> 
> 
>  ___
>  Mailing list: https://launchpad.net/~kicad-developers
>  Post to : kicad-developers@lists.launchpad.net
>  Unsubscribe : https://launchpad.net/~kicad-developers
>  More help   : https://help.launchpad.net/ListHelp
> 
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~kicad-developers
> >>> Post to : kicad-developers@lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> More help   : https://help.launchpad.net/ListHelp
> >>>
> >>
> >>
> >>
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : 

Re: [Kicad-developers] validators

[Jeff Young]

A couple of additional data-points:

The wheel isn’t much to reinvent.  There’s not a lot to the wxWidgets numeric 
validators.  (The num validator, int validator and floating point validator 
together make up only 300 lines of commented code.)

The developer has to add UNIT_BINDERs for each unit-scaled control anyway; at 
that point having to set up a validator in wxFormBuilder is more work as 
opposed to less.

The same for evaluation: the UNIT_BINDER handles that by default, or you can 
turn it off, but there’s nothing you have to add.

Cheers,
Jeff.

PS: this version of the Grid Settings dialog shows just how simple a dialog 
using the unit binder can be.  It handles typed-in unit conversions, 
evaluation, and validation.

https://git.launchpad.net/~jeyjey/kicad/tree/pcbnew/dialogs/dialog_set_grid.cpp 


> On 26 Feb 2018, at 14:23, Wayne Stambaugh  wrote:
> 
> Hey Jeff,
> 
> This is a better argument.  I will counter by suggesting that the
> OnChar() event handler can be overridden to provide the behavior we
> need.  I realize that it would be difficult to perform units
> verification and/or numerical evaluation in the OnChar() event handler
> but you can prevent any illegal characters from be entered which AFAIK
> UNIT_BINDER does not handle.  UNIT_BINDER handles everything after the
> characters have been entered into the control so the user has to clean
> up any entry issues after the fact.  I'm not shooting down the idea of
> UNIT_BINDER, I just want to be sure we are not reinventing the wheel.
> 
> Cheers,
> 
> Wayne
> 
> On 2/25/2018 6:01 PM, Jeff Young wrote:
>> Hi Wayne,
>> 
>> The primary issue is that they try to do all their validation through 
>> OnChar().  As JP mentioned, this leads to problems like typing 0 to start a 
>> number.  But it also means the only way they have to guarantee a number is 
>> to allow only digits, zero-or-one minus sign, and zero-or-one decimal 
>> separator.  This strategy is completely unsuitable for handling typed-in 
>> units, never mind evaluation.
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>>> On 25 Feb 2018, at 22:21, Wayne Stambaugh  wrote:
>>> 
>>> Jeff,
>>> 
>>> I'm not opposed to this solution but I need technical information as to why 
>>> we should use one solution over another.  "Brain dead" is not a technical 
>>> reason and doesn't really help me make an informed decision. I've used 
>>> validators for simple edit control validation in the past and they worked 
>>> just fine so I need something tangible as to why they are unacceptable in 
>>> this case.  I'm not saying I agree or disagree with you, I just need 
>>> something more to go on.
>>> 
>>> Cheers,
>>> 
>>> Wayne
>>> 
>>> On 02/24/2018 04:18 PM, Jeff Young wrote:
 I looked in to wxWidget’s validators, and they’re definitely challenged.  
 (Brain-dead might be more accurate.)
 As part of the units overhaul I’m going to propose making widespread use 
 of the UNIT_BINDER, which is a wrapper for a 
 wxTextEntry/wxStaticText-tuple.
 As a wrapper it’ll be easy to add evaluation and validation to it, and 
 allow most all other clients to wash their hands of unit display, unit 
 conversion, evaluation, and validation.
 (We’ll probably want to rename UNIT_BINDER something more generic at that 
 point.)
 Cheers,
 Jeff.
> On 23 Feb 2018, at 20:10, Wayne Stambaugh <1751...@bugs.launchpad.net> 
> wrote:
> 
> @JP,
> 
> Understood but we can always create our own validator derive from the
> base wxNumValidator or wxValidator object if wxFloatingPointValidator is
> to restrictive.  As for the numeric limiting, if you set the limit's to
> 0.5 than 0.6 is illegal both as an initial value and as user entered
> value so that is just the behavior of the validator which we could also
> override in a derived object.
> 
> On 02/23/2018 02:39 PM, jean-pierre charras wrote:
>> @Wayne,
>> 
>> I was never impressed by the wxFloatingPointValidator.
>> 
>> AFAIK, for instance, if a minimal value is fixed to 0.5, you cannot 
>> enter a value starting by 0 like 0.6 (just because starting a value by 0 
>> is too small)
>> You need to enter 1.6 and after change 1.6 to 0.6
>> 
>> But the issue here is different:
>> In countries using a comma as separator, we use both the . or the , to 
>> enter a floating point value.
>> In a dialog, these 2 separators *must be* equivalent when the separator 
>> is the comma.
>> 
>> But wxFloatingPointValidator does not accept both separators, only the
>> comma.
>> 
>> This is very annoying.
>> 
>> If we want to use a FloatingPointValidator, we need to create our own 
>> validator.
>> For me wxFloatingPointValidator just does not work in Kicad.
>> 
> 
> -- 
> You received this bug notification because you are a member of KiCad Bug
> Squad, which is 

Re: [Kicad-developers] PPA: KiCad 5.0

[Nick Østergaard]

No.

2018-02-26 17:03 GMT+01:00 Kevin Cozens :

> On 2018-02-26 05:15 AM, Maciej Sumiński wrote:
>
>> Does it mean there are no more documentation updates for 5.0
>> foreseen/accepted?
>>
> Have the file format docs been updated to reflect the recent changes?
>
> --
> 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
>
___
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] Don't use the RTREE in UpdateAllLayersOrder() / UpdateAllLayersColor()

[Maciej Sumiński]

Apparently clang analyzer has been correct this time. It turns out that
PCB_PAINTER::Draw() and PCB_RENDER_SETTINGS::GetColor() assume that all
objects are EDA_ITEMs, which is not true for VIEW_GROUP class. When a
layer is changed, VIEW::UpdateAllLayersColor() iterates through all
VIEW_ITEMs and eventually calls PCB_RENDER_SETTINGS::GetColor() which
incorrectly casts VIEW_GROUP objects to EDA_ITEM.

The attached patch uses dynamic_cast to verify the downcast results. I
measured performance drop at order of 1% in a debug build, so it does
not seem like a huge loss. I think we have not seen any problems as
RTree::Query() had never returned VIEW_GROUP objects as they had too
large bounding box.

I would rather keep Jon's patch, as it makes sense to simply iterate
through a simple array of items during full world updates, rather than
using RTree algorithms to extract the same list.

Cheers,
Orson

On 02/26/2018 04:12 PM, Wayne Stambaugh wrote:
> Orson,
> 
> That's what I was doing so it sounds like it might be something with
> your setup.
> 
> Wayne
> 
> On 2/26/2018 9:30 AM, Maciej Sumiński wrote:
>> Wayne,
>>
>> I meant selecting any layer in the right-hand layer widget. Perhaps it
>> is a false positive in clang analyzer, I will have a look at it. Pcbnew
>> does not crash here when built with gcc (and no analyzer enabled).
>>
>> Cheers,
>> Orson
>>
>> On 02/26/2018 03:02 PM, Wayne Stambaugh wrote:
>>> Orson,
>>>
>>> What do you mean by "any layer switching"?  I am not have any issues on
>>> windows when selecting a different layer in the layer manager using
>>> either canvas when launched from kicad or stand alone mode.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 2/26/2018 5:01 AM, Maciej Sumiński wrote:
 Jon,

 With this patch applied, any layer switching in pcbnew leads to a crash,
 even with no layout loaded. Can anyone else confirm this? See the the
 attached address sanitizer report for details.

 Regards,
 Orson

 On 02/25/2018 10:01 PM, Jon Evans wrote:
> This patch uses simple iteration instead of the RTREE search to update the
> layer order and color in VIEW.  On my Linux system, this results in a ~50%
> speedup in release build (less in debug build) and is most noticeable when
> switching layers in GerbView with large Gerber files loaded (i.e. high
> number of items in the view).
>
> -Jon
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>



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

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

From 5a970815c2463410ebcb1bd46b391252157c1e5f Mon Sep 17 00:00:00 2001
From: Maciej Suminski 
Date: Mon, 26 Feb 2018 16:51:18 +0100
Subject: [PATCH] PCB_PAINTER: use dynamic_cast to determine whether an object
 is of EDA_ITEM type

---
 pcbnew/pcb_painter.cpp | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/pcbnew/pcb_painter.cpp b/pcbnew/pcb_painter.cpp
index 907ecbe24..52f9c5428 100644
--- a/pcbnew/pcb_painter.cpp
+++ b/pcbnew/pcb_painter.cpp
@@ -212,7 +212,7 @@ void PCB_RENDER_SETTINGS::LoadDisplayOptions( const PCB_DISPLAY_OPTIONS* aOption
 const COLOR4D& PCB_RENDER_SETTINGS::GetColor( const VIEW_ITEM* aItem, int aLayer ) const
 {
 int netCode = -1;
-const EDA_ITEM* item = static_cast( aItem );
+const EDA_ITEM* item = dynamic_cast( aItem );
 
 if( item )
 {
@@ -277,7 +277,10 @@ int PCB_PAINTER::getLineThickness( int aActualThickness ) const
 
 bool PCB_PAINTER::Draw( const VIEW_ITEM* aItem, int aLayer )
 {
-const EDA_ITEM* item = static_cast( aItem );
+const EDA_ITEM* item = dynamic_cast( aItem );
+
+if( !item )
+return 

Re: [Kicad-developers] PPA: KiCad 5.0

[Kevin Cozens]

On 2018-02-26 05:15 AM, Maciej Sumiński wrote:

Does it mean there are no more documentation updates for 5.0
foreseen/accepted?

Have the file format docs been updated to reflect the recent changes?

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

Re: [Kicad-developers] PPA: KiCad 5.0

[Jean-Samuel Reynaud]

So now every repositories are tagged and all packages are built. PPA for
KiCad 5 is ready now...

Le 26/02/2018 à 16:00, Carsten Schoenert a écrit :
> Am 26.02.2018 um 12:10 schrieb Rene Pöschl:
>> The library repos have been tagged with 5.0.0-rc1
>>
>> (As requested yesterday in a similar mailing list thread. [1])
> 
> Excellent! Thanks.
> 
>> This will not be the last tag for 5.0.0. We will make more bugfixes. If 
>> time permits we might also do some larger changes as well.
>>
>> After the v5 release we will limit the lib to bugfixes and new 
>> additions. If a larger change is proposed we might create separate 
>> branches for v5 and v6
> 
> Sounds also correct, also thanks for this!
> 


___
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] Don't use the RTREE in UpdateAllLayersOrder() / UpdateAllLayersColor()

[Wayne Stambaugh]

Orson,

That's what I was doing so it sounds like it might be something with
your setup.

Wayne

On 2/26/2018 9:30 AM, Maciej Sumiński wrote:
> Wayne,
> 
> I meant selecting any layer in the right-hand layer widget. Perhaps it
> is a false positive in clang analyzer, I will have a look at it. Pcbnew
> does not crash here when built with gcc (and no analyzer enabled).
> 
> Cheers,
> Orson
> 
> On 02/26/2018 03:02 PM, Wayne Stambaugh wrote:
>> Orson,
>>
>> What do you mean by "any layer switching"?  I am not have any issues on
>> windows when selecting a different layer in the layer manager using
>> either canvas when launched from kicad or stand alone mode.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 2/26/2018 5:01 AM, Maciej Sumiński wrote:
>>> Jon,
>>>
>>> With this patch applied, any layer switching in pcbnew leads to a crash,
>>> even with no layout loaded. Can anyone else confirm this? See the the
>>> attached address sanitizer report for details.
>>>
>>> Regards,
>>> Orson
>>>
>>> On 02/25/2018 10:01 PM, Jon Evans wrote:
 This patch uses simple iteration instead of the RTREE search to update the
 layer order and color in VIEW.  On my Linux system, this results in a ~50%
 speedup in release build (less in debug build) and is most noticeable when
 switching layers in GerbView with large Gerber files loaded (i.e. high
 number of items in the view).

 -Jon



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

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

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

Re: [Kicad-developers] PPA: KiCad 5.0

[Carsten Schoenert]

Am 26.02.2018 um 12:10 schrieb Rene Pöschl:
> The library repos have been tagged with 5.0.0-rc1
> 
> (As requested yesterday in a similar mailing list thread. [1])

Excellent! Thanks.

> This will not be the last tag for 5.0.0. We will make more bugfixes. If 
> time permits we might also do some larger changes as well.
> 
> After the v5 release we will limit the lib to bugfixes and new 
> additions. If a larger change is proposed we might create separate 
> branches for v5 and v6

Sounds also correct, also thanks for this!

-- 
Regards
Carsten Schoenert

___
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] Don't use the RTREE in UpdateAllLayersOrder() / UpdateAllLayersColor()

[Maciej Sumiński]

Wayne,

I meant selecting any layer in the right-hand layer widget. Perhaps it
is a false positive in clang analyzer, I will have a look at it. Pcbnew
does not crash here when built with gcc (and no analyzer enabled).

Cheers,
Orson

On 02/26/2018 03:02 PM, Wayne Stambaugh wrote:
> Orson,
> 
> What do you mean by "any layer switching"?  I am not have any issues on
> windows when selecting a different layer in the layer manager using
> either canvas when launched from kicad or stand alone mode.
> 
> Cheers,
> 
> Wayne
> 
> On 2/26/2018 5:01 AM, Maciej Sumiński wrote:
>> Jon,
>>
>> With this patch applied, any layer switching in pcbnew leads to a crash,
>> even with no layout loaded. Can anyone else confirm this? See the the
>> attached address sanitizer report for details.
>>
>> Regards,
>> Orson
>>
>> On 02/25/2018 10:01 PM, Jon Evans wrote:
>>> This patch uses simple iteration instead of the RTREE search to update the
>>> layer order and color in VIEW.  On my Linux system, this results in a ~50%
>>> speedup in release build (less in debug build) and is most noticeable when
>>> switching layers in GerbView with large Gerber files loaded (i.e. high
>>> number of items in the view).
>>>
>>> -Jon
>>>
>>>
>>>
>>> ___
>>> 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
> 




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

Re: [Kicad-developers] validators

[Wayne Stambaugh]

Hey Jeff,

This is a better argument.  I will counter by suggesting that the
OnChar() event handler can be overridden to provide the behavior we
need.  I realize that it would be difficult to perform units
verification and/or numerical evaluation in the OnChar() event handler
but you can prevent any illegal characters from be entered which AFAIK
UNIT_BINDER does not handle.  UNIT_BINDER handles everything after the
characters have been entered into the control so the user has to clean
up any entry issues after the fact.  I'm not shooting down the idea of
UNIT_BINDER, I just want to be sure we are not reinventing the wheel.

Cheers,

Wayne

On 2/25/2018 6:01 PM, Jeff Young wrote:
> Hi Wayne,
> 
> The primary issue is that they try to do all their validation through 
> OnChar().  As JP mentioned, this leads to problems like typing 0 to start a 
> number.  But it also means the only way they have to guarantee a number is to 
> allow only digits, zero-or-one minus sign, and zero-or-one decimal separator. 
>  This strategy is completely unsuitable for handling typed-in units, never 
> mind evaluation.
> 
> Cheers,
> Jeff.
> 
> 
>> On 25 Feb 2018, at 22:21, Wayne Stambaugh  wrote:
>>
>> Jeff,
>>
>> I'm not opposed to this solution but I need technical information as to why 
>> we should use one solution over another.  "Brain dead" is not a technical 
>> reason and doesn't really help me make an informed decision. I've used 
>> validators for simple edit control validation in the past and they worked 
>> just fine so I need something tangible as to why they are unacceptable in 
>> this case.  I'm not saying I agree or disagree with you, I just need 
>> something more to go on.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 02/24/2018 04:18 PM, Jeff Young wrote:
>>> I looked in to wxWidget’s validators, and they’re definitely challenged.  
>>> (Brain-dead might be more accurate.)
>>> As part of the units overhaul I’m going to propose making widespread use of 
>>> the UNIT_BINDER, which is a wrapper for a wxTextEntry/wxStaticText-tuple.
>>> As a wrapper it’ll be easy to add evaluation and validation to it, and 
>>> allow most all other clients to wash their hands of unit display, unit 
>>> conversion, evaluation, and validation.
>>> (We’ll probably want to rename UNIT_BINDER something more generic at that 
>>> point.)
>>> Cheers,
>>> Jeff.
 On 23 Feb 2018, at 20:10, Wayne Stambaugh <1751...@bugs.launchpad.net> 
 wrote:

 @JP,

 Understood but we can always create our own validator derive from the
 base wxNumValidator or wxValidator object if wxFloatingPointValidator is
 to restrictive.  As for the numeric limiting, if you set the limit's to
 0.5 than 0.6 is illegal both as an initial value and as user entered
 value so that is just the behavior of the validator which we could also
 override in a derived object.

 On 02/23/2018 02:39 PM, jean-pierre charras wrote:
> @Wayne,
>
> I was never impressed by the wxFloatingPointValidator.
>
> AFAIK, for instance, if a minimal value is fixed to 0.5, you cannot enter 
> a value starting by 0 like 0.6 (just because starting a value by 0 is too 
> small)
> You need to enter 1.6 and after change 1.6 to 0.6
>
> But the issue here is different:
> In countries using a comma as separator, we use both the . or the , to 
> enter a floating point value.
> In a dialog, these 2 separators *must be* equivalent when the separator 
> is the comma.
>
> But wxFloatingPointValidator does not accept both separators, only the
> comma.
>
> This is very annoying.
>
> If we want to use a FloatingPointValidator, we need to create our own 
> validator.
> For me wxFloatingPointValidator just does not work in Kicad.
>

 -- 
 You received this bug notification because you are a member of KiCad Bug
 Squad, which is subscribed to KiCad.
 https://bugs.launchpad.net/bugs/1751315

 Title:
  pcbnew: float point separator '.' truncate fractional part (default
  separator is ',')

 Status in KiCad:
  New

 Bug description:
  For example: if set in dialog 'Move exactly' `Move vector X` to 2.5 then 
 number truncated up to 2.
  If set 2,5 then number not truncated (OK).
  I use the RU locale.

  Application: kicad
  Version: 5.0-dev-unknown-997d4de~62~ubuntu17.10.1, release build
  Libraries:
  wxWidgets 3.0.3
  libcurl/7.55.1 OpenSSL/1.0.2g zlib/1.2.11 libidn2/2.0.2 libpsl/0.18.0 
 (+libidn2/2.0.2) librtmp/2.3
  Platform: Linux 4.13.0-32-generic x86_64, 64 bit, Little endian, wxGTK
  Build Info:
  wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
  Boost: 1.62.0
  Curl: 7.55.1
  Compiler: GCC 7.2.0 with C++ ABI 1011

  Build settings:
  USE_WX_GRAPHICS_CONTEXT=OFF
  

Re: [Kicad-developers] [PATCH] Don't use the RTREE in UpdateAllLayersOrder() / UpdateAllLayersColor()

[Wayne Stambaugh]

Orson,

What do you mean by "any layer switching"?  I am not have any issues on
windows when selecting a different layer in the layer manager using
either canvas when launched from kicad or stand alone mode.

Cheers,

Wayne

On 2/26/2018 5:01 AM, Maciej Sumiński wrote:
> Jon,
> 
> With this patch applied, any layer switching in pcbnew leads to a crash,
> even with no layout loaded. Can anyone else confirm this? See the the
> attached address sanitizer report for details.
> 
> Regards,
> Orson
> 
> On 02/25/2018 10:01 PM, Jon Evans wrote:
>> This patch uses simple iteration instead of the RTREE search to update the
>> layer order and color in VIEW.  On my Linux system, this results in a ~50%
>> speedup in release build (less in debug build) and is most noticeable when
>> switching layers in GerbView with large Gerber files loaded (i.e. high
>> number of items in the view).
>>
>> -Jon
>>
>>
>>
>> ___
>> 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] Pads front and F.Cu visibility, possible bugs?

[Wayne Stambaugh]

Copper layers can be renamed so I only expect the layer names F.Cu and
B.Cu when I have not renamed them.  I'm guessing you have one of the
kicad demo projects open based on the French layer names which JP likes
to use.

On 2/25/2018 8:59 PM, Andrey Kuznetsov wrote:
> Not sure if this is the right thread that dealt with Layers tab, but
> anyone else thinks the first 2 names should say:
> F.Copper
> B.Copper
> 
> instead of:
> Inline image 1
> 
> On Sat, Feb 17, 2018 at 3:04 PM, Andrzej Wolski  > wrote:
> 
> There is a simple fix to this problem, patch in attachment. It needs
> to be applied on top of this patch:
> https://bugs.launchpad.net/kicad/+bug/1743890
> 
> 
> Witch this patch there is another issue: when all layers (in Layer
> tab) are hidden, anchors and invisible text are still displayed.
> I'm not sure what to do about it, maybe they also should be hidden?
> 
> Cheers,
> Andrzej
> 
> 
> 
> On 02/07/2018 04:24 PM, Kristoffer Ödmark wrote:
> 
> Hey!
> 
> Another confusion arised when I was speaking to a friend. When
> disabling the F.Cu layer, the pads are still visible. I can
> understand the need to be able to disable the pads on the front
> layer separate from everything else, to check for things under
> pads etc.
> 
> What I cannot understand is why the pads are visible if I want
> to disable the entire front layer in pcbnew, also if one wants
> transparent layers, one can actually se the compositioning for
> the front pads and front traces, and allowing them to be
> different colors also seem a bit confusing actually.
> 
> I could basically change the front pad colors to look like they
> belong to the back layer, I know its stupid, but this seems like
> the kind of thing one would not want to even be possible, except
> maybe for pranks.
> 
> TLDR;
> 
> Possible bugs:
> 1. pads not affected by layer visibility setting
> 2. pads and layer compositioning even when same setting
> 3. pads and corresponding layer color setting
> 
> Possible solution:
> 1. Both layer and pads setting must be enabled for pads to render.
> 2. Seems hard, Dont know
> 3. pads and layer share color setting, not necessarily opacity
> setting.
> 
> Comments on these?
> 
> 
> 
> 
> ___
> 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

Re: [Kicad-developers] pcbnew: Right Click Context Menu

[Jeff Young]

The zoom / grid options on the context menu are available when using an 
interactive tool.  That doesn’t really work well with the toolbar versions.

Why are cut/copy/paste on the context menus?  They must be the most known 
command-keys in computerdom.



> On 26 Feb 2018, at 03:33, hauptmech  wrote:
> 
> 
> I agree that it could be improved; though I agree with Jon that messing with 
> someone's muscle memory might make them sad.
> 
> Editable context menus are the solution I've seen (and used) in other complex 
> software.
> 
> The heuristics that kicad uses to create the context menu are complex, so the 
> user-editable approach that would probably work best is a suppression list. A 
> list of Command IDs for which popup entries will be suppressed, in the config 
> file. When one eventually wants to make it user friendly, it looks like 
> http://blogs.solidworks.com/tech/wp-content/uploads/sites/4/menu-customisation.jpg.
> 
> On 26/02/18 15:27, Andrey Kuznetsov wrote:
>> Hi,
>> 
>> Does anyone else think the right context menu in pcbnew should have some 
>> items shelved into submenus?
>> 
> 
> 
> ___
> 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] Don't use the RTREE in UpdateAllLayersOrder() / UpdateAllLayersColor()

[Jon Evans]

Hi Orson, I don't see that behavior, but I don't have asan turned on right
now either so maybe it isn't deterministic without it.

I won't be able to look at this issue until tonight, so please revert for
now unless you find a simple fix (I guess maybe preview items are missing
some initialization that permanent items get?)

Thanks,
-Jon

On Mon, Feb 26, 2018, 05:02 Maciej Sumiński  wrote:

> Jon,
>
> With this patch applied, any layer switching in pcbnew leads to a crash,
> even with no layout loaded. Can anyone else confirm this? See the the
> attached address sanitizer report for details.
>
> Regards,
> Orson
>
> On 02/25/2018 10:01 PM, Jon Evans wrote:
> > This patch uses simple iteration instead of the RTREE search to update
> the
> > layer order and color in VIEW.  On my Linux system, this results in a
> ~50%
> > speedup in release build (less in debug build) and is most noticeable
> when
> > switching layers in GerbView with large Gerber files loaded (i.e. high
> > number of items in the view).
> >
> > -Jon
> >
> >
> >
> > ___
> > 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] Windows Nightlies Installer - Unable to check components for instal

[Simon Richter]

Hi,

On 25.02.2018 22:52, Andrey Kuznetsov wrote:

> The unchecked components in the image below cannot be checked.

Yes, these are no longer in the nightly installer, because they are
600MB compressed, and most nightly users maintain their libraries
themselves.

   Simon



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

Re: [Kicad-developers] PPA: KiCad 5.0

[Rene Pöschl]

On 26/02/18 10:53, Jean-Samuel Reynaud wrote:

Dear All,

  Following KiCad 5.0 tagging, I had create a dedicated PPA for next
release (5.0). For the moment, only RC1 of kicad is built. When other
repositories will be tagger (i18n, docs and all libs), I will also
provide them on this PPA.

It's available at:
https://launchpad.net/~js-reynaud/+archive/ubuntu/kicad-5

Daily build are still active and still building "master" branch of KiCad
as usual.

Regards,

___
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



The library repos have been tagged with 5.0.0-rc1

(As requested yesterday in a similar mailing list thread. [1])

This will not be the last tag for 5.0.0. We will make more bugfixes. If 
time permits we might also do some larger changes as well.


After the v5 release we will limit the lib to bugfixes and new 
additions. If a larger change is proposed we might create separate 
branches for v5 and v6



[1] https://lists.launchpad.net/kicad-developers/msg34367.html


___
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] Improving Eagle Import netlist matching

[Russell Oliver]

Awesome,

I'm excited to finally see v5 come to pass. I think we should nickname the
release, Godot, since we have all be waiting for it for so long.

Russ

On Mon, Feb 26, 2018 at 9:59 PM Maciej Sumiński 
wrote:

> Hi Russell,
>
> I plan to merge your changes, I have almost finished the refactor to use
> KiWay mail. I will test the patches a bit and given no extra issues
> appear, I will push them to the master branch.
>
> Regards,
> Orson
>
> On 02/25/2018 10:30 PM, Russell Oliver wrote:
> > Just wondering what approach we are going to use for v5? Global labels or
> > my latest matching algorithm?
> >
> > Kind Regards
> > Russell
> >
> >
> >
> > On 25 Feb 2018 08:43, "Russell Oliver"  wrote:
> >
> >> Hi Orson,
> >>
> >> I looked at the Kicad project from the and I don't see any global
> labels,
> >> just local labels. The PCB will still have the global nets though, since
> >> they are created during import of the eagle pcb file.
> >> Just to be clear my patches are intended to only generate global labels
> >> when necessary, which should only occur when there are multiple sheets
> in
> >> the original Eagle schematic.
> >>
> >> Russell
> >>
> >>
> >>
> >> On Tue, Feb 20, 2018 at 9:55 AM Maciej Suminski <
> maciej.sumin...@cern.ch>
> >> wrote:
> >>
> >>> Hi Russell,
> >>>
> >>> On 02/19/2018 08:25 PM, Russell Oliver wrote:
>  Hi Orson,
> 
>  I wasn't sure about using the KiMail, since I didn't know how
> immediate
>  those calls are processed plus I didn't have the time to implement it
> >>> using
>  that anyway.
> >>>
> >>> That is fine, no problem. I realize it takes more time and is a bit
> >>> clunky compared to direct function calling, but I can refactor the code
> >>> to use KiMail.
> >>>
>  I'm a bit puzzled by the statement that you are getting global labels
> >>> using
>  the Arduino project. Can you send me your copy of the project and the
> >>> kicad
>  files that are generated?
> >>>
> >>> Sure, this is the official Arduino Mega 2560 rev3 [1]. I uploaded the
> >>> import result to my private server [2].
> >>>
> >>> Best regards,
> >>> Orson
> >>>
> >>> 1. https://www.arduino.cc/en/uploads/Main/arduino-mega2560_R3-
> >>> ref-design.zip
> >>> 2. https://orson.net.pl/pub/Arduino_MEGA_2560-Rev3.tar.xz
> >>>
>  Kind Regards
>  Russell
> 
>  On Tue, Feb 20, 2018 at 2:05 AM Maciej Sumiński <
> >>> maciej.sumin...@cern.ch>
>  wrote:
> 
> > Hi Russell,
> >
> > I am grateful for your continuous support. I confirm your patch
> handles
> > local net labels and zones in the attached example
> (orphanzonetest.zip)
> > correctly, but I am still getting global labels with the Arduino
> >>> project
> > mentioned by Wayne. Reverting "Fix netlist mapping for zones and
> vias"
> > is enough to get them back. I will have a look at it soon, but if you
> > see an obvious fix, do not hesitate to tell me.
> >
> > There is at least one thing that needs to be fixed, but I can handle
> >>> it.
> > One should not extend KIWAY_PLAYER interface with application
> specific
> > functions (FixEagleNets(), ListNets()), we use KiMail mechanism for
> > simple IPC. I see it had been accepted before, but probably as an
> > overlook. I have already fixed it for netlist read and generate
> methods
> > (9e80eff9), one more on my to-do list is ImportFile().
> >
> > I also noticed that my two stage netlist update does not always
> update
> > timestamps in pcbnew, so there is one more thing I should fix.
> >
> > To sum up: I am going to merge your patch and apply necessary
> > KIWAY_PLAYER interface fixes. There are still two issues to address:
> > - global labels in the Arduino test project
> > - unassigned timestamps in pcbnew (I think for multisheet schematics)
> >
> > Regards,
> > Orson
> >
> > On 02/19/2018 12:31 PM, Russell Oliver wrote:
> >> here are the patches again after the relevant sections being
> > uncrustified.
> >>
> >> Kind Regards
> >> Russell
> >>
> >> On Mon, Feb 19, 2018 at 3:07 AM Wayne Stambaugh <
> stambau...@gmail.com
> 
> >> wrote:
> >>
> >>> This looks a lot more reasonable to me although there may be some
> >>> corner
> >>> cases that we haven't thought about but we can fix those as they
> pop
> >>> up.
> >>>   I'm sure user's reactions to the all global label solution will
> be
> >>> WTF.  At least that was my reaction.  The amount of work to go back
> >>> and
> >>> fix this manually could put off users.
> >>>
> >>> Orson, what are your thoughts on this patch.  I would like your
> input
> >>> before we merge this just in case you see something that I am
> >>> missing.
> >>>
> >>> Russell, if we decide to merge this patch please fix you coding
> >>> policy
> >>> violations.  You are using K curly brace placement.
> 

Re: [Kicad-developers] Improving Eagle Import netlist matching

[Maciej Sumiński]

Hi Russell,

I plan to merge your changes, I have almost finished the refactor to use
KiWay mail. I will test the patches a bit and given no extra issues
appear, I will push them to the master branch.

Regards,
Orson

On 02/25/2018 10:30 PM, Russell Oliver wrote:
> Just wondering what approach we are going to use for v5? Global labels or
> my latest matching algorithm?
> 
> Kind Regards
> Russell
> 
> 
> 
> On 25 Feb 2018 08:43, "Russell Oliver"  wrote:
> 
>> Hi Orson,
>>
>> I looked at the Kicad project from the and I don't see any global labels,
>> just local labels. The PCB will still have the global nets though, since
>> they are created during import of the eagle pcb file.
>> Just to be clear my patches are intended to only generate global labels
>> when necessary, which should only occur when there are multiple sheets in
>> the original Eagle schematic.
>>
>> Russell
>>
>>
>>
>> On Tue, Feb 20, 2018 at 9:55 AM Maciej Suminski 
>> wrote:
>>
>>> Hi Russell,
>>>
>>> On 02/19/2018 08:25 PM, Russell Oliver wrote:
 Hi Orson,

 I wasn't sure about using the KiMail, since I didn't know how immediate
 those calls are processed plus I didn't have the time to implement it
>>> using
 that anyway.
>>>
>>> That is fine, no problem. I realize it takes more time and is a bit
>>> clunky compared to direct function calling, but I can refactor the code
>>> to use KiMail.
>>>
 I'm a bit puzzled by the statement that you are getting global labels
>>> using
 the Arduino project. Can you send me your copy of the project and the
>>> kicad
 files that are generated?
>>>
>>> Sure, this is the official Arduino Mega 2560 rev3 [1]. I uploaded the
>>> import result to my private server [2].
>>>
>>> Best regards,
>>> Orson
>>>
>>> 1. https://www.arduino.cc/en/uploads/Main/arduino-mega2560_R3-
>>> ref-design.zip
>>> 2. https://orson.net.pl/pub/Arduino_MEGA_2560-Rev3.tar.xz
>>>
 Kind Regards
 Russell

 On Tue, Feb 20, 2018 at 2:05 AM Maciej Sumiński <
>>> maciej.sumin...@cern.ch>
 wrote:

> Hi Russell,
>
> I am grateful for your continuous support. I confirm your patch handles
> local net labels and zones in the attached example (orphanzonetest.zip)
> correctly, but I am still getting global labels with the Arduino
>>> project
> mentioned by Wayne. Reverting "Fix netlist mapping for zones and vias"
> is enough to get them back. I will have a look at it soon, but if you
> see an obvious fix, do not hesitate to tell me.
>
> There is at least one thing that needs to be fixed, but I can handle
>>> it.
> One should not extend KIWAY_PLAYER interface with application specific
> functions (FixEagleNets(), ListNets()), we use KiMail mechanism for
> simple IPC. I see it had been accepted before, but probably as an
> overlook. I have already fixed it for netlist read and generate methods
> (9e80eff9), one more on my to-do list is ImportFile().
>
> I also noticed that my two stage netlist update does not always update
> timestamps in pcbnew, so there is one more thing I should fix.
>
> To sum up: I am going to merge your patch and apply necessary
> KIWAY_PLAYER interface fixes. There are still two issues to address:
> - global labels in the Arduino test project
> - unassigned timestamps in pcbnew (I think for multisheet schematics)
>
> Regards,
> Orson
>
> On 02/19/2018 12:31 PM, Russell Oliver wrote:
>> here are the patches again after the relevant sections being
> uncrustified.
>>
>> Kind Regards
>> Russell
>>
>> On Mon, Feb 19, 2018 at 3:07 AM Wayne Stambaugh > wrote:
>>
>>> This looks a lot more reasonable to me although there may be some
>>> corner
>>> cases that we haven't thought about but we can fix those as they pop
>>> up.
>>>   I'm sure user's reactions to the all global label solution will be
>>> WTF.  At least that was my reaction.  The amount of work to go back
>>> and
>>> fix this manually could put off users.
>>>
>>> Orson, what are your thoughts on this patch.  I would like your input
>>> before we merge this just in case you see something that I am
>>> missing.
>>>
>>> Russell, if we decide to merge this patch please fix you coding
>>> policy
>>> violations.  You are using K curly brace placement.
>>>
>>> On 02/18/2018 06:48 AM, Russell Oliver wrote:
 Attached are patches which implement the logic below and a test
>>> eagle
 project to demonstrate the problem.

 This patch set though includes a revert of Orsons patch to use only
 global labels.
 At this point before v5, I'm fine with just using global labels,
>>> but I
 think this patch set works well


 Kind Regards
 Russell



 On 

Re: [Kicad-developers] PPA: KiCad 5.0

[Jean-Samuel Reynaud]

Thanks,

It's currently building doc and i18n. Should be ready in few minutes.

Le 26/02/2018 à 11:13, Nick Østergaard a écrit :
> kicad-doc and kicad-i18n has been tagged
> 
> 2018-02-26 10:53 GMT+01:00 Jean-Samuel Reynaud  >:
> 
> Dear All,
> 
>  Following KiCad 5.0 tagging, I had create a dedicated PPA for next
> release (5.0). For the moment, only RC1 of kicad is built. When other
> repositories will be tagger (i18n, docs and all libs), I will also
> provide them on this PPA.
> 
> It's available at:
> https://launchpad.net/~js-reynaud/+archive/ubuntu/kicad-5
> 
> 
> Daily build are still active and still building "master" branch of KiCad
> as usual.
> 
> Regards,
> 
> ___
> 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] Ensure ROUTER_PREVIEW_ITEM draws on top of all normal layers

[Maciej Sumiński]

Thank you Jon, I have just committed your patch.

Cheers,
Orson

On 02/26/2018 12:18 AM, Jon Evans wrote:
> Fixes: https://bugs.launchpad.net/kicad/+bug/1751646
> 
> 
> 
> ___
> 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
> 




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

Re: [Kicad-developers] [PATCH] expose BOARD_COMMIT to python

[miles mccoo]

So I think I may have discovered something that renders this patch
irrelevant.

I was trying to debug the behavior I mentioned in the first mail of this
thread, where undo via BOARD_COMMIT doesn't work right when running code
from within an external plugin.

Turns out that the external plugin code handles undo, redraw,... for me.
Trying to handle undo twice is what caused my issue.

The funny thing is that I worked on exposing the BOARD_COMMIT stuff as a
prep step to plugin'ifying a bunch of my utilities.



Miles


On Mon, Feb 26, 2018 at 10:23 AM, miles mccoo  wrote:

>
> On whether it's appropriate to expose BOARD_COMMIT to python, the class
> originally came to my attention in this message (though not by a core kicad
> developer?):
> https://lists.launchpad.net/kicad-developers/msg32275.html
>
>
> As a follow on to that suggestion, I started this thread which was
> premised on the idea of exposing BOARD_COMMIT.
> https://lists.launchpad.net/kicad-developers/msg32063.html
>
> Most of the discussion in that thread centers around understanding BC, so
> perhaps it wasn't noticed that exposing BC to python is the point.
>
>
> If it's preferred to omit from python, please advise on a)how to best get
> redraw to work? My last patched improved, but didn't entirely fix redraw.
> b)undo would be nice to have in external plugins. How best to achieve this?
>
>
>
>
>
> On formatting, I looked at it again and I see two errors. In one function,
> I'm missing two leading spaces. On another, I have a curly on the same line
> as the if. (or perhaps the curly shouldn't be there?)
>
> Is there more to it? I'm happy to resubmit but would prefer only one
> iteration (assuming the consensus is that BOARD_COMMIT should be exposed)
>
>
> Miles
>
>
>
>
> for reference:
>  #include 
>  #include 
>  #include 
> +#include 
>
>  static PCB_EDIT_FRAME* s_PcbEditFrame = NULL;
>
> @@ -57,6 +58,10 @@ void ScriptingSetPcbEditFrame( PCB_EDIT_FRAME*
> aPcbEditFrame )
>  s_PcbEditFrame = aPcbEditFrame;
>  }
>
> +PCB_EDIT_FRAME* GetPcbEditFrame()
> +{
> +  return s_PcbEditFrame;
> +}
>
>  BOARD* LoadBoard( wxString& aFileName )
>  {
> @@ -135,3 +140,12 @@ void UpdateUserInterface()
>  if( s_PcbEditFrame )
>  s_PcbEditFrame->UpdateUserInterface();
>  }
> +
> +
> +BOARD_COMMIT*
> +NewBoardCommit()
> +{
> +if( s_PcbEditFrame ) {
> +return new BOARD_COMMIT( s_PcbEditFrame );
> +}
> +}
>
>
>
> On Sat, Feb 24, 2018 at 3:02 PM, Wayne Stambaugh 
> wrote:
>
>> Miles,
>>
>> I'm not opposite to exposing the BOARD_COMMIT object but there are some
>> serious ramifications of doing so.  Although we already expose objects that
>> can crash the board editor from python scripting so I don't know that one
>> more will be all that significant.  Can anyone else think of a reason not
>> to expose the BOARD_COMMIT object to the python scripting? Before I merged
>> your patch I am going to ask you to reformat the c++ code in the
>> pcbnew_scripting_helpers.cpp file.  If you are unsure of the code
>> formating, please take a look at the kicad coding policy[1].
>>
>> Thanks,
>>
>> Wayne
>>
>> [1]: http://docs.kicad-pcb.org/doxygen/md_Documentation_developme
>> nt_coding-style-policy.html
>>
>> On 02/24/2018 05:04 AM, miles mccoo wrote:
>>
>>> Back in November I was in a thread about board_commit:
>>> https://lists.launchpad.net/kicad-developers/msg32063.html
>>>
>>> The topic had come up in another patch:
>>> https://lists.launchpad.net/kicad-developers/msg32134.html
>>>
>>>
>>> See attached path file. added needed code to SWIG to enable using
>>> BOARD_COMMIT
>>>
>>>
>>> As a basic test, I ran the attached commit.py [1] on the attached
>>> commit.kicad_pcb. It just moves some modules and adds some vias. undo seems
>>> to work fine and (perhaps more important) the canvas updates correctly
>>> (there are some bugs in fresh that I haven't figured out)
>>>
>>> I have also updated some of my other scripts to use it and almost all
>>> seems well.
>>> *
>>> *
>>> *The thing that doesn't work...*
>>>
>>>
>>> If I run a script as an external plugin, undoing, brings me back to an
>>> empty canvas. I don't know how to debug that. Some guidance could be
>>> helpful. I don't think this is a problem in the python interface, but
>>> rather some multi-threading thing in BOARD_COMMIT itself.
>>>
>>> Here's a demo of the problem:
>>> https://youtu.be/YR-9dx_lkUo
>>>
>>> place_by_sch described in the video is here:
>>> https://github.com/mmccoo/kicad_mmccoo/blob/master/place_by_
>>> sch/place_by_sch.py
>>>
>>> The board_commit stuff isn't in that version[2]
>>>
>>>
>>> Miles
>>>
>>>
>>> [1] I have a feeling the py file will be filtered, so here it is
>>> toplayer = layertable['F.Cu']
>>> bottomlayer = layertable['B.Cu']
>>> for mod in board.GetModules():
>>>  print("mod {}".format(mod.GetReference()))
>>>  newvia = pcbnew.VIA(board)
>>>  board.Add(newvia)
>>>  newvia.SetNet(gnd)
>>>  nc = 

Re: [Kicad-developers] PPA: KiCad 5.0

[Nick Østergaard]

No, it means that a tag has been made such that build scripts can pass if
they use the tag.

Den 26. feb. 2018 11.16 AM skrev "Maciej Sumiński" :

Does it mean there are no more documentation updates for 5.0
foreseen/accepted?

On 02/26/2018 11:13 AM, Nick Østergaard wrote:
> kicad-doc and kicad-i18n has been tagged
>
> 2018-02-26 10:53 GMT+01:00 Jean-Samuel Reynaud :
>
>> Dear All,
>>
>>  Following KiCad 5.0 tagging, I had create a dedicated PPA for next
>> release (5.0). For the moment, only RC1 of kicad is built. When other
>> repositories will be tagger (i18n, docs and all libs), I will also
>> provide them on this PPA.
>>
>> It's available at:
>> https://launchpad.net/~js-reynaud/+archive/ubuntu/kicad-5
>>
>> Daily build are still active and still building "master" branch of KiCad
>> as usual.
>>
>> Regards,
>>
>> ___
>> 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] PPA: KiCad 5.0

[Maciej Sumiński]

Does it mean there are no more documentation updates for 5.0
foreseen/accepted?

On 02/26/2018 11:13 AM, Nick Østergaard wrote:
> kicad-doc and kicad-i18n has been tagged
> 
> 2018-02-26 10:53 GMT+01:00 Jean-Samuel Reynaud :
> 
>> Dear All,
>>
>>  Following KiCad 5.0 tagging, I had create a dedicated PPA for next
>> release (5.0). For the moment, only RC1 of kicad is built. When other
>> repositories will be tagger (i18n, docs and all libs), I will also
>> provide them on this PPA.
>>
>> It's available at:
>> https://launchpad.net/~js-reynaud/+archive/ubuntu/kicad-5
>>
>> Daily build are still active and still building "master" branch of KiCad
>> as usual.
>>
>> Regards,
>>
>> ___
>> 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
> 




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

Re: [Kicad-developers] PPA: KiCad 5.0

[Nick Østergaard]

kicad-doc and kicad-i18n has been tagged

2018-02-26 10:53 GMT+01:00 Jean-Samuel Reynaud :

> Dear All,
>
>  Following KiCad 5.0 tagging, I had create a dedicated PPA for next
> release (5.0). For the moment, only RC1 of kicad is built. When other
> repositories will be tagger (i18n, docs and all libs), I will also
> provide them on this PPA.
>
> It's available at:
> https://launchpad.net/~js-reynaud/+archive/ubuntu/kicad-5
>
> Daily build are still active and still building "master" branch of KiCad
> as usual.
>
> Regards,
>
> ___
> 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] Don't use the RTREE in UpdateAllLayersOrder() / UpdateAllLayersColor()

[Maciej Sumiński]

Jon,

With this patch applied, any layer switching in pcbnew leads to a crash,
even with no layout loaded. Can anyone else confirm this? See the the
attached address sanitizer report for details.

Regards,
Orson

On 02/25/2018 10:01 PM, Jon Evans wrote:
> This patch uses simple iteration instead of the RTREE search to update the
> layer order and color in VIEW.  On my Linux system, this results in a ~50%
> speedup in release build (less in debug build) and is most noticeable when
> switching layers in GerbView with large Gerber files loaded (i.e. high
> number of items in the view).
> 
> -Jon
> 
> 
> 
> ___
> 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
> 

10:57:55: Warning: Mismatch between the program and library build versions 
detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1011,wx 
containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1002,wx 
containers,compatible with 2.8).
10:57:55: Debug: Adding locale lookup path: /usr/local/share/kicad/internat
10:57:56 AM: Debug: Failed to connect to session manager: SESSION_MANAGER 
environment variable not defined
=
==24147==ERROR: AddressSanitizer: heap-use-after-free on address 0x6040001df714 
at pc 0x7fb608f95423 bp 0x7ffd1f1e92a0 sp 0x7ffd1f1e9298
READ of size 4 at 0x6040001df714 thread T0
#0 0x7fb608f95422 in EDA_ITEM::IsBrightened() const 
/home/orson/workspace/kicad-master/include/base_struct.h:253:47
#1 0x7fb608f825ac in KIGFX::PCB_RENDER_SETTINGS::GetColor(KIGFX::VIEW_ITEM 
const*, int) const 
/home/orson/workspace/kicad-master/pcbnew/pcb_painter.cpp:220:19
#2 0x7fb6094d6c85 in KIGFX::VIEW::UpdateAllLayersColor() 
/home/orson/workspace/kicad-master/common/view/view.cpp:688:61
#3 0x7fb608f632d0 in PCB_DRAW_PANEL_GAL::SetHighContrastLayer(PCB_LAYER_ID) 
/home/orson/workspace/kicad-master/pcbnew/pcb_draw_panel_gal.cpp:237:13
#4 0x7fb60899e73a in PCB_DRAW_PANEL_GAL::SetHighContrastLayer(int) 
/home/orson/workspace/kicad-master/pcbnew/./pcb_draw_panel_gal.h:73:9
#5 0x7fb6086dad06 in PCB_EDIT_FRAME::SetActiveLayer(PCB_LAYER_ID) 
/home/orson/workspace/kicad-master/pcbnew/pcb_edit_frame.cpp:943:25
#6 0x7fb6086cd2b7 in PCB_LAYER_WIDGET::OnLayerSelect(int) 
/home/orson/workspace/kicad-master/pcbnew/pcb_layer_widget.cpp:615:14
#7 0x7fb608631b2c in LAYER_WIDGET::OnLeftDownLayers(wxMouseEvent&) 
/home/orson/workspace/kicad-master/pcbnew/layer_widget.cpp:118:9
#8 0x7fb61c2ded4d in 
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&) (/usr/lib/libwx_baseu-3.0.so.0+0x1efd4d)
#9 0x7fb61c2df16a in wxEvtHandler::SearchDynamicEventTable(wxEvent&) 
(/usr/lib/libwx_baseu-3.0.so.0+0x1f016a)
#10 0x7fb61c2df1ff in wxEvtHandler::TryHereOnly(wxEvent&) 
(/usr/lib/libwx_baseu-3.0.so.0+0x1f01ff)
#11 0x7fb61c2df2b3 in wxEvtHandler::ProcessEventLocally(wxEvent&) 
(/usr/lib/libwx_baseu-3.0.so.0+0x1f02b3)
#12 0x7fb61c2df315 in wxEvtHandler::ProcessEvent(wxEvent&) 
(/usr/lib/libwx_baseu-3.0.so.0+0x1f0315)
#13 0x7fb61c2e04b3 in wxEvtHandler::ProcessPendingEvents() 
(/usr/lib/libwx_baseu-3.0.so.0+0x1f14b3)
#14 0x7fb61c159387 in wxAppConsoleBase::ProcessPendingEvents() 
(/usr/lib/libwx_baseu-3.0.so.0+0x6a387)
#15 0x7fb61ca0557d in wxApp::DoIdle() 
(/usr/lib/libwx_gtk2u_core-3.0.so.0+0x23c57d)
#16 0x7fb61ca056a3  (/usr/lib/libwx_gtk2u_core-3.0.so.0+0x23c6a3)
#17 0x7fb6178bc8c4 in g_main_context_dispatch 
(/usr/lib/libglib-2.0.so.0+0x4a8c4)
#18 0x7fb6178bcc87  (/usr/lib/libglib-2.0.so.0+0x4ac87)
#19 0x7fb6178bcfa1 in g_main_loop_run (/usr/lib/libglib-2.0.so.0+0x4afa1)
#20 0x7fb61896d3a6 in gtk_main (/usr/lib/libgtk-x11-2.0.so.0+0x12e3a6)
#21 0x7fb61ca25865 in wxGUIEventLoop::DoRun() 
(/usr/lib/libwx_gtk2u_core-3.0.so.0+0x25c865)
#22 0x7fb61c194783 in wxEventLoopBase::Run() 
(/usr/lib/libwx_baseu-3.0.so.0+0xa5783)
#23 0x7fb61c15b246 in wxAppConsoleBase::MainLoop() 
(/usr/lib/libwx_baseu-3.0.so.0+0x6c246)
#24 0x55aaecc4ab17 in APP_SINGLE_TOP::OnRun() 
/home/orson/workspace/kicad-master/common/single_top.cpp:165:26
#25 0x7fb61c1e8577 in wxEntry(int&, wchar_t**) 
(/usr/lib/libwx_baseu-3.0.so.0+0xf9577)
#26 0x55aaecc40686 in main 
/home/orson/workspace/kicad-master/common/single_top.cpp:239:1
#27 0x7fb618e9f4c9 in __libc_start_main (/usr/lib/libc.so.6+0x204c9)
#28 0x55aaecb4d6b9 in _start 
(/home/orson/workspace/kicad-master/build_debug_clang/pcbnew/pcbnew+0x836b9)

0x6040001df714 is located 4 bytes inside of 36-byte region 
[0x6040001df710,0x6040001df734)
freed by thread T0 here:
#0 0x55aaecc02ed0 in __interceptor_cfree.localalias.1 
(/home/orson/workspace/kicad-master/build_debug_clang/pcbnew/pcbnew+0x138ed0)
 

[Kicad-developers] PPA: KiCad 5.0

[Jean-Samuel Reynaud]

Dear All,

 Following KiCad 5.0 tagging, I had create a dedicated PPA for next
release (5.0). For the moment, only RC1 of kicad is built. When other
repositories will be tagger (i18n, docs and all libs), I will also
provide them on this PPA.

It's available at:
https://launchpad.net/~js-reynaud/+archive/ubuntu/kicad-5

Daily build are still active and still building "master" branch of KiCad
as usual.

Regards,

___
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] expose BOARD_COMMIT to python

[miles mccoo]

On whether it's appropriate to expose BOARD_COMMIT to python, the class
originally came to my attention in this message (though not by a core kicad
developer?):
https://lists.launchpad.net/kicad-developers/msg32275.html


As a follow on to that suggestion, I started this thread which was premised
on the idea of exposing BOARD_COMMIT.
https://lists.launchpad.net/kicad-developers/msg32063.html

Most of the discussion in that thread centers around understanding BC, so
perhaps it wasn't noticed that exposing BC to python is the point.


If it's preferred to omit from python, please advise on a)how to best get
redraw to work? My last patched improved, but didn't entirely fix redraw.
b)undo would be nice to have in external plugins. How best to achieve this?





On formatting, I looked at it again and I see two errors. In one function,
I'm missing two leading spaces. On another, I have a curly on the same line
as the if. (or perhaps the curly shouldn't be there?)

Is there more to it? I'm happy to resubmit but would prefer only one
iteration (assuming the consensus is that BOARD_COMMIT should be exposed)


Miles




for reference:
 #include 
 #include 
 #include 
+#include 

 static PCB_EDIT_FRAME* s_PcbEditFrame = NULL;

@@ -57,6 +58,10 @@ void ScriptingSetPcbEditFrame( PCB_EDIT_FRAME*
aPcbEditFrame )
 s_PcbEditFrame = aPcbEditFrame;
 }

+PCB_EDIT_FRAME* GetPcbEditFrame()
+{
+  return s_PcbEditFrame;
+}

 BOARD* LoadBoard( wxString& aFileName )
 {
@@ -135,3 +140,12 @@ void UpdateUserInterface()
 if( s_PcbEditFrame )
 s_PcbEditFrame->UpdateUserInterface();
 }
+
+
+BOARD_COMMIT*
+NewBoardCommit()
+{
+if( s_PcbEditFrame ) {
+return new BOARD_COMMIT( s_PcbEditFrame );
+}
+}



On Sat, Feb 24, 2018 at 3:02 PM, Wayne Stambaugh 
wrote:

> Miles,
>
> I'm not opposite to exposing the BOARD_COMMIT object but there are some
> serious ramifications of doing so.  Although we already expose objects that
> can crash the board editor from python scripting so I don't know that one
> more will be all that significant.  Can anyone else think of a reason not
> to expose the BOARD_COMMIT object to the python scripting? Before I merged
> your patch I am going to ask you to reformat the c++ code in the
> pcbnew_scripting_helpers.cpp file.  If you are unsure of the code
> formating, please take a look at the kicad coding policy[1].
>
> Thanks,
>
> Wayne
>
> [1]: http://docs.kicad-pcb.org/doxygen/md_Documentation_developme
> nt_coding-style-policy.html
>
> On 02/24/2018 05:04 AM, miles mccoo wrote:
>
>> Back in November I was in a thread about board_commit:
>> https://lists.launchpad.net/kicad-developers/msg32063.html
>>
>> The topic had come up in another patch:
>> https://lists.launchpad.net/kicad-developers/msg32134.html
>>
>>
>> See attached path file. added needed code to SWIG to enable using
>> BOARD_COMMIT
>>
>>
>> As a basic test, I ran the attached commit.py [1] on the attached
>> commit.kicad_pcb. It just moves some modules and adds some vias. undo seems
>> to work fine and (perhaps more important) the canvas updates correctly
>> (there are some bugs in fresh that I haven't figured out)
>>
>> I have also updated some of my other scripts to use it and almost all
>> seems well.
>> *
>> *
>> *The thing that doesn't work...*
>>
>>
>> If I run a script as an external plugin, undoing, brings me back to an
>> empty canvas. I don't know how to debug that. Some guidance could be
>> helpful. I don't think this is a problem in the python interface, but
>> rather some multi-threading thing in BOARD_COMMIT itself.
>>
>> Here's a demo of the problem:
>> https://youtu.be/YR-9dx_lkUo
>>
>> place_by_sch described in the video is here:
>> https://github.com/mmccoo/kicad_mmccoo/blob/master/place_by_
>> sch/place_by_sch.py
>>
>> The board_commit stuff isn't in that version[2]
>>
>>
>> Miles
>>
>>
>> [1] I have a feeling the py file will be filtered, so here it is
>> toplayer = layertable['F.Cu']
>> bottomlayer = layertable['B.Cu']
>> for mod in board.GetModules():
>>  print("mod {}".format(mod.GetReference()))
>>  newvia = pcbnew.VIA(board)
>>  board.Add(newvia)
>>  newvia.SetNet(gnd)
>>  nc = gnd.GetNetClass()
>>  newvia.SetWidth(nc.GetViaDiameter())
>>  newvia.SetPosition(mod.GetPosition())
>>  newvia.SetLayerPair(toplayer, bottomlayer)
>>  newvia.SetViaType(pcbnew.VIA_THROUGH)
>>  bc.Added(newvia)
>>  bc.Modify(mod)
>>  mod.SetPosition(pcbnew.wxPoint(mod.GetPosition().x +
>> pcbnew.Millimeter2iu(10),
>> mod.GetPosition().y +
>> pcbnew.Millimeter2iu(10)))
>>
>>
>> bc.Push("moved stuff")
>>
>>
>> [2]
>> diff --git a/place_by_sch/place_by_sch.py b/place_by_sch/place_by_sch.py
>> index 22bc21c..5f70354 100644
>> --- a/place_by_sch/place_by_sch.py
>> +++ b/place_by_sch/place_by_sch.py
>> @@ -7,7 +7,9 @@ import re
>>   def PlaceBySch():
>>   board = pcbnew.GetBoard()
>> -
>> +print("getting board