[Kicad-developers] [PATCH] Rearrange Render panel of PcbNew layer widget; add spacers

[Jon Evans]

Hi all,

This patch rearranges the Render panel to be in a more logical order, and
adds some whitespace.
I divided it into three groupings:
1) footprint related
2) other board objects
3) non-board stuff like grid, ratlines, etc.

I also bumped out the default size so that scrollbars aren't needed by
default on my Linux system.

-Jon
From f7aedd67a9dc51a312106c5232a7803b1cfddd23 Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Wed, 21 Feb 2018 23:39:14 -0500
Subject: [PATCH] Rearrange Render panel of PcbNew layer widget; add spacers

---
 pcbnew/layer_widget.cpp | 35 ---
 pcbnew/layer_widget.h   |  8 
 pcbnew/pcb_layer_widget.cpp | 32 +---
 3 files changed, 49 insertions(+), 26 deletions(-)

diff --git a/pcbnew/layer_widget.cpp b/pcbnew/layer_widget.cpp
index 87acce504..404b6bf2a 100644
--- a/pcbnew/layer_widget.cpp
+++ b/pcbnew/layer_widget.cpp
@@ -385,16 +385,20 @@ void LAYER_WIDGET::insertRenderRow( int aRow, const ROW& aSpec )
 const int   flags = wxALIGN_CENTER_VERTICAL | wxALIGN_LEFT;
 
 wxString renderName( aSpec.rowName );
+wxCheckBox* cb = nullptr;
 
 // column 1
-col = 1;
-wxCheckBox* cb = new wxCheckBox( m_RenderScrolledWindow, encodeId( col, aSpec.id ),
-aSpec.rowName, wxDefaultPosition, wxDefaultSize, wxALIGN_LEFT );
-shrinkFont( cb, m_PointSize );
-cb->SetValue( aSpec.state );
-cb->Enable( aSpec.changeable );
-cb->Bind( wxEVT_COMMAND_CHECKBOX_CLICKED, _WIDGET::OnRenderCheckBox, this );
-cb->SetToolTip( aSpec.tooltip );
+if( !aSpec.spacer )
+{
+col = 1;
+cb = new wxCheckBox( m_RenderScrolledWindow, encodeId( col, aSpec.id ),
+aSpec.rowName, wxDefaultPosition, wxDefaultSize, wxALIGN_LEFT );
+shrinkFont( cb, m_PointSize );
+cb->SetValue( aSpec.state );
+cb->Enable( aSpec.changeable );
+cb->Bind( wxEVT_COMMAND_CHECKBOX_CLICKED, _WIDGET::OnRenderCheckBox, this );
+cb->SetToolTip( aSpec.tooltip );
+}
 
 // column 0
 col = 0;
@@ -424,7 +428,16 @@ void LAYER_WIDGET::insertRenderRow( int aRow, const ROW& aSpec )
 
 // Items have to be inserted in order
 col = 1;
-m_RenderFlexGridSizer->wxSizer::Insert( index+col, cb, 0, flags );
+
+if( aSpec.spacer )
+{
+wxPanel* invisible = new wxPanel( m_RenderScrolledWindow, wxID_ANY );
+m_RenderFlexGridSizer->wxSizer::Insert( index+col, invisible, 0, flags );
+}
+else
+{
+m_RenderFlexGridSizer->wxSizer::Insert( index+col, cb, 0, flags );
+}
 }
 
 
@@ -539,7 +552,7 @@ wxSize LAYER_WIDGET::GetBestSize() const
 }
 
 // Account for the parent's frame:
-totWidth += 10;
+totWidth += 32;
 
 
 /* The minimum height is a small size to properly force computation
@@ -565,7 +578,7 @@ wxSize LAYER_WIDGET::GetBestSize() const
 }
 }
 // account for the parent's frame, this one has void space of 10 PLUS a border:
-totWidth += 20;
+totWidth += 32;
 
 // For totHeight re-use the previous small one
 wxSize renderz( totWidth, totHeight );
diff --git a/pcbnew/layer_widget.h b/pcbnew/layer_widget.h
index d1fe0e76b..e76a710b4 100644
--- a/pcbnew/layer_widget.h
+++ b/pcbnew/layer_widget.h
@@ -90,6 +90,7 @@ public:
 boolstate;  ///< initial wxCheckBox state
 wxStringtooltip;///< if not empty, use this tooltip on row
 boolchangeable; ///< if true, the state can be changed
+boolspacer; ///< if true, this row is a spacer
 
 ROW( const wxString& aRowName, int aId, COLOR4D aColor = COLOR4D::UNSPECIFIED,
 const wxString& aTooltip = wxEmptyString, bool aState = true, bool aChangeable = true )
@@ -101,6 +102,13 @@ public:
 tooltip = aTooltip;
 changeable = aChangeable;
 }
+
+ROW()
+{
+spacer = true;
+color = COLOR4D::UNSPECIFIED;
+id = 0;
+}
 };
 
 static const wxEventType EVT_LAYER_COLOR_CHANGE;
diff --git a/pcbnew/pcb_layer_widget.cpp b/pcbnew/pcb_layer_widget.cpp
index a2a184b65..3d0f746c5 100644
--- a/pcbnew/pcb_layer_widget.cpp
+++ b/pcbnew/pcb_layer_widget.cpp
@@ -60,31 +60,30 @@ const LAYER_WIDGET::ROW PCB_LAYER_WIDGET::s_render_rows[] = {
 #define NOCOLOR COLOR4D::UNSPECIFIED// specify rows that do not have a color selector icon
 
  // textid  color   tooltip
+RR( _( "Footprints Front" ),LAYER_MOD_FR, NOCOLOR,  _( "Show footprints that are on board's front") ),
+RR( _( "Footprints Back" ), LAYER_MOD_BK, NOCOLOR,  _( "Show footprints that are on board's back") ),
+RR( _( "Values" ),  LAYER_MOD_VALUES, NOCOLOR,  _( "Show footprint values") ),
+RR( _( "References" ),  LAYER_MOD_REFERENCES, NOCOLOR,  _( "Show footprint references") ),

[Kicad-developers] [PATCH] Don't recache items unnecessarily when toggling D-code display

[Jon Evans]

Hi all,

This patch improves the logic for d-code display in GerbView so that there
is now no cost in toggling the codes on or off.  They are still slow to
render in huge files, but at least we only have the hit once when the file
first is loaded.

-Jon
From 1d670987a0a40e0fe339b60ec33546bbcf737a79 Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Wed, 21 Feb 2018 23:08:59 -0500
Subject: [PATCH 1/2] Don't recache items unnecessarily when toggling D-code
 display

---
 gerbview/gerbview_frame.cpp   | 20 ++--
 gerbview/gerbview_painter.cpp |  5 +
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/gerbview/gerbview_frame.cpp b/gerbview/gerbview_frame.cpp
index 6a4dd1107..72252108a 100644
--- a/gerbview/gerbview_frame.cpp
+++ b/gerbview/gerbview_frame.cpp
@@ -488,9 +488,12 @@ void GERBVIEW_FRAME::ReFillLayerWidget()
 void GERBVIEW_FRAME::SetElementVisibility( GERBVIEW_LAYER_ID aItemIdVisible,
bool aNewState )
 {
+bool dcodes_changed = false;
+
 switch( aItemIdVisible )
 {
 case LAYER_DCODES:
+dcodes_changed = m_DisplayOptions.m_DisplayDCodes != aNewState;
 m_DisplayOptions.m_DisplayDCodes = aNewState;
 break;
 
@@ -506,6 +509,19 @@ void GERBVIEW_FRAME::SetElementVisibility( GERBVIEW_LAYER_ID aItemIdVisible,
 wxLogDebug( wxT( "GERBVIEW_FRAME::SetElementVisibility(): bad arg %d" ), aItemIdVisible );
 }
 
+if( dcodes_changed )
+{
+auto view = GetGalCanvas()->GetView();
+
+for( int i = 0; i < GERBER_DRAWLAYERS_COUNT; i++ )
+{
+int layer = GERBER_DRAW_LAYER( i );
+int dcode_layer = GERBER_DCODE_LAYER( layer );
+view->SetLayerVisible( dcode_layer,
+   aNewState && view->IsLayerVisible( layer ) );
+}
+}
+
 applyDisplaySettingsToGAL();
 m_LayersManager->SetRenderState( aItemIdVisible, aNewState );
 }
@@ -520,7 +536,6 @@ void GERBVIEW_FRAME::applyDisplaySettingsToGAL()
 
 settings->ImportLegacyColors( m_colorsSettings );
 
-view->RecacheAllItems();
 view->MarkTargetDirty( KIGFX::TARGET_NONCACHED );
 }
 
@@ -756,7 +771,8 @@ void GERBVIEW_FRAME::SetVisibleLayers( long aLayerMask )
 bool v = ( aLayerMask & ( 1 << i ) );
 int layer = GERBER_DRAW_LAYER( i );
 canvas->GetView()->SetLayerVisible( layer, v );
-canvas->GetView()->SetLayerVisible( GERBER_DCODE_LAYER( layer ), v );
+canvas->GetView()->SetLayerVisible( GERBER_DCODE_LAYER( layer ),
+m_DisplayOptions.m_DisplayDCodes && v );
 }
 }
 }
diff --git a/gerbview/gerbview_painter.cpp b/gerbview/gerbview_painter.cpp
index 486c90a66..ada045a9f 100644
--- a/gerbview/gerbview_painter.cpp
+++ b/gerbview/gerbview_painter.cpp
@@ -189,12 +189,9 @@ void GERBVIEW_PAINTER::draw( /*const*/ GERBER_DRAW_ITEM* aItem, int aLayer )
 // TODO(JE) This doesn't actually work properly for ImageNegative
 bool isNegative = ( aItem->GetLayerPolarity() ^ aItem->m_GerberImageFile->m_ImageNegative );
 
