Re: [Kicad-developers] [PATCH] UX for ENV_VAR editor

[Oliver Walters]

Wayne,

I styled these improvements in this manner for three main reasons:

1. It makes input validation easier (e.g. prevent user from changing the
name of immutable path variables / prevent input of duplicate variables)
2. The functionality is more obvious with buttons, I feel (perhaps at the
sake of efficiency)
3. It is more in line with UI elements from other software, where the UI is
more "user friendly"

Maybe it's less efficient but this dialog is rarely used and certainly not
for large scale data entry.

However, whatever changes are made here, I feel should be commonised with
other similar data entry dialogs. In particular, the pretty-table and
symbol-table dialogs.

1. A common table class should be created (currently code is duplicated all
over the place)
2. Better input validation
3. Ability to select library paths with a directory chooser dialog
4. Consistency across all dialogs

I would be happy to defer to the 'spreadsheet' style approach if we can
have a common dialog style and also improve as above.

e.g. in the 'PCB library tables' window, some buttons only work when you
have the entire row selected, and some work when you have a cell selected.
Also, the 'remove library' button removes the last library even if no
library is selected.

I'd rather make a set of changes to improve all of these tables, rather
than "improve" this one but then have style differences.

What do you think?

Oliver


On Sat, Oct 7, 2017 at 6:08 AM, Wayne Stambaugh 
wrote:

> Oliver,
>
> My original intention with this dialog was to do away with the "Add" and
> "Remove" buttons all together and create an object derived from
> wxGridTable and wxGrid for editing the environment variable list.  I did
> this because it was expedient.  I've never been a big fan of the way we
> use buttons to add, delete, edit, etc. entries in grids and list
> controls.  Why not just make them directly editable like a typical
> spreadsheet?  I would think that this would be more natural for users
> rather than using buttons.  It seems to me that double clicking (or
> right clicking and context menu) in the path grid cell would launch the
> dir select dialog.  I know it's more work to do it this way but I think
> it is a more user friendly approach than having to use buttons to modify
> the grid.
>
> That being said, I would be willing to commit this patch if you fix a
> few things in DIALOG_ENV_VAR_SINGLE_BASE:
>
> Make the dialog resizable so DIALOG_SHIM can do it's job.
>
> Don't allow the controls to expand.
>
> Don't allow the wxStdDialogButtonSizer to expand.
>
> Set the spacer proportion to 0.
>
> Use a wxDirPickCtrl instead of your own custom control.  It will be more
> consistent across platforms.
>
> Get rid of the dialog size and let the sizers select the best size for
> the controls.
>
> Cheers,
>
> Wayne
>
> On 10/6/2017 10:53 AM, Oliver Walters wrote:
> > Attached is a patch which improves UX for the ENV_VAR editor dialog
> >
> > * Adds ability to select path with file chooser
> > * General cleanup
> > * Removal of that sinking feeling you get when interacting with a clunky
> UI
> >
> > Oliver
> >
> >
> > ___
> > 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] Icon consolidation

[Oliver Walters]

Not intentional, didn't notice that!

On 7 Oct 2017 04:04, "Wayne Stambaugh"  wrote:

Oliver,

I merged you patch into the master branch.  Thanks!  I noticed that the
polyline toolbar button is different between the board and footprint
editors as well.  Did you miss this or was this intentional?

Cheers,

Wayne

On 10/4/2017 7:36 AM, Oliver Walters wrote:
> Attached is a patch that consolidates the icon for "add line or polygon"
> in pcbnew and modedit.
>
> Previously there was a different icon in each viewer.
>
>
>
>
> ___
> 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-developers] [PATCH] Collision-based select in library editor

[Seth Hillbrand]

​Crosses off a couple FIXMEs.  Previous code checked if text and circle
centers were inside selection rectangle.  This patch adds collision
detection to full objects.  Makes selecting items in library editor a bit
easier.

-Seth
From 5673542c24ec252a9a51ab0a8dc58f2a00ccc813 Mon Sep 17 00:00:00 2001
From: Seth Hillbrand 
Date: Fri, 6 Oct 2017 13:58:27 -0700
Subject: [PATCH 1/1] Eeschema: Add collision-based selection code to circles
 and text