-// Draw DCODEs if enabled
+// Draw DCODE overlay text
 if( IsDCodeLayer( aLayer ) )
 {
-if( !m_gerbviewSettings.m_showCodes )
-return;
-
 wxString codeText;
 VECTOR2D textPosition;
 double textSize;
-- 
2.14.1

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

Re: [Kicad-developers] [PATCH] Use polygonal hit testing for module selection

[Jon Evans]

Here's a patch that fixes the issues observed.
I have changed the algorithm to a simpler one that should be more
bulletproof.
I think the optimal approach for complicated footprints is still not this
way, but that would require more time to tweak and optimize (i.e.
generating some kind of bounding hull that is non-convex, and caching it
until the shape changes)

You can see the new patch on Andrzej's test files here:
https://imgur.com/a/L16ky
Purple shows the bounding boxes, yellow shows the selectable area under the
new algorithm.
​
-Jon

On Wed, Feb 21, 2018 at 1:41 PM, Wayne Stambaugh 
wrote:

> If you could get it done by Friday before I roll out rc1, that's fine.
>
> Wayne
>
> On 2/21/2018 1:37 PM, Jon Evans wrote:
> > I'll be able to look at it this evening.  Can report then whether or not
> > I will have a patch tonight.  Up to you whether or not that is too long
> > of a delay.
> >
> > -Jon
> >
> > On Wed, Feb 21, 2018 at 1:32 PM, Wayne Stambaugh  > > wrote:
> >
> > Jon,
> >
> > Would you please take a look at this as soon as possible?  If you
> cannot
> > get to it in a reasonable amount of time, please let me know so I can
> > back out your polygon hit test patch.  We need to be able to select
> > footprints.
> >
> > Thanks,
> >
> > Wayne
> >
> > On 2/21/2018 11:41 AM, Andrzej Wolski wrote:
> > > After this patch, I can no longer select some footprints by
> clicking
> > > inside their area.
> > > Please see the board in an attachment.
> > >
> > > Andrzej
> > >
> > > W dniu 2018-02-20 o 16:44, Wayne Stambaugh pisze:
> > >> Jon,
> > >>
> > >> I merged your patch.
> > >>
> > >> Thanks,
> > >>
> > >> Wayne
> > >>
> > >> On 2/18/2018 7:01 PM, Jon Evans wrote:
> > >>> Hi Wayne,
> > >>>
> > >>> In my testing there is no performance impact, but more testing is
> > >>> welcome.  It shouldn't be doing the calculation on too many
> > objects in
> > >>> general, since this is a "second pass" hit test that applies to
> > modules
> > >>> that have a bounding box overlapping the mouse cursor.
> > >>> However, I did some more testing and discovered some weird
> > behavior, so
> > >>> I have tweaked the algorithm in the attached new version of the
> > patch.
> > >>>
> > >>> -Jon
> > >>>
> > >>> On Sun, Feb 18, 2018 at 5:25 PM, Wayne Stambaugh
> > 
> > >>> >>
> wrote:
> > >>>
> > >>>  Hey Jon,
> > >>>
> > >>>  Did you notice an performance hit with your patch?
> > Obviously there
> > >>>  is going to be more overhead calculating a polygon versus a
> > >>>  rectangle.  I just want to be sure we are not causing any
> > usability
> > >>>  issues due to the polygon calculations.
> > >>>
> > >>>  Thanks,
> > >>>
> > >>>  Wayne
> > >>>
> > >>>
> > >>>  On 02/18/2018 12:10 PM, Jon Evans wrote:
> > >>>
> > >>>  Hi all,
> > >>>
> > >>>  The attached patch adds some plumbing to calculate and
> > make use
> > >>>  of a polygonal bounding area for modules.  It fixes the
> > below
> > >>>  issue and in general improves the accuracy of selection
> > in my
> > >>>  testing.
> > >>>
> > >>>  This mechanism could be extended to other objects
> besides
> > >>>  modules if it's useful.  I figured I'd start by sending
> out
> > >>> this
> > >>>  patch to get feedback, and if it gets merged, look for
> > other
> > >>>  areas where we could improve things by using polygons
> > >>> instead of
> > >>>  bounding boxes.
> > >>>
> > >>>  https://bugs.launchpad.net/kicad/+bug/1749077
> > 
> > >>>   > >
> > >>>
> > >>>  -Jon
> > >>>
> > >>>
> > >>>  ___
> > >>>  Mailing list: https://launchpad.net/~kicad-developers
> > 
> > >>>   > >
> > >>>  Post to : kicad-developers@lists.launchpad.net
> > 
> > >>>   > >
> > >>>  Unsubscribe : https://launchpad.net/~kicad-developers
> > 
> > >>>  

Re: [Kicad-developers] IPC-2581

[Ouabache Designworks]

On Wed, Feb 21, 2018 at 3:37 PM, Wayne Stambaugh 
wrote:

> I'm not opposed to KiCad taking part in this it's just a simple matter
> of lack of time.  If someone else is interested in representing KiCad at
> these meetings, I would not be opposed to that it's just not going to be
> me.  I am completely out of free time to do any more than my current
> work load.
>
> Cheers,
>
> Wayne
>
>

Well I'm retired and have plenty of time on my hands so I will join as an
individual and keep this group up
to date with what you would have to do if you wanted to advertise
compliance. I will not be an "official" representative
for Kicad and will not make any claims that would commit this group to do
anything  to comply with the standard. You
will need to make that decision for your self

I have also been working with the IEEE-1685 IP-Xact folks and will keep you
informed on how that standard can help you.



John Eaton
___
Mailing list: https://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] IPC-2581

[Wayne Stambaugh]

I'm not opposed to KiCad taking part in this it's just a simple matter
of lack of time.  If someone else is interested in representing KiCad at
these meetings, I would not be opposed to that it's just not going to be
me.  I am completely out of free time to do any more than my current
work load.

Cheers,

Wayne

On 02/21/2018 12:44 PM, Ouabache Designworks wrote:
> This might be a good time to discuss industry standards and how they are
> currently undergoing a massive change that the Kicad team could help  with.
> 
> 
> 
> Standards have in the past been created by large formal organizations
> like the IEEE for the entire industry.They were written in a very strict
> and formal language
> and had to be complete and unambiguous. They were written by
> professionals who did that for a living.
> 
> If there was a error or omission in a standard then correcting it,
> getting all the reviews and approvals, re-releasing a revised standard,
> changing all the EDA tools
> using it and getting the end user to change all of their accumulated IP
> could easily take 10 years.
> 
> The verilog standard was revised in 1995 to allow for port creation in
> one line instead of two. It was 2005 before the design team that I was
> on allowed us to use
>  the new standard in our coding. It took us that long  to prove that all
> of our tools were correct and we could trust our tool flow with
> production code.
> 
> 
> I'm sorry IEEE but I have a problem and I need a a working solution by
> Friday. You are fired. You can no longer control the standards that I use.
> 
> This has already happened. Nobody goes to the verilog standard for
> answers about the language. The official solution is to write a test
> case and run it under verilogXL
>  to see what it does. EDA  tool smiths are no longer implementing
> standards, they are creating them. Gerber created the PCB standard.
> Kicad 5 will create its own standard
> and all the standard committee can do is to document it.
> 
> 
> We need to work with these groups not to ask them what we should support
> but to tell them what we are doing and let them follow us. We can also
> pick up some good ideas as
> to what other groups are doing.
> 
> We don't argue in a committee but rather release everything and let the
> market decide. Open source can win in that arena. If we get it wrong
> then theres always the next revision.
> 
> 
> So what can the Kicad team do? If any new release breaks designs created
> under the old release then provide tools and instructions for converting
> the end users IP to run under the new release.
>  Otherwise its a huge mess. Icarus verilog did a new release for version
> 10 that fixed an "off-by-one" error in its LOG function. Now its a
> complete mess because old code has to be rewritten before
>  it can be used with any new code. When you make a change you must also
> come up with a plan for all the old IP. Make it easy for the end user to
> use your tool.
> 
> 
> 
> John Eaton
> 
> 
> 
> 
> ___
> Mailing list: https://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] Use polygonal hit testing for module selection

[Jon Evans]

I'll be able to look at it this evening.  Can report then whether or not I
will have a patch tonight.  Up to you whether or not that is too long of a
delay.

-Jon

On Wed, Feb 21, 2018 at 1:32 PM, Wayne Stambaugh 
wrote:

> Jon,
>
> Would you please take a look at this as soon as possible?  If you cannot
> get to it in a reasonable amount of time, please let me know so I can
> back out your polygon hit test patch.  We need to be able to select
> footprints.
>
> Thanks,
>
> Wayne
>
> On 2/21/2018 11:41 AM, Andrzej Wolski wrote:
> > After this patch, I can no longer select some footprints by clicking
> > inside their area.
> > Please see the board in an attachment.
> >
> > Andrzej
> >
> > W dniu 2018-02-20 o 16:44, Wayne Stambaugh pisze:
> >> Jon,
> >>
> >> I merged your patch.
> >>
> >> Thanks,
> >>
> >> Wayne
> >>
> >> On 2/18/2018 7:01 PM, Jon Evans wrote:
> >>> Hi Wayne,
> >>>
> >>> In my testing there is no performance impact, but more testing is
> >>> welcome.  It shouldn't be doing the calculation on too many objects in
> >>> general, since this is a "second pass" hit test that applies to modules
> >>> that have a bounding box overlapping the mouse cursor.
> >>> However, I did some more testing and discovered some weird behavior, so
> >>> I have tweaked the algorithm in the attached new version of the patch.
> >>>
> >>> -Jon
> >>>
> >>> On Sun, Feb 18, 2018 at 5:25 PM, Wayne Stambaugh  >>> > wrote:
> >>>
> >>>  Hey Jon,
> >>>
> >>>  Did you notice an performance hit with your patch?  Obviously
> there
> >>>  is going to be more overhead calculating a polygon versus a
> >>>  rectangle.  I just want to be sure we are not causing any
> usability
> >>>  issues due to the polygon calculations.
> >>>
> >>>  Thanks,
> >>>
> >>>  Wayne
> >>>
> >>>
> >>>  On 02/18/2018 12:10 PM, Jon Evans wrote:
> >>>
> >>>  Hi all,
> >>>
> >>>  The attached patch adds some plumbing to calculate and make
> use
> >>>  of a polygonal bounding area for modules.  It fixes the below
> >>>  issue and in general improves the accuracy of selection in my
> >>>  testing.
> >>>
> >>>  This mechanism could be extended to other objects besides
> >>>  modules if it's useful.  I figured I'd start by sending out
> >>> this
> >>>  patch to get feedback, and if it gets merged, look for other
> >>>  areas where we could improve things by using polygons
> >>> instead of
> >>>  bounding boxes.
> >>>
> >>>  https://bugs.launchpad.net/kicad/+bug/1749077
> >>>  
> >>>
> >>>  -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] [PATCH] Add progress reporting for GerbView file loading

[Wayne Stambaugh]

Patch merged.  Thanks!

On 2/20/2018 10:21 PM, Jon Evans wrote:
> Hi all,
> 
> This patch adds the progress reporter dialog to GerbView file loading,
> when loading multiple files and the total load time goes over 1 second. 
> I've also done some refactoring to share code between loading multiple
> files via a gerber job file and via the regular open dialog.
> 
> -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

Re: [Kicad-developers] [RFC] Change to object visibility system for usability/clarity

[Wayne Stambaugh]

Andrzej,

I merged your patches.  Hopefully this will tamp down some of the layer
visibility complaints.  Thank you for your contribution to KiCad.

Cheers,

Wayne

On 2/21/2018 12:44 PM, Andrzej Wolski wrote:
> Wayne,
> 
> in attachment all 3 patches I have, rebased.
> 
> Cheers,
> Andrzej
> 
> 
> On 02/21/2018 05:45 PM, Wayne Stambaugh wrote:
>> Andrzej,
>>
>> This patch does not apply cleanly.  Please rebase and resubmit it when
>> you get a chance.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 2/21/2018 11:27 AM, Andrzej Wolski wrote:
>>> Wayne,
>>>
>>> I have attached that patch to bug report whom which you messaged me,
>>> thought you will see it.
>>>
>>> I'm attaching it again in this email.
>>>
>>> Cheers,
>>> Andrzej
>>>
>>>
>>> On 02/21/2018 05:20 PM, Wayne Stambaugh wrote:
 Andrzej,

 You have not replied to my last message about your original patch that
 you sent to the developers mailing list[1].  I need that one so I can
 apply and test the rest of your layer visibility patches.  If you want
 these to make it into rc1, please send me this patch as an attachment
 soon.  I am planning to branch rc1 by Friday at the latest.

 Cheers,

 Wayne


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

 On 2/19/2018 10:05 AM, Andrzej Wolski wrote:
> Patch (in attachment) for "Tracks" turned out to be very simple.
> If it gets accepted, I could make more of these.
>
> Andrzej
>
>
> On 02/19/2018 02:12 PM, Andrzej Wolski wrote:
>> It would be also nice to have separate controls for:
>> 1. Tracks
>> 2. Drawing primitives (graphic lines, arcs, and circles)
>> 3. Zones
>> 4. Polygons
>> 5. Text (now there is control only for footprint text)
>> 6. Dimensions
>> 7. Plated holes
>>
>> That would make Render tab (almost) complete.
>>
>> Andrzej
>>
>> W dniu 2018-02-18 o 21:00, Jon Evans pisze:
>>> Hi all,
>>>
>>> Right now the behavior of the "Layer" and "Render" tabs of the
>>> layers
>>> widget are confusing to users, resulting in complaints on the forum
>>> and some bug reports:
>>>
>>> https://bugs.launchpad.net/kicad/+bug/1748181
>>> https://bugs.launchpad.net/kicad/+bug/1743890
>>>
>>> I could take a crack at fixing this (before or after 5.0
>>> depending on
>>> what the complexity ends up being) but before I write any code I
>>> wanted to propose how I think it should work.
>>>
>>> I think the visibility of any object should be the AND of layer
>>> visibility and render visibility.
>>>
>>> To get there:
>>>
>>> 1) In the Render tab, get rid of the distinction between front/back.
>>> For example "Pads Back" and "Pads Front" becomes just "Pads"
>>>
>>> 2) Change the visibility code so that an object is visible if (a)
>>> the
>>> associated Render setting is turned on for the type of object, and
>>> (b) at least one of the layers the object is on is enabled in the
>>> Layers tab.
>>>
>>> 3) (optionally) Rename "Render" to something more friendly like
>>> "Items" or "Item Types" to make it more clear to the user that this
>>> is where they can turn off the display of various types of items as
>>> opposed to various layerse
>>>
>>> If this plan is OK, I will start working out the details of how to
>>> get there.  Right now the Render tab is directly controlling the
>>> visibility of certain "GAL Layers" but unfortunately the set of
>>> objects that appears on one GAL layer is not always equal to the set
>>> of objects that the user would expect to turn on and off, as seen by
>>> the bug reports.  So, there will have to be some additional logic
>>> created to manage these settings beyond just turning on and off
>>> layers in the GAL.
>>>
>>> -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 

Re: [Kicad-developers] [PATCH] Use polygonal hit testing for module selection

[Wayne Stambaugh]

Jon,

Would you please take a look at this as soon as possible?  If you cannot
get to it in a reasonable amount of time, please let me know so I can
back out your polygon hit test patch.  We need to be able to select
footprints.

Thanks,

Wayne

On 2/21/2018 11:41 AM, Andrzej Wolski wrote:
> After this patch, I can no longer select some footprints by clicking
> inside their area.
> Please see the board in an attachment.
> 
> Andrzej
> 
> W dniu 2018-02-20 o 16:44, Wayne Stambaugh pisze:
>> Jon,
>>
>> I merged your patch.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 2/18/2018 7:01 PM, Jon Evans wrote:
>>> Hi Wayne,
>>>
>>> In my testing there is no performance impact, but more testing is
>>> welcome.  It shouldn't be doing the calculation on too many objects in
>>> general, since this is a "second pass" hit test that applies to modules
>>> that have a bounding box overlapping the mouse cursor.
>>> However, I did some more testing and discovered some weird behavior, so
>>> I have tweaked the algorithm in the attached new version of the patch.
>>>
>>> -Jon
>>>
>>> On Sun, Feb 18, 2018 at 5:25 PM, Wayne Stambaugh >> > wrote:
>>>
>>>  Hey Jon,
>>>
>>>  Did you notice an performance hit with your patch?  Obviously there
>>>  is going to be more overhead calculating a polygon versus a
>>>  rectangle.  I just want to be sure we are not causing any usability
>>>  issues due to the polygon calculations.
>>>
>>>  Thanks,
>>>
>>>  Wayne
>>>
>>>
>>>  On 02/18/2018 12:10 PM, Jon Evans wrote:
>>>
>>>  Hi all,
>>>
>>>  The attached patch adds some plumbing to calculate and make use
>>>  of a polygonal bounding area for modules.  It fixes the below
>>>  issue and in general improves the accuracy of selection in my
>>>  testing.
>>>
>>>  This mechanism could be extended to other objects besides
>>>  modules if it's useful.  I figured I'd start by sending out
>>> this
>>>  patch to get feedback, and if it gets merged, look for other
>>>  areas where we could improve things by using polygons
>>> instead of
>>>  bounding boxes.
>>>
>>>  https://bugs.launchpad.net/kicad/+bug/1749077
>>>  
>>>
>>>  -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] [PATCH] Pcbnew menu bar

[Bernhard Stegmaier]

I can’t tell, I didn’t look for that bug.
I didn’t follow the restructuring on the ML.
My comment was just about the “Preferences” menu entry in KiCad menu.
I did search it for some time before the restructuring and wondered a bit that 
it still like that after.

> On 21. Feb 2018, at 19:13, Michael Kavanagh  
> wrote:
> 
> Bernhard, do you mean this bug [1] existed before the 3b085f0 "Pcbnew new 
> menubar structure" commit?
> 
> [1] https://bugs.launchpad.net/kicad/+bug/1750494 
> 
> 
> On 21 February 2018 at 13:07, Bernhard Stegmaier  > wrote:
> > Hi,
> >
> > Just to mention… it has been like this before the patches.
> > At least on macOS, there is still a “Preferences” menu entry below the
> > “KiCad” menu bar entry (the “General Settings” dialog).
> > Then, there is the “Preferences” menu… without those “General Setting”.
> >
> > Because there is a “Preferences” menu bar entry I didn’t look anywhere else
> > for the general settings.
> > Took me quite a while to find them in the “KiCad” menu bar entry.
> >
> > Any plans to change this?
> >
> >
> > Regards,
> > Bernhard
> >
> > On 20. Feb 2018, at 08:17, Nick Østergaard  > > wrote:
> >
> > Hello Michael and Jeff,
> >
> > It seems like we got our first small regression from this patch series.
> > Could you have a look. Please note it looks like it is window manager
> > dependent.
> > https://bugs.launchpad.net/kicad/+bug/1750494 
> > 
> >
> > Nick
> >
> > 2018-02-18 23:03 GMT+01:00 Wayne Stambaugh  > >:
> >>
> >> Indeed I did forget.  Thanks for the reminder.  Thank you Jeff for the
> >> patches.
> >>
> >>
> >> On 02/18/2018 03:02 PM, Michael Kavanagh wrote:
> >>>
> >>> Thanks Wayne. Please don't forget to merge Jeffs dialog changes which
> >>> complete the Pcbnew menubar modifications. I have reattached them to
> >>> this email for convenience.
> >>>
> >>> Cheers,
> >>> Michael
> >>>
> >>> On 18 February 2018 at 19:16, Wayne Stambaugh  >>> >
> >>> wrote:
> 
>  Michael,
> 
>  I figured out why we are not using IS_ACCELERATOR for these menu
>  entries.
>  AddHotkeyName() adds a "+Alt+" to the hotkey so this is *not* what we
>  want
>  so I used the original 0003 patch.  I apologize for the confusion.  I
>  merged
>  this and you 0004 patch.  We can make any tweaks to it if it's not
>  exactly
>  what we want.  Thank you for your contribution to KiCad.
> 
>  Cheers,
> 
>  Wayne
> 
> 
>  On 02/18/2018 10:10 AM, Michael Kavanagh wrote:
> >
> >
> > In every other app New, Open, Save, Save As and Print are standard
> > hotkeys and not accelerators. They don't have the modifier key, so are
> > the "standard" keyboard shortcuts.
> >
> > Nevertheless, please find attached new patches for review. These
> > accompany both of Jeffs dialog patches. Hopefully I didn't break
> > anything, implementing the sketch modes removed from the dialogs
> > involved fiddling with the GAL tools framework.
> >
> > Cheers,
> > Michael
> >
> > On 17 February 2018 at 17:27, Wayne Stambaugh  > >
> > wrote:
> >>
> >>
> >> It should be.  We really need to get out of the bad habit of having
> >> toolbar only access to tools and settings.  I'm sure there are some in
> >> the schematic editor, symbol editor, and footprint editor as well.
> >>
> >> On 02/17/2018 06:16 AM, Jeff Young wrote:
> >>>
> >>>
> >>> The Fill/Outline stuff is included.  Not sure about High Contrast
> >>> mode,
> >>> but it probably should be.
> >>>
>  On 17 Feb 2018, at 06:58, Gaurav Juvekar   >
>  wrote:
> 
>  Hi all,
> 
>  Probably not too relevant, but can we have a workaround of
>  https://bugs.launchpad.net/kicad/+bug/1575097 
>   (hidden icons) by
>  adding
>  View -> High Contrast (Checkable like the "Flip board view")
>  View -> Tracks -> Outline (Radio button like the canvas selector)
>  -> Fill
>  View -> Vias   -> Outline
>  -> Fill
>  View -> Pads   -> Outline
>  -> Fill
> 
>  to the menu entries?
> 
>  --
>  Regards,
>  Gaurav Juvekar
> 
>  ___
>  Mailing list: https://launchpad.net/~kicad-developers 
>  

Re: [Kicad-developers] [PATCH] Use polygonal hit testing for module selection

[Wayne Stambaugh]

If you could get it done by Friday before I roll out rc1, that's fine.

Wayne

On 2/21/2018 1:37 PM, Jon Evans wrote:
> I'll be able to look at it this evening.  Can report then whether or not
> I will have a patch tonight.  Up to you whether or not that is too long
> of a delay.
> 
> -Jon
> 
> On Wed, Feb 21, 2018 at 1:32 PM, Wayne Stambaugh  > wrote:
> 
> Jon,
> 
> Would you please take a look at this as soon as possible?  If you cannot
> get to it in a reasonable amount of time, please let me know so I can
> back out your polygon hit test patch.  We need to be able to select
> footprints.
> 
> Thanks,
> 
> Wayne
> 
> On 2/21/2018 11:41 AM, Andrzej Wolski wrote:
> > After this patch, I can no longer select some footprints by clicking
> > inside their area.
> > Please see the board in an attachment.
> >
> > Andrzej
> >
> > W dniu 2018-02-20 o 16:44, Wayne Stambaugh pisze:
> >> Jon,
> >>
> >> I merged your patch.
> >>
> >> Thanks,
> >>
> >> Wayne
> >>
> >> On 2/18/2018 7:01 PM, Jon Evans wrote:
> >>> Hi Wayne,
> >>>
> >>> In my testing there is no performance impact, but more testing is
> >>> welcome.  It shouldn't be doing the calculation on too many
> objects in
> >>> general, since this is a "second pass" hit test that applies to
> modules
> >>> that have a bounding box overlapping the mouse cursor.
> >>> However, I did some more testing and discovered some weird
> behavior, so
> >>> I have tweaked the algorithm in the attached new version of the
> patch.
> >>>
> >>> -Jon
> >>>
> >>> On Sun, Feb 18, 2018 at 5:25 PM, Wayne Stambaugh
> 
> >>> >> wrote:
> >>>
> >>>  Hey Jon,
> >>>
> >>>  Did you notice an performance hit with your patch? 
> Obviously there
> >>>  is going to be more overhead calculating a polygon versus a
> >>>  rectangle.  I just want to be sure we are not causing any
> usability
> >>>  issues due to the polygon calculations.
> >>>
> >>>  Thanks,
> >>>
> >>>  Wayne
> >>>
> >>>
> >>>  On 02/18/2018 12:10 PM, Jon Evans wrote:
> >>>
> >>>  Hi all,
> >>>
> >>>  The attached patch adds some plumbing to calculate and
> make use
> >>>  of a polygonal bounding area for modules.  It fixes the
> below
> >>>  issue and in general improves the accuracy of selection
> in my
> >>>  testing.
> >>>
> >>>  This mechanism could be extended to other objects besides
> >>>  modules if it's useful.  I figured I'd start by sending out
> >>> this
> >>>  patch to get feedback, and if it gets merged, look for
> other
> >>>  areas where we could improve things by using polygons
> >>> instead of
> >>>  bounding boxes.
> >>>
> >>>  https://bugs.launchpad.net/kicad/+bug/1749077
> 
> >>>   >
> >>>
> >>>  -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 : 

Re: [Kicad-developers] [PATCH] Pcbnew menu bar

[Michael Kavanagh]

Bernhard, do you mean this bug [1] existed before the 3b085f0 "Pcbnew new
menubar structure" commit?

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