---
 eeschema/lib_circle.cpp | 12 +++-
 eeschema/lib_field.cpp  | 15 ++-
 eeschema/lib_text.cpp   | 15 ++-
 3 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/eeschema/lib_circle.cpp b/eeschema/lib_circle.cpp
index 78a915325..a44f2974e 100644
--- a/eeschema/lib_circle.cpp
+++ b/eeschema/lib_circle.cpp
@@ -146,11 +146,13 @@ void LIB_CIRCLE::SetOffset( const wxPoint& aOffset )
 
 bool LIB_CIRCLE::Inside( EDA_RECT& aRect ) const
 {
-/*
- * FIXME: This fails to take into account the radius around the center
- *point.
- */
-return aRect.Contains( m_Pos.x, -m_Pos.y );
+wxPoint delta = m_Pos -  aRect.ClosestPointTo( m_Pos );
+
+delta.x = abs( delta.x );
+delta.y = abs( delta.y );
+
+return ( ( delta.x <= m_Radius ) || ( delta.y <= m_Radius ) ||
+( delta.x * delta.x + delta.y * delta.y <= m_Radius * m_Radius ));
 }
 
 
diff --git a/eeschema/lib_field.cpp b/eeschema/lib_field.cpp
index cd7e524b6..0cea51fbb 100644
--- a/eeschema/lib_field.cpp
+++ b/eeschema/lib_field.cpp
@@ -447,11 +447,16 @@ void LIB_FIELD::SetOffset( const wxPoint& aOffset )
 
 bool LIB_FIELD::Inside( EDA_RECT& rect ) const
 {
-/*
- * FIXME: This fails to take into account the size and/or orientation of
- *the text.
- */
-return rect.Contains( GetTextPos().x, -GetTextPos().y );
+EDA_RECT bb = GetBoundingBox();
+bb.Normalize();
+rect.Normalize();
+wxPoint p1 = bb.GetPosition();
+wxPoint p2 = p1 + bb.GetSize();
+wxPoint p3 = rect.GetPosition();
+wxPoint p4 = p3 + rect.GetSize();
+
+//This works because the rotation can only be a multiple of 90 deg
+return p2.y >= p3.y && p1.y <= p4.y && p2.x >= p3.x && p1.x <= p4.x;
 }
 
 
diff --git a/eeschema/lib_text.cpp b/eeschema/lib_text.cpp
index 428a28d0f..be95249ad 100644
--- a/eeschema/lib_text.cpp
+++ b/eeschema/lib_text.cpp
@@ -268,11 +268,16 @@ void LIB_TEXT::SetOffset( const wxPoint& aOffset )
 
 bool LIB_TEXT::Inside( EDA_RECT& rect ) const
 {
-/*
- * FIXME: This should calculate the text size and justification and
- *use rectangle intersect.
- */
-return rect.Contains( GetTextPos().x, -GetTextPos().y );
+EDA_RECT bb = GetBoundingBox();
+bb.Normalize();
+rect.Normalize();
+wxPoint p1 = bb.GetPosition();
+wxPoint p2 = p1 + bb.GetSize();
+wxPoint p3 = rect.GetPosition();
+wxPoint p4 = p3 + rect.GetSize();
+
+//This works because the rotation can only be a multiple of 90 deg
+return p2.y >= p3.y && p1.y <= p4.y && p2.x >= p3.x && p1.x <= p4.x;
 }
 
 
-- 
2.11.0

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

[Kicad-developers] Symbol library table update.

[Wayne Stambaugh]

I just pushed the latest symbol library table updates to
https://code.launchpad.net/~stambaughw/kicad/+git/kicad-dev/+ref/remap-symbols-to-sym-lib-table.
 Everything (library editor, symbol chooser dialog, symbol viewer, etc.)
now uses the symbol library table for access library symbols except for
the schematic rescue code.  I had to leave the schematic rescue code as
is in case a final rescue had to be performed before the remapping to
the symbol library table.  Please test it if you get some time and let
me know if you find any issues.  It's going to be disruptive enough even
if I haven't broken anything which is highly unlikely given the amount
of code that has changed.  There are only a few things left to do:

Refactor the schematic rescue code so there is one that uses the current
libraries and one that uses the symbol library table.

Remove all of the legacy libraries from the project file after
successful remapping.

Remove the legacy library management dialog.

Any other code that someone else is working outside the master branch.
I'm mostly thinking about the Eagle schematic plugin.

Hopefully I will finish up the schematic rescue code this weekend.  I'll
probably hold off on clearing the libraries and the project management
dialog until after this is merged into the master branch and it gets
wider testing.

Cheers,

Wayne

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

Re: [Kicad-developers] [PATCH] UX for ENV_VAR editor

[Wayne Stambaugh]

Oliver,

My original intention with this dialog was to do away with the "Add" and
"Remove" buttons all together and create an object derived from
wxGridTable and wxGrid for editing the environment variable list.  I did
this because it was expedient.  I've never been a big fan of the way we
use buttons to add, delete, edit, etc. entries in grids and list
controls.  Why not just make them directly editable like a typical
spreadsheet?  I would think that this would be more natural for users
rather than using buttons.  It seems to me that double clicking (or
right clicking and context menu) in the path grid cell would launch the
dir select dialog.  I know it's more work to do it this way but I think
it is a more user friendly approach than having to use buttons to modify
the grid.

That being said, I would be willing to commit this patch if you fix a
few things in DIALOG_ENV_VAR_SINGLE_BASE:

Make the dialog resizable so DIALOG_SHIM can do it's job.

Don't allow the controls to expand.

Don't allow the wxStdDialogButtonSizer to expand.

Set the spacer proportion to 0.

Use a wxDirPickCtrl instead of your own custom control.  It will be more
consistent across platforms.

Get rid of the dialog size and let the sizers select the best size for
the controls.

Cheers,

Wayne

On 10/6/2017 10:53 AM, Oliver Walters wrote:
> Attached is a patch which improves UX for the ENV_VAR editor dialog
> 
> * Adds ability to select path with file chooser
> * General cleanup
> * Removal of that sinking feeling you get when interacting with a clunky UI
> 
> Oliver
> 
> 
> ___
> 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] GitHub Plugin (my nemesis)

[Simon Küppers]

For what is worth, I strongly support this standpoint! :-)


Am 06.10.2017 um 15:33 schrieb Oliver Walters:
> Wayne,
> 
> Thanks for the clarification - this discussion is getting a bit
> sidetracked I feel.
> 
> We will operate under the assumption that the footprints will be in a
> single repo, without using submodules.
> 
> Any tools that can or will be developed for managing KiCad libraries are
> a secondary requirement at this point.
> 
> Cheers,
> 
> Oliver
> 
> On Sat, Oct 7, 2017 at 12:20 AM, Wayne Stambaugh  > wrote:
> 
> On 10/6/2017 5:43 AM, Rene Pöschl wrote:
> > On 02/10/17 11:37, Simon Küppers wrote:
> >> I am no expert, but this question is out of the scope of this
> thread..
> >> For downloading, gut applies compression anyway.
> >>
> >> I respect the people having slow Internet lines.. However as shown a
> >> few posts backwards, the whole footprints and symbol library is like
> >> 100 megabytes without the 3d models. If think the benefit of a single
> >> repo outways the ability to download only a selection of libraries...
> >> By a LOT.
> >>
> > I agree with you here. Lets ignore the 3d model stuff and get back
> > talking about the footprint libs.
> > We are planning a massive library reorganization. (for the v5 release)
> > This will require a lot more footprint libs. If all these new libs are
> > all in a separate repo then this can not be done!
> > In addition to the new repos the old once still need to exist (and
> have
> > at least one footprint each) because otherwise the github plugin will
> > stop working for everyone who has this old repo in their fp-lib-table.
> >
> > **We library managers require whatever lib distribution is used to
> > support one repo that holds all footprint libs.** (one repo that
> has the
> > pretty folders as subdirectorys)
> > To be honest i do not care what will be used as long as this
> requirement
> > is fulfilled.
> >
> > We would really need a decision soon. Are you guys prepared to help us
> > out here such that we can move on with the lib reorganization? (The
> > details of how you do it can be discussed later.)
> >
> 
> I thought I already addressed this issue but I will reiterate.  I am
> fine with the footprint library reorganization as long as the existing
> footprint library repos remain in tact for existing users.  These
> libraries do not need to be updated but we cannot remove them.  The
> other thing that will have to happen is that our package devs will have
> to buy into packaging the new footprint library repo as part of the
> install packages.  We will have to agree on an install path (
> ${CMAKE_INSTALL_PREFIX}/share/kicad/footprints seems logical) and make
> the default fp-lib-table file use the local install path with the KiCad
> plugin instead of the github plugin fp-lib-table.  I don't think this
> will be a major issue.  Does anyone have any major objections to this?
> If not, we will make this part of the stable 5 release.
> 
> Cheers,
> 
> Wayne
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] [PATCH] Clean up unused junctions