On 21 February 2018 at 13:07, Bernhard Stegmaier 
wrote:
> Hi,
>
> Just to mention… it has been like this before the patches.
> At least on macOS, there is still a “Preferences” menu entry below the
> “KiCad” menu bar entry (the “General Settings” dialog).
> Then, there is the “Preferences” menu… without those “General Setting”.
>
> Because there is a “Preferences” menu bar entry I didn’t look anywhere
else
> for the general settings.
> Took me quite a while to find them in the “KiCad” menu bar entry.
>
> Any plans to change this?
>
>
> Regards,
> Bernhard
>
> On 20. Feb 2018, at 08:17, Nick Østergaard  wrote:
>
> Hello Michael and Jeff,
>
> It seems like we got our first small regression from this patch series.
> Could you have a look. Please note it looks like it is window manager
> dependent.
> https://bugs.launchpad.net/kicad/+bug/1750494
>
> Nick
>
> 2018-02-18 23:03 GMT+01:00 Wayne Stambaugh :
>>
>> Indeed I did forget.  Thanks for the reminder.  Thank you Jeff for the
>> patches.
>>
>>
>> On 02/18/2018 03:02 PM, Michael Kavanagh wrote:
>>>
>>> Thanks Wayne. Please don't forget to merge Jeffs dialog changes which
>>> complete the Pcbnew menubar modifications. I have reattached them to
>>> this email for convenience.
>>>
>>> Cheers,
>>> Michael
>>>
>>> On 18 February 2018 at 19:16, Wayne Stambaugh 
>>> wrote:

 Michael,

 I figured out why we are not using IS_ACCELERATOR for these menu
 entries.
 AddHotkeyName() adds a "+Alt+" to the hotkey so this is *not* what we
 want
 so I used the original 0003 patch.  I apologize for the confusion.  I
 merged
 this and you 0004 patch.  We can make any tweaks to it if it's not
 exactly
 what we want.  Thank you for your contribution to KiCad.

 Cheers,

 Wayne


 On 02/18/2018 10:10 AM, Michael Kavanagh wrote:
>
>
> In every other app New, Open, Save, Save As and Print are standard
> hotkeys and not accelerators. They don't have the modifier key, so are
> the "standard" keyboard shortcuts.
>
> Nevertheless, please find attached new patches for review. These
> accompany both of Jeffs dialog patches. Hopefully I didn't break
> anything, implementing the sketch modes removed from the dialogs
> involved fiddling with the GAL tools framework.
>
> Cheers,
> Michael
>
> On 17 February 2018 at 17:27, Wayne Stambaugh 
> wrote:
>>
>>
>> It should be.  We really need to get out of the bad habit of having
>> toolbar only access to tools and settings.  I'm sure there are some
in
>> the schematic editor, symbol editor, and footprint editor as well.
>>
>> On 02/17/2018 06:16 AM, Jeff Young wrote:
>>>
>>>
>>> The Fill/Outline stuff is included.  Not sure about High Contrast
>>> mode,
>>> but it probably should be.
>>>
 On 17 Feb 2018, at 06:58, Gaurav Juvekar 
 wrote:

 Hi all,

 Probably not too relevant, but can we have a workaround of
 https://bugs.launchpad.net/kicad/+bug/1575097 (hidden icons) by
 adding
 View -> High Contrast (Checkable like the "Flip board view")
 View -> Tracks -> Outline (Radio button like the canvas selector)
 -> Fill
 View -> Vias   -> Outline
 -> Fill
 View -> Pads   -> Outline
 -> Fill

 to the menu entries?

 --
 Regards,
 Gaurav Juvekar

 ___
 Mailing list: https://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
>> 

Re: [Kicad-developers] [PATCH] Use polygonal hit testing for module selection

[Andrzej Wolski]

Seems to happen when there is no closed outline drawn in the footprint.
Another test cases in an attachment.

Andrzej

W dniu 2018-02-21 o 17:41, Andrzej Wolski pisze:
After this patch, I can no longer select some footprints by clicking 
inside their area.

Please see the board in an attachment.

Andrzej

W dniu 2018-02-20 o 16:44, Wayne Stambaugh pisze:

Jon,

I merged your patch.

Thanks,

Wayne

On 2/18/2018 7:01 PM, Jon Evans wrote:

Hi Wayne,

In my testing there is no performance impact, but more testing is
welcome.  It shouldn't be doing the calculation on too many objects in
general, since this is a "second pass" hit test that applies to modules
that have a bounding box overlapping the mouse cursor.
However, I did some more testing and discovered some weird behavior, so
I have tweaked the algorithm in the attached new version of the patch.

-Jon

On Sun, Feb 18, 2018 at 5:25 PM, Wayne Stambaugh > wrote:

 Hey Jon,

 Did you notice an performance hit with your patch? Obviously there
 is going to be more overhead calculating a polygon versus a
 rectangle.  I just want to be sure we are not causing any 
usability

 issues due to the polygon calculations.

 Thanks,

 Wayne


 On 02/18/2018 12:10 PM, Jon Evans wrote:

 Hi all,

 The attached patch adds some plumbing to calculate and make 
use

 of a polygonal bounding area for modules.  It fixes the below
 issue and in general improves the accuracy of selection in my
 testing.

 This mechanism could be extended to other objects besides
 modules if it's useful.  I figured I'd start by sending out 
this

 patch to get feedback, and if it gets merged, look for other
 areas where we could improve things by using polygons 
instead of

 bounding boxes.

 https://bugs.launchpad.net/kicad/+bug/1749077
 

 -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





(kicad_pcb (version 20171130) (host pcbnew "(5.0-dev-4108-g1013f8160)")

  (general
(thickness 1.6)
(drawings 0)
(tracks 0)
(zones 0)
(modules 3)
(nets 1)
  )

  (page A4)
  (layers
(0 F.Cu signal)
(31 B.Cu signal)
(32 B.Adhes user)
(33 F.Adhes user)
(34 B.Paste user)
(35 F.Paste user)
(36 B.SilkS user)
(37 F.SilkS user)
(38 B.Mask user)
(39 F.Mask user)
(40 Dwgs.User user)
(41 Cmts.User user)
(42 Eco1.User user)
(43 Eco2.User user)
(44 Edge.Cuts user)
(45 Margin user)
(46 B.CrtYd user)
(47 F.CrtYd user)
(48 B.Fab user)
(49 F.Fab user)
  )

  (setup
(last_trace_width 0.25)
(trace_clearance 0.2)
(zone_clearance 0.508)
(zone_45_only no)
(trace_min 0.2)
(segment_width 0.2)
(edge_width 0.15)
(via_size 0.8)
(via_drill 0.4)
(via_min_size 0.4)
(via_min_drill 0.3)
(uvia_size 0.3)
(uvia_drill 0.1)
(uvias_allowed no)
(uvia_min_size 0.2)
(uvia_min_drill 0.1)
(pcb_text_width 0.3)
(pcb_text_size 1.5 1.5)
(mod_edge_width 0.15)
(mod_text_size 1 1)
(mod_text_width 0.15)
(pad_size 1.524 1.524)
(pad_drill 0.762)
(pad_to_mask_clearance 0.2)
(aux_axis_origin 0 0)
(visible_elements EF7F)
(pcbplotparams
  (layerselection 0x010fc_)
  (usegerberextensions false)
  (usegerberattributes false)
  (usegerberadvancedattributes false)
  (creategerberjobfile false)
  (excludeedgelayer true)
  (linewidth 0.10)
  (plotframeref false)
  (viasonmask false)
  (mode 1)
  (useauxorigin false)
  (hpglpennumber 1)
  (hpglpenspeed 20)
  (hpglpendiameter 15)
  

Re: [Kicad-developers] [RFC] Change to object visibility system for usability/clarity

[Andrzej Wolski]

Wayne,

in attachment all 3 patches I have, rebased.

Cheers,
Andrzej


On 02/21/2018 05:45 PM, Wayne Stambaugh wrote:

Andrzej,

This patch does not apply cleanly.  Please rebase and resubmit it when
you get a chance.

Thanks,

Wayne

On 2/21/2018 11:27 AM, Andrzej Wolski wrote:

Wayne,

I have attached that patch to bug report whom which you messaged me,
thought you will see it.

I'm attaching it again in this email.

Cheers,
Andrzej


On 02/21/2018 05:20 PM, Wayne Stambaugh wrote:

Andrzej,

You have not replied to my last message about your original patch that
you sent to the developers mailing list[1].  I need that one so I can
apply and test the rest of your layer visibility patches.  If you want
these to make it into rc1, please send me this patch as an attachment
soon.  I am planning to branch rc1 by Friday at the latest.

Cheers,

Wayne


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

On 2/19/2018 10:05 AM, Andrzej Wolski wrote:

Patch (in attachment) for "Tracks" turned out to be very simple.
If it gets accepted, I could make more of these.

Andrzej


On 02/19/2018 02:12 PM, Andrzej Wolski wrote:

It would be also nice to have separate controls for:
1. Tracks
2. Drawing primitives (graphic lines, arcs, and circles)
3. Zones
4. Polygons
5. Text (now there is control only for footprint text)
6. Dimensions
7. Plated holes

That would make Render tab (almost) complete.

Andrzej

W dniu 2018-02-18 o 21:00, Jon Evans pisze:

Hi all,

Right now the behavior of the "Layer" and "Render" tabs of the layers
widget are confusing to users, resulting in complaints on the forum
and some bug reports:

https://bugs.launchpad.net/kicad/+bug/1748181
https://bugs.launchpad.net/kicad/+bug/1743890

I could take a crack at fixing this (before or after 5.0 depending on
what the complexity ends up being) but before I write any code I
wanted to propose how I think it should work.

I think the visibility of any object should be the AND of layer
visibility and render visibility.

To get there:

1) In the Render tab, get rid of the distinction between front/back.
For example "Pads Back" and "Pads Front" becomes just "Pads"

2) Change the visibility code so that an object is visible if (a) the
associated Render setting is turned on for the type of object, and
(b) at least one of the layers the object is on is enabled in the
Layers tab.

3) (optionally) Rename "Render" to something more friendly like
"Items" or "Item Types" to make it more clear to the user that this
is where they can turn off the display of various types of items as
opposed to various layerse

If this plan is OK, I will start working out the details of how to
get there.  Right now the Render tab is directly controlling the
visibility of certain "GAL Layers" but unfortunately the set of
objects that appears on one GAL layer is not always equal to the set
of objects that the user would expect to turn on and off, as seen by
the bug reports.  So, there will have to be some additional logic
created to manage these settings beyond just turning on and off
layers in the GAL.

-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


>From 7b764ae730d80feac0c2c4560359fb2cdaa32b1d Mon Sep 17 00:00:00 2001
From: Andrzej Wolski 
Date: Sat, 17 Feb 2018 19:03:22 +0100
Subject: [PATCH 1/3] Fix pads and footprints rendering switches behavior
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.7.4"

This is a multi-part message in MIME format.
--2.7.4
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit


Pads and footprints rendering switches in Render tab were working incorrectly, as described in bug report:
https://bugs.launchpad.net/kicad/+bug/1743890

This patch fixes it and makes GAL behave as the legacy canvas.

Fixes: lp:1743890
---
 pcbnew/class_edge_mod.cpp | 26 ++
 pcbnew/class_edge_mod.h   |  3 +++
 pcbnew/class_pad.cpp  | 22 +-
 pcbnew/class_text_mod.cpp | 31 ++-
 pcbnew/class_text_mod.h   |  2 ++
 pcbnew/pcb_draw_panel_gal.cpp | 14 --
 6 files changed, 74 insertions(+), 24 deletions(-)


--2.7.4
Content-Type: text/x-patch; 

Re: [Kicad-developers] IPC-2581

[Ouabache Designworks]

This might be a good time to discuss industry standards and how they are
currently undergoing a massive change that the Kicad team could help  with.



Standards have in the past been created by large formal organizations like
the IEEE for the entire industry.They were written in a very strict and
formal language
and had to be complete and unambiguous. They were written by professionals
who did that for a living.

If there was a error or omission in a standard then correcting it, getting
all the reviews and approvals, re-releasing a revised standard, changing
all the EDA tools
using it and getting the end user to change all of their accumulated IP
could easily take 10 years.

The verilog standard was revised in 1995 to allow for port creation in one
line instead of two. It was 2005 before the design team that I was on
allowed us to use
 the new standard in our coding. It took us that long  to prove that all of
our tools were correct and we could trust our tool flow with production
code.


I'm sorry IEEE but I have a problem and I need a a working solution by
Friday. You are fired. You can no longer control the standards that I use.

This has already happened. Nobody goes to the verilog standard for answers
about the language. The official solution is to write a test case and run
it under verilogXL
 to see what it does. EDA  tool smiths are no longer implementing
standards, they are creating them. Gerber created the PCB standard. Kicad 5
will create its own standard
and all the standard committee can do is to document it.


We need to work with these groups not to ask them what we should support
but to tell them what we are doing and let them follow us. We can also pick
up some good ideas as
to what other groups are doing.

We don't argue in a committee but rather release everything and let the
market decide. Open source can win in that arena. If we get it wrong then
theres always the next revision.


So what can the Kicad team do? If any new release breaks designs created
under the old release then provide tools and instructions for converting
the end users IP to run under the new release.
 Otherwise its a huge mess. Icarus verilog did a new release for version 10
that fixed an "off-by-one" error in its LOG function. Now its a complete
mess because old code has to be rewritten before
 it can be used with any new code. When you make a change you must also
come up with a plan for all the old IP. Make it easy for the end user to
use your tool.



John Eaton
___
Mailing list: https://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] Use polygonal hit testing for module selection

[Andrzej Wolski]

After this patch, I can no longer select some footprints by clicking 
inside their area.

Please see the board in an attachment.

Andrzej

W dniu 2018-02-20 o 16:44, Wayne Stambaugh pisze:

Jon,

I merged your patch.

Thanks,

Wayne

On 2/18/2018 7:01 PM, Jon Evans wrote:

Hi Wayne,

In my testing there is no performance impact, but more testing is
welcome.  It shouldn't be doing the calculation on too many objects in
general, since this is a "second pass" hit test that applies to modules
that have a bounding box overlapping the mouse cursor.
However, I did some more testing and discovered some weird behavior, so
I have tweaked the algorithm in the attached new version of the patch.

-Jon

On Sun, Feb 18, 2018 at 5:25 PM, Wayne Stambaugh > wrote:

 Hey Jon,

 Did you notice an performance hit with your patch?  Obviously there
 is going to be more overhead calculating a polygon versus a
 rectangle.  I just want to be sure we are not causing any usability
 issues due to the polygon calculations.

 Thanks,

 Wayne


 On 02/18/2018 12:10 PM, Jon Evans wrote:

 Hi all,

 The attached patch adds some plumbing to calculate and make use
 of a polygonal bounding area for modules.  It fixes the below
 issue and in general improves the accuracy of selection in my
 testing.

 This mechanism could be extended to other objects besides
 modules if it's useful.  I figured I'd start by sending out this
 patch to get feedback, and if it gets merged, look for other
 areas where we could improve things by using polygons instead of
 bounding boxes.

 https://bugs.launchpad.net/kicad/+bug/1749077
 

 -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



(kicad_pcb (version 20171130) (host pcbnew "(5.0-dev-4108-g1013f8160)")

  (general
(thickness 1.6)
(drawings 0)
(tracks 0)
(zones 0)
(modules 2)
(nets 1)
  )

  (page A4)
  (layers
(0 F.Cu signal)
(31 B.Cu signal)
(32 B.Adhes user hide)
(33 F.Adhes user hide)
(34 B.Paste user hide)
(35 F.Paste user hide)
(36 B.SilkS user hide)
(37 F.SilkS user)
(38 B.Mask user hide)
(39 F.Mask user hide)
(40 Dwgs.User user)
(41 Cmts.User user)
(42 Eco1.User user)
(43 Eco2.User user)
(44 Edge.Cuts user)
(45 Margin user)
(46 B.CrtYd user)
(47 F.CrtYd user)
(48 B.Fab user)
(49 F.Fab user)
  )

  (setup
(last_trace_width 0.25)
(trace_clearance 0.2)
(zone_clearance 0.508)
(zone_45_only no)
(trace_min 0.2)
(segment_width 0.2)
(edge_width 0.15)
(via_size 0.8)
(via_drill 0.4)
(via_min_size 0.4)
(via_min_drill 0.3)
(uvia_size 0.3)
(uvia_drill 0.1)
(uvias_allowed no)
(uvia_min_size 0.2)
(uvia_min_drill 0.1)
(pcb_text_width 0.3)
(pcb_text_size 1.5 1.5)
(mod_edge_width 0.15)
(mod_text_size 1 1)
(mod_text_width 0.15)
(pad_size 1.524 1.524)
(pad_drill 0.762)
(pad_to_mask_clearance 0.2)
(aux_axis_origin 0 0)
(visible_elements EF7F)
(pcbplotparams
  (layerselection 0x010fc_)
  (usegerberextensions false)
  (usegerberattributes false)
  (usegerberadvancedattributes false)
  (creategerberjobfile false)
  (excludeedgelayer true)
  (linewidth 0.15)
  (plotframeref false)
  (viasonmask false)
  (mode 1)
  (useauxorigin false)
  (hpglpennumber 1)
  (hpglpenspeed 20)
  (hpglpendiameter 15)
  (psnegative false)
  (psa4output false)
  (plotreference true)
  (plotvalue true)
  (plotinvisibletext false)
  (padsonsilk 

Re: [Kicad-developers] [RFC] Change to object visibility system for usability/clarity

[Wayne Stambaugh]

Andrzej,

You have not replied to my last message about your original patch that
you sent to the developers mailing list[1].  I need that one so I can
apply and test the rest of your layer visibility patches.  If you want
these to make it into rc1, please send me this patch as an attachment
soon.  I am planning to branch rc1 by Friday at the latest.

Cheers,

Wayne


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

On 2/19/2018 10:05 AM, Andrzej Wolski wrote:
> Patch (in attachment) for "Tracks" turned out to be very simple.
> If it gets accepted, I could make more of these.
> 
> Andrzej
> 
> 
> On 02/19/2018 02:12 PM, Andrzej Wolski wrote:
>> It would be also nice to have separate controls for:
>> 1. Tracks
>> 2. Drawing primitives (graphic lines, arcs, and circles)
>> 3. Zones
>> 4. Polygons
>> 5. Text (now there is control only for footprint text)
>> 6. Dimensions
>> 7. Plated holes
>>
>> That would make Render tab (almost) complete.
>>
>> Andrzej
>>
>> W dniu 2018-02-18 o 21:00, Jon Evans pisze:
>>> Hi all,
>>>
>>> Right now the behavior of the "Layer" and "Render" tabs of the layers
>>> widget are confusing to users, resulting in complaints on the forum
>>> and some bug reports:
>>>
>>> https://bugs.launchpad.net/kicad/+bug/1748181
>>> https://bugs.launchpad.net/kicad/+bug/1743890
>>>
>>> I could take a crack at fixing this (before or after 5.0 depending on
>>> what the complexity ends up being) but before I write any code I
>>> wanted to propose how I think it should work.
>>>
>>> I think the visibility of any object should be the AND of layer
>>> visibility and render visibility.
>>>
>>> To get there:
>>>
>>> 1) In the Render tab, get rid of the distinction between front/back.
>>> For example "Pads Back" and "Pads Front" becomes just "Pads"
>>>
>>> 2) Change the visibility code so that an object is visible if (a) the
>>> associated Render setting is turned on for the type of object, and
>>> (b) at least one of the layers the object is on is enabled in the
>>> Layers tab.
>>>
>>> 3) (optionally) Rename "Render" to something more friendly like
>>> "Items" or "Item Types" to make it more clear to the user that this
>>> is where they can turn off the display of various types of items as
>>> opposed to various layerse
>>>
>>> If this plan is OK, I will start working out the details of how to
>>> get there.  Right now the Render tab is directly controlling the
>>> visibility of certain "GAL Layers" but unfortunately the set of
>>> objects that appears on one GAL layer is not always equal to the set
>>> of objects that the user would expect to turn on and off, as seen by
>>> the bug reports.  So, there will have to be some additional logic
>>> created to manage these settings beyond just turning on and off
>>> layers in the GAL.
>>>
>>> -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] [PATCH] Pcbnew menu bar

[Clemens Koller]

On 2018-02-21 15:08, Jeff Young wrote:
> Yes, but not for 5.0.
> 
> See https://bugs.launchpad.net/kicad/+bug/1748680 (most of the Kicad menu 
> items will be app settings).
> 
> But this reminds me that I should probably add a task to tabularize pcbnew’s 
> preferences like we did with eeschema.

+1 for TreeView (+ Tabs only if necessary).

But before that: PLEASE use the available screen real-estate as much as 
possible! Clicking through a small tabs or dialogs makes it difficult to find 
preferences is IMO wasting time.

Imagine that dual-screen desktops (usually >1920x1080px) are standard in 
CAD/CAE workstations with the trend to add a third screen which can be stuffed 
up with the setup dialogs.

What is the minimum resolution KiCad's dialogs are supposed to fit into?

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] Pcbnew menu bar

[Jeff Young]

Yes, the JetBrains stuff did that too.  I remember being quite a fan of it.

> On 21 Feb 2018, at 14:42, Jon Evans  wrote:
> 
> List+Tabs can work well too.  I just think we will benefit from multiple 
> levels of hierarchy, and from having the first level of hierarchy be a 
> vertical list that can have some kind of logical grouping (section headers, 
> horizontal lines, etc)
> 
> To be honest, I don't find Qt Creator to be a shining example of preferences 
> done right, because while the List+tabs is a good start, many of the tabs 
> then go off to spawn child dialogs and discovery is harder than it should be.
> 
> I think no matter what we do, we should think about it as embracing the fact 
> that we will have a lot of preferences, rather than begrudgingly accepting 
> that.  The latter can lead to people removing preferences that some other 
> people want to use, just because the preferences dialog can't display them 
> all in a nice way.
> 
> While it's not perfect, I think the Eclipse IDE preferences are actually a 
> neat model for this -- there are tons of options, and so the preferences 
> dialog even has a search box that lets you quickly identify where certain 
> settings live (I think JetBrains IDEs do this too).
> 
> Best,
> Jon
> 
> On Wed, Feb 21, 2018 at 9:35 AM, Jeff Young  > wrote:
> I’m not a fan of tree controls for preferences, but there’s also the 
> compromise of a list + tabs (a la QTCreator).
> 
> 
>> On 21 Feb 2018, at 14:28, Jon Evans > > wrote:
>> 
>> Before you commit to that, I had wanted to make an argument in favor of tree 
>> view preferences instead of tabs.
>> I think we will quickly exceed a reasonable number of tabs in order to 
>> accommodate having all the preferences in one place, especially given that 
>> we will only have more and more features to bring us closer to feature 
>> parity with more advanced ECAD software and those features will sometimes 
>> come with their own preferences.
>> 
>> -Jon
>> 
>> On Wed, Feb 21, 2018 at 9:08 AM, Jeff Young > > wrote:
>> Yes, but not for 5.0.
>> 
>> See https://bugs.launchpad.net/kicad/+bug/1748680 
>>  (most of the Kicad menu 
>> items will be app settings).
>> 
>> But this reminds me that I should probably add a task to tabularize pcbnew’s 
>> preferences like we did with eeschema.
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>>> On 21 Feb 2018, at 13:07, Bernhard Stegmaier >> > wrote:
>>> 
>>> Hi,
>>> 
>>> Just to mention… it has been like this before the patches.
>>> At least on macOS, there is still a “Preferences” menu entry below the 
>>> “KiCad” menu bar entry (the “General Settings” dialog).
>>> Then, there is the “Preferences” menu… without those “General Setting”.
>>> 
>>> Because there is a “Preferences” menu bar entry I didn’t look anywhere else 
>>> for the general settings.
>>> Took me quite a while to find them in the “KiCad” menu bar entry.
>>> 
>>> Any plans to change this?
>>> 
>>> 
>>> Regards,
>>> Bernhard
>>> 
 On 20. Feb 2018, at 08:17, Nick Østergaard > wrote:
 
 Hello Michael and Jeff,
 
 It seems like we got our first small regression from this patch series. 
 Could you have a look. Please note it looks like it is window manager 
 dependent.
 https://bugs.launchpad.net/kicad/+bug/1750494 
 
 
 Nick
 
 2018-02-18 23:03 GMT+01:00 Wayne Stambaugh >:
 Indeed I did forget.  Thanks for the reminder.  Thank you Jeff for the 
 patches.
 
 
 On 02/18/2018 03:02 PM, Michael Kavanagh wrote:
 Thanks Wayne. Please don't forget to merge Jeffs dialog changes which
 complete the Pcbnew menubar modifications. I have reattached them to
 this email for convenience.
 
 Cheers,
 Michael
 
 On 18 February 2018 at 19:16, Wayne Stambaugh > wrote:
 Michael,
 
 I figured out why we are not using IS_ACCELERATOR for these menu entries.
 AddHotkeyName() adds a "+Alt+" to the hotkey so this is *not* what we want
 so I used the original 0003 patch.  I apologize for the confusion.  I 
 merged
 this and you 0004 patch.  We can make any tweaks to it if it's not exactly
 what we want.  Thank you for your contribution to KiCad.
 
 Cheers,
 
 Wayne
 
 
 On 02/18/2018 10:10 AM, Michael Kavanagh wrote:
 
 In every other app New, Open, Save, Save As and Print are standard
 hotkeys and not accelerators. They don't have the modifier key, so are
 the "standard" keyboard shortcuts.
 
 Nevertheless, please 