[Seth Hillbrand]

In further testing, it appears that currently delete connection doesn't
properly undo/redo.  As the junction add/remove should function seamlessly
with undo, I'll withdraw this patch request until I can propose a fix for
the undo/redo.

-Set

On Wed, Sep 27, 2017 at 4:57 PM, Seth Hillbrand 
wrote:

> Hi Jon-
>
> Thanks for catching that.  The delete node/delete connection follow a
> different path to deletion, so I missed them initially.  As I was doing
> this, I noticed a couple of corner cases where junctions were not properly
> added/deleted, so this fixes that issue as well.
>
> There is one remaining issue, which is that junctions along the wire are
> not deleted if they are no longer required.  But I'm holding off on adding
> this because I don't think that we want to keep the wire crossing multiple
> junctions and I'll try to lay out that proposal at a later date.
>
> Best-
> Seth
>
> On Tue, Sep 26, 2017 at 5:58 PM, Jon Evans  wrote:
>
>> Hi Seth,
>>
>> Neat feature!  I just checked this out and it does seem to work in most
>> cases.
>> There seem to be some situations where it doesn't remove junctions in my
>> existing schematics -- when I use "delete connection" it works, but when I
>> use "delete wire" it only works some of the time.  I haven't looked closely
>> at the code to see why this might be happening.
>>
>> -Jon
>>
>> On Tue, Sep 26, 2017 at 7:39 PM, Seth Hillbrand > > wrote:
>>
>>> ​Hi All-
>>>
>>> Currently, when laying wire in eeschema, junctions are automatically
>>> added​ where needed.  This patch provides the reverse.  When deleting
>>> segments in eeschema, it automatically removes the junction if it is no
>>> longer needed.
>>>
>>> This should save extra clicks when re-wiring and hopefully help new
>>> Kicad users keep their schematics cleaner.
>>>
>>> Best-
>>> Seth
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [PATCH] Improve eeschema wire merging

[Seth Hillbrand]

​Currently​, if you draw a line _over_ another line, eeschema will make a
junction unless you make the new line exactly on the endpoint of the old
line.

The attached patch fixes this by allowing line merges of arbitrary
overlapping segments.  It also speeds up the merge (trivially) by removing
the atan2() calls.

-Seth
From 4c25be81ec64391cc90378c616be8836377e7c64 Mon Sep 17 00:00:00 2001
From: Seth Hillbrand 
Date: Fri, 6 Oct 2017 10:42:55 -0700
Subject: [PATCH 1/1] Eeschema: Improve performance and merge overlapping
 segments

---
 eeschema/sch_line.cpp | 56 +--
 1 file changed, 36 insertions(+), 20 deletions(-)