Re: [Kicad-developers] [PATCH] Pcbnew menu bar

[Jon Evans]

List+Tabs can work well too.  I just think we will benefit from multiple
levels of hierarchy, and from having the first level of hierarchy be a
vertical list that can have some kind of logical grouping (section headers,
horizontal lines, etc)

To be honest, I don't find Qt Creator to be a shining example of
preferences done right, because while the List+tabs is a good start, many
of the tabs then go off to spawn child dialogs and discovery is harder than
it should be.

I think no matter what we do, we should think about it as embracing the
fact that we will have a lot of preferences, rather than begrudgingly
accepting that.  The latter can lead to people removing preferences that
some other people want to use, just because the preferences dialog can't
display them all in a nice way.

While it's not perfect, I think the Eclipse IDE preferences are actually a
neat model for this -- there are tons of options, and so the preferences
dialog even has a search box that lets you quickly identify where certain
settings live (I think JetBrains IDEs do this too).

Best,
Jon

On Wed, Feb 21, 2018 at 9:35 AM, Jeff Young  wrote:

> I’m not a fan of tree controls for preferences, but there’s also the
> compromise of a list + tabs (a la QTCreator).
>
>
> On 21 Feb 2018, at 14:28, Jon Evans  wrote:
>
> Before you commit to that, I had wanted to make an argument in favor of
> tree view preferences instead of tabs.
> I think we will quickly exceed a reasonable number of tabs in order to
> accommodate having all the preferences in one place, especially given that
> we will only have more and more features to bring us closer to feature
> parity with more advanced ECAD software and those features will sometimes
> come with their own preferences.
>
> -Jon
>
> On Wed, Feb 21, 2018 at 9:08 AM, Jeff Young  wrote:
>
>> Yes, but not for 5.0.
>>
>> See https://bugs.launchpad.net/kicad/+bug/1748680 (most of the Kicad
>> menu items will be app settings).
>>
>> But this reminds me that I should probably add a task to tabularize
>> pcbnew’s preferences like we did with eeschema.
>>
>> Cheers,
>> Jeff.
>>
>>
>> On 21 Feb 2018, at 13:07, Bernhard Stegmaier 
>> wrote:
>>
>> Hi,
>>
>> Just to mention… it has been like this before the patches.
>> At least on macOS, there is still a “Preferences” menu entry below the
>> “KiCad” menu bar entry (the “General Settings” dialog).
>> Then, there is the “Preferences” menu… without those “General Setting”.
>>
>> Because there is a “Preferences” menu bar entry I didn’t look anywhere
>> else for the general settings.
>> Took me quite a while to find them in the “KiCad” menu bar entry.
>>
>> Any plans to change this?
>>
>>
>> Regards,
>> Bernhard
>>
>> On 20. Feb 2018, at 08:17, Nick Østergaard  wrote:
>>
>> Hello Michael and Jeff,
>>
>> It seems like we got our first small regression from this patch series.
>> Could you have a look. Please note it looks like it is window manager
>> dependent.
>> https://bugs.launchpad.net/kicad/+bug/1750494
>>
>> Nick
>>
>> 2018-02-18 23:03 GMT+01:00 Wayne Stambaugh :
>>
>>> Indeed I did forget.  Thanks for the reminder.  Thank you Jeff for the
>>> patches.
>>>
>>>
>>> On 02/18/2018 03:02 PM, Michael Kavanagh wrote:
>>>
 Thanks Wayne. Please don't forget to merge Jeffs dialog changes which
 complete the Pcbnew menubar modifications. I have reattached them to
 this email for convenience.

 Cheers,
 Michael

 On 18 February 2018 at 19:16, Wayne Stambaugh 
 wrote:

> Michael,
>
> I figured out why we are not using IS_ACCELERATOR for these menu
> entries.
> AddHotkeyName() adds a "+Alt+" to the hotkey so this is *not* what we
> want
> so I used the original 0003 patch.  I apologize for the confusion.  I
> merged
> this and you 0004 patch.  We can make any tweaks to it if it's not
> exactly
> what we want.  Thank you for your contribution to KiCad.
>
> Cheers,
>
> Wayne
>
>
> On 02/18/2018 10:10 AM, Michael Kavanagh wrote:
>
>>
>> In every other app New, Open, Save, Save As and Print are standard
>> hotkeys and not accelerators. They don't have the modifier key, so are
>> the "standard" keyboard shortcuts.
>>
>> Nevertheless, please find attached new patches for review. These
>> accompany both of Jeffs dialog patches. Hopefully I didn't break
>> anything, implementing the sketch modes removed from the dialogs
>> involved fiddling with the GAL tools framework.
>>
>> Cheers,
>> Michael
>>
>> On 17 February 2018 at 17:27, Wayne Stambaugh 
>> wrote:
>>
>>>
>>> It should be.  We really need to get out of the bad habit of having
>>> toolbar only access to tools and settings.  I'm sure there are some
>>> in
>>> the schematic 

Re: [Kicad-developers] [PATCH] Pcbnew menu bar

[Jeff Young]

I’m not a fan of tree controls for preferences, but there’s also the compromise 
of a list + tabs (a la QTCreator).

> On 21 Feb 2018, at 14:28, Jon Evans  wrote:
> 
> Before you commit to that, I had wanted to make an argument in favor of tree 
> view preferences instead of tabs.
> I think we will quickly exceed a reasonable number of tabs in order to 
> accommodate having all the preferences in one place, especially given that we 
> will only have more and more features to bring us closer to feature parity 
> with more advanced ECAD software and those features will sometimes come with 
> their own preferences.
> 
> -Jon
> 
> On Wed, Feb 21, 2018 at 9:08 AM, Jeff Young  > wrote:
> Yes, but not for 5.0.
> 
> See https://bugs.launchpad.net/kicad/+bug/1748680 
>  (most of the Kicad menu items 
> will be app settings).
> 
> But this reminds me that I should probably add a task to tabularize pcbnew’s 
> preferences like we did with eeschema.
> 
> Cheers,
> Jeff.
> 
> 
>> On 21 Feb 2018, at 13:07, Bernhard Stegmaier > > wrote:
>> 
>> Hi,
>> 
>> Just to mention… it has been like this before the patches.
>> At least on macOS, there is still a “Preferences” menu entry below the 
>> “KiCad” menu bar entry (the “General Settings” dialog).
>> Then, there is the “Preferences” menu… without those “General Setting”.
>> 
>> Because there is a “Preferences” menu bar entry I didn’t look anywhere else 
>> for the general settings.
>> Took me quite a while to find them in the “KiCad” menu bar entry.
>> 
>> Any plans to change this?
>> 
>> 
>> Regards,
>> Bernhard
>> 
>>> On 20. Feb 2018, at 08:17, Nick Østergaard >> > wrote:
>>> 
>>> Hello Michael and Jeff,
>>> 
>>> It seems like we got our first small regression from this patch series. 
>>> Could you have a look. Please note it looks like it is window manager 
>>> dependent.
>>> https://bugs.launchpad.net/kicad/+bug/1750494 
>>> 
>>> 
>>> Nick
>>> 
>>> 2018-02-18 23:03 GMT+01:00 Wayne Stambaugh >> >:
>>> Indeed I did forget.  Thanks for the reminder.  Thank you Jeff for the 
>>> patches.
>>> 
>>> 
>>> On 02/18/2018 03:02 PM, Michael Kavanagh wrote:
>>> Thanks Wayne. Please don't forget to merge Jeffs dialog changes which
>>> complete the Pcbnew menubar modifications. I have reattached them to
>>> this email for convenience.
>>> 
>>> Cheers,
>>> Michael
>>> 
>>> On 18 February 2018 at 19:16, Wayne Stambaugh >> > wrote:
>>> Michael,
>>> 
>>> I figured out why we are not using IS_ACCELERATOR for these menu entries.
>>> AddHotkeyName() adds a "+Alt+" to the hotkey so this is *not* what we want
>>> so I used the original 0003 patch.  I apologize for the confusion.  I merged
>>> this and you 0004 patch.  We can make any tweaks to it if it's not exactly
>>> what we want.  Thank you for your contribution to KiCad.
>>> 
>>> Cheers,
>>> 
>>> Wayne
>>> 
>>> 
>>> On 02/18/2018 10:10 AM, Michael Kavanagh wrote:
>>> 
>>> In every other app New, Open, Save, Save As and Print are standard
>>> hotkeys and not accelerators. They don't have the modifier key, so are
>>> the "standard" keyboard shortcuts.
>>> 
>>> Nevertheless, please find attached new patches for review. These
>>> accompany both of Jeffs dialog patches. Hopefully I didn't break
>>> anything, implementing the sketch modes removed from the dialogs
>>> involved fiddling with the GAL tools framework.
>>> 
>>> Cheers,
>>> Michael
>>> 
>>> On 17 February 2018 at 17:27, Wayne Stambaugh >> >
>>> wrote:
>>> 
>>> It should be.  We really need to get out of the bad habit of having
>>> toolbar only access to tools and settings.  I'm sure there are some in
>>> the schematic editor, symbol editor, and footprint editor as well.
>>> 
>>> On 02/17/2018 06:16 AM, Jeff Young wrote:
>>> 
>>> The Fill/Outline stuff is included.  Not sure about High Contrast mode,
>>> but it probably should be.
>>> 
>>> On 17 Feb 2018, at 06:58, Gaurav Juvekar >> >
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> Probably not too relevant, but can we have a workaround of
>>> https://bugs.launchpad.net/kicad/+bug/1575097 
>>>  (hidden icons) by adding
>>> View -> High Contrast (Checkable like the "Flip board view")
>>> View -> Tracks -> Outline (Radio button like the canvas selector)
>>> -> Fill
>>> View -> Vias   -> Outline
>>> -> Fill
>>> View -> Pads   -> Outline
>>> -> Fill
>>> 
>>> to the menu entries?
>>> 
>>> --
>>> Regards,
>>> Gaurav Juvekar
>>> 
>>> ___
>>> 

Re: [Kicad-developers] [PATCH] Pcbnew menu bar

[Jon Evans]

Before you commit to that, I had wanted to make an argument in favor of
tree view preferences instead of tabs.
I think we will quickly exceed a reasonable number of tabs in order to
accommodate having all the preferences in one place, especially given that
we will only have more and more features to bring us closer to feature
parity with more advanced ECAD software and those features will sometimes
come with their own preferences.

-Jon

On Wed, Feb 21, 2018 at 9:08 AM, Jeff Young  wrote:

> Yes, but not for 5.0.
>
> See https://bugs.launchpad.net/kicad/+bug/1748680 (most of the Kicad menu
> items will be app settings).
>
> But this reminds me that I should probably add a task to tabularize
> pcbnew’s preferences like we did with eeschema.
>
> Cheers,
> Jeff.
>
>
> On 21 Feb 2018, at 13:07, Bernhard Stegmaier 
> wrote:
>
> Hi,
>
> Just to mention… it has been like this before the patches.
> At least on macOS, there is still a “Preferences” menu entry below the
> “KiCad” menu bar entry (the “General Settings” dialog).
> Then, there is the “Preferences” menu… without those “General Setting”.
>
> Because there is a “Preferences” menu bar entry I didn’t look anywhere
> else for the general settings.
> Took me quite a while to find them in the “KiCad” menu bar entry.
>
> Any plans to change this?
>
>
> Regards,
> Bernhard
>
> On 20. Feb 2018, at 08:17, Nick Østergaard  wrote:
>
> Hello Michael and Jeff,
>
> It seems like we got our first small regression from this patch series.
> Could you have a look. Please note it looks like it is window manager
> dependent.
> https://bugs.launchpad.net/kicad/+bug/1750494
>
> Nick
>
> 2018-02-18 23:03 GMT+01:00 Wayne Stambaugh :
>
>> Indeed I did forget.  Thanks for the reminder.  Thank you Jeff for the
>> patches.
>>
>>
>> On 02/18/2018 03:02 PM, Michael Kavanagh wrote:
>>
>>> Thanks Wayne. Please don't forget to merge Jeffs dialog changes which
>>> complete the Pcbnew menubar modifications. I have reattached them to
>>> this email for convenience.
>>>
>>> Cheers,
>>> Michael
>>>
>>> On 18 February 2018 at 19:16, Wayne Stambaugh 
>>> wrote:
>>>
 Michael,

 I figured out why we are not using IS_ACCELERATOR for these menu
 entries.
 AddHotkeyName() adds a "+Alt+" to the hotkey so this is *not* what we
 want
 so I used the original 0003 patch.  I apologize for the confusion.  I
 merged
 this and you 0004 patch.  We can make any tweaks to it if it's not
 exactly
 what we want.  Thank you for your contribution to KiCad.

 Cheers,

 Wayne


 On 02/18/2018 10:10 AM, Michael Kavanagh wrote:

>
> In every other app New, Open, Save, Save As and Print are standard
> hotkeys and not accelerators. They don't have the modifier key, so are
> the "standard" keyboard shortcuts.
>
> Nevertheless, please find attached new patches for review. These
> accompany both of Jeffs dialog patches. Hopefully I didn't break
> anything, implementing the sketch modes removed from the dialogs
> involved fiddling with the GAL tools framework.
>
> Cheers,
> Michael
>
> On 17 February 2018 at 17:27, Wayne Stambaugh 
> wrote:
>
>>
>> It should be.  We really need to get out of the bad habit of having
>> toolbar only access to tools and settings.  I'm sure there are some in
>> the schematic editor, symbol editor, and footprint editor as well.
>>
>> On 02/17/2018 06:16 AM, Jeff Young wrote:
>>
>>>
>>> The Fill/Outline stuff is included.  Not sure about High Contrast
>>> mode,
>>> but it probably should be.
>>>
>>> On 17 Feb 2018, at 06:58, Gaurav Juvekar 
 wrote:

 Hi all,

 Probably not too relevant, but can we have a workaround of
 https://bugs.launchpad.net/kicad/+bug/1575097 (hidden icons) by
 adding
 View -> High Contrast (Checkable like the "Flip board view")
 View -> Tracks -> Outline (Radio button like the canvas selector)
 -> Fill
 View -> Vias   -> Outline
 -> Fill
 View -> Pads   -> Outline
 -> Fill

 to the menu entries?

 --
 Regards,
 Gaurav Juvekar

 ___
 Mailing list: https://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 : 

Re: [Kicad-developers] [PATCH] Pcbnew menu bar

[Jeff Young]

Yes, but not for 5.0.

See https://bugs.launchpad.net/kicad/+bug/1748680 
 (most of the Kicad menu items 
will be app settings).

But this reminds me that I should probably add a task to tabularize pcbnew’s 
preferences like we did with eeschema.

Cheers,
Jeff.


> On 21 Feb 2018, at 13:07, Bernhard Stegmaier  wrote:
> 
> Hi,
> 
> Just to mention… it has been like this before the patches.
> At least on macOS, there is still a “Preferences” menu entry below the 
> “KiCad” menu bar entry (the “General Settings” dialog).
> Then, there is the “Preferences” menu… without those “General Setting”.
> 
> Because there is a “Preferences” menu bar entry I didn’t look anywhere else 
> for the general settings.
> Took me quite a while to find them in the “KiCad” menu bar entry.
> 
> Any plans to change this?
> 
> 
> Regards,
> Bernhard
> 
>> On 20. Feb 2018, at 08:17, Nick Østergaard > > wrote:
>> 
>> Hello Michael and Jeff,
>> 
>> It seems like we got our first small regression from this patch series. 
>> Could you have a look. Please note it looks like it is window manager 
>> dependent.
>> https://bugs.launchpad.net/kicad/+bug/1750494 
>> 
>> 
>> Nick
>> 
>> 2018-02-18 23:03 GMT+01:00 Wayne Stambaugh > >:
>> Indeed I did forget.  Thanks for the reminder.  Thank you Jeff for the 
>> patches.
>> 
>> 
>> On 02/18/2018 03:02 PM, Michael Kavanagh wrote:
>> Thanks Wayne. Please don't forget to merge Jeffs dialog changes which
>> complete the Pcbnew menubar modifications. I have reattached them to
>> this email for convenience.
>> 
>> Cheers,
>> Michael
>> 
>> On 18 February 2018 at 19:16, Wayne Stambaugh > > wrote:
>> Michael,
>> 
>> I figured out why we are not using IS_ACCELERATOR for these menu entries.
>> AddHotkeyName() adds a "+Alt+" to the hotkey so this is *not* what we want
>> so I used the original 0003 patch.  I apologize for the confusion.  I merged
>> this and you 0004 patch.  We can make any tweaks to it if it's not exactly
>> what we want.  Thank you for your contribution to KiCad.
>> 
>> Cheers,
>> 
>> Wayne
>> 
>> 
>> On 02/18/2018 10:10 AM, Michael Kavanagh wrote:
>> 
>> In every other app New, Open, Save, Save As and Print are standard
>> hotkeys and not accelerators. They don't have the modifier key, so are
>> the "standard" keyboard shortcuts.
>> 
>> Nevertheless, please find attached new patches for review. These
>> accompany both of Jeffs dialog patches. Hopefully I didn't break
>> anything, implementing the sketch modes removed from the dialogs
>> involved fiddling with the GAL tools framework.
>> 
>> Cheers,
>> Michael
>> 
>> On 17 February 2018 at 17:27, Wayne Stambaugh > >
>> wrote:
>> 
>> It should be.  We really need to get out of the bad habit of having
>> toolbar only access to tools and settings.  I'm sure there are some in
>> the schematic editor, symbol editor, and footprint editor as well.
>> 
>> On 02/17/2018 06:16 AM, Jeff Young wrote:
>> 
>> The Fill/Outline stuff is included.  Not sure about High Contrast mode,
>> but it probably should be.
>> 
>> On 17 Feb 2018, at 06:58, Gaurav Juvekar > >
>> wrote:
>> 
>> Hi all,
>> 
>> Probably not too relevant, but can we have a workaround of
>> https://bugs.launchpad.net/kicad/+bug/1575097 
>>  (hidden icons) by adding
>> View -> High Contrast (Checkable like the "Flip board view")
>> View -> Tracks -> Outline (Radio button like the canvas selector)
>> -> Fill
>> View -> Vias   -> Outline
>> -> Fill
>> View -> Pads   -> Outline
>> -> Fill
>> 
>> to the menu entries?
>> 
>> --
>> Regards,
>> Gaurav Juvekar
>> 
>> ___
>> Mailing list: https://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] Add progress reporting for GerbView file loading

[Jon Evans]

It's dependent on the data in the files, which is why I decided to use the
time based delay method.

On my machine it normally doesn't show up, but a full set of Gerbers from a
very large board is slow enough to show it.

-Jon

On Feb 21, 2018 00:07, "Andrey Kuznetsov"  wrote:

> Does it make sense to predict whether a loading/progress window is
> necessary based on total file size, based on prediction that a certain size
> takes X seconds to load?
> Or is loading highly dependent on the data/objects being loaded?
>
> On Tue, Feb 20, 2018 at 7:21 PM, Jon Evans  wrote:
>
>> Hi all,
>>
>> This patch adds the progress reporter dialog to GerbView file loading,
>> when loading multiple files and the total load time goes over 1 second.
>> I've also done some refactoring to share code between loading multiple
>> files via a gerber job file and via the regular open dialog.
>>
>> -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
>>
>>
>
>
> --
> 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] [PATCH] Pcbnew menu bar

[Bernhard Stegmaier]

Hi,

Just to mention… it has been like this before the patches.
At least on macOS, there is still a “Preferences” menu entry below the “KiCad” 
menu bar entry (the “General Settings” dialog).
Then, there is the “Preferences” menu… without those “General Setting”.

Because there is a “Preferences” menu bar entry I didn’t look anywhere else for 
the general settings.
Took me quite a while to find them in the “KiCad” menu bar entry.

Any plans to change this?


Regards,
Bernhard

> On 20. Feb 2018, at 08:17, Nick Østergaard  wrote:
> 
> Hello Michael and Jeff,
> 
> It seems like we got our first small regression from this patch series. Could 
> you have a look. Please note it looks like it is window manager dependent.
> https://bugs.launchpad.net/kicad/+bug/1750494 
> 
> 
> Nick
> 
> 2018-02-18 23:03 GMT+01:00 Wayne Stambaugh  >:
> Indeed I did forget.  Thanks for the reminder.  Thank you Jeff for the 
> patches.
> 
> 
> On 02/18/2018 03:02 PM, Michael Kavanagh wrote:
> Thanks Wayne. Please don't forget to merge Jeffs dialog changes which
> complete the Pcbnew menubar modifications. I have reattached them to
> this email for convenience.
> 
> Cheers,
> Michael
> 
> On 18 February 2018 at 19:16, Wayne Stambaugh  > wrote:
> Michael,
> 
> I figured out why we are not using IS_ACCELERATOR for these menu entries.
> AddHotkeyName() adds a "+Alt+" to the hotkey so this is *not* what we want
> so I used the original 0003 patch.  I apologize for the confusion.  I merged
> this and you 0004 patch.  We can make any tweaks to it if it's not exactly
> what we want.  Thank you for your contribution to KiCad.
> 
> Cheers,
> 
> Wayne
> 
> 
> On 02/18/2018 10:10 AM, Michael Kavanagh wrote:
> 
> In every other app New, Open, Save, Save As and Print are standard
> hotkeys and not accelerators. They don't have the modifier key, so are
> the "standard" keyboard shortcuts.
> 
> Nevertheless, please find attached new patches for review. These
> accompany both of Jeffs dialog patches. Hopefully I didn't break
> anything, implementing the sketch modes removed from the dialogs
> involved fiddling with the GAL tools framework.
> 
> Cheers,
> Michael
> 
> On 17 February 2018 at 17:27, Wayne Stambaugh  >
> wrote:
> 
> It should be.  We really need to get out of the bad habit of having
> toolbar only access to tools and settings.  I'm sure there are some in
> the schematic editor, symbol editor, and footprint editor as well.
> 
> On 02/17/2018 06:16 AM, Jeff Young wrote:
> 
> The Fill/Outline stuff is included.  Not sure about High Contrast mode,
> but it probably should be.
> 
> On 17 Feb 2018, at 06:58, Gaurav Juvekar  >
> wrote:
> 
> Hi all,
> 
> Probably not too relevant, but can we have a workaround of
> https://bugs.launchpad.net/kicad/+bug/1575097 
>  (hidden icons) by adding
> View -> High Contrast (Checkable like the "Flip board view")
> View -> Tracks -> Outline (Radio button like the canvas selector)
> -> Fill
> View -> Vias   -> Outline
> -> Fill
> View -> Pads   -> Outline
> -> Fill
> 
> to the menu entries?
> 
> --
> Regards,
> Gaurav Juvekar
> 
> ___
> Mailing list: https://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 : 