diff --git a/eeschema/sch_line.cpp b/eeschema/sch_line.cpp
index 48c3cb397..cac1cb91d 100644
--- a/eeschema/sch_line.cpp
+++ b/eeschema/sch_line.cpp
@@ -273,12 +273,36 @@ void SCH_LINE::Rotate( wxPoint aPosition )
  */
 bool SCH_LINE::MergeOverlap( SCH_LINE* aLine )
 {
+SCH_LINE *leftmost, *rightmost;
 wxCHECK_MSG( aLine != NULL && aLine->Type() == SCH_LINE_T, false,
  wxT( "Cannot test line segment for overlap." ) );
 
 if( this == aLine || GetLayer() != aLine->GetLayer() )
 return false;
 
+auto less = []( const wxPoint& lhs, const wxPoint& rhs ) -> bool
+{
+if( lhs.x == rhs.x )
+return lhs.y < rhs.y;
+return lhs.x < rhs.x;
+};
+
+if( m_start != std::min( { m_start, m_end }, less ) )
+std::swap( m_start, m_end );
+if( aLine->m_start != std::min( { aLine->m_start, aLine->m_end }, less ) )
+std::swap( aLine->m_start, aLine->m_end );
+
+if( less( m_start, aLine->m_start ) )
+{
+leftmost = this;
+rightmost = aLine;
+}
+else
+{
+leftmost = aLine;
+rightmost = this;
+}
+
 // Search for a common end:
 if( m_start == aLine->m_start )
 {
@@ -296,8 +320,9 @@ bool SCH_LINE::MergeOverlap( SCH_LINE* aLine )
 }
 else if( m_end != aLine->m_start )
 {
-// No common end point, segments cannot be merged.
-return false;
+// No common end point, check for maybe overlapping
+if( less ( leftmost->m_end, rightmost->m_start ) )
+return false;
 }
 
 bool colinear = false;
@@ -319,12 +344,13 @@ bool SCH_LINE::MergeOverlap( SCH_LINE* aLine )
 }
 else
 {
-if( atan2( (double) ( m_start.x - m_end.x ), (double) ( m_start.y - m_end.y ) )
-== atan2( (double) ( aLine->m_start.x - aLine->m_end.x ),
-  (double) ( aLine->m_start.y - aLine->m_end.y ) ) )
-{
-colinear = true;
-}
+int dx = leftmost->m_end.x - leftmost->m_start.x;
+int dy = leftmost->m_end.y - leftmost->m_start.y;
+
+colinear = ( ( ( rightmost->m_start.y - leftmost->m_start.y ) * dx ==
+( rightmost->m_start.x - leftmost->m_start.x ) * dy ) &&
+( ( rightmost->m_end.y - leftmost->m_start.y ) * dx ==
+( rightmost->m_end.x - leftmost->m_start.x ) * dy ) );
 }
 
 // Make a segment which merge the 2 segments
@@ -333,18 +359,8 @@ bool SCH_LINE::MergeOverlap( SCH_LINE* aLine )
 // for horizontal segments the uppermost and the lowest point
 if( colinear )
 {
-auto less = []( const wxPoint& lhs, const wxPoint& rhs ) -> bool
-{
-if( lhs.x == rhs.x )
-return lhs.y < rhs.y;
-return lhs.x < rhs.x;
-};
-
-wxPoint top_left = std::min( { m_start, m_end, aLine->m_start, aLine->m_end }, less );
-wxPoint bottom_right = std::max( { m_start, m_end, aLine->m_start, aLine->m_end }, less );
-
-m_start = top_left;
-m_end = bottom_right;
+m_start = leftmost->m_start;
+m_end = rightmost->m_end;
 return true;
 }
 return false;
-- 
2.11.0

___
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] GitHub Plugin (my nemesis)

[Wayne Stambaugh]

On 10/6/2017 9:33 AM, Oliver Walters wrote:
> Wayne,
> 
> Thanks for the clarification - this discussion is getting a bit
> sidetracked I feel.
> 
> We will operate under the assumption that the footprints will be in a
> single repo, without using submodules.
> 
> Any tools that can or will be developed for managing KiCad libraries are
> a secondary requirement at this point.

Yes, this is a separate discussion and will not be part of the stable 5
release.