Re: [Kicad-developers] wxPython/wxWidgets compatibility check

[Maciej Sumiński]

Gah, I would expect there is a consistent way to do the checks. I made
the check Linux specific, as actually it is the only platform that can
have wxWidgets built against different toolkits. Thanks for the report.

Cheers,
Orson

On 02/21/2018 11:30 AM, Nick Østergaard wrote:
> But I notice it is broken on the macos nightly.
> 
> It can not import the wx python module and hence we get an empty string for
> the toolkit from wxpython, (osx_cocoa vs ).
> 
> http://ci.kicad-pcb.org/job/osx-kicad-adam-head/576/console
> 
> 
> 2018-02-20 23:55 GMT+01:00 Nick Østergaard :
> 
>> Yippee, build fixed!
>> Project KiCad (Windows, MSYS2) Nightly Build build #203: FIXED in 30 min:
>> http://darine.hogyros.de:8080/job/windows-kicad-msys2/203/
>>
>> 2018-02-20 20:33 GMT+01:00 Maciej Suminski :
>>
>>> Apologies, it should be fine now.
>>>
>>> Cheers,
>>> Orson
>>>
>>> On 02/20/2018 08:09 PM, Wayne Stambaugh wrote:
 Me too!  Orson, can you please take a look at this when you get a
>>> chance.

 On 2/20/2018 12:10 PM, Nick Østergaard wrote:
> Ok, but it seems to break the msys2 build.
>
> http://darine.hogyros.de:8080/job/windows-kicad-msys2/202/console
>
> *17:58:19* C:/msys64/mingw32/lib/python2.
>>> 7/site-packages/wx-3.0-msw/wx/_core.py:16633: UserWarning:
>>> wxPython/wxWidgets release number mismatch
> *17:58:19*   warnings.warn("wxPython/wxWidgets release number
>>> mismatch")
> *17:58:19* CMake Error at CMakeLists.txt:710 (message):
> *17:58:19*
> *17:58:19*
> *17:58:19*   wxWidgets and wxPython use different toolkits ( vs msw).
>>> It will result in
> *17:58:19*   a broken build.  Please either install wxPython built
>>> using or add
> *17:58:19*   '-DKICAD_SCRIPTING_WXPYTHON=OFF' to cmake parameters to
>>> disable wxPython
> *17:58:19*   support.
>
>
> Latest wxpython classic is 3.0.2.0 and the wxwidgets is 3.0.3.
>
> 2018-02-20 17:52 GMT+01:00 Maciej Sumiński  >:
>
> Ok, committed with a message explaining the possible solutions.
>
> Cheers,
> Orson
>
> On 02/20/2018 03:22 PM, Wayne Stambaugh wrote:
> > Orson,
> >
> > You should just be able to turn of the wxPython scripting.  All
>>> of the
> > other scripting should work fine unless someone changed
>>> something that
> > drags in wxPython when only the KICAD_SCRIPTING option is
>>> enabled.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 2/20/2018 2:40 AM, Maciej Sumiński wrote:
> >> Hi Nick,
> >>
> >> Thank you for testing the patch. I think a hint about disabling
> >> scripting is a good idea. Do you know if it is enough just to
>>> disable
> >> wxPython or rather everything scripting related should be
>>> turned off?
> >>
> >> There is a different warning when GTK3 is detected as the
> wxWidgets toolkit.
> >>
> >> Regards,
> >> Orson
> >>
> >> On 02/19/2018 10:47 PM, Nick Østergaard wrote:
> >>> Ok, I just tried to do:
> >>>
> >>> In [3]: wx.version()
> >>> Out[3]: '4.0.1 gtk3 (phoenix)'
> >>>
> >>> I clearly also have python2-wxpython-phoenix installed. I just
> tried to
> >>> remove that from my system.
> >>>
> >>> Now it seems to complete the cmake configure successfully. I
> guess the
> >>> patch works afterall :D
> >>>
> >>> But I have a comment. Should we be a bit more helpful for the
> packager, to
> >>> tell him that he can temporarely disable the scripting options
> to make it
> >>> build, maybe also hint that we on do support gtk2 for the time
> being.
> >>>
> >>> 2018-02-19 22:28 GMT+01:00 Nick Østergaard  >:
> >>>
>  Hello Maciej,
> 
>  I just tested your patch on archlinux. It does not seem to
>>> work
> properly,
>  tested in a clean build dir. Even if I remove wxpython (with
> gtk3) and
>  install wxpython-gtk2 (with gtk2 from AUR) it still complains
> that there is
>  a mismatch. I have wxwidgets with gtk2 and gtk3 installed,
>>> taht
> is the
>  packages wxgtk2 and wxgtk3.
> 
>  I see it says; "wxPython version 3.0 found."
> 
>  So the patch as is seems to be broken for me.
> 
>  2018-02-17 21:03 GMT+01:00 Maciej Suminski
> >:
> 
> > In order to prevent faulty builds in case of
> wxPython/wxWidgets toolkit
> > 

Re: [Kicad-developers] wxPython/wxWidgets compatibility check

[Nick Østergaard]

But I notice it is broken on the macos nightly.

It can not import the wx python module and hence we get an empty string for
the toolkit from wxpython, (osx_cocoa vs ).

http://ci.kicad-pcb.org/job/osx-kicad-adam-head/576/console


2018-02-20 23:55 GMT+01:00 Nick Østergaard :

> Yippee, build fixed!
> Project KiCad (Windows, MSYS2) Nightly Build build #203: FIXED in 30 min:
> http://darine.hogyros.de:8080/job/windows-kicad-msys2/203/
>
> 2018-02-20 20:33 GMT+01:00 Maciej Suminski :
>
>> Apologies, it should be fine now.
>>
>> Cheers,
>> Orson
>>
>> On 02/20/2018 08:09 PM, Wayne Stambaugh wrote:
>> > Me too!  Orson, can you please take a look at this when you get a
>> chance.
>> >
>> > On 2/20/2018 12:10 PM, Nick Østergaard wrote:
>> >> Ok, but it seems to break the msys2 build.
>> >>
>> >> http://darine.hogyros.de:8080/job/windows-kicad-msys2/202/console
>> >>
>> >> *17:58:19* C:/msys64/mingw32/lib/python2.
>> 7/site-packages/wx-3.0-msw/wx/_core.py:16633: UserWarning:
>> wxPython/wxWidgets release number mismatch
>> >> *17:58:19*   warnings.warn("wxPython/wxWidgets release number
>> mismatch")
>> >> *17:58:19* CMake Error at CMakeLists.txt:710 (message):
>> >> *17:58:19*
>> >> *17:58:19*
>> >> *17:58:19*   wxWidgets and wxPython use different toolkits ( vs msw).
>> It will result in
>> >> *17:58:19*   a broken build.  Please either install wxPython built
>> using or add
>> >> *17:58:19*   '-DKICAD_SCRIPTING_WXPYTHON=OFF' to cmake parameters to
>> disable wxPython
>> >> *17:58:19*   support.
>> >>
>> >>
>> >> Latest wxpython classic is 3.0.2.0 and the wxwidgets is 3.0.3.
>> >>
>> >> 2018-02-20 17:52 GMT+01:00 Maciej Sumiński > >> >:
>> >>
>> >> Ok, committed with a message explaining the possible solutions.
>> >>
>> >> Cheers,
>> >> Orson
>> >>
>> >> On 02/20/2018 03:22 PM, Wayne Stambaugh wrote:
>> >> > Orson,
>> >> >
>> >> > You should just be able to turn of the wxPython scripting.  All
>> of the
>> >> > other scripting should work fine unless someone changed
>> something that
>> >> > drags in wxPython when only the KICAD_SCRIPTING option is
>> enabled.
>> >> >
>> >> > Cheers,
>> >> >
>> >> > Wayne
>> >> >
>> >> > On 2/20/2018 2:40 AM, Maciej Sumiński wrote:
>> >> >> Hi Nick,
>> >> >>
>> >> >> Thank you for testing the patch. I think a hint about disabling
>> >> >> scripting is a good idea. Do you know if it is enough just to
>> disable
>> >> >> wxPython or rather everything scripting related should be
>> turned off?
>> >> >>
>> >> >> There is a different warning when GTK3 is detected as the
>> >> wxWidgets toolkit.
>> >> >>
>> >> >> Regards,
>> >> >> Orson
>> >> >>
>> >> >> On 02/19/2018 10:47 PM, Nick Østergaard wrote:
>> >> >>> Ok, I just tried to do:
>> >> >>>
>> >> >>> In [3]: wx.version()
>> >> >>> Out[3]: '4.0.1 gtk3 (phoenix)'
>> >> >>>
>> >> >>> I clearly also have python2-wxpython-phoenix installed. I just
>> >> tried to
>> >> >>> remove that from my system.
>> >> >>>
>> >> >>> Now it seems to complete the cmake configure successfully. I
>> >> guess the
>> >> >>> patch works afterall :D
>> >> >>>
>> >> >>> But I have a comment. Should we be a bit more helpful for the
>> >> packager, to
>> >> >>> tell him that he can temporarely disable the scripting options
>> >> to make it
>> >> >>> build, maybe also hint that we on do support gtk2 for the time
>> >> being.
>> >> >>>
>> >> >>> 2018-02-19 22:28 GMT+01:00 Nick Østergaard > >> >:
>> >> >>>
>> >>  Hello Maciej,
>> >> 
>> >>  I just tested your patch on archlinux. It does not seem to
>> work
>> >> properly,
>> >>  tested in a clean build dir. Even if I remove wxpython (with
>> >> gtk3) and
>> >>  install wxpython-gtk2 (with gtk2 from AUR) it still complains
>> >> that there is
>> >>  a mismatch. I have wxwidgets with gtk2 and gtk3 installed,
>> taht
>> >> is the
>> >>  packages wxgtk2 and wxgtk3.
>> >> 
>> >>  I see it says; "wxPython version 3.0 found."
>> >> 
>> >>  So the patch as is seems to be broken for me.
>> >> 
>> >>  2018-02-17 21:03 GMT+01:00 Maciej Suminski
>> >> >:
>> >> 
>> >> > In order to prevent faulty builds in case of
>> >> wxPython/wxWidgets toolkit
>> >> > mismatch [1,2] (gtk2 vs gtk3), I added a check in CMakeLists.
>> >> I verified
>> >> > it with Windows 7 and Linux, but I would love to hear from
>> OSX
>> >> users
>> >> > that I do not break their build.
>> >> >
>> >> > Cheers,
>> >> > Orson
>> >> >
>> >> > 1.