> 
> Cheers,
> 
> Oliver
> 
> On Sat, Oct 7, 2017 at 12:20 AM, Wayne Stambaugh  > wrote:
> 
> On 10/6/2017 5:43 AM, Rene Pöschl wrote:
> > On 02/10/17 11:37, Simon Küppers wrote:
> >> I am no expert, but this question is out of the scope of this
> thread..
> >> For downloading, gut applies compression anyway.
> >>
> >> I respect the people having slow Internet lines.. However as shown a
> >> few posts backwards, the whole footprints and symbol library is like
> >> 100 megabytes without the 3d models. If think the benefit of a single
> >> repo outways the ability to download only a selection of libraries...
> >> By a LOT.
> >>
> > I agree with you here. Lets ignore the 3d model stuff and get back
> > talking about the footprint libs.
> > We are planning a massive library reorganization. (for the v5 release)
> > This will require a lot more footprint libs. If all these new libs are
> > all in a separate repo then this can not be done!
> > In addition to the new repos the old once still need to exist (and
> have
> > at least one footprint each) because otherwise the github plugin will
> > stop working for everyone who has this old repo in their fp-lib-table.
> >
> > **We library managers require whatever lib distribution is used to
> > support one repo that holds all footprint libs.** (one repo that
> has the
> > pretty folders as subdirectorys)
> > To be honest i do not care what will be used as long as this
> requirement
> > is fulfilled.
> >
> > We would really need a decision soon. Are you guys prepared to help us
> > out here such that we can move on with the lib reorganization? (The
> > details of how you do it can be discussed later.)
> >
> 
> I thought I already addressed this issue but I will reiterate.  I am
> fine with the footprint library reorganization as long as the existing
> footprint library repos remain in tact for existing users.  These
> libraries do not need to be updated but we cannot remove them.  The
> other thing that will have to happen is that our package devs will have
> to buy into packaging the new footprint library repo as part of the
> install packages.  We will have to agree on an install path (
> ${CMAKE_INSTALL_PREFIX}/share/kicad/footprints seems logical) and make
> the default fp-lib-table file use the local install path with the KiCad
> plugin instead of the github plugin fp-lib-table.  I don't think this
> will be a major issue.  Does anyone have any major objections to this?
> If not, we will make this part of the stable 5 release.
> 
> Cheers,
> 
> Wayne
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 


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

Re: [Kicad-developers] [PATCH] Icon consolidation

[Wayne Stambaugh]

Oliver,

I merged you patch into the master branch.  Thanks!  I noticed that the
polyline toolbar button is different between the board and footprint
editors as well.  Did you miss this or was this intentional?

Cheers,

Wayne

On 10/4/2017 7:36 AM, Oliver Walters wrote:
> Attached is a patch that consolidates the icon for "add line or polygon"
> in pcbnew and modedit.
> 
> Previously there was a different icon in each viewer.
> 
> 
> 
> 
> ___
> 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] GitHub Plugin (my nemesis)

[Oliver Walters]

Wayne,

Thanks for the clarification - this discussion is getting a bit sidetracked
I feel.

We will operate under the assumption that the footprints will be in a
single repo, without using submodules.

Any tools that can or will be developed for managing KiCad libraries are a
secondary requirement at this point.

Cheers,

Oliver

On Sat, Oct 7, 2017 at 12:20 AM, Wayne Stambaugh 
wrote:

> On 10/6/2017 5:43 AM, Rene Pöschl wrote:
> > On 02/10/17 11:37, Simon Küppers wrote:
> >> I am no expert, but this question is out of the scope of this thread..
> >> For downloading, gut applies compression anyway.
> >>
> >> I respect the people having slow Internet lines.. However as shown a
> >> few posts backwards, the whole footprints and symbol library is like
> >> 100 megabytes without the 3d models. If think the benefit of a single
> >> repo outways the ability to download only a selection of libraries...
> >> By a LOT.
> >>
> > I agree with you here. Lets ignore the 3d model stuff and get back
> > talking about the footprint libs.
> > We are planning a massive library reorganization. (for the v5 release)
> > This will require a lot more footprint libs. If all these new libs are
> > all in a separate repo then this can not be done!
> > In addition to the new repos the old once still need to exist (and have
> > at least one footprint each) because otherwise the github plugin will
> > stop working for everyone who has this old repo in their fp-lib-table.
> >
> > **We library managers require whatever lib distribution is used to
> > support one repo that holds all footprint libs.** (one repo that has the
> > pretty folders as subdirectorys)
> > To be honest i do not care what will be used as long as this requirement
> > is fulfilled.
> >
> > We would really need a decision soon. Are you guys prepared to help us
> > out here such that we can move on with the lib reorganization? (The
> > details of how you do it can be discussed later.)
> >
>
> I thought I already addressed this issue but I will reiterate.  I am
> fine with the footprint library reorganization as long as the existing
> footprint library repos remain in tact for existing users.  These
> libraries do not need to be updated but we cannot remove them.  The
> other thing that will have to happen is that our package devs will have
> to buy into packaging the new footprint library repo as part of the
> install packages.  We will have to agree on an install path (
> ${CMAKE_INSTALL_PREFIX}/share/kicad/footprints seems logical) and make
> the default fp-lib-table file use the local install path with the KiCad
> plugin instead of the github plugin fp-lib-table.  I don't think this
> will be a major issue.  Does anyone have any major objections to this?
> If not, we will make this part of the stable 5 release.
>
> Cheers,
>
> Wayne
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] GitHub Plugin (my nemesis)

[Wayne Stambaugh]

On 10/6/2017 5:43 AM, Rene Pöschl wrote:
> On 02/10/17 11:37, Simon Küppers wrote:
>> I am no expert, but this question is out of the scope of this thread..
>> For downloading, gut applies compression anyway.
>>
>> I respect the people having slow Internet lines.. However as shown a
>> few posts backwards, the whole footprints and symbol library is like
>> 100 megabytes without the 3d models. If think the benefit of a single
>> repo outways the ability to download only a selection of libraries...
>> By a LOT.
>>
> I agree with you here. Lets ignore the 3d model stuff and get back
> talking about the footprint libs.
> We are planning a massive library reorganization. (for the v5 release)
> This will require a lot more footprint libs. If all these new libs are
> all in a separate repo then this can not be done!
> In addition to the new repos the old once still need to exist (and have
> at least one footprint each) because otherwise the github plugin will
> stop working for everyone who has this old repo in their fp-lib-table.
> 
> **We library managers require whatever lib distribution is used to
> support one repo that holds all footprint libs.** (one repo that has the
> pretty folders as subdirectorys)
> To be honest i do not care what will be used as long as this requirement
> is fulfilled.
> 
> We would really need a decision soon. Are you guys prepared to help us
> out here such that we can move on with the lib reorganization? (The
> details of how you do it can be discussed later.)
> 

I thought I already addressed this issue but I will reiterate.  I am
fine with the footprint library reorganization as long as the existing
footprint library repos remain in tact for existing users.  These
libraries do not need to be updated but we cannot remove them.  The
other thing that will have to happen is that our package devs will have
to buy into packaging the new footprint library repo as part of the
install packages.  We will have to agree on an install path (
${CMAKE_INSTALL_PREFIX}/share/kicad/footprints seems logical) and make
the default fp-lib-table file use the local install path with the KiCad
plugin instead of the github plugin fp-lib-table.  I don't think this
will be a major issue.  Does anyone have any major objections to this?
If not, we will make this part of the stable 5 release.

Cheers,

Wayne

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

Re: [Kicad-developers] GitHub Plugin (my nemesis)

[Rene Pöschl]

On 02/10/17 11:37, Simon Küppers wrote:
I am no expert, but this question is out of the scope of this thread.. 
For downloading, gut applies compression anyway.


I respect the people having slow Internet lines.. However as shown a 
few posts backwards, the whole footprints and symbol library is like 
100 megabytes without the 3d models. If think the benefit of a single 
repo outways the ability to download only a selection of libraries... 
By a LOT.


I agree with you here. Lets ignore the 3d model stuff and get back 
talking about the footprint libs.

We are planning a massive library reorganization. (for the v5 release)
This will require a lot more footprint libs. If all these new libs are 
all in a separate repo then this can not be done!
In addition to the new repos the old once still need to exist (and have 
at least one footprint each) because otherwise the github plugin will 
stop working for everyone who has this old repo in their fp-lib-table.


**We library managers require whatever lib distribution is used to 
support one repo that holds all footprint libs.** (one repo that has the 
pretty folders as subdirectorys)
To be honest i do not care what will be used as long as this requirement 
is fulfilled.


We would really need a decision soon. Are you guys prepared to help us 
out here such that we can move on with the lib reorganization? (The 
details of how you do it can be discussed later.)


___
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