Re: [Kicad-developers] Version 6 release schedule

[José Ignacio]

I second this. I am affected by most of these bugs (except the eeschema
one). Now that we are past the string freeze, would it be possible to at
least restore the functionality that was available in V5, even if the API
is different? Missing this functions will break things for a long time.

On Mon, Nov 1, 2021, 05:05 Jan Mrázek  wrote:

> Hello Wayne and others,
>
> I am really looking forward for the release. As a maintainer of several
> KiCAD plugins, I would like to add support for KiCAD 6 to them  before
> it is released so my users can migrate right away. However, the last
> time I wanted to add the support I run into a problem of missing Python
> API due to the migration from SWIG to Pybind.
>
> Could you (or anyone else)  give me a brief overview (or point me to
> relevant sources) where can I learn how was the API changed so I can
> adapt my plugins? I was trying to learn about it from the commits, but I
> wasn't able to learn anything due to the tremendous commit rate (I
> admire the whole team for that), so this is why I am reaching out to you.
>
> Also, what can we expect in v6? And what will lack? I noticed that some
> of the Python API relevant issues, that I consider as essential, still
> left open and have no updates in them:
>
> - Pbnew Python API: Cannot to set board design settings
>   (https://gitlab.com/kicad/code/kicad/-/issues/6885)
> - Python: Missing API for setting board aux origin
> (https://gitlab.com/kicad/code/kicad/-/issues/8836)
> - Eeschema python library
> (https://gitlab.com/kicad/code/kicad/-/issues/2077)
>
> Jan
>
> On 28. 10. 21 23:09, Wayne Stambaugh wrote:
> > The lead development team has agreed on a version 6 release schedule
> > as follows:
> >
> >
> > - String freeze November 1.
> > - Tag RC1 on November 15.
> > - All repos frozen on December 14.
> > - Tag all repos with 6.0.0 on December 15.
> > - 6.0.0 release announcement December 31 (maybe the day before Christmas
> >   just for fun).
> > - Branch V6 and open master for new feature development on January 1.
> >
> > Our goal is to stick to that as closely as possible so if you have any
> > outstanding work, please use this schedule as a reference to get it done.
> >
> > Going forward, we will be following the new stable release policy[1]
> > which will move us to an annual release schedule.
> >
> > Thank you everyone for your continued support of the KiCad project.
> > Hopefully the version 6 release will go reasonably smoothly and we can
> > get started on version 7 in 2022.
> >
> > Cheers,
> >
> > Wayne
> >
> > [1]: https://dev-docs.kicad.org/en/rules-guidelines/release-policy/
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCAD 5.99/6 Python API status & time schedule

[José Ignacio]

I am an avid user of Jan's tools (KiKit mostly) and it has become
increasingly difficult to keep them working with current v6 code as api
calls keep getting removed or moved around. I know that having an open
development process for the new API can be counter productive (bikeshedding
and all) but if there is not a defined deadline for this to land on in this
feature freeze, would the developers consider accepting bug reports and
merge requests against api regressions from 5.1 as bugs in the interim?


On Thu, Apr 1, 2021 at 4:15 AM Jan Mrázek  wrote:

> Hello,
>
> I develop and maintain several KiCAD plugins. Many of my users started
> switching/would like to KiCAD 5.99 as it brings many exciting features.
> Therefore, I get frequently a question when KiCAD v5.99 will be
> supported. However, as there were some breaking changes and some parts
> of the API are gone and their substitutes are missing, I cannot support
> nightly (e.g., [1]). I remember there were some promises on the API for
> 5.99/6 during summer-autumn 2020 that it could be ready around end of
> January 2021. However, as I checked the source code, there are no news
> regarding the API. I also did not found any draft on the proposed
> feature of the API.
>
> Therefore, I would like to ask you:
>
> - is there any proposal of the new API for pcbnew and eeschema we could
> check out? I am interested to see it, possibly start adapting my plugins
> to it and e.g., give you feedback on missing functionality/hard to use
> parts before it gets freeze (basically my concerns from [2])
> - is there any work-in-progress we can test? If not, is there a known
> time estimate when KiCAD can reach first testable version of the Python
> API?
> - I know that maintaining large open-source project is hard and time
> consuming, so I would like to ask if there is anything I could do to
> help your regarding the API? I have already contributed to KiCAD and I
> think am a skillful C++ programmer, so if there are some isolated tasks
> that you can delegate, I am willing to contribute!
>
> PS: As I am not a native speaker, so I am not sure if I set the tone of
> the e-mail right. To clarify; I am writing in a curious and caring
> matter. I do not blame you guys for not having the API yet. I value your
> work and appreciate it a lot!
>
> Jan
>
> [1] https://gitlab.com/kicad/code/kicad/-/issues/6885
> [2] https://gitlab.com/kicad/code/kicad/-/issues/7134
>
>
>
> ___
> 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] Altium board importer

[José Ignacio]

Just one step closer to KiCAD world domination.

On Sat, Apr 4, 2020 at 11:19 AM Wayne Stambaugh 
wrote:

> For those of you who haven't heard, the Altium board importer[1] was
> merged into the master branch.  It should be available in nightly builds
> now or in the very near future.  If you have Altium boards, please test
> the new importer.  Pcbnew must be run in stand alone mode to import
> Altium boards at the moment.  At some point in the future, support for
> importing Altium schematics and eventually Altium project import will be
> implemented.
>
> Many thanks to Thomas Pointhuber for all of his hard work in coding this
> great new feature.
>
> Cheers,
>
> Wayne
>
>
> [1]: https://gitlab.com/kicad/code/kicad/-/merge_requests/60
>
> ___
> 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] Altium 20 new interactive routing features

[José Ignacio]

Cows (like most mammals) are toruses though...

On Mon, Dec 2, 2019 at 11:06 AM Wayne Stambaugh 
wrote:

> On 12/2/19 11:59 AM, Tomasz Wlostowski wrote:
> > On 02/12/2019 17:40, Vesa Solonen wrote:
> >> topological routing will
> >
> > Could you please explain what 'topological routing' does mean (other
> > than being marketing buzzword used by some companies) and what exactly
> > it has to do with topology [1]?
> >
> > Tom
> >
> > [1] https://en.wikipedia.org/wiki/Topology
>
> The cow morphing into a sphere made me smile :)
>
> ___
> 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] Ctrl-click to highlight in pcbnew missing?

[José Ignacio]

That's a big change. Are you sure it is a good idea to do without asking
users about it? (from my part it would annoy me quite a bit if i was using
master).

On Tue, Sep 10, 2019 at 8:09 AM Jeff Young  wrote:

> Ctrl-click was made consistent with Pcbnew (and platform standards) for
> toggle selection.
>
> ` is now hooked up to highlight net.
>
> Cheers,
> Jeff.
>
> > On 10 Sep 2019, at 13:30, Tomasz Wlostowski 
> wrote:
> >
> > Hi,
> >
> > Am I missing something or did Ctrl-click to highlight a net suddenly
> > stopped working in pcbnew?
> >
> > Cheers,
> > Tom
> >
> > ___
> > 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] [RFC] Comments for a Layer Stack Manager in Pcbnew

[José Ignacio]

+1 on Wayne's comments. One of the nice things about the recent work on the
board setup dialog is the centralization of board settings that were
previously spread all over the place, we really shouldn't go back the other
direction.

On Wed, Aug 21, 2019 at 8:46 AM Wayne Stambaugh 
wrote:

> Hi JP,
>
> On 8/17/19 2:39 PM, jp charras wrote:
> > Le 13/08/2019 à 18:52, Wayne Stambaugh a écrit :
> >> JP,
> >>
> >> I took a look at your patch and I have a few comments.
> >>
> >> Shouldn't the stack up dialog just be another panel the the board setup
> >> dialog?  I would think this information is part of the board setup but I
> >> could be wrong.
> >>
> >> If the stack up information is part of the board setup then it should be
> >> in the "setup" section of the file format as well instead of a separate
> >> section.
> >>
> >> Change the "board_stackup" token to "stackup".  Board is implied.
> >>
> >> I'm not sure "dielectric_constrains" is necessarily clear.  Maybe
> >> "control_dielectric" would be more clear although I'm open to
> suggestion.
> >>
> >> The dialog layout definitely needs improved.  The board thickness
> >> control has the units appended in the edit control along with the units
> >> displayed using static text.  The layer color swatches are not aligned
> >> with the rest of the layer row controls.  The color comboboxes are
> >> cutoff on GTK.  The capitalization is incorrect for the check box and
> >> sizer strings.
> >>
> >> All in all, it's a good first step.  I'm sure this will be improved over
> >> time to cover other board stack up parameters.
> >>
> >> Cheers,
> >>
> >> Wayne
> >>
> >
> > Wayne and Seth, thanks for your input.
> >
> > I attached a new version of the  Layer Stack Manager that fixes some
> issues.
>
> I could not apply the attached patch.  Please rebase against the latest
> master when you get a chance so I can test it.
>
> I did not see the updated file format revision in your patch but maybe I
> missed it.
>
> >
> > A few comments on the dialog (also for @Seth):
> > I have fixed some issues (the issue with wxBitmapComboBox is a wxGTK
> > bug: I added a workaround)
> > Currently the  Layer Stack Manager uses its own dialog.
> > However the main code uses a wxPanel, so it can be easily moved in the
> > Preferences or the Board setup dialogs.
> >
> > But I am not convinced the Preferences or the Board setup is the right
> > place for this stack manager:
> >
> >  1- the Layer Setup in board setup is already a list with many info.
> > Adding more widgets on each line will create usability issues.
>
> I wasn't suggesting that we merge the layer setup panel and layer stack
> dialog.  I agree that it would probably to too confusing.  I was merely
> suggesting that the board stack manager be a separate panel in the board
> setup dialog which would not change the complexity of either the layer
> or the stack configuration views.
>
> >
> >  2- these (layer setup and stack manager) panels are already not easy to
> > use when setting the copper layer count to 32.
> >
> > 3- the layer setup manages info for the board editor.
> > the stack manager manages info only for the CAM tools (currently, the
> > .gbrjob file) and none of the settings in  this stack manager are used
> > by the board editor (but some will be used by the 3D viewer).
> > I do not see a good reason to merge the layer setup the stack manager.
> > Moreover, in the future, the layer setup should manage more info (when
> > the possibility to add custom layers is added)
>
> True, but there are design parameters where the layer stack information
> could be used such as in the router to prevent layer to layer minimum
> insulation violations or signal integrity simulations.  While the stack
> information may be primarily for CAM tools in it's current form, there
> is valuable information that could be used for things like the routing,
> thermal simulation, RF simulation, etc. so that is why I think it should
> be added to the board setup dialog even if initially it's only used for
> CAM output.  I also think users will be more likely to expected it to be
> in the same place as the rest of the board configuration but I could be
> wrong.
>
> >
> > 4- Once the stack manager is added to Pcbnew, the board thickness
> > setting will be removed from the Layer setup panel.
>
> This is one more reason that the layer stack configuration should be in
> the board setup dialog.  It's replacing the current fixed board
> thickness setting.
>
> >
> > 5- A good place for this stack manager could be inside a CAM tool that
> > allows to create all files (Gerber, drill files and gbrjob file) in one
> > command, with the same settings.
> > The the current stack manager dialog should be seen only as a temporary
> > dialog.
>
> How would a CAM tool be separate from the board setup?  As long as the
> information was CAM only, I could see this making sense.  What I want to
> avoid is having duplicate information in the setup and stack
> 

Re: [Kicad-developers] 5.1.4 status

[José Ignacio]

Well, relatively speaking, KiCad has been releasing at a breakneck pace
lately :)

On Mon, Jul 15, 2019 at 11:51 AM Wayne Stambaugh 
wrote:

> Oops, sorry about that.  Should read 5.1.3.
>
> On 7/15/2019 12:50 PM, Steven A. Falco wrote:
> > On 7/15/19 12:26 PM, Wayne Stambaugh wrote:
> >> Were do we stand on the translations?  I saw a few commits to the
> >> translations repo over the past week but it didn't look like all
> >> languages got updated.  Please let me know when the translations are
> >> ready so we can tag the source and library repos.  I have the release
> >> announcement ready to go.
> >
> > Are we skipping 5.1.3 and jumping to 5.1.4?
> >
> >   Steve
> >
> >
> > ___
> > 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] Arc Adjustment proposal

[José Ignacio]

Why not use start end, "bulge" as DXFs do for LWPOLYLINEs?
http://www.lee-mac.com/bulgeconversion.html Instead of the bulge number
(which is related to the included angle of the triangle formed between the
endpoints and the center) you could also write out the angle of the arc
directly. This is a very compact representation for polylines that have
arcs (like arc traces) as the center point is implied. there are also no
invalid values as a bulge of zero is a straight segment and an almost full
circle of infinite radius would be + or - infinity.

On Wed, Jul 10, 2019 at 6:57 PM Seth Hillbrand  wrote:

> On 2019-07-10 14:08, Brian wrote:
> > On 7/10/19 2:02 PM, Seth Hillbrand wrote:
> >> Start-center-end is under constrained and requires the additional
> >> knowledge of which direction the arc is going.
> >
> > On the contrary.  Start-center-end is fully constrained.  Arc
> > direction is implied and unambiguous.
>
> Ah yes, you are right.  We can assume a CW or CCW direction and swap
> start/end to match.
>
> The only remaining concern would be robustness.  You can create a
> start-center-end combination that is invalid, so we'd need to define a
> governing parameter.
>
> The start-midpoint-end triplet can also be invalid but only if you
> assume the midpoint is exactly midway.  The three-point conversion I
> listed previously allows the third point to exist anywhere on the arc
> and avoids this issue.  We would use midpoint for convenience when
> writing the file but don't require it when reading.
>
> Is there a good solution to this issue for the center point idea?
>
> 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

Re: [Kicad-developers] Kicad's way of drawing filled zones

[José Ignacio]

I don't think any desktop computer released after 2010 would have issues
with GL3 unless the hardware/OS is defective in some way.

On Fri, May 10, 2019 at 11:43 AM Jon Evans  wrote:

> Does anyone have a good sense of which hardware / software platforms would
> be impacted by a switch to OpenGL 3.0 as baseline requirement?
>
> As far as I am aware, all commercial tools in the space have more advanced
> / modern system requirements than KiCad, with the possible exception of
> Eagle.  We have to consider whether supporting old  graphics cards goes
> counter to the desire to have KiCad handle more professional use cases
> (including large designs).
>
> The integrated Intel GPUs that are old enough to not have OpenGL 3.0 are
> no longer supported by Intel (everything since HD2000 series has it, as far
> as I know)
>
> -Jon
>
> On Fri, May 10, 2019, at 12:33 PM, Tomasz Wlostowski wrote:
>
> Hi,
>
> I've been recently playing with Victor's huge 32-layer PCB design and
> trying to improve the performance of pcbnew for larger designs. This
> board causes even pretty decent PCs to crash/render glitches due to
> pcbnew's enormous VBO (Vertex Buffer) memory consumption.
>
> It turns out it's caused by the way KiCad renders filled zones:
> - the inside of a zone is drawn/plotted as a filled polygon with 0-width
> boundary. This one not a problem - we already triangulate the polygons
> and I recently developed a patch for the OpenGL GAL that allows reusing
> vertices of triangulated polys in the VBO/Index buffer to further reduce
> memory footprint.
> - the thick outline is drawn with rounded segments with the width =
> minimum width of the polygon. Since we don't have arcs in polygons, each
> of round features (e.g. vias) surrounded by a zone gets a ton of tiny
> segments in the polygon outline. Each rounded segment in OpenGL is
> composed of 2 triangles, hence 6 vertices (that can't be reused...). For
> Victor's board it means 1 GB (sic!) of the VBO goes for outlines of the
> polygons alone. Disabling the outline drawing makes the renderer work
> smooth again.
>
> I've been experimenting with some ways to fix this:
> - generating the thick outline strokes using a Geometry Shader (which
> means bumping up GL 3.0+), which means farewell to many Linux/older
> integrated Graphics users.
> - caching a triangulated polygon which is a boolean sum of the filled
> inside and the thick stroked outline. This takes a lot of time (~2
> minutes for Victor's design) to load and still takes quite a bit of VBO
> memory. Another downside is that the polygons are not fully WYSIWYG
> (outline segments have true rounded corners, while the corners of the
> displayed shape would be approximated with line segments).
> - change the way KiCad handles filled zones to calculate the (stroke +
> inside) boolean sum during zone filling process. It means changes to the
> plotting/GAL/3D code, but no changes to the file format. We'll also be
> forced to inform the users that they have to refill the zones if they
> read a file generated by an older KiCad version.
>
>
> Which solution would you prefer?
> Cheers,
> Tom
>
> ___
> 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] 6.0 string proposal

[José Ignacio]

When you implement command line switches you will probably want --help to
emit a translated message.

On Fri, May 3, 2019 at 1:51 PM Wayne Stambaugh  wrote:

> On 5/3/2019 11:27 AM, Dick Hollenbeck wrote:
> > On 5/3/19 9:41 AM, Wayne Stambaugh wrote:
> >> There is a secondary goal of removing wxWidgets from our low level
> >> objects.  Maybe some day we can build the low level KiCad non-ui
> >> libraries sans wxWdigets.  My thinking is that wxString should only come
> >> into play at the UI level when dealing with wxWidgets UI code.  Being
> >> able to use a standard C++ string implementation would (may?) go a long
> >> way in helping with that goal.
> >
> > That goal is what I had in mind when I wrote the UTF8 class, and its
> bidirectional
> > conversions to and from wxString.  I think you can pass instances of
> UTF8 to wx functions
> > in many cases, and assign to UTF8 on function returns.
> >
> > But, you don't have all the nice translation support there.  You could
> through use wx
> > translation support and simply assign to UTF8, however.
> >
>
> I don't think translations are an issue because AFAIK we don't have any
> strings in the low level non-ui objects that needs translated but I
> could be wrong.
>
> ___
> 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] Feedback on 5.1

[José Ignacio]

One good example of a really flexible snapping system is what Autocad does
with OSNAP and OTRACK modes

Object snap (OSNAP) creates snap points from many features in the objects
or interaction between objects. an important feature is that the different
classes of snapping points active at any time are user-selectable:

[image: image.png]

Most types are self explanatory, endpoints of lines and arcs, center
points, midpoints and quadrants. extensions from endpoints and intersection
between lines, arcs, circles or combinations. When they are activated they
work as a simple "magnet" for the active tool. another very useful feature
is that the UI shows a distinctive icon for each kind of different snapping
point, so it is easy to tell if you are snapping to the correct thing. Eg
squares for endpoints, triangles for midpoints, diamonds for quadrants,
circles for centers, etc.

Object Snap Tracking (OTRACK) is the really delicious thing. if you hover
over an object snap point for a couple seconds, it "sticks", now tracks
shooting out of those points are snapping guides, and you can snap to the
intersection of such, it is hard to explain how much it improves the
drafting experience but this page does a pretty good job of describing it
with pictures: http://www.ccadinc.com/autocad-tutorials-otrack.html


I'm not saying we have to copy autocad... but the tools are a bit of an
industry standard in the drafting world and they really improve
productivity when you have to lay down lines, arcs and have all of them
line up perfectly, with some practice you can make very complex shapes
using construction geometry and the snapping system.



On Thu, Mar 14, 2019 at 3:48 AM Eeli Kaikkonen 
wrote:

> ke 13. maalisk. 2019 klo 19.51 Wayne Stambaugh (stambau...@gmail.com)
> kirjoitti:
>
>> On 3/12/2019 1:21 PM, Ruth Ivimey-Cook wrote:
>>
>> >  4. Pcb: is there a chance of a smart snap - where the editor looks for
>> > things to line up the cursor with (e.g. while moving 1 wire it looks
>> > to see if there is another wire nearly in line with it, or while
>> > moving a component it checks to see when this component is 1/2 way
>> > between two other components?)
>>
>> I'm not sure what you mean precisely mean by this.
>>
>>
> I have given thought to something like this. Technically my proposition
> would be a bit more generic.
>
> There could be an "alternative grid" which would consist of lines going
> through special points of items. Now the grid can be thought of as
> horizontal and vertical lines and each grid point has one of each. In a
> regular grid most of the lines converge, i.e. points 1,0 and 2,0 have the
> same horizontal line but different vertical lines.
>
> The proposed alternative grid would be activated with for example a
> hotkey. The normal grid would disappear. Instead there would be an
> irregular grid where every horizontal and vertical line would go through at
> least one special point of some item. Special points would be for example
> anchor points of footprints and end/start points of lines or track
> segments. When moving an item the beginning point of the movement would be
> a special point, too (like it is even now, I think, so that you can move
> horizontally without changing vertical coordinate or vice versa). The grid
> would consist of all those special points and all crossings of these
> alternative grid lines.
>
> To be really useful this should be configurable with regards to special
> points. Many footprints would be simple enough that all special points
> could be active. I would include corner points of pads to the special
> points (and would like to have an ability to grab a pad from a corner or
> from the mid point of an edge). But for most boards the alternative grid
> would soon become too crowded to be practical. Therefore the user should be
> able to select which points are used as special points. For example only
> center points of footprints or only vias or only track segments or some
> combination.
>
> This wouldn't help with finding the mid point ("1/2 way") between two
> points. But I have missed such a feature many times, especially when
> drawing outlines and other graphics. It's quite tedious to calculate mid
> points and hit or mark them.
>
> Eeli Kaikkonen
> ___
> 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] Idea: Merging libraries along the search path

[José Ignacio]

I like this, though if the UI is not made carefully it has the potential to
be confusing.

On Mon, Mar 11, 2019 at 10:13 AM Simon Richter 
wrote:

> Hi,
>
> since the topic of library management came up: Would it make sense to
> collect library contents along the library search path?
>
> The search path would always be
>
>  - project libraries (stored in the project folder)
>  - user libraries (stored in the user home)
>  - organization libraries
>  - distributor libraries
>  - upstream libraries
>
> The last three are pretty much optional, and would be just tags on the
> existing search path configuration.
>
> Rules:
>
>  - The contents of each library is determined by scanning the full path
> and merging the entries in all the libraries with the same name.
>
>  - All parts used in a project are copied to the project.
>
>  - The editor saves to user or organization paths, and doesn't ask if no
> organization exists.
>
>  - Parts altered by selecting "edit" on an instance should prompt for a
> name change, and are saved to the project and optionally also to
> user/organization.
>
>  - Selection allows filtering by source tag (making shadowed parts
> available)
>
> This would solve the problem where users modify parts from shipped
> libraries and cannot save back because they are read-only and would also
> ensure that projects contain all parts required (so we don't have to
> embed them into the files). We could also display parts in the project
> and user libraries more prominently, giving users quick access to parts
> they use often.
>
> Would that make sense?
>
>Simon
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
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 6/7] Eeschema: Field editor closes on Esc+Shift.

[José Ignacio]

great change, the current behavior of exiting with esc has bitten me in the
ass too many times to count!

On Wed, Jan 16, 2019, 7:41 AM Baranovskiy Konstantin <
baranovskiykonstan...@gmail.com wrote:

> CHANGED: By default dialog closes on Esc key immediately. But in case
> with Field editor there is no way to close a cell editor with canceling
> changes in a fields grid (it's done by pressing Esc key). The fields
> grid is the main control here and it must be the most comfortable to
> work with. So default behavior on Esc key pressing disabled in Field
> editor and for now it closes by Esc+Shift.
> ---
>  .../dialogs/dialog_fields_editor_global.cpp   |  15 +-
>  .../dialogs/dialog_fields_editor_global.h |   3 +-
>  .../dialog_fields_editor_global_base.cpp  |  90 +-
>  .../dialog_fields_editor_global_base.fbp  | 826 ++
>  .../dialog_fields_editor_global_base.h|  23 +-
>  5 files changed, 347 insertions(+), 610 deletions(-)
>
> diff --git a/eeschema/dialogs/dialog_fields_editor_global.cpp
> b/eeschema/dialogs/dialog_fields_editor_global.cpp
> index ec928e05b..868297350 100644
> --- a/eeschema/dialogs/dialog_fields_editor_global.cpp
> +++ b/eeschema/dialogs/dialog_fields_editor_global.cpp
> @@ -646,6 +646,11 @@
> DIALOG_FIELDS_EDITOR_GLOBAL::DIALOG_FIELDS_EDITOR_GLOBAL( SCH_EDIT_FRAME*
> parent
>  {
>  wxSize defaultDlgSize = ConvertDialogToPixels( wxSize( 600, 300 ) );
>
> +// Disable dialog closing on Esc key.
> +// It is necessary for a grid that also must handle this key event.
> +// Current dialog closes on Esc+Shift (see OnCharHook handler).
> +SetEscapeId( wxID_NONE );
> +
>  // Get all components from the list of schematic sheets
>  SCH_SHEET_LIST sheets( g_RootSheet );
>  sheets.GetComponents( m_componentRefs, false );
> @@ -1025,19 +1030,25 @@ void DIALOG_FIELDS_EDITOR_GLOBAL::OnSizeFieldList(
> wxSizeEvent& event )
>  }
>
>
> -void DIALOG_FIELDS_EDITOR_GLOBAL::OnSaveAndContinue( wxCommandEvent&
> aEvent )
> +void DIALOG_FIELDS_EDITOR_GLOBAL::OnSaveAndContinue( wxCommandEvent&
> event )
>  {
>  if( TransferDataFromWindow() )
>  m_parent->SaveProject();
>  }
>
> +void DIALOG_FIELDS_EDITOR_GLOBAL::OnCharHook( wxKeyEvent& event )
> +{
> +if( event.GetKeyCode() == WXK_ESCAPE && event.ShiftDown() )
> +Close();
> +
> +event.Skip();
> +}
>
>  void DIALOG_FIELDS_EDITOR_GLOBAL::OnCancel( wxCommandEvent& event )
>  {
>  Close();
>  }
>
> -
>  void DIALOG_FIELDS_EDITOR_GLOBAL::OnClose( wxCloseEvent& event )
>  {
>  // This is a cancel, so commit quietly as we're going to throw the
> results away anyway.
> diff --git a/eeschema/dialogs/dialog_fields_editor_global.h
> b/eeschema/dialogs/dialog_fields_editor_global.h
> index 4d8abfc65..a9c14818c 100644
> --- a/eeschema/dialogs/dialog_fields_editor_global.h
> +++ b/eeschema/dialogs/dialog_fields_editor_global.h
> @@ -64,7 +64,8 @@ private:
>  void OnTableItemContextMenu( wxGridEvent& event ) override;
>  void OnSizeFieldList( wxSizeEvent& event ) override;
>  void OnAddField( wxCommandEvent& event ) override;
> -void OnSaveAndContinue( wxCommandEvent& aEvent ) override;
> +void OnSaveAndContinue( wxCommandEvent& event ) override;
> +void OnCharHook( wxKeyEvent& event ) override;
>  void OnCancel( wxCommandEvent& event ) override;
>  void OnClose( wxCloseEvent& event ) override;
>  };
> diff --git a/eeschema/dialogs/dialog_fields_editor_global_base.cpp
> b/eeschema/dialogs/dialog_fields_editor_global_base.cpp
> index c261b5bc8..ab2fcf2e3 100644
> --- a/eeschema/dialogs/dialog_fields_editor_global_base.cpp
> +++ b/eeschema/dialogs/dialog_fields_editor_global_base.cpp
> @@ -1,5 +1,5 @@
>
>  ///
> -// C++ code generated with wxFormBuilder (version Dec 30 2017)
> +// C++ code generated with wxFormBuilder (version Jan 12 2019)
>  // http://www.wxformbuilder.org/
>  //
>  // PLEASE DO *NOT* EDIT THIS FILE!
> @@ -14,118 +14,119 @@
>  DIALOG_FIELDS_EDITOR_GLOBAL_BASE::DIALOG_FIELDS_EDITOR_GLOBAL_BASE(
> wxWindow* parent, wxWindowID id, const wxString& title, const wxPoint& pos,
> const wxSize& size, long style ) : DIALOG_SHIM( parent, id, title, pos,
> size, style )
>  {
> this->SetSizeHints( wxSize( -1,-1 ), wxDefaultSize );
> -
> +
> wxBoxSizer* bMainSizer;
> bMainSizer = new wxBoxSizer( wxVERTICAL );
> -
> +
> m_splitter1 = new wxSplitterWindow( this, wxID_ANY,
> wxDefaultPosition, wxDefaultSize, wxSP_LIVE_UPDATE );
> m_splitter1->SetMinimumPaneSize( 200 );
> -
> +
> m_leftPanel = new wxPanel( m_splitter1, wxID_ANY,
> wxDefaultPosition, wxDefaultSize, wxTAB_TRAVERSAL );
> wxBoxSizer* bLeftSizer;
> bLeftSizer = new wxBoxSizer( wxVERTICAL );
> -
> +
> wxBoxSizer* bGroupSizer;
> bGroupSizer = new wxBoxSizer( wxHORIZONTAL );
> -
> +
> m_groupComponentsBox = new wxCheckBox( 

Re: [Kicad-developers] [RFC] Symbol library file format

[José Ignacio]

I think all this babble about data representations to be pointless and
counterproductive. the S expression parser is already implemented and it
works fine, it is trivial to convert s-expressions to any other data
representation you like, be it, xml, json or whatever comes up next week in
NPM. The issue with the file format is really to come up with a good data
model to represent the objects in kicad, and neither protobufs nor any of
the other guys really does anything for us in that area, if anything that
is the input that needs to be given to whatever parser generator, or
manually generated parser process we choose to utilize. I think useful
comments to the proposed format should see beyond the actual low level
representation of the data and talk about the overall model being used to
store it.

On Thu, Jan 3, 2019 at 3:37 AM Andrew Lutsenko  wrote:

> Hi Martijn,
> My guess is that most of the complexity is in switching to new data model
> in eeschema, which is going to happen anyway. Since with protobufs you
> don't concern yourself with parsing data the only tricky thing would be to
> seamlessly integrate proto codegen into build process on all platforms.
> Since eeschema data model is going to change without backward
> compatibility, file compatibility is out of the window too so this is good
> opportunity to change underlying format to something that is better in the
> long run. If we decide to go this route than ideally pcbnew would switch to
> proto at some point too, not necessarily in v6.
>
> > Would it be feasible to support both in V6 and let the future tell us
> which one would prevail?
> What do you mean by prevailing? It's clear at this point that
> s-expressions are not a winner of global trends while I can guarantee that
> sizable portion of the data in the internet (except probably porn, lol) is
> exchanged in protobufs and thrift since all tech giants use them.
> If you mean in terms of what KiCad users prefer I don't think vast
> majority would care either way. Both formats are easy to edit directly and
> protos are much better for devs because codegen takes all the routine out
> of data manipulation.
> While having both formats coexist is theoretically possible I think it
> will only split the user base since people will pick one and stick to it. I
> think this is the case where devs should be empowered to make the choice,
> same as when switch to s-expressions happened.
> Of course new version still needs to be able to read old files or at least
> some conversion utility needs to be provided to migrate projects to v6 so
> s-expressions code will not be going away for some time.
>
> Andrew
>
> On Wed, Jan 2, 2019 at 11:53 PM Martijn Kuipers 
> wrote:
>
>>
>>
>> On 3 Jan 2019, at 04:17, Andrew Lutsenko  wrote:
>>
>> Wayne,
>>
>> > There are some interesting and practical concepts with protobuf but it's
>> functionally a binary storage method which I am opposed to.
>>
>> That is a somewhat common misconception because protobufs are frequently
>> used for efficient storage/transfer in binary format. But it's not tied to
>> that format at all, at it's core protobufs are just a way of defining well
>> structured data, nothing more. It comes with bells and whistles like
>> ability to serialize it in various ways, binary being one of them.
>>
>> > Encoding and decoding to a text format would be an acceptable solution.
>> Perfect, here is example of built in proto text encoder, it resembles
>> JSON in that it uses curly braces to encase submessages but doesn't abuse
>> punctuation marks unnecessarily.
>>
>> user_collection {
>>   description = "my default users"
>>   users {
>> key: "user_1234"
>> value {
>>   handle: "winniepoo"
>>   paid_membership: true
>> }
>>   }
>>   users {
>> key: "user_9b27"
>> value {
>>   handle: "smokeybear"
>> }
>>   }}
>>
>> > There is also the issue of learning curve and another build dependency.
>> Yes, that is inevitable but benefits I outlined in my earlier email are
>> too significant to overlook in my opinion.
>>
>> > S-expr is not at all like XML at least not in terms of readability.
>> It actually is a lot like XML, just less pointy brackets. Same arbitrary
>> distinctions between attributes (which are not even named in S-expr, which
>> adds to confusion when glancing at the file) and subfields.
>>
>> Here is real example:
>> (fp_text value 330K (at 0 -1.75) (layer B.Fab)
>>   (effects (font (size 1 1) (thickness 0.15)) (justify mirror))
>> )
>> or
>> (pad 2 smd rect (at 0.95 0 180) (size 0.7 1.3) (layers B.Cu B.Paste
>> B.Mask)
>>   (net 95 "Net-(R17-Pad2)"))
>>
>> Without reading file format docs and/or source code I have no idea why
>> some data is in subfields and some data is in some special fixed order on
>> the same level as it's container.
>> It's also very easy to confuse "330K" being related to "value" when in
>> fact "value" is field name and "330K" is the value. In proto that would
>> 

Re: [Kicad-developers] RFC: Moving footprint wizards to github

[José Ignacio]

I think there could be a benefit to not tying add-ins to the KiCad release
schedule. As the python APIs get more stable it will be increasingly
possible for people to run the exact same python scripts in both the stable
and nightly build versions of KiCad (or even across several versions for
stuff that really doesn't change much), helping people collaborate and stay
up to date. An example is FreeCAD's add-on repository
https://github.com/FreeCAD/FreeCAD-addons most add-ons work across several
versions including 0.18-pre. I'm not sure I love the way the add on manager
is implemented within FreeCAD (the UX is fairly rough and the
security/scalability model is questionable), but it does work quite well in
practice from an user perspective.

On Sun, Dec 16, 2018 at 10:54 AM Wayne Stambaugh 
wrote:

> On 12/15/2018 10:42 PM, Seth Hillbrand wrote:
> > Am 2018-12-15 21:09, schrieb Oliver Walters:
> >> Seth,
> >>
> >>> I like this idea.  Coupled with a build/install CMake script in the
> >>> repo
> >>> would make iterating on the Python script development faster/easier.
> >>
> >> A cmake script sounds like a good idea, would you be willing to add
> >> this to the repo?
> >
> > Sure.  But let's give a few days for any objections before moving ahead.
> >  There may be concerns that I'm not thinking of.
> >
> > -S
> >
>
> I'm not sure I like this idea.  I have no objections to scripts that are
> not distributed with KiCad to be maintained in any manner the developer
> see fit.  I would prefer that any source code that gets distributed with
> KiCad remain in the source repo.  I would not be opposed to removing the
> footprint wizards from KiCad and make them a separate project but I'm
> not sure all of our users would agree with installing them separately
> since they have been part of KiCad almost as long as the python
> scripting support.
>
> 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] Python shebangs

[José Ignacio]

I don't think this is an issue outside of Fedora.

On Tue, Nov 6, 2018 at 8:45 AM Steven A. Falco 
wrote:

> I'd like to have a discussion about python shebangs.  I noticed several
> rpmlint errors when building the official Fedora packages.  Specifically,
> rpmlint is complaining about using "env" as a method for locating the
> python interpreter.  Here are the errors:
>
> kicad-doc.noarch: E: wrong-script-interpreter
> /usr/share/doc/kicad/scripts/ddr3_length_match.py /usr/bin/env python2
> kicad-doc.noarch: E: wrong-script-interpreter
> /usr/share/doc/kicad/scripts/mk_macos_icons.py /usr/bin/env python
> kicad-doc.noarch: E: wrong-script-interpreter
> /usr/share/doc/kicad/scripts/mk_mime_icons.py /usr/bin/env python
>
> I've done a little research, and apparently, the concern is that "env" may
> find a locally installed python interpreter that doesn't work the same as
> the system python interpreter, and that can result in subtle bugs.  Of
> course the locally-installed interpreter may have been installed
> specifically because of bugs in the system interpreter!
>
> There is an interesting web page
> https://blogs.gnome.org/mcatanzaro/2018/02/16/on-python-shebangs/ that
> goes into a lot more detail about this topic.
>
> I see a few ways I can proceed.
>
> 1) Ignore the errors.  I don't know if this is viable - I have to wait a
> week or so to see if the package is accepted with the errors present.
>
> 2) Add a Fedora-only patch to change the shebangs into something
> acceptable.  I'd probably set them to "#!/usr/bin/python2".
>
> 3) Add an "exception file" to tell rpmlint to ignore these errors.
>
> 4) Have upstream KiCad "fix" the problem, although given the discussion in
> the web page above, I'm not even sure what a good fix would be.
>
> Some people have suggested having the build scripts locate the correct
> (system) interpreter to use, and patch the scripts at build-time to
> explicitly put in the absolute path to the system interpreter.  That might
> be a nice way to deal with cross-platform issues between Mac, Linux, and
> Windows but it could get messy if a later OS release puts the interpreter
> in a different place or renames it.
>
> Please let me know what you think about this so I know how to proceed.
>
> Thanks,
> Steve
>
> ___
> 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] Net ties and copper DRC

[José Ignacio]

If possible this would solve the problem quite elegantly for the time
being. +1

On Tue, Oct 23, 2018 at 8:54 AM Jeff Young  wrote:

> Hi Seth and Wayne,
>
> I had considered and discarded having DRC ignore copper graphics in
> footprints.  But the “same footprint” test didn’t occur to me, and I think
> it's just enough to make it work.
>
> Cheers,
> Jeff.
>
>
> On 23 Oct 2018, at 14:38, Wayne Stambaugh  wrote:
>
> On 10/23/2018 9:05 AM, Seth Hillbrand wrote:
>
> Am 2018-10-23 08:10, schrieb Jeff Young:
>
> So I broke our net-ties work-around when I added DRC for copper
> graphic items.
>
> I plan to add a IS_NET_TIE flag to graphic items to fix it.  (This
> appears compatible with the net tie discussions of yore on the email
> list.)  There will be a checkbox in Graphic Item Properties to set it.
>
> Question: add checkbox only to graphic items in a footprint, or to all?
>
> Any other issues you see?
>
> Thanks,
> Jeff.
>
> Note: we save the STATUS_FLAGS as an integer in the file, so while
> this constitutes a file-format change of sorts (an additional bit
> might be set), it’s fully backwards-compatible.
>
>
> Hi Jeff-
>
> What about just avoiding DRC between footprint graphic items and the
> other items in the same footprint?  That would avoid the file format
> change while keeping the purpose of the DRC (mostly).
>
>
> I like this solution better than using the status bits for something
> that really should be change in the footprint file format.  The status
> bits were really mean to be transient when editing objects.  I regret
> actually saving them in the new board file format.  It was a relic left
> over from the legacy board file format.  Hind sight is always 20/20.
>
>
> 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
>
___
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] ideas to improve patch and CI integration

[José Ignacio]

Funny you say that, Today I had to try 5 times to get a bug submitted on
LP, kept giving me internal server errors

On Mon, Oct 22, 2018 at 6:57 PM Seth Hillbrand  wrote:

> Am 2018-10-22 11:22, schrieb Wayne Stambaugh:
> > On 10/22/2018 11:10 AM, Mark Roszko wrote:
> >>> If the community edition meets the projects needs, all the better.
> >>
> >> Yep, should far more than enough. There are definitely some "nicer"
> >> features in the enterprise edition but at the same time its stuff that
> >> isn't be used right now anyway and won't really hurt anything.
> >> For further proof. GNOME uses Gitlab Community Edition
> >> now https://gitlab.gnome.org
> >>
> >>
> >>> It makes sense to do this in manageable pieces so as not to overload
> >> our great benefactor.
> >>
> >> Ah, the way it works is we can deploy and manage the stuff ourselves.
> >
> > Even setting up gitlab on their servers?  If so, that's a sweet deal.
> > I
> > probably should be kept in the loop so I can keep track of what is
> > going
> > on in the project.
> >
>
> Hi All-
>
> I would love a more modern interface to bug tracking and branch
> management.  I've used a GitLab instance for a number of projects
> locally and find that it works as expected.
>
> That said, for all of its warts, Launchpad has been remarkable stable
> with virtually 0 downtime and 0 data loss.
>
> Hosting our own stack sounds like a logistical challenge.  While gnome
> hosts their own, they also pay for a team of sysadmins [1].  Perhaps
> this also exists in the systems being referenced here but, if not, we
> might be better off utilizing either GitHub or GitLab directly.
>
> Best-
> Seth
>
> [1] https://www.gnome.org/foundation/careers/devops-sysadmin/
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Conference?

[José Ignacio]

Oooh you can count me in for any Chicago Kicad shenanigans...

On Tue, Oct 2, 2018 at 9:34 AM Wayne Stambaugh  wrote:

> I've been talking with some key players over the last month or so who
> are trying to make this happen, but I was holding off saying anything on
> the mailing list until everything was finalized.  It's still not a done
> deal but it does look like it is going to happen.  As soon as I have the
> date and venue, I will make an official announcement.  I really hope
> this happens.  It will be fun to meet up with some of the US KiCad
> developers and users who can't make it to FOSDEM.
>
> Cheers,
>
> Wayne
>
> On 10/2/2018 10:25 AM, Seth Hillbrand wrote:
> > Hi All-
> >
> > Sophi Kravitz from Hackaday mentioned to me that they are planning a
> > KiCad event in Chicago for next April (2019).
> >
> > This is the first I've heard of it.  Have they been in touch with anyone
> > on the list?
> >
> > 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
>
___
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] RFC: toolbar button support for action plugins

[José Ignacio]

Pull requests cannot be disabled on Github

On Thu, Aug 23, 2018 at 1:26 PM, Carsten Schoenert 
wrote:

> Hello Wayne,
>
> Am 23.08.18 um 20:01 schrieb Wayne Stambaugh:
> > We do not use github for kicad source development.  It is merely a
> > mirror for user convenience.  Please do not open any issues on github
> > for the kicad source mirror.
>
> I'd suggest to disable all these kind of features on GitHub then and
> mention this circumstance more in detail in the project description on GH.
>
> --
> Regards
> Carsten Schoenert
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Windows performance issue

[José Ignacio]

On Wed, Aug 8, 2018 at 3:24 PM, Jeff Young  wrote:

> It was sort of like pulling on a string: first I put the library tree into
> the footprint editor, but it made it too slow to launch.
>
>
So then I added the fp-info-cache, but it was too slow checking the cache
> validity.
>
> So then came the TimestampDir() changes. :)
>
>
It is the refactoring guide we have on IRC: https://i.imgur.com/miVHGTP.gifv



> Thanks for the help with it JP!
>
> Cheers,
> Jeff.
>
>
> On 8 Aug 2018, at 19:13, Wayne Stambaugh  wrote:
>
> On 8/8/2018 2:12 PM, jp charras wrote:
>
> Le 08/08/2018 à 18:24, Wayne Stambaugh a écrit :
>
> On 8/8/2018 10:09 AM, jp charras wrote:
>
>
>
> Le 08/08/2018 à 14:11, Jeff Young a écrit :
>
> OK, accidental commit reverted, and attached is an updated patch.
> (This time not done with diff rather than format-patch so I don’t
> accidentally commit it again.)
>
>
>
> Hi Jeff,
>
> Attached a modified patch that fixes 2  compil issues
>
> jp charras
>
>
> Hey JP,
>
> This works fine for me on 64-bit windows 10 for both 32 and 64 bit kicad
> builds.  I didn't see a huge difference in the first time library loads
> but subsequent time loads are really quick.  Feel free to merge this
> when you get a chance.  I think users will appreciate the performance
> improvements.
>
> Cheers,
>
> Wayne
>
>
> I also didn't see a huge difference in the first time library load.
> But I use only a few libraries.
>
> I just committed the Jeff's patch modified.
>
> Indeed, the fp-info-cache is a big enhancement.
>
>
>
> I agree.  Nice work Jeff and JP!
>
> 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] 5.1 UI feedback

[José Ignacio]

I like the button idea, the same thing should be done in the schematic
field editor, that would basically replace cvpcb for most usecases.

On Thu, Jul 19, 2018 at 2:53 PM, Jeff Young  wrote:

> I thought there was already a bug for this (reported by Gabriel perhaps?),
> but I can’t seem to find it.
>
>
> On 19 Jul 2018, at 20:40, Wayne Stambaugh  wrote:
>
> I second this motion.  I didn't find the right click trick so I fell
> back to cvpcb which is overkill to change the footprint of a single
> symbol.  A tooltip might be useful here as well.
>
> On 7/19/2018 3:19 PM, Diego Herranz wrote:
>
> Hi,
>
> I've started to test these changes and, on the Symbol properties dialog,
> I found it hard to assign a footprint.
> Before, there used to be a button to open the Footprint selector window.
> Now you seem to need right click on the footprint field and "select
> footprint" and that only works if you're not editing the text of that
> field. It took me a while to find out.
> I don't find it straightforward.
>
> Maybe a double-click on that field should open the Footprint selector?
> Maybe a button like attached? (Mind my poor mock-up)
> Any other suggestions?
>
> Thanks for all the work on this.
>
> Diego
>
>
>
>
>
> On Wed, Jul 18, 2018 at 6:00 PM Jeff Young  > wrote:
>
>Changes in.  Could Kevin or Wayne please post the following dialogs
>one more time:
>
>1) Change Footprints
>2) CvPCB (with footprint selected from right column)
>3) Footprint Properties
>4) Edit Track & Via Properties
>
>Thanks,
>Jeff.
>
> On 18 Jul 2018, at 15:28, Jeff Young 
>> wrote:
>
>
> Yeah, the “Show” label of the Output Messages checkboxes is
>
>misplaced too.
>
>
> I’ll have another build along shortly….
>
> Cheers,
> Jeff.
>
>
> On 18 Jul 2018, at 15:05, Kevin Cozens 
>> wrote:
>
>
> On 2018-07-18 08:32 AM, Wayne Stambaugh wrote:
>
> Attached are the updated screen shots.
>
>
> One minor point. In the first screen shot the icon with the books
>
>and magnifying glass is on the right side of the dialog the first
>time it appears but is just after the end of the entry field the
>second time it appears.
>
>
> It would look a little better if they were in the same relative
>
>horizontal position.
>
>
> --
> Cheers!
>
> Kevin.
>
> http://www.ve3syb.ca/   | "Nerds make the shiny
>
>things that
>
> https://www.patreon.com/KevinCozens | distract the
>
>mouth-breathers, and
>
>| that's why we're powerful"
> Owner of Elecraft K2 #2172  |
> #include  | --Chris Hardwick
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
>
>
>
> Post to : kicad-developers@lists.launchpad.net
>
> >
>
> Unsubscribe : https://launchpad.net/~kicad-developers
>
>
>
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
>
>
>
> Post to : kicad-developers@lists.launchpad.net
>
> >
>
> Unsubscribe : https://launchpad.net/~kicad-developers
>
>
>
> More help   : https://help.launchpad.net/ListHelp
>
>
>
>___
>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 : 

Re: [Kicad-developers] ngspice-28 for KiCad

[José Ignacio]

That is great news! Is debian packaging underway for testing now that it is
DFSG compliant?

On Tue, Jun 12, 2018 at 2:29 PM, Holger Vogt  wrote:

> Dear developers,
>
>
> ngspice-28 is available. Please check if this can be part of the new KiCad
> release.
>
>
> Major advances:
>
> ngspice-28 reads device libs with PSPICE syntax (no more manual tweaking
> of device vendors' device libraries)
>
> All licenses involved are DFSG compatible (no more mixing of free and
> unfree software in Debian etc.).
>
> A power device model VDMOS is available
>
> pkg-config is generated
>
>
> I have made some successful tests with recent KiCad nightly on Windows
> using the demos delivered by KiCad.
>
>
> Holger
>
>
> ngspice maintainer
>
>
> ___
> 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] Netlist generation for pins with no-connects

[José Ignacio]

Btw, I noticed nets don't get generated when the symbol is missing pins
(does not include all the non-connect pins), which i consider to be
defective symbols.

On Mon, Jun 4, 2018 at 10:46 PM, José Ignacio  wrote:

> Non-connected pins should each have an unique net to prevent connection to
> eachother, either that or a special net that behaves that way. In pcbnew,
> pins with no net assigned can be connected to eachother (and that can be an
> useful behavior when doing things on pcbnew only).
>
> On Mon, Jun 4, 2018 at 9:38 PM, Jon Evans  wrote:
>
>> Hi all,
>>
>> In the current netlisting algorithm, pins with no-connects sometimes
>> appear in the netlist, with auto-generated names like Net-(U1-Pad1).
>>
>> This seems to not always happen, but I haven't investigated why yet,
>> since I'm approaching netlisting from a different direction with my new
>> connectivity algorithm.  In my algorithm, a pin with a no-connect attached
>> will never generate an entry in the netlist.
>>
>> Is there some reason we should be including these pins on the netlist?
>> It seems like if they are marked as no-connects and don't actually connect
>> to anything, we shouldn't be forwarding them to the layout.
>>
>> -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] Netlist generation for pins with no-connects

[José Ignacio]

Non-connected pins should each have an unique net to prevent connection to
eachother, either that or a special net that behaves that way. In pcbnew,
pins with no net assigned can be connected to eachother (and that can be an
useful behavior when doing things on pcbnew only).

On Mon, Jun 4, 2018 at 9:38 PM, Jon Evans  wrote:

> Hi all,
>
> In the current netlisting algorithm, pins with no-connects sometimes
> appear in the netlist, with auto-generated names like Net-(U1-Pad1).
>
> This seems to not always happen, but I haven't investigated why yet, since
> I'm approaching netlisting from a different direction with my new
> connectivity algorithm.  In my algorithm, a pin with a no-connect attached
> will never generate an entry in the netlist.
>
> Is there some reason we should be including these pins on the netlist?  It
> seems like if they are marked as no-connects and don't actually connect to
> anything, we shouldn't be forwarding them to the layout.
>
> -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] [PATCH] Large board speed

[José Ignacio]

+1!

On Fri, Jun 1, 2018 at 12:57 PM, Simon Richter 
wrote:

> Hi,
>
> On 01.06.2018 06:36, Seth Hillbrand wrote:
>
> > Do people have concerns with the risk exposure for this patch or would
> > anyone like some additional time to evaluate?
>
> I think this needs a round of user testing, and doing it this late in
> the 5.0 cycle (post rc2) would delay the release.
>
> If we're going to have 5.x minor releases, that would be a better
> target. We now have two changes that need extensive testing but should
> not behave semantics:
>
>  - gtk3
>  - connectivity speedup
>
> How this is mapped to releases is up to Wayne, I think. We could have a
> 5.1 with both features (so we have to ask only once for testing), or
> have one in 5.1, one in 5.2 (so testing is more focused).
>
>Simon
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
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] More default fields in schematic

[José Ignacio]

Kicad v5 has that feature, it's called the field editor.

On Sun, May 20, 2018 at 5:27 PM, Andrey Kuznetsov <kandre...@gmail.com>
wrote:

> I agree, I had the same issue when I was doing my board, I needed a field
> for all components, and I had to manually add it for every item, there was
> no way to add this field to all components at the same time or to have it
> add by default from the addition of a new component to the sheet.
>
> Which reminds me, Cadence Designer has tools to manipulate fields on a
> large scale, whether to add, delete, show, hide, etc, this is something
> that would be nice to have in KiCAD, either that or a table of all
> components for the sheet or schematic and columns for each field, with
> ability to show/hide each cell individually.
>
> I think the ultimate goal is to make the Symbol Table more useful, but
> that'll take to long for v5 so if Kristoffer's patch allows an easy way to
> add fields to all components or similar, I'd say do it because people will
> be pissed and waste their time doing it for every component in their
> schematic.
>
> On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark <
> kristofferodmar...@gmail.com> wrote:
>
>> I obvviously disagree, the correct solution would be to have both. This
>> does not hinder that, its not even the same problem.
>>
>> The problem is for everyone who want for example the Manufacturer Part
>> Number will have to define a fieldname, which every time
>> results in them abbreviating it to something different. Hence nobody can
>> work with Manufacturer Part Numbers.
>>
>> Here is something similar, Imagine all of the colours in Kicad for all of
>> the layers where white by default. Have fun defining all the colours
>> yourself.
>> Maybe you want to define them yourself, nobody is stopping you now
>> either, just get cracking.
>>
>> How easy would it be for you to look at the board someone else made later
>> and understand what is what? Maybe for some that is a better solution, but
>> for me that
>> would be an extreme example of bad default values.
>>
>> This is how the default fields are now, they are white, or more like
>> see-throught, which makes life harder for anyone that
>> wants to contribute or create tools that interact with kicad, and as I
>> previously said, this is only a default, you are still
>> equally able to add/remove or change the fields how you want to. But,
>> tools like kibom or various other web-based tools can much
>> easier integrate to it, or at least support a default value as well. So
>> for the majority of users, who doesnt change defaults,
>> the tool would just work.
>>
>> I will reiterate, I do not care what they are named, I want a default
>> field where I can put my manufacturer part number, amongs others.
>> The specific abbreviation or name does not matter, If i care, I can
>> manually add/remove my own fields *JUST AS I DO NOW*, but for the people
>> who use it, it will be easier across projects, for the people that dont,
>> It will not matter.
>>
>> Sane defaults matter. A lot actually.
>>
>> - Kristoffer
>>
>> On 2018-05-20 23:40, José Ignacio wrote:
>>
>>> I dont like this, the right solution would be to allow for importing a
>>> default config into kicad for things like that, as different groups will
>>> have different policies.
>>>
>>> On Sun, May 20, 2018 at 3:31 PM, Kristoffer Ödmark <
>>> kristofferodmar...@gmail.com <mailto:kristofferodmar...@gmail.com>>
>>> wrote:
>>>
>>> The patch should only affect first startup, changes to the fields
>>> will be saved
>>>
>>> On May 20, 2018 22:18, "Seth Hillbrand" <seth.hillbr...@gmail.com
>>> <mailto:seth.hillbr...@gmail.com>> wrote:
>>>
>>> ​Hi Kristoffer-
>>>
>>> This feels like a management issue rather than a tool issue.
>>> If the user doesn't want any extra fields, how would your
>>> patch allow that?
>>>
>>> -S
>>>
>>>
>>> Am So., 20. Mai 2018 um 13:00 Uhr schrieb kristoffer Ödmark
>>> <kristofferodmar...@gmail.com
>>> <mailto:kristofferodmar...@gmail.com>>:
>>>
>>>
>>> Hello!
>>>
>>> I will open this can of worms again, I feel that I have
>>> to. So from what
>>> I gather we have proffessionals as the main aim in Kicad.
>>> The

Re: [Kicad-developers] More default fields in schematic

[José Ignacio]

I dont like this, the right solution would be to allow for importing a
default config into kicad for things like that, as different groups will
have different policies.

On Sun, May 20, 2018 at 3:31 PM, Kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:

> The patch should only affect first startup, changes to the fields will be
> saved
>
> On May 20, 2018 22:18, "Seth Hillbrand"  wrote:
>
> ​Hi Kristoffer-
>
> This feels like a management issue rather than a tool issue.  If the user
> doesn't want any extra fields, how would your patch allow that?
>
> -S
>
>
> Am So., 20. Mai 2018 um 13:00 Uhr schrieb kristoffer Ödmark <
> kristofferodmar...@gmail.com>:
>
>> Hello!
>>
>> I will open this can of worms again, I feel that I have to. So from what
>> I gather we have proffessionals as the main aim in Kicad.
>> The reason I will open this issue again is that I feel we have a
>> collaboration issue, maybe not a mayor one. But one nonetheless.
>>
>> We really need more default fields for our schematic symbols. Im not
>> proposing required fields, I am *ONLY* proposing that
>> there should be default fields added into the default fields settings
>> tab. I am not proposing they need to be filled in the
>> libraries, nor that people need to use them. only that they need to
>> exist with a fresh install of kicad so that easy problems
>> such as theese do not happen:
>>
>>  - Collaborators working on the same project will not create
>> duplicate fields in libs/projects describing the same thing by mistake
>>  - Projects that aim to interact or add to Kicad can assume that the
>> Fields will exist, and will know what name/tag to look for
>>(bom exporters, price checkers, MacroFab, etc)
>>  - Open source projects will be easier to collaborate, read and order
>>
>> The reason I think it is better to have the fields by default than the
>> current solution to add them is that the majority will use
>> what exists, and tools can support it from the very beginning, people
>> with inhouse tools seems to dislike this, since they map their
>> parts with an inhouse number - and then handle the information about the
>> part there. From what I gather, this is not the majority, and
>> these persons still modify the default fields settings.
>>
>> I spent maybe 30-40 mins checking the "made with kicad" projects, I
>> found that the most common addition to libs and schematics are:
>>  - Manufacturers part number, these were named widely different in
>> projects, (BOM, MP, MPN, #mfg, or different syntaxes in the Value field )
>>  I even saw a mix of these in the same project once, along with
>> some people having the vendor id only.
>>  - Manufacturer ( found some different languages though )
>>
>> more uncommon things was, Tolerance( 10%, 20pps), Ratings ( 1/4W, 85C,
>> 16V ), Vendor information and different Descriptions. They were named
>> and abbreviated
>> very differently accross projects.
>>
>> What I would like to see is these additional fields by default, but
>> hidden from the schematic unless changed by user.
>>  Tolerance ( used for setting tolerances of resistors, capacitors,
>> oscillators, etc )
>>  MaxRating ( field were one can specify max Voltage, Ampere,
>> Frequency, or whatever the component needs )
>>  Manufacturer ( For inhouse numbers, they could either just remove
>> it, or use the company/group name )
>>  MPN ( Maybe PartNumber could be used here, and people who use
>> inhouse numbers use it aswell, I dont really care what its called, as
>> long as its called something )
>>  Vendor
>>  Notes
>>
>> I would be all up for extra additions/removals, but I would prefer if
>> the naming is not discussed, but rather just decided/agreed upon by
>> someone in the lead team.
>> The very least I think should be added in case the previous is to much
>> are:
>>  Tolerance
>>  Manufacturer
>>  MPN
>>
>> I attach a patch for the minimal set, tested on linux by removing the
>> .config/kicad/eeschema file.
>>
>> - Kristoffer
>>
>>
>> ps
>> Some github files i reviewed, not all:
>> https://github.com/AnaviTechnology/anavi-gardening/blob/master/MCP3002-
>> I_SN.lib
>> https://github.com/jonpe960/blixten/blob/master/Blixten%
>> 20LED%20Device/Blixten.sch
>> https://github.com/paltatech/half-bridge/blob/master/pcb%
>> 20design/IGBT_board-cache.lib
>> https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_smd.lib
>> https://github.com/jim17/memtype/blob/master/schematic_
>> pcb/electronic_design_kicad/electronic_design_kicad.sch
>> ___
>> 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] Feature request : Allow hide of Fab text reference designation

[José Ignacio]

That is a library issue, the way it is implemented in the kicad library is
making a text that references the refdes with "%R", that looks like a
normal text to kicad, so it has no way of knowing unless it gets tailored a
bit too specific to that library style. In my particular case i do not use
the kicad standard library (partly for that reason) and get the reference
designators in my fab aids by compositing the silkscreen layer onto the fab.

On Wed, May 2, 2018 at 4:41 PM, Brian Piccioni 
wrote:

> Sorry if this is not the correct venue for this request, of it has already
> been addressed.
>
>
>
> The issue:
>
>
>
>1. Reference designation is presented in the silkscreen and duplicated
>in many library parts as a FAB layer text.
>2. Silkscreen text is usually manually adjusted to make it readable
>prior to manufacturing.
>3. The position of the FAB layer reference designation is independent
>of the Silkscreen reference designation.
>4. Fab layer typically has part number, value or other information.
>5. As an assembly aid, it may be desirable to print the Fab layer.
>6. Because the Fab layer reference designation position is independent
>from the silkscreen reference designation, to print the Fab layer all Fab
>layer reference designation has to be manually adjusted to make it line up
>properly (i.e. like the silkscreen).
>7. This is redundant and unnecessary as the silkscreen reference
>designation has already been moved.
>8. It is easier to simply hide the Fab lay reference designation and
>print both the silkscreen and fab layer.
>
>
>
> Therefor I suggest a mechanism (perhaps in the Layers menu or Set Text
> Size menu) which selectively hides/unhides Fab layer reference designation.
>
> ___
> 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] Spate of bugs in global fields editor (aka BOM editor)

[José Ignacio]

Got you a fresh batch

https://bugs.launchpad.net/kicad/+bug/1765443 <- this one helped me lose a
few hours of work
https://bugs.launchpad.net/kicad/+bug/1765446
https://bugs.launchpad.net/kicad/+bug/1765447

On Tue, Apr 17, 2018 at 5:59 AM, Jeff Young  wrote:

> Turned out to either be not as bad as I thought, or most of the work will
> be in fixing my 6.0 tree.  Either way, I merged it into master.
>
> Should fix:
>
> https://bugs.launchpad.net/kicad/+bug/1749287
> https://bugs.launchpad.net/kicad/+bug/1737361
> https://bugs.launchpad.net/kicad/+bug/1759756
> https://bugs.launchpad.net/kicad/+bug/1763223
> https://bugs.launchpad.net/kicad/+bug/1761378
>
>
>
> > On 16 Apr 2018, at 18:26, Wayne Stambaugh  wrote:
> >
> > Please let me know how much effort is involved on your part and we can
> > make a decision from there.
> >
> > Thanks,
> >
> > Wayne
> >
> > On 4/16/2018 1:18 PM, Jeff Young wrote:
> >> Can I?  Certainly.
> >>
> >> Without tearing my hair out?  Much more questionable. ;)
> >>
> >> I’ll look into it….
> >>
> >>> On 16 Apr 2018, at 18:10, Wayne Stambaugh 
> wrote:
> >>>
> >>> Is there any way you could do this without dragging in all of the other
> >>> changes?  If we cannot fix the current table editor, I'm OK with
> >>> updating to the wxGrid based design but I would prefer to keep the
> >>> changes to just the table editor.
> >>>
> >>> On 4/16/2018 6:02 AM, Jeff Young wrote:
>  Given the spate of bug reports recently on the global fields editor
> (the spreadsheet icon in eeschema), I’m thinking perhaps I should back-port
> my 6.0 rewrite which moves it to wxGrid.
> 
>  The implementation itself seems pretty sound, but does drag one other
> change list along with it (for dialog consistency and beautification) that
> adjusts the layouts and icons of a bunch of dialogs to be more consistent.
> 
>  Thoughts?
>  ___
>  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] What is the purpose of multiple 3D models?

[José Ignacio]

I use this feature for components that may have multiple bodies, like a
battery inside a battery holder, or the mating board into a connector. It
is great for making rudimentary assemblies as kicad cant place any bodies
that are not associated with a component.

On Fri, Mar 30, 2018 at 5:02 PM, Jeff Young  wrote:

> A footprint can have several 3D models associated with it (confusingly
> named 3D Shape Names in the dialog, but never mind that).
>
> What is the purpose of this?
>
> Is it so that library devs can add different formats and the renderer will
> choose the first it has a plugin for?
>
> If so, we need to say that in the UI.  Right now if you add two models,
> selecting between them has no effect.  (That makes sense if the above is
> true and you as a user have figured that out, but is confusing as all heck
> otherwise.)
>
> But that also means you might want to order them (so that a preferred one
> will be selected over a fall-back if both plugins are available), no?
>
> Or is it for some other reason entirely?
>
> Thanks,
> Jeff.
> ___
> 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] - File format shim for clearance data

[José Ignacio]

The user would have to click through a big fat warning that the file is
from the future. If you wanna be doubly sure, open things in read only mode
if there is a version mismatch, so the user at worst can save the file with
another name, allowing recovery without having to drop into a text editor.


On Tue, Mar 20, 2018 at 9:48 AM, Wayne Stambaugh 
wrote:

> Jeff,
>
> I wanted some time to think about this.  It has been discussed before.
> While I'm not completely opposed to it, I still haven't found a more
> compelling argument to convince me that it is a better idea than using
> strict parsing.  As a user, it does have a certain appeal.  As a
> developer, it opens a Pandora's box of issues that once they are in
> play, could be extremely difficult to reverse.  Please see my responses
> below.
>
> On 3/20/2018 9:40 AM, Jeff Young wrote:
> > @Wayne, did you have any thoughts on this iteration?
> >
> >> On 20 Mar 2018, at 10:22, Jeff Young  >> > wrote:
> >>
> >> Oh, and I don’t think this materially alters the support equation: we
> >> already have to deal with hand-edited boards, so what’s in the file is
> >> never guaranteed to be something Kicad put there.
>
> True, but this is one of the reasons that the board parser is strict.
> It is immediately obvious what doesn't belong in the file.  Also, in the
> past users have tricked eeschema and pcbnew into a feature that didn't
> technically exist by taking advantage of the loose file parsing.  Then
> when something changed internally and their clever hacks were broken, we
> ended up with bug reports.  I do not want to repeat this again.
>
> >>
> >>> On 20 Mar 2018, at 10:19, Jeff Young  >>> > wrote:
> >>>
> >>> Hi Seth,
> >>>
> >>> The original version spit out log entries for skipped elements.  This
> >>> version follows the XML/browser convention of silently ignoring.
> >>>  Even though this isn’t an XML format, I think we need to recognise
> >>> that we live in an XML world and XML processing conventions set
> >>> expectations.
>
> After reading this, I am even more thankful that we didn't choose XML
> for our file format.  Gleefully ignoring file syntax that the parser
> doesn't understand IMO is a bad idea.  This flies in the face of the
> basic premise that we control the format of our files not someone else.
> As soon as you allow others to dictate your file format, you are in
> trouble.
>
> >>>
> >>> The patch strictly checks everything for round-tripping so that there
> >>> is no data loss.  The pad stuff is really a separate issue: it was
> >>> meant to be loose only during development and then tightened up, but
> >>> the tightening step was forgotten.  Since we don’t store pad stuff we
> >>> don’t understand, it has to be tightened.  In short: if you can round
> >>> trip stuff you don’t understand then do so; otherwise throw.
>
> The round tripping is fine and makes sense but it also adds to the code
> complexity of the parser.  The pad issue is different.  I don't know
> when that was slipped into the parser but it should not be there.  If
> there is an unexpected token, that should flag a file load error.
>
> >>>
> >>> Certainly one use case is opening boards from future versions.  If
> >>> you edit them, then you’re at your own peril.  This behaviour is
> >>> common enough that I believe it is well understood (although we
> >>> should obviously mention it in a version-check dialog).
>
> Perhaps, but I just see this ending badly.  Maybe I'm being paranoid
> here but it's so easy to imagine a scenario where someone did a lot of
> editing in a newer version of kicad then makes the fatal mistake of
> opening the board in an older version of kicad and wipes out a lot of
> work.  Technically not kicad's fault but I'm not so sure the user will
> see it that way.
>
> >>>
> >>> Another use case is 3rd-party tools (which might even be written as
> >>> Python plugins) that want to carry their own stuff around in the
> >>> board.  These might even be processing/manufacturing instructions
> >>> that don’t have any visual expression in Kicad anyway.
>
> This is one of the primary reasons that I do not like ignoring unknown
> file formatting.  It creates the potential for name space pollution that
> could cause issues down the road.  The eventual goal is to implement the
> "property" token to define key/value pairs for third party applications
> to add user specific information to any board object without polluting
> the controlled part of the file format.  The beauty of this is that we
> do not have to coordinate with 3rd party developers to ensure we are not
> clashing with anything the are working on.  They are free to add
> whatever properties they would like while we still maintain strict file
> parsing.  This was always part of the grand plan for the board file
> format that kind of got lost in the noise and me becoming project leader.
>
> Cheers,
>
> 

Re: [Kicad-developers] small typo

[José Ignacio]

Bad keming strikes again!

On Thu, Mar 15, 2018 at 4:34 PM, Marco Ciampa  wrote:

> Here is a small typo:
>
> diff --git a/gerbview/toolbars_gerber.cpp b/gerbview/toolbars_gerber.cpp
> index 2c774baad..58e3c9163 100644
> --- a/gerbview/toolbars_gerber.cpp
> +++ b/gerbview/toolbars_gerber.cpp
> @@ -524,7 +524,7 @@ void GERBVIEW_FRAME::OnUpdateCoordType(
> wxUpdateUIEvent& aEvent )
>  m_optionsToolBar->SetToolShortHelp( ID_TB_OPTIONS_SHOW_POLAR_
> COORD,
>  
> m_DisplayOptions.m_DisplayPolarCood
> ?
>  _( "Turn rectangular
> coordinates on" ) :
> -_( "Tunn polar coordinates
> on" ) );
> +_( "Turn polar coordinates
> on" ) );
>  }
>
> TIA
>
> --
>
>
> Marco Ciampa
>
> I know a joke about UDP, but you might not get it.
>
> 
>
>  GNU/Linux User #78271
>  FSFE fellow #364
>
> 
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Proposed roadmap changes

[José Ignacio]

The separate program issue is just an implementation detail. The main thing
that Kicad is headed for is the refactoring slated for the 6.0 dev cycle.
The cleaner data structure foundation and subsequent decoupling of the
logic from the UI classes will allow all sorts of automation that are
currently very hard or impossible. The vision that was set since over 5
years ago was for Kicad to present a library-like interface to the outside
world. It kind of does now on PCBnew only, but things are slowly improving
as things get refactored and legacy code gets phased out.

I honestly think the last thing Kicad needs right now is a chance of
direction, I speak as a user that has been using Kicad professionally for
just over 2 years now, working on dozens of PCB projects over that time.
The developments in the past few years have been nothing but awesome for a
project with Kicad's resources. We just need to be patient, or try to help
out in a constructive manner.

Over the past couple years I have been using the dev version in production
to take advantage of the new features (dealing with versions/instability
was a small price to pay for me), I also helped a little bit (as time
allowed) with the occasional patch or grumpy bug report. I'd like to thank
everyone that has worked on the project so far; It basically has made it
possible for me to make a living doing what I enjoy, and I really hope the
project can retain the momentum it has built up in the past few months, it
just keeps getting better!

Thanks,
Jose

On Wed, Mar 7, 2018 at 8:21 PM, Ouabache Designworks 
wrote:

>
>
> On Wed, Mar 7, 2018 at 3:08 PM, Tomasz Wlostowski <
> tomasz.wlostow...@cern.ch> wrote:
>
>>
>> Which features you think should go to separate programs?
>>
>
> Export netlist for one. It is a simple addition as long as your design
> fits completely
> on the sheet that you are editing but what happens if you have a
> multisheet design?
> Now you have to locate and read  all those other sheets from files.  What
> used to
> be a graphics editor now has to deal with a lot of other problems that
> have nothing
> to do with placing and displaying graphics.
>
> What happens if you edit a schematic, export the netlist and are
> interrupted before
> you can save the schematic?  That might only happen one time out of a
> thousand
> but you now have a corrupt database where the schematic file doesn't match
> the
> netlist. Kicad is getting enough users to make that a real problem. We
> need to
> go through and prevent that from every occurring in the first place. You
> can
> do that by placing the netlister in a separate program that only operates
> on
> the outputed files.
>
> DRC has the same problem in that it depends on data that has to be located
> and
> read in from other files.
>
>
>>
>> Bear in mind that most PCB designers don't like the 'unix-style'
>> workflow, if by that you mean writing makefiles, shell scripts or other
>> programming just to stitch different 'independent programs that do their
>> particular jobs well' together.
>
>
> The user doesn't do the stitching. The tool smith does. EEschema will call
> a
> netlist or DRC program to operate on the schematic files rather than on the
> design image in memory.
>
>
> >
>> > Create a Pad Mux tool that lets you codesign the IC package and pinout
>> > as part of the IC design team. That is the ultimate in pin swapping
>> > capability.
>> >
>> Kicad is a PCB design tool. We don't aim to become an IC design tool.
>>
>> Tom
>>
>
> I used to be a PCB design engineer until I switched over to design IC's.
> My tools
> did not change, all I did was change libraries. It was great. My
> deliverable to the
> board designer was the symbol that they used for my chip. It was easy to
> work
> together have them try out different pinouts before we had to release.
>
> That was back in the 90's. 10 years later our tools had diverged enough
> that on my
> latest chips the tool that we used to collaborate between the IC and PCB
> teams was
> a spreadsheet. The system architects that used to use schematic capture to
> create
> their block diagrams had switched over to using microsoft visio. We can do
> a lot  better.
>
> EEschema would make a great engineering tool for a lot of engineers if it
> only had two
> additional features. The first is true hierarchy and the second is
> heterogeneous buses.
> I understand that Jon Evans has the bussing working and we could deal with
> the hierarchy
> by writing out the data and processing it in separate programs.
>
>
> 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 : 

Re: [Kicad-developers] Proposed roadmap changes

[José Ignacio]

Only jon can edit, our "edits" are just suggestions, which can be accepted
or rejected.

On Tue, Mar 6, 2018 at 1:33 PM, Wayne Stambaugh 
wrote:

> I'm fine with using this for bike shedding as long as the results get
> updated in the actual road map and this is not the official road map.
> One caveat, by allowing anyone to edit this file, you may loose control
> of it's content.  That's one of the things I don't like about launchpads
> blueprints.  I also don't want this to turn into a popularity contest.
> We have to make sensible decisions based upon project requirements and
> manpower limitations so all final decisions are made by the lead
> development team.
>
> On 3/5/2018 12:57 PM, Jon Evans wrote:
> > Hi all,
> >
> > Since my day job involves a lot of engineering planning/timelines/etc,
> > I've had this rolling around in my head...
> > I started brainstorming some proposed changes to the roadmaps.
> >
> > I am using Google drive because that's what is easiest for me to play
> > with; I'm happy to send patches against the official roadmaps if get
> > some buy-in for this.
> >
> > Feel free to comment (either directly on the doc or by email) with
> > thoughts on this.
> >
> > https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF
> 7ooTtcT_HU86kw/edit#
> >
> > Basically what I am proposing is to put most of the energy into Eeschema
> > for 6.0, with changes to other parts of the software basically being
> > "whatever people have time left over for".  Everything else has been
> > bumped to 7.0
> >
> > -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] Rearrange Render panel of PcbNew layer widget; add spacers

[José Ignacio]

I couldn't find it so I reported
https://bugs.launchpad.net/kicad/+bug/1751171

On Thu, Feb 22, 2018 at 6:34 PM, Jon Evans <j...@craftyjon.com> wrote:

> Is there already a bug report for that?  We should make sure to keep track
> of all this so if someone has time to do some kind of settings-saving
> overhaul for V6 we catch all of that stuff.
>
> On Thu, Feb 22, 2018 at 7:31 PM, José Ignacio <jose.cyb...@gmail.com>
> wrote:
>
>> One thing that is very inconsistent is that layer settings for plotting
>> gerbers are saved in the board file (as they should), but settings for the
>> drill file are saved in the global kicad settings (which means that if i
>> have two different projects that need different drill settings i need to
>> remember to change them back and forth). In an ideal world those settings
>> would be saved in a CAM file with the project, but having them saved in the
>> board file is the second best.
>>
>> On Thu, Feb 22, 2018 at 3:28 PM, Eeli Kaikkonen <eeli.kaikko...@gmail.com
>> > wrote:
>>
>>>
>>>
>>> 2018-02-22 23:05 GMT+02:00 Tiger12506 <tiger12...@gmail.com>:
>>>
>>>> I agree 100% on separate file. As someone who puts kicad files in git,
>>>> the most irritating thing in the world is having unrelated changes in your
>>>> diff. Separate file gives you the flexibility to have either situation --
>>>> if you want the vcs to track it, you include the file, if you don't, your
>>>> vcs ignores the file. It's unfortunate that there are already UI states in
>>>> any of the files that represent a design.
>>>>
>>>> Cheers. :)
>>>>
>>>>
>>> I agree, too. As a both end user and someone who has studied usability I
>>> know the current situation creates unnecessary cognitive and emotinal
>>> stress for the end user. Many times a user can't be sure or can't remember
>>> what he/she actually did or if he did something by accident. Seeing the
>>> message that something was changed is disturbing because you can't know
>>> what happened and what will be saved. If the non-design-related data would
>>> be in a separate file it wouldn't even have to be asked about IMO because
>>> it's safe to save always, it's not critical data in any way.
>>>
>>> But about the compatibility between versions - what kind of
>>> compatibility would be needed? I just tried deleting the layers section
>>> from a board file. Pcbnew opened it happily. So, let's suppose v5.1 is
>>> released later with this change in file format: extra data is not stored in
>>> the kicad_pcb file but in another file. If the project is created with 5.1
>>> then 5.0 can read it, it just doesn't restore the layer visibility. How
>>> serious would that be? If the project was created with 5.0, then 5.1 could
>>> also handle it (if the code which reads the file wasn't changed). It could
>>> either save the data in the compatible way or take it off from the design
>>> file and move it to the other file.
>>>
>>> How KiCad reacts to removing other non-design data from the file, I
>>> don't know.
>>>
>>> Eeli Kaikkonen
>>>
>>> ___
>>> 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] Rearrange Render panel of PcbNew layer widget; add spacers

[José Ignacio]

One thing that is very inconsistent is that layer settings for plotting
gerbers are saved in the board file (as they should), but settings for the
drill file are saved in the global kicad settings (which means that if i
have two different projects that need different drill settings i need to
remember to change them back and forth). In an ideal world those settings
would be saved in a CAM file with the project, but having them saved in the
board file is the second best.

On Thu, Feb 22, 2018 at 3:28 PM, Eeli Kaikkonen 
wrote:

>
>
> 2018-02-22 23:05 GMT+02:00 Tiger12506 :
>
>> I agree 100% on separate file. As someone who puts kicad files in git,
>> the most irritating thing in the world is having unrelated changes in your
>> diff. Separate file gives you the flexibility to have either situation --
>> if you want the vcs to track it, you include the file, if you don't, your
>> vcs ignores the file. It's unfortunate that there are already UI states in
>> any of the files that represent a design.
>>
>> Cheers. :)
>>
>>
> I agree, too. As a both end user and someone who has studied usability I
> know the current situation creates unnecessary cognitive and emotinal
> stress for the end user. Many times a user can't be sure or can't remember
> what he/she actually did or if he did something by accident. Seeing the
> message that something was changed is disturbing because you can't know
> what happened and what will be saved. If the non-design-related data would
> be in a separate file it wouldn't even have to be asked about IMO because
> it's safe to save always, it's not critical data in any way.
>
> But about the compatibility between versions - what kind of compatibility
> would be needed? I just tried deleting the layers section from a board
> file. Pcbnew opened it happily. So, let's suppose v5.1 is released later
> with this change in file format: extra data is not stored in the kicad_pcb
> file but in another file. If the project is created with 5.1 then 5.0 can
> read it, it just doesn't restore the layer visibility. How serious would
> that be? If the project was created with 5.0, then 5.1 could also handle it
> (if the code which reads the file wasn't changed). It could either save the
> data in the compatible way or take it off from the design file and move it
> to the other file.
>
> How KiCad reacts to removing other non-design data from the file, I don't
> know.
>
> Eeli Kaikkonen
>
> ___
> 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] Stable branch update

[José Ignacio]

This is a bit of a pet issue. the original patch introduced a regression
(text suddenly got flipped upside down because of the way it was saved and
the way kicad restricted text angles), that later was fixed, but the fix
only worked correctly for files created before the change (regression) was
introduced. Thus the "regression" kevin refers to was just the restoration
of the original behavior for files _from the previous released version of
KiCad_, Using the dev version carries a small risk of having to manually
change your files as kicad can only really promise to open successfully
files from actual released versions of the software (though in general it
has done a pretty damn good job at keeping continuous compatibility
throughout the development of this new series).

On Mon, Feb 12, 2018 at 5:01 PM, Marco Ciampa  wrote:

> On Mon, Feb 12, 2018 at 02:14:41PM -0500, Kevin Cozens wrote:
> > On 2018-02-12 12:52 PM, Wayne Stambaugh wrote:
> > >Obviously I did not get the stable 5 branch created over the weekend.  I
> > >was busy patch reviewing and merging.
> > [snip]> I should be able to get v5 branched this weekend so going
> forward we
> > >have a few bugs tagged for rc2 which I'm hoping take less than a month
> > >to complete.
> >
> > Text rotation in pcbnew is another item that needs to be looked at
> (again).
> > I provided a patch to allow R to rotate text to any multiple of 90
> degrees.
> > Since the patch was accepted in to the code base some other code change
> has
> > limited the rotations of text to 0 or 90 degrees once again. Half the
> text
> > on a PCB of mine is now upside down.
> >
> > I've been busy on a couple of projects so I haven't yet filed a bug
> report
> > about this regression. I will file a report asap.
>
> Hi Kevin,
> since it seems to me that it is not the first time I see this kind of
> regressions happen to KiCad, I wonder why this happens and also if there
> is a way to avoid it, for example a more strict workflow to commit
> patches or to do more atomic changes or to use more git rebase instead
> of merge and so on ...
>
> I am _not_ a developer so I might have said something incorrect or naïve
> but I am curious and I cannot resist to ask ... sorry for the noise...
>
> TIA
>
> Best regards,
>
> --
>
>
> Marco Ciampa
>
> I know a joke about UDP, but you might not get it.
>
> 
>
>  GNU/Linux User #78271
>  FSFE fellow #364
>
> 
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Allow OpenCASCADE standard edition

[José Ignacio]

I think you might be confusing the GPL with the *L*GPL, they are very
different licenses in practice

On Mon, Jan 29, 2018 at 2:04 PM, Wayne Stambaugh 
wrote:

> Hey Seth,
>
> One of us missed something.  Here is my interpretation:
>
> The opencascade website license states:
>
> "Open CASCADE Technology version 6.7.0 and later are governed by GNU
> Lesser General Public License (LGPL) version 2.1 with additional
> exception."
>
> It makes no mention of later versions of the LGPL (including the
> exception) so I am interpreting this as v2.1 only.  I do not have a copy
> (and I'm not going to sign up to get a copy so please check the
> copyright in the source to see if it matches the website) of the
> opencascade source archive to see if the license in the source
> specifically states "v2.1 or (at your option) any later version" which
> is typically how the GPL and LGPL are used.  If it does, than I can
> safely add this patch because I can make the claim that I am using
> opencascade under at later version of the LGPL which is compatible with
> the GPL 3 used by kicad.
>
> According to the folks at the FSF:
>
> "Please note that GPLv2 is, by itself, not compatible with GPLv3.
> However, most software released under GPLv2 allows you to use the terms
> of later versions of the GPL as well. When this is the case, you can use
> the code under GPLv3 to make the desired combination. To learn more
> about compatibility between GNU licenses, please see our FAQ."
>
> I hope this clarifies why I am hesitant to merge this patch and what
> needs to clarified.  Isn't licensing fun! ;)
>
> Thanks,
>
> Wayne
>
> On 1/29/2018 2:47 PM, Seth Hillbrand wrote:
> > Hi Wayne-
> >
> > My reading of your links is different.  Here's the relevant quote:
> >
> > "GNU Lesser General Public License (LGPL) version 2.1 (#LGPLv2.1) This
> > is the previous version of the LGPL: a free software license, but not a
> > strong copyleft license, because it permits linking with nonfree
> > modules. It is compatible with GPLv2 and GPLv3."
> >
> > Did I miss something?
> >
> > -Seth
> >
> > 2018-01-29 11:18 GMT-08:00 Wayne Stambaugh  > >:
> >
> > Seth,
> >
> > There maybe licensing issues involved with this.  OpenCascade is
> > licensed using LGPL v2.1 not v2.1[1] or later.  LGPL v2.1 is not
> > compatible with GPL 3[2].  If OpenCascade is willing to change their
> > license LPGL 2.1 or later or if this is just an oversight on their
> part,
> > than I can include this patch.  Please verify the OpenCascade license
> > with something that I can verify to ensure we are not violating and
> > licensing terms.
> >
> > Cheers,
> >
> > Wayne
> >
> > [1]: https://www.opencascade.com/content/licensing
> > 
> > [2]:
> > https://www.gnu.org/licenses/license-list.en.html#
> GPLCompatibleLicenses
> >  GPLCompatibleLicenses>
> >
> > On 1/29/2018 1:54 PM, Seth Hillbrand wrote:
> > > ​Hi All-
> > >
> > > Currently, the build requires the opencascade community edition.
> For
> > > various reasons, I need to have the current non-community edition
> of
> > > OpenCASCADE installed on my work machine.
> > >
> > > The attached patch allows compiling KiCad with either the
> OpenCASCADE
> > > community edition or standard edition.
> > >
> > > I've tested on a homebrew-based Mac install as well as Linux but
> > haven't
> > > verified MSW, if someone would be willing to test it there, that
> would
> > > be great!  The basic search routines are lightly modified from
> > FreeCAD's
> > > logic and keep their LGPL copyright on the CMake file.
> > >
> > > -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
> > 
> >
> >
> >
> >
> > ___
> > Mailing list: 

Re: [Kicad-developers] spaces not allowed in SCH library nicknames

[José Ignacio]

I reported this multiple[1] times[2] long ago, and have since given up and
folded all my library names to use underscores instead. There are basically
no up to date design documents on how kicad's different systems and overall
architecture are supposed to work, many large refactors and overhauls have
been made, some inadvertently causing large incompatibilities like this one
since there is no document to reference on what is correct and what it's
not. Users are left on an easter egg hunt to see what will break in the new
version.

On the particular issue, just replacing @ instead of / will just move the
problem around, the real fix is just to document the current
behavior/design properly, homogenize it and just not make this kind of mess
again.

[1]: https://lists.launchpad.net/kicad-developers/msg27754.html
[2]: https://lists.launchpad.net/kicad-developers/msg31789.html

On Fri, Jan 26, 2018 at 12:07 PM, Tomasz Wlostowski <
tomasz.wlostow...@cern.ch> wrote:

> On 26/01/18 19:01, Tomasz Wlostowski wrote:
> > Hi all,
> >
> > Why are space characters not allowed in the SCH library nicknames, but
> > are OK for the FP libraries? Is this an overlook on SCH/PCB side?
>
> Also, the LIB_IDs follow the following scheme:
>
> library:symbol/revision.
>
> The / (slash) character is often used in the part names (see [1]). For
> 'heavy library style' people like CERN, the part names in the lib need
> to perfectly match the manufacturers' names. '/' as a revision separator
> makes this impossible.
>
> Would anyone here oppose changing it to something not met in typical IC
> names e.g, '@'?
>
> Cheers,
> Tom
>
> [1]
> http://uk.farnell.com/w/c/semiconductors-ics/power-
> management-ics-pmic/prl/results?st=%2Fnopb
>
>
>
>
> ___
> 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] Run-time expression eval in text fields

[José Ignacio]

I don't think fixing this is even necessary, fields are auto-placed in
eeschema master since last year. And if I cant leave it to the autoplacer i
usually want to manually tweak the location of the field once in the
schematic anyway, the default placement would be almost always wrong, this
goes for footprints too.

On Wed, Jan 17, 2018 at 4:14 PM, Jeff Young  wrote:

> Hi Wayne,
>
> I don’t think it’s as simple as fixing it in the file format.  If we add
> field instances for each unit, then we also have to add “shared” vs.
> “specific” radio buttons in the Edit Fields dialog, and that's going to
> open a whole ‘nother can of worms.
>
> But I’m not sold on expressions for this either (or even that we *need*
> to fix it); more just brainstorming...
>
> Cheers,
> Jeff.
>
>
> On 17 Jan 2018, at 19:08, Wayne Stambaugh  wrote:
>
> Jeff,
>
> Using expression evaluation seems like overkill in this case.  Even if
> you do manage to design something that doesn't make a complete mess of
> the source code, you would still have to get buy in from the symbol
> library devs to go back and add the expressions to every symbol with
> multiple units where per unit field positions would be helpful.  I'm not
> going to ask them to do that for a temporary fix.  Given that the very
> first thing I'm going to work on after the v5 release is the new symbol
> library file format, I just don't see how implementing this would be
> helpful.  I'm not opposed to expression evaluation in general, just not
> to fix a broken file format.
>
> Cheers,
>
> Wayne
>
> On 1/17/2018 1:49 PM, Jeff Young wrote:
>
> Hi Wayne,
>
> But even for 6, does this issue warrant it?  Having an expression
> evaluator would remove the need.
>
> (Mind you, it would still be overkill for this issue if the expression
> evaluator didn’t have other uses.  That was the reason for my query.)
>
> Cheers,
> Jeff.
>
>
> On 17 Jan 2018, at 18:31, Wayne Stambaugh  wrote:
>
> Jeff,
>
> Adding separate field locations for each symbol unit requires a symbol
> library file format change which is going to happen after v5 is
> released.  Please do not change any of this code because it will just
> get replaced when this occurs.
>
> Cheers,
>
> Wayne
>
> On 1/17/2018 12:27 PM, Jeff Young wrote:
>
> There’s a bug[1] that complains that the user can’t reposition a reference
> or value differently for different units that might be different sizes.
>  (You can do this on the eeschema canvas, but not in the library, so you
> have to do it each time you use one of the units.)
>
> It occurred to me that one could accomplish this using existing stuff if
> we had a (very simple) evaluator for text fields at runtime.  They could
> then add a text field to their units (marked shared-between-units or not as
> required), and set the value to something like “%REF” or “%VALUE”.  The
> expression evaluator could even be as simple as doing those two
> replacements, or maybe looking up any field value or something.
>
> Anyway, I’m not sure this issue warrants it, but if it had other uses it
> might be worth doing (whereas adding separate REF and VALUE fields per unit
> and giving them shared-between-units flags, etc., would be more work than
> this bug probably warrants).
>
> Thoughts?
>
> [1] https://bugs.launchpad.net/kicad/+bug/1334502
> ___
> 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] KiCad And Quces

[José Ignacio]

In case you didn't get to try it yet, the development version of kicad
already includes integration with a very good simulator, ngspice. That may
already do everything you need.

On Tue, Jan 16, 2018 at 12:10 AM, Babar Malik  wrote:

> Hi Everyone,
> Hopefully you people are doing good, I need assistance related to Kicad
> development. My aim is to develop Kicad in such a way that we can simulate
> the circuits along with PCB designing. As far as I know , Kicad is
> developed in C++ basically, Moreover there is another software named Qucs
> which is also devolped in C++ (circuit simulator). I want to study the
> source code of KiCad and Qucs to combine them in a way that we can develop
> PCB and circuit simulation both at a time. Can anyone please guide me
> related to this. I need to work from scratch.
>
> Your assistance will be highly appreciated.
>
>
>
>
> Best Regards,
> Muhammad Babar Malik
> Namal College Mianwali
> An Associate College of University of Bradford
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Don't draw invisible pins in component chooser

[José Ignacio]

Why can invisible pins be connected at all?

On Mon, Jan 15, 2018 at 3:00 AM, Maciej Sumiński 
wrote:

> Hi Jon,
>
> It seems there is no patch attached to this message. I realize it is
> better to hide invisible pins when they obscure the view, but I wonder
> whether the user should be at least aware of their presence.
>
> In case a symbol does not follow the KLC and has invisible pins exposed,
> then it can easily create an unwanted connection. In my opinion such
> symbol is badly designed and should not really occur, but I am just
> giving an idea of what may go wrong. Perhaps we should have an ERC rule
> that warns about invisible pins being connected to a wire, any thoughts?
>
> Regards,
> Orson
>
> On 01/11/2018 05:10 AM, Jon Evans wrote:
> > Implemented an override flag that makes it possible to turn off invisible
> > pin rendering outside of the EDA_DRAW_FRAME.
> >
> > Fixes: https://bugs.launchpad.net/kicad/+bug/1742485
> >
> > IMHO this is a bug, not a feature request, because the invisible pins
> > clutter the view in the preview pane of the component chooser and are not
> > necessary.
> >
> > -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] Minor releases (post v5.0.0)

[José Ignacio]

I think this is relevant now so the feature set can be frozen definitely,
but also don't make people feel like they either have to rush it now or
wait years for their pet feature to appear on the next stable release, this
could also mean dropping unfinished features in the interest of having v5
out the door on schedule, knowing that they will be there when ready in the
next release.

On Thu, Jan 11, 2018 at 12:41 PM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> Please save this for the post v5 discussion.
>
> On 1/11/2018 1:27 PM, Chris Pavlina wrote:
> > I agree with all of this 100%.
> >
> > On Thu, Jan 11, 2018 at 11:45:58AM -0600, José Ignacio wrote:
> >> I've started to see a flurry of features that are either getting rushed
> in
> >> for v5.0 or being pushed aside to the future "v6" version of kicad. Due
> to
> >> the limited resources of the development team and the sheer amount of
> work
> >> for each major release, the development cycles get pretty long, and many
> >> small but significant features will not see wide use until v6 will come
> out
> >> in a couple of years, as new features are not allowed in bugfix
> releases.
> >>
> >> Would it be possible to this week clamp down completely now on _any_
> kind
> >> of new feature for v5.0, and instead of pushing it to v6 (which sounds
> very
> >> far in the future), push it instead to v5.1, which could be released
> just a
> >> few months after v5.0 and include small features that don't break
> >> compatibility in a major way. That should also ease the continual
> >> backporting of bug fixes as the stable branch wont get overly stale, and
> >> small convenience features will get much better testing before the rush
> of
> >> the next release. IMO it will make the 5->6.0 cycle a lot less stressful
> >> than it's been for the past two cycles.
> >>
> >> Features in the v4->5 cycle that have forced me to use the master branch
> >> for production are things like the eeschema field autoplacing, eeschema
> >> field editor, gal performance improvements, STEP support. All things
> that
> >> didn't really break compatibility of my projects as much as a major
> release
> >> can do, but many people using the stable release haven't been able to
> test.
> >>
> >> ~Jose
> >
> >
> > ___
> > 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] Minor releases (post v5.0.0)

[José Ignacio]

I've started to see a flurry of features that are either getting rushed in
for v5.0 or being pushed aside to the future "v6" version of kicad. Due to
the limited resources of the development team and the sheer amount of work
for each major release, the development cycles get pretty long, and many
small but significant features will not see wide use until v6 will come out
in a couple of years, as new features are not allowed in bugfix releases.

Would it be possible to this week clamp down completely now on _any_ kind
of new feature for v5.0, and instead of pushing it to v6 (which sounds very
far in the future), push it instead to v5.1, which could be released just a
few months after v5.0 and include small features that don't break
compatibility in a major way. That should also ease the continual
backporting of bug fixes as the stable branch wont get overly stale, and
small convenience features will get much better testing before the rush of
the next release. IMO it will make the 5->6.0 cycle a lot less stressful
than it's been for the past two cycles.

Features in the v4->5 cycle that have forced me to use the master branch
for production are things like the eeschema field autoplacing, eeschema
field editor, gal performance improvements, STEP support. All things that
didn't really break compatibility of my projects as much as a major release
can do, but many people using the stable release haven't been able to test.

~Jose
___
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] Exchange/update footprints proposal

[José Ignacio]

This would make it so much more user friendly, and it's only UI code

On Sat, Jan 6, 2018 at 2:08 PM, Jeff Young  wrote:

> We’ve had some users be quite vocal about it being hard to update
> footprints from the library (and trying to use cvpcb to do so)[1].  While
> you can do this through the 4th option on the Exchange Footprints dialog,
> it’s pretty hidden.
>
> Lumping together Exchange and Update is also confusing, whether in the
> selected footprint case or in the global case.
>
> I’d like to propose the following changes (I’m happy to implement them):
>
> 1) Add Edit > Update All Footprints.  This would open the Exchange
> Footprints dialog with all the update options and exchange information
> removed.
>
> 2) Add Context Menu > Update Footprints (just under Exchange Footprints).
> This would open the Exchange Footprints dialog with all the exchange
> information removed.
>
> 3) Remove the fourth option (global update) from the Exchange Footprints
> dialog.
>
> Thoughts?
>
> Cheers,
> Jeff.
>
> [1] https://bugs.launchpad.net/kicad/+bug/1466857
> ___
> 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] Stable 5 branch status

[José Ignacio]

This sequence of actions is what puts the project on a stuffed up state:

* Open schematic and be greeted with some symbols that need rescue, rescue
a couple symbols
* Be greeted by the remap dialog (1)
* Regret remapping and quit without save
* Open schematic again
* Be greeted by the rescue dialog, with ALL symbols, refuse
* Remap dialog fails to find anything, click through (2)

Schematic looks fine, but the remap and rescue dialogs will show up every
time even though there is a valid sym-lib-table.

(1) At this point the pro file is overwritten, deleting all project library
entries
(2) At this point the pro file is overwritten again!, clobbering the backup
(SOL)

If you accept the second rescue you will have to map everything manually.
The remapper should really take the existing sym-lib-table or just not
clobber the pro file until the schematic is saved.

The close without save step should be perfectly valid if you're just
peeking at an old project and (possibly much later) you want to go modify
it you're greeted with that bad surprise.


On Tue, Jan 2, 2018 at 1:28 PM, Chris Pavlina <pavlina.ch...@gmail.com>
wrote:

> On Tue, Jan 02, 2018 at 02:20:10PM -0500, Wayne Stambaugh wrote:
> > It's exactly as insane as the cache has always been.
>
> I respectfully disagree. As I recall from many years of using KiCad
> before this, nothing about the cache has ever spontaneously deleted all
> libraries without warning. That's a whole new level of insanity that
> deserves its own "what not to do" section in a UX book somewhere. (And
> before you think this is all just "this UX guide sez" vague complaining,
> don't forget that I and many others still have _no idea wtf we're doing_
> trying to drive this thing.)
>
> > The only way I can
> > think of this happening is that the schematic was not saved after the
> > remapping and once all of the libraries are removed from the project
> > file but cache should still be valid if no save was performed.  Let me
> > try remapping this project and I will get back to you.
> >
> > On 1/2/2018 2:08 PM, Chris Pavlina wrote:
> > > Ah, that explains my question mark case. That's insane.
> > >
> > > On Tue, Jan 02, 2018 at 01:08:11PM -0600, José Ignacio wrote:
> > >> One big problem is that even if everything fails, the project will
> show up
> > >> fine with all symbols, but they wont have the remap done. at the same
> time
> > >> the remapper deletes all library entries from the project file, which
> > >> causes it to open with question marks only if you reopen it again
> after
> > >> saving. It should show the question marks before then or make better
> use of
> > >> the cache.
> > >>
> > >> On Tue, Jan 2, 2018 at 12:44 PM, Chris Pavlina <
> pavlina.ch...@gmail.com>
> > >> wrote:
> > >>
> > >>> Keep in mind my problem is not necessarily that things are _broken_
> but
> > >>> perhaps that they are so opaque that they only make sense in the
> mind of
> > >>> the designer. As I said in the previous message, we've been getting
> TONS
> > >>> of people on IRC who can't figure out how the hell to drive this
> thing,
> > >>> and I count myself among them. Still takes me like three tries to
> load
> > >>> an old project without it stuffing everything up.
> > >>>
> > >>> On Tue, Jan 02, 2018 at 01:40:40PM -0500, Wayne Stambaugh wrote:
> > >>>> Please send me a sample project if possible.  I have tested this
> every
> > >>>> which way I can think of and it works fine for everything I throw
> at it.
> > >>>>  The only time things fall apart are when the cache is corrupted or
> > >>>> missing and/or rescues have be ignored.  In those cases there is
> nothing
> > >>>> I can do because the proper symbols do not exist anywhere so
> remapping
> > >>>> is not possible.
> > >>>>
> > >>>> On 1/2/2018 1:33 PM, Chris Pavlina wrote:
> > >>>>> Are we really going to do an RC now without any more work to the
> remap
> > >>>>> stuff? I just had it ruin another project last night. It behaves
> very
> > >>>>> poorly when things also have to be rescued or libraries are
> missing, it
> > >>>>> seems.
> > >>>>>
> > >>>>> On Tue, Jan 02, 2018 at 09:10:20AM -0500, Wayne Stambaugh wrote:
> > >>>>>> On 1/2/2018 8:58 AM, Tomasz Wlostowski wrote:
> > >>>>>>> On 28/12/17 2

Re: [Kicad-developers] Stable 5 branch status

[José Ignacio]

This is doubly compounded if the project has symbols with (newly) illegal
names. The cache gets symbols with the original names but the code cant
find them anymore, even though the remapper can find it in the library with
the slashes, so you have to manually edit the library before opening, or
operate on a copy. It's been pretty painful to convert my old projects when
I've had to uprev them. Add rescue to the mix and things get even more
confusing.

On Tue, Jan 2, 2018 at 1:08 PM, Chris Pavlina <pavlina.ch...@gmail.com>
wrote:

> Ah, that explains my question mark case. That's insane.
>
> On Tue, Jan 02, 2018 at 01:08:11PM -0600, José Ignacio wrote:
> > One big problem is that even if everything fails, the project will show
> up
> > fine with all symbols, but they wont have the remap done. at the same
> time
> > the remapper deletes all library entries from the project file, which
> > causes it to open with question marks only if you reopen it again after
> > saving. It should show the question marks before then or make better use
> of
> > the cache.
> >
> > On Tue, Jan 2, 2018 at 12:44 PM, Chris Pavlina <pavlina.ch...@gmail.com>
> > wrote:
> >
> > > Keep in mind my problem is not necessarily that things are _broken_ but
> > > perhaps that they are so opaque that they only make sense in the mind
> of
> > > the designer. As I said in the previous message, we've been getting
> TONS
> > > of people on IRC who can't figure out how the hell to drive this thing,
> > > and I count myself among them. Still takes me like three tries to load
> > > an old project without it stuffing everything up.
> > >
> > > On Tue, Jan 02, 2018 at 01:40:40PM -0500, Wayne Stambaugh wrote:
> > > > Please send me a sample project if possible.  I have tested this
> every
> > > > which way I can think of and it works fine for everything I throw at
> it.
> > > >  The only time things fall apart are when the cache is corrupted or
> > > > missing and/or rescues have be ignored.  In those cases there is
> nothing
> > > > I can do because the proper symbols do not exist anywhere so
> remapping
> > > > is not possible.
> > > >
> > > > On 1/2/2018 1:33 PM, Chris Pavlina wrote:
> > > > > Are we really going to do an RC now without any more work to the
> remap
> > > > > stuff? I just had it ruin another project last night. It behaves
> very
> > > > > poorly when things also have to be rescued or libraries are
> missing, it
> > > > > seems.
> > > > >
> > > > > On Tue, Jan 02, 2018 at 09:10:20AM -0500, Wayne Stambaugh wrote:
> > > > >> On 1/2/2018 8:58 AM, Tomasz Wlostowski wrote:
> > > > >>> On 28/12/17 20:24, Wayne Stambaugh wrote:
> > > > >>>> There are a few outstanding crash bugs that need to be fixed
> before
> > > we
> > > > >>>> can consider branching the stable 5 release.  Here is the list
> of
> > > > >>>> unresolved crash bugs that effect the development branch:
> > > > >>>>
> > > > >>>> https://bugs.launchpad.net/kicad/+bug/1562788
> > > > >>>> https://bugs.launchpad.net/kicad/+bug/1732274
> > > > >>>> https://bugs.launchpad.net/kicad/+bug/1738872
> > > > >>>> https://bugs.launchpad.net/kicad/+bug/1738999
> > > > >>>> https://bugs.launchpad.net/kicad/+bug/1739614
> > > > >>>> https://bugs.launchpad.net/kicad/+bug/1740253
> > > > >>>
> > > > >>> Hey Wayne,
> > > > >>>
> > > > >>> I fixed the remaining 2 bugs yesterday (the STEP import one is a
> bug
> > > in
> > > > >>> OCE). Please proceed with the 5.0-rc.
> > > > >>>
> > > > >>> Tom
> > > > >>>
> > > > >>
> > > > >> Hi Tom,
> > > > >>
> > > > >> Thanks!.  I wont have time to get to this until the weekend.  If
> there
> > > > >> are no additional critical severity bug reports by then, I will
> create
> > > > >> the version 5 branch.
> > > > >>
> > > > >> 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] Stable 5 branch status

[José Ignacio]

One big problem is that even if everything fails, the project will show up
fine with all symbols, but they wont have the remap done. at the same time
the remapper deletes all library entries from the project file, which
causes it to open with question marks only if you reopen it again after
saving. It should show the question marks before then or make better use of
the cache.

On Tue, Jan 2, 2018 at 12:44 PM, Chris Pavlina 
wrote:

> Keep in mind my problem is not necessarily that things are _broken_ but
> perhaps that they are so opaque that they only make sense in the mind of
> the designer. As I said in the previous message, we've been getting TONS
> of people on IRC who can't figure out how the hell to drive this thing,
> and I count myself among them. Still takes me like three tries to load
> an old project without it stuffing everything up.
>
> On Tue, Jan 02, 2018 at 01:40:40PM -0500, Wayne Stambaugh wrote:
> > Please send me a sample project if possible.  I have tested this every
> > which way I can think of and it works fine for everything I throw at it.
> >  The only time things fall apart are when the cache is corrupted or
> > missing and/or rescues have be ignored.  In those cases there is nothing
> > I can do because the proper symbols do not exist anywhere so remapping
> > is not possible.
> >
> > On 1/2/2018 1:33 PM, Chris Pavlina wrote:
> > > Are we really going to do an RC now without any more work to the remap
> > > stuff? I just had it ruin another project last night. It behaves very
> > > poorly when things also have to be rescued or libraries are missing, it
> > > seems.
> > >
> > > On Tue, Jan 02, 2018 at 09:10:20AM -0500, Wayne Stambaugh wrote:
> > >> On 1/2/2018 8:58 AM, Tomasz Wlostowski wrote:
> > >>> On 28/12/17 20:24, Wayne Stambaugh wrote:
> >  There are a few outstanding crash bugs that need to be fixed before
> we
> >  can consider branching the stable 5 release.  Here is the list of
> >  unresolved crash bugs that effect the development branch:
> > 
> >  https://bugs.launchpad.net/kicad/+bug/1562788
> >  https://bugs.launchpad.net/kicad/+bug/1732274
> >  https://bugs.launchpad.net/kicad/+bug/1738872
> >  https://bugs.launchpad.net/kicad/+bug/1738999
> >  https://bugs.launchpad.net/kicad/+bug/1739614
> >  https://bugs.launchpad.net/kicad/+bug/1740253
> > >>>
> > >>> Hey Wayne,
> > >>>
> > >>> I fixed the remaining 2 bugs yesterday (the STEP import one is a bug
> in
> > >>> OCE). Please proceed with the 5.0-rc.
> > >>>
> > >>> Tom
> > >>>
> > >>
> > >> Hi Tom,
> > >>
> > >> Thanks!.  I wont have time to get to this until the weekend.  If there
> > >> are no additional critical severity bug reports by then, I will create
> > >> the version 5 branch.
> > >>
> > >> 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] Default Canvas for v5

[José Ignacio]

On Tue, Jan 2, 2018 at 11:18 AM, André S. 
wrote:

> Hi everyone,
>
> I want to add from a users view:
> In the current KiCad 4.0.7 (Windows 64 bit) you can't drag traces in
> OpenGL/Cairo, only in legacy. (With this I mean: move a segment of a trace
> and it stays attached to the other segments of the trace (Hotkey: 'G')).
> Hotkey 'M' moves segments in OpenGL but moves 'connections' in Legacy
> (segments stay connected).
> More often than not I need the behaviour of Legacy and not that of the
> OpenGL canvas.
>
> In GAL the key to move connections is D, which allows you to drag traces
using the push and shove algorithm. Why is it this not G? I have no idea.


> Values are not displayed in OpenGL/Cairo, only in Legacy.
>

That is odd, is there a bug report for that?


> And "transparency" is better in Legacy. With only 2 layers you can see the
> traces on the bottom layer better than in OpenGL/Cairo.
>

This was broken recently when the RGBA setting was added. It used to be
that all layers would have 80% transparency by default. this probably
should be fixed again, I personally prefer to set the transparency even
lower for inner layers too. This is all user settable in the nightlies.


>
> Just for this few reasons I still use Legacy more often than OpenGL when
> modifying an existing PCB design.
>
> From my view OpenGL is nice because you can manipulate single items
> (segments of traces) better/more comfortably than in Legacy. And initial
> layout work feels smoother.
>
> Just my 2 cents. :)
>
> Happy new year,
>   André
>
> PS: as a side note: When I switch from "Standard/Legacy" or OpenGL to
> Cairo the PCB view goes white and only after a few seconds displays the
> PCB. In the other direction there is no delay.
>

Performance was greatly improved in GAL in the latest nightlies, did you
try them or just the GAL as seen in 4.0.7?


>
>
> Am 2017-12-31 um 22:28 schrieb Jon Evans:
>
> For your consideration, a patch is attached that implements the above.
>
>
> On Sun, Dec 31, 2017 at 2:24 PM, Jon Evans  wrote:
>
>> I think that getting automatic OpenGL detection and recovery working for
>> 5.0 might be ambitious.
>> Maybe Chris can detail what the next steps are for his approach there,
>> but in case we want to push that to a later release, here's what I propose:
>>
>> 1) Rename the View menu options based on my proposal "Legacy", "Modern
>> (Accelerated)", "Modern (Fallback)"
>> 2) Change PCB_BASE_FRAME::SwitchCanvas to save the canvas config value
>> after calling UseGalCanvas() rather than before.
>> 3) Show a first-run dialog like the mockup in my earlier email, IF canvas
>> is not OpenGL and the dialog has not been shown before
>> 44) If user clicks "yes" in the first run dialog, then:
>> (a) set the config value to prevent the dialog from showing again,
>> (b) Set the canvas config setting to Cairo (but don't switch the GAL
>> to Cairo), then
>> (c) switch to OpenGL canvas using SwitchCanvas()
>>
>> That way, if the app crashes in step 4c, it should come back up as Cairo
>> on the next launch (assuming we crash right away when trying to set up the
>> canvas)
>>
>> Any concerns with the above?
>>
>> -Jon
>>
>>
>>
>> On Sun, Dec 31, 2017 at 1:55 PM, Jeff Young  wrote:
>>
>>> +1
>>>
>>> No menu items.  Just a checkbox for Enable Hardware Acceleration in
>>> Preferences.
>>>
>>> On 31 Dec 2017, at 18:36, Andy Peters  wrote:
>>>
>>> - In the case of graphics glitches, inform the users in the FAQ/Manual
>>> that they can fall back to software renderer in the View menu.
>>> - Don't use the term 'canvas' or 'view'. Just 'Enable HW acceleration’.
>>>
>>>
>>> I like that. The fewer technical/programmer terms, the better.
>>>
>>>
>>>
>>> ___
>>> 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

[Kicad-developers] Default Canvas for v5

[José Ignacio]

Since the GAL is pretty much feature complete (I have used it exclusively
for the last year and a half) and the Cairo canvas has much improved
performance (it is *significantly* faster than legacy on my systems),
should pcbnew make the switch to have Cairo as the default canvas?

I understand OpenGL may still be undesirable because some defective or
misconfigured systems may have crashing issues with kicad preventing the
user to switch away from OpenGL, but that may even not be the case anymore.
___
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] OSX dev environments

[José Ignacio]

Another +1 for QT creator, I've used it on Linux and works very well with
the kicad codebase

On Mon, Dec 25, 2017 at 2:09 AM, Bernhard Stegmaier  wrote:

> For my taste for KiCad the best I tried is QTCreator.
> Works practically out-of-the-box perfectly with cmake and everything you
> would expect from an IDE (like debugging, etc.).
>
>
> Regards,
> Bernhard
>
>
> On 25. Dec 2017, at 03:47, Oliver Walters 
> wrote:
>
> I followed this guide to set-up eclipse environment.
>
> https://gist.github.com/johnbeard/895bad60e4716f7f9c77
>
> On 25 Dec 2017 12:37, "Tomasz Wlostowski" 
> wrote:
>
>> On 25/12/17 02:03, Jeff Young wrote:
>> > I was going to ask you guys for an Xcode project file for Christmas,
>> but I’ve come to the conclusion that I absolutely hate Xcode.
>> >
>> > I’ve used Eclipse before, and was no big fan of it either.  I did
>> really like IntelliJ, though, and I see they’ve got a C version too
>> (CLion).  Has anyone used it to build KiCad?
>> >
>> Hi Jeff,
>>
>> I tried CLion. After a ~10 minute-long freeze (indexing the code) it
>> crashed due to lack of memory. With a 6 GB java heap the project loaded,
>> but the editor was veeery slow.
>>
>> IMHO Get Atom if you need something easy to use on a Mac or Visual
>> Studio (if you like "big" C++ IDEs).
>>
>> Cheers,
>> Tom
>>
>> ___
>> 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] Eeschema fields in Pcbnew (RFC)

[José Ignacio]

The netlist format already exports all fields by default. my tool [1] uses
a .net file as an input to generate BOM and macrofab XYRS files.

[1]: https://github.com/iromero91/bomtool

On Wed, Dec 13, 2017 at 2:16 PM, Justin Partain 
wrote:

> As a user, I do all my scripting outside of Kicad. From a developer's POV,
> since Value/Reference fields are available to Python scripting, I can see
> that these should be too. What do you think about a third tab in the module
> edit dialogue, 'Fields', for these read-only fields?
>
> How does everyone feel about changing the netlist format to export these
> fields by default or with a checkbox? Would an alternative intermediate
> file be preferred instead?
>
> --
>
> Justin Partain
>
> On Wed, Dec 13, 2017 at 2:32 PM, Maciej Suminski 
> wrote:
>
>> Hi Justin,
>>
>> I also use an XML netlist and a python script to generate pick and place
>> files. I agree it would be much better to have it done in one step, so
>> you have my vote.
>>
>> Do you foresee any user interface to display the fields imported from
>> netlist? I imagine the fields would be read-only for the time being,
>> until we develop back annotation. Do you plan to make the fields
>> available to Python scripts?
>>
>> Regards,
>> Orson
>>
>> On 12/13/2017 05:56 PM, Justin Partain wrote:
>> > I understand Kicad is in feature freeze and getting ready to release
>> soon,
>> > this is an RFC for a feature for Kicad 6.0 (or whatever is next).
>> >
>> > Proposition: add the ability to import custom fields from Eeschema into
>> > Pcbnew via the netlist
>> >
>> > As a design engineer, I work closely with our production branch and the
>> > ability to export xy-data with user-created fields (namely, internal
>> part
>> > number in our case) is a need. Currently, I'm looking at generating a
>> .bom
>> > file from Eeschema with the needed fields, generating .pos file from
>> Pcbnew
>> > per usual, and using a script to rip out the needed data from both and
>> > reassemble in our desired format. This proposal covers getting the data
>> > into Pcbnew, I'll probably send out another proposal for more
>> customizable
>> > XY-data output later. If this is approved, I'd rather Kicad support this
>> > out of the box and I can maintain a branch until Kicad is ready to
>> merge it.
>> >
>> > This would require a .kicad_pcb format update and would not be backwards
>> > compatible (unable to open new format in old Kicad). I'm imagining
>> > key-value pairs like "(customfield $fieldname $fieldvalue)" for each
>> > (module ...). There may be interest in being able to draw these to the
>> > board, I'm not sure, maybe that could be added later if this gets
>> approved.
>> > --
>> >
>> > Justin Partain
>> >
>> >
>> >
>> > ___
>> > 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] file format change and STEP exporter

[José Ignacio]

Indeed, it is much easier to just re-parse pcb files than it is to extract
data using the internal APIs. The intention is for that to be temporary
until the internal api improves to the point where writing something
interfacing with it wont be a pile of workarounds for quirks and sharp
corners. If anything, it is a testament to the improvement the s-expr
format brought to kicad, being so easy to parse and work with external
tools.

On Sat, Dec 9, 2017 at 12:59 AM, Kevin Cozens  wrote:

> On 2017-12-08 04:34 PM, Cirilo Bernardo wrote:
>
>>   I haven't had time to follow changes for quite some time but there
>> was some talk about making changes to the PCB file format. If the
>> file format changes, some changes will also have to be made to
>> the STEP exporter (utils/kicad2step) to handle the new format.
>>
>
> This surprises me a little. Does that mean kicad2step is processing the
> saved file and not working from the data held internal to the program?
>
> --
> Cheers!
>
> Kevin.
>
> http://www.ve3syb.ca/   |"Nerds make the shiny things that
> distract
> Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
> | powerful!"
> #include  | --Chris Hardwick
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Prevent multiple item delete when routing (fixes lp:1715158)

[José Ignacio]

THANK YOU

On Wed, Dec 6, 2017 at 10:13 PM, Seth Hillbrand 
wrote:

> ​The attached patch corrects https://bugs.launchpad.net/kicad/+bug/1715158
> where pressing delete in pcbnew GAL canvas will delete _both_ a wire​ and
> the footprint underneath it.
>
> I know that this bug was marked "triaged" but it bit me on a board and I
> didn't notice the missing footprint (was zoomed in) until quite a few
> clicks later.
>
> -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

Re: [Kicad-developers] Fwd: Re: [PATCH] Fix for 3D model offset

[José Ignacio]

That's one of the risks that come from using the dev version without
looking at the changes beforehand. The impact should be pretty small.

On Fri, Dec 1, 2017 at 11:50 AM, easyw  wrote:

> just a side note on this thread:
> this latest patch is messing up all the previous offset values in boards
> that a user, which had the latest and previous patched pcbnew, opened and
> saved ...
> And obviously this mess is happening in a 'silent' way, without any
> warning message for the user which will find all the offset multiplied by
> 25.4...
> IMO this is just a bigger headache than what I even thought it may have
> been
>
>
>
> On 12/01/2017 4:17 PM, Wayne Stambaugh wrote:
>
>> On 12/01/2017 06:31 AM, jp charras wrote:
>>
>>> Le 30/11/2017 à 13:43, Oliver Walters a écrit :
>>>
 Rebuilt and attached

 On Thu, Nov 30, 2017 at 7:53 PM, jp charras >
 wrote:


   Message transféré 
  Sujet : Re: [Kicad-developers] [PATCH] Fix for 3D model offset
  Date : Thu, 30 Nov 2017 09:43:05 +0100
  De : jp charras >> jp.char...@wanadoo.fr>>
  Répondre à : KiCad Developers >
  Pour : Oliver Walters >> oliver.henry.walt...@gmail.com>>

  Le 30/11/2017 à 08:38, Oliver Walters a écrit :
  > JP, Wayne,
  >
  > Any update on how we want to handle this?

>>>
>>> Looks good to me now.
>>>
>>> Wayne, do you want me to commit these patchs?
>>>
>>>
>> Please commit this patch when you get a chance.  The reason it took me
>> so long to pull the trigger on this is that I was trying to think of a
>> better way to handle it.  I can not really think of a better solution so
>> we will have to live with it unless someone else has a better idea.
>> It's best to make the change so everyone will get their complaining over
>> with now rather than later.  I think for version 6, I would like to
>> revisit the footprint file format given some of its limitations but I'm
>> going to hold off on that until after the new schematic file formats are
>> done.
>>
>> Thanks,
>>
>> 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] Migrating old designs best practice

[José Ignacio]

This might be related to the wire optimizer/junction management code.
Eeschema used to allow degenerate connections like that, where an L was
superimposed to a wire, connecting into a junction.

On Sun, Nov 26, 2017 at 4:59 AM, Diego Herranz <
diegoherr...@diegoherranz.com> wrote:

> Please ignore the previous attachments. They should have been these.
>
> Thanks.
>
> On Sun, Nov 26, 2017 at 10:55 AM, Diego Herranz <
> diegoherr...@diegoherranz.com> wrote:
>
>> Hi, Nick
>>
>> Changes like: (- is removed, + added)
>>
>> -Wire Wire Line
>> - 12550 700  12600 700
>>
>> -Wire Wire Line
>> - 12700 700  12700 700
>>
>>  Wire Wire Line
>> - 22250 14500 22250 11600
>> + 22250 9200 22250 14600
>>
>> - Wire Wire Line
>> - 22250 9200 22250 14600
>>
>> - Wire Wire Line
>> - 22700 750  15350 750
>>
>>  Wire Wire Line
>> - 16650 750  16650 750
>> + 15350 750  22700 750
>>
>>
>> This happens on a dummy schematic which I've got for basically trying
>> things out in KiCad, and to test nightlies. So the schematic is basically a
>> mess.
>>
>> Thant means I've got crappy connections (before.png), which the rescue
>> process broke (after.png). Maybe it wouldn't have happened if the
>> connections were nice in the first place, but I wasn't expecting them to
>> break.
>>
>> Thanks!
>>
>>
>>
>> On Sat, Nov 25, 2017 at 9:15 PM, Nick Østergaard 
>> wrote:
>>
>>> What modifications are made to the wires?
>>>
>>> 2017-11-25 21:28 GMT+01:00 Diego Herranz 
>>> :
>>>
 Hi,

 Related to this, I'm migrating an old design (~2 month old nightly) to
 the current master. First I faced some problem with '/' characters (
 https://lists.launchpad.net/kicad-developers/msg31705.html) but there
 have been some improvements since then so I'm trying again.

 When opening the schematic, 2 dialogs are shown:
 1) Rescue symbols dialog: it offers to rescue a couple of symbols which
 use '/' in their name. It seems to rescue them properly on -rescue.lib
 (replacing '/' by '_')
 2) Remap dialog: Everything gets remapped properly except the symbols
 mentioned in 1). That is because -rescue.lib is not in sym-lib-table
 yet. After adding it to sym-lib-table, I can edit those broken symbols
 ("?")  to point those rescued in -rescue.lib and it all looks OK.

 After this, which I think that can be challenging for many people (it
 has been for me), it seems everything should be OK now. However when I push
 the netlist to pcbnew, it shows a few changes and I wasn't expecting any.
 Comparing the schematic file with a text editor a few wires have been
 modified.

 I've don't some testing it seems the wires get modified when doing 1).
 If I skip the rescue, no wire gets modified.

 Why is that happening? I wouldn't expect the rescue process to modify
 wires. Am I doing something wrong?

 Many thanks,
 Diego



 On Sat, Nov 25, 2017 at 3:00 PM, Wayne Stambaugh 
 wrote:

> On 11/24/2017 05:01 PM, hauptmech wrote:
> > On 25/11/17 02:14, Wayne Stambaugh wrote:
> >> This is *the* fatal flaw with the cache library.  User's assume it
> is
> >> stale symbols or a temporary copy.  It is not.  It is a snapshot of
> the
> >> current library symbols linked to the symbols in the schematic.  It
> gets
> >> refreshed every time the schematic is saved.  Once you delete this
> file
> >> or keep an out of date copy using cvs, all bets are off.  It is
> only a
> >> matter of time before one of your symbol libraries changes or gets
> >> removed and you will end up with a broken schematic.  The rescue
> code
> >> depends on the cache being up to date in order preserve you
> schematic.
> >> If the cache is not current, the rescuing cannot be guaranteed.
> >
> > I don't think it's necessarily a flaw. And your description above is
> > indeed a cache. That's not a bad thing. I recall that I left it out
> of
> > version control because I wanted to make sure fixes to my symbols
> were
> > always propagated to the design. In the repo I'm referencing for this
> > discussion I had 10 project files all using the same local library. I
> > didn't want to have to manually update each schematic to propagate
> > changes. Deleting untracked files was what I did instead. At the
> time no
> > one was making breaking changes to system installed symbols, so the
> > system libs were stable for this workflow.
> >
> > I'm trying think of the least effort way to migrate an old design in
> > these circumstances.
> >
> > Can we have the rescue code fail if no cache file is found? That at
> > least lets the user know they are in uncharted territory. Then if a
> lot
> > of users come complaining you will know if it is worth doing a bit

Re: [Kicad-developers] [PATCH] Allow items to be moved from all anchor points

[José Ignacio]

Friendly bump, this bug is very annoying, related bug report
https://bugs.launchpad.net/kicad/+bug/1722512 this patch fixes it.

On Mon, Nov 20, 2017 at 10:29 AM, José Ignacio <jose.cyb...@gmail.com>
wrote:

> A change in commit 57310001350 caused kicad to stop allowing users
> to move items like footprints, arcs and lines using anchors other
> than the center point.
>
> This was caused by the new code that stores reference points for
> clipboard pasting, a call to updateModificationPoint() prevented
> some old code paths from executing, which caused the selection to
> snap into the cursor, always using the center anchor.
>
> This fix moves the call within the if-cases that need it, and adds
> a ClearReferencePoint call when the selection is "dropped" to allow
> the user to grab the same selection again from a different anchor.
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

[José Ignacio]

I have several footprints that use manufacturer's models, where offsets and
rotations are necessary. I really fail to see the point of breaking
people's designs and libraries needlessly.

On Nov 22, 2017 7:07 AM, "Wayne Stambaugh"  wrote:

> What is wrong with just reading the footprint in mm rather than
> converting from decimils from now on?  It's only going to be a one time
> issue when a user adds a footprint that has not been converted to mm to
> a board.
>
> On 11/22/2017 06:16 AM, Oliver Walters wrote:
> > Wayne,
> >
> >
> > I believe he has a point. The footprint files do not have version
> > information so if you load and save a footprint multiple times, the
> > "offset" (if non zero) will continuously be multiplied by 2.54x
> >
> > I think there are two ways forward:
> >
> > 1. Revert my patch and live with the file format unit inconsistency
> > 2. I can provide a patch for my original idea of writing "offset"
> > instead of "at". We make a clean break and "at" is legacy and always
> > read as inches. "offset" is new and is mm.
> >
> > Let me know what you want to do.
> >
> > Thanks,
> > Oliver
> >
> > On Wed, Nov 22, 2017 at 8:25 PM, easyw  > > wrote:
> >
> > Hi Wayne,
> >
> > I'm not sure I understand what the issue is.  Once an offset is
> > changed
> > to mm when either a footprint in a board or a library is parsed,
> why
> > would it not be saved as mm.  If it isn't, then this is a bug.
> > Once the
> > footprint offset is converted to mm, there should be no
> > expectation that
> > it will be correct for older versions of KiCad.  Is there
> > something else
> > at play here?
> >
> >
> > this issue is related to the footprint editor...
> >
> > 1) The fp exporter button exports correctly the footprint with
> > offset in mm
> > 2) The fp importer button imports always reading the data as
> > deci-mils and multiplies it internally
> > 3) To fix this issue the patch needs to manage the footprint
> > importer code to read the values in mm instead of deci-mils.
> >
> > What if you open the same file again, how can it tell it's in mm
> > or inches?
> >
> > @Jose ... this is an issue already addressed...
> > The decision to change offset values to mm will break previous
> > footprints that have non zero offset.
> > But I think this has been considered a 'small' disturb for users
> > when the patch has been committed, as stated in a previous mail:
> >
> > This is not a big issue because the only effects the footprints
> > embedded
> > in the board.  Users with custom footprint libraries that
> contain 3D
> > model offsets will just have to fix the offsets.  I'm guessing
> > this is a
> > fairly small number of users.
> >
> > https://lists.launchpad.net/kicad-developers/msg31589.html
> > 
> >
> > M
> >
> >
> > On 11/22/2017 2:19 AM, Wayne Stambaugh wrote:
> >
> > I'm not sure I understand what the issue is.  Once an offset is
> > changed
> > to mm when either a footprint in a board or a library is parsed,
> why
> > would it not be saved as mm.  If it isn't, then this is a bug.
> > Once the
> > footprint offset is converted to mm, there should be no
> > expectation that
> > it will be correct for older versions of KiCad.  Is there
> > something else
> > at play here?
> >
> > On 11/21/2017 04:26 PM, Oliver Walters wrote:
> >
> > Wayne,
> >
> > Not sure how you want to handle this but I feel that making
> > a clean
> > break and using "offset" for mm solves all the issues
> > associated with
> > embedded footprints without version info, as Maurice says
> > above. Let me
> > know if want me to implement.
> >
> > On Wed, Nov 22, 2017 at 8:24 AM, easyw  > 
> > >>
> wrote:
> >
> >  Hi,
> >  first headache symptom...
> >
> >  Testing conditions:
> >  latest KiCad patched
> >  Application: pcbnew
> >  Version: (2017-11-21 revision 8de70f3)-master, release
> > build
> >
> >  If you edit a footprint adding 3D models offset and
> > then export it,
> >  it will be saved with the new mm convention...
> >  but when re-imported it will be read with deci-mils and
> > displayed
> >  with wrong convention...
> >  Moreover if the imported footprint will be 

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

[José Ignacio]

What if you open the same file again, how can it tell it's in mm or inches?

On Tue, Nov 21, 2017 at 7:19 PM, Wayne Stambaugh 
wrote:

> I'm not sure I understand what the issue is.  Once an offset is changed
> to mm when either a footprint in a board or a library is parsed, why
> would it not be saved as mm.  If it isn't, then this is a bug.  Once the
> footprint offset is converted to mm, there should be no expectation that
> it will be correct for older versions of KiCad.  Is there something else
> at play here?
>
> On 11/21/2017 04:26 PM, Oliver Walters wrote:
> > Wayne,
> >
> > Not sure how you want to handle this but I feel that making a clean
> > break and using "offset" for mm solves all the issues associated with
> > embedded footprints without version info, as Maurice says above. Let me
> > know if want me to implement.
> >
> > On Wed, Nov 22, 2017 at 8:24 AM, easyw  > > wrote:
> >
> > Hi,
> > first headache symptom...
> >
> > Testing conditions:
> > latest KiCad patched
> > Application: pcbnew
> > Version: (2017-11-21 revision 8de70f3)-master, release build
> >
> > If you edit a footprint adding 3D models offset and then export it,
> > it will be saved with the new mm convention...
> > but when re-imported it will be read with deci-mils and displayed
> > with wrong convention...
> > Moreover if the imported footprint will be inserted into the board,
> > the footprint will conserve the wrong values...
> > Those wrong values will be then saved with the new kicad_pcb
> board
> >
> > On 11/15/2017 3:40 PM, Maciej Suminski wrote:
> >
> > Hi Maurice,
> >
> > On 15/11/2017 1:21 PM, easyw wrote:
> >
> > Just a clarification request:
> >
> > Kicad Stable has version assigned to 4
> > Previous stable had version assigned to 3
> >
> > I imagine that next stable would have version assigned to
> 5...
> > Am I right in supposing the next numbering release?
> >
> > If I'm fine, with the proposed patch the new stable release,
> > if assigned
> > coherently to actual releases numbering, will fail the check
> > that is in
> > this patch; the new parser will then mess up all 3D offsets
> > each time
> > the board will be saved/displayed...
> >
> > +if(m_requiredVersion < 20171114UL)
> >
> >
> > I think you write this assuming the v5 file format will have
> > m_requiredVersion set to 5. If I recall correctly, we have
> > decided to use dates for file versioning and this method will be
> > kept for v5 and later versions, so we should be safe here.
> >
> > As I already stated the actual situation has no problem in
> > displaying
> > the correct offset in 3D viewer and the exporters are fine...
> > The only 'issue', if we can say this is an issue, is that
> > the offset is
> > assigned to deci-mils and not millimeters inside the
> > footprint...
> >
> > This is going to open big headaches for which enhancement?
> > My 2 cents
> >
> >
> > The solution Oliver has proposed looks solid to me, I do not see
> > any potential headache. The patch has a very noble goal of
> > fixing one of the biggest KiCad sins - incoherence. I think the
> > reason is good enough to commit the patch.
> >
> > Regards,
> > Orson
> >
> > Maurice
> >
> >
> >
> > On 11/14/2017 10:55 AM, Oliver Walters wrote:
> >
> > Wayne,
> >
> > Please find attached updated patch set. If an old
> > version is detected,
> > inches are converted to mm.
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > 
> > Post to : kicad-developers@lists.launchpad.net
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > 
> > More help   : https://help.launchpad.net/ListHelp
> > 
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > 
> > Post to : kicad-developers@lists.launchpad.net
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > 
> > More help   : 

Re: [Kicad-developers] New symbol table: problems with '/' characters?

[José Ignacio]

This is pretty much the same issue that happened back in February (
https://lists.launchpad.net/kicad-developers/msg27766.html ) I don't have
my launchpad logins right now to comment on it but I strongly disagree with
classifying bug #1732236  as a low
priority. I can tell you it breaks dozens of my current designs, that is, I
can't even open them without doing some surgery to both the schematics and
libraries. I though KiCAD was supposed to be able to open designs of the
previous version?

I've not looked at what the fix was when this came up in February, but is
there a reason something similar couldn't be done now for the legacy
plugin? PCB files didn't break like this because the footprints were
embedded, eeschema now can't even load symbols from the cache if they have
slashes.

On Sat, Nov 18, 2017 at 7:07 AM, Wayne Stambaugh 
wrote:

> Diego,
>
> Thank you for the offer but I'm already working on it.  It is not as
> easy to fix as it would seem.  The problem is what to do when you do not
> have write access to the library with the invalid characters.  I have a
> few ideas but it will take me a while to get it the way I want it.
>
> Cheers,
>
> Wayne
>
> On 11/18/2017 08:00 AM, Diego Herranz wrote:
> > Thanks. I'll chase that bug.
> >
> > Diego
> >
> > On 18 Nov 2017 11:35 am, "Nick Østergaard"  > > wrote:
> >
> > See https://bugs.launchpad.net/bugs/1732236
> > 
> >
> > 2017-11-18 11:42 GMT+01:00 Diego Herranz
> >  >>:
> >
> > Hi,
> >
> > I'm testing a recent build (41f9c19b) on Ubuntu 16.04 64 bits.
> >
> > When opening a schematic made with a nightly build ~2 months
> > old, the remapping dialog shows up. So far so good.
> >
> > I've followed the recommendations
> > in http://kicad-pcb.org/post/symbol-lib-table/
> >  and most things
> > seem to be working fine. Every symbol gets remapped but 2. Both
> > of which include '/' in their name (e.g. PIC32MX110F016D-I/PT).
> >
> > Opening the schematic after the remap, it seems Kicad has
> > changed it to PIC32MX110F016D-I_PT.
> >
> > In fact, after a bit more searching, I've found out that as soon
> > as the remapping dialog shows up, before clicking on "Remap
> > symbols" the '/' characters have been replaced to '_'. So I'm
> > guessing that is the reason why it can't find the symbols when
> > remapping?
> > "Warning: No symbol 'PIC32MX110F016D-I_PT' found in symbol
> > library table." confirms that the name was changed before the
> > remapping attempt.
> >
> > I have then tried to edit the broken symbols in Eeschema. When I
> > try to assign "PIC32MX110F016D-I/PT" again, which can be found
> > through the "Choose Symbol" dialog without problems, it
> complains:
> > " Symbol 'PIC32MX1XXFXXXD-I_PT' not found in library
> > 'MCU_Microchip_PIC32'! "
> >
> > Am I doing something wrong? Is this a bug?
> >
> > Many thanks,
> > Diego
> >
> > ___
> > 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

[Kicad-developers] [PATCH] Allow items to be moved from all anchor points

[José Ignacio]

A change in commit 57310001350 caused kicad to stop allowing users
to move items like footprints, arcs and lines using anchors other
than the center point.

This was caused by the new code that stores reference points for
clipboard pasting, a call to updateModificationPoint() prevented
some old code paths from executing, which caused the selection to
snap into the cursor, always using the center anchor.

This fix moves the call within the if-cases that need it, and adds
a ClearReferencePoint call when the selection is "dropped" to allow
the user to grab the same selection again from a different anchor.
From 630f2895040eef1efda17685dc7054910a746798 Mon Sep 17 00:00:00 2001
From: Jose I Romero 
Date: Mon, 20 Nov 2017 10:14:41 -0600
Subject: [PATCH] Allow items to be moved from all anchor points

A change in commit 57310001350 caused kicad to stop allowing users
to move items like footprints, arcs and lines using anchors other
than the center point.

This was caused by the new code that stores reference points for
clipboard pasting, a call to updateModificationPoint() prevented
some old code paths from executing, which caused the selection to
snap into the cursor, always using the center anchor.

This fix moves the call within the if-cases that need it, and adds
a ClearReferencePoint call when the selection is "dropped" to allow
the user to grab the same selection again from a different anchor.
---
 pcbnew/tools/edit_tool.cpp | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/pcbnew/tools/edit_tool.cpp b/pcbnew/tools/edit_tool.cpp
index 2ae7a4d8b..e6aaad55c 100644
--- a/pcbnew/tools/edit_tool.cpp
+++ b/pcbnew/tools/edit_tool.cpp
@@ -450,8 +450,6 @@ int EDIT_TOOL::Main( const TOOL_EVENT& aEvent )
 
 m_cursor = controls->GetCursorPosition();
 
-updateModificationPoint( selection );
-
 if ( selection.HasReferencePoint() )
 {
 // start moving with the reference point attached to the cursor
@@ -469,11 +467,13 @@ int EDIT_TOOL::Main( const TOOL_EVENT& aEvent )
 {
 // Set the current cursor position to the first dragged item origin, so the
 // movement vector could be computed later
+updateModificationPoint( selection );
 m_cursor = grid.BestDragOrigin( originalCursorPos, curr_item );
 grid.SetAuxAxes( true, m_cursor );
 }
 else
 {
+updateModificationPoint( selection );
 m_cursor = grid.Align( m_cursor );
 }
 
@@ -556,6 +556,8 @@ int EDIT_TOOL::Main( const TOOL_EVENT& aEvent )
 controls->SetAutoPan( false );
 
 m_dragging = false;
+// Discard reference point when selection is "dropped" onto the board (ie: not dragging anymore)
+selection.ClearReferencePoint();
 
 if( unselect || restore )
 m_toolMgr->RunAction( PCB_ACTIONS::selectionClear, true );
-- 
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] Changed behaviour: Moving objects by their pads not possible anymore

[José Ignacio]

A subtle bug still remains unfortunately, if you try to move the same
selection multiple times using different anchor points you can't because
once the reference point is set by updateModificationPoint, it is never
unset until the selection is destroyed. perhaps it should be unset whenever
a transfomation is done.

On Sun, Nov 19, 2017 at 8:17 PM, José Ignacio <jose.cyb...@gmail.com> wrote:

> I think i found a possible fix that avoids interfering with the copy and
> paste origin logic added (even on single element pastes):
>
> diff --git a/pcbnew/tools/edit_tool.cpp b/pcbnew/tools/edit_tool.cpp
> index bb6fe3f80..f8ff9ce32 100644
> --- a/pcbnew/tools/edit_tool.cpp
> +++ b/pcbnew/tools/edit_tool.cpp
> @@ -450,8 +450,6 @@ int EDIT_TOOL::Main( const TOOL_EVENT& aEvent )
>
>  m_cursor = controls->GetCursorPosition();
>
> -updateModificationPoint( selection );
> -
>
> This call guarantees that selection.HasReferencePoint() always returns
> true, so the other two code paths never get executed, so i removed it, as
> it is not necessary in the first if case:
>
>
>  if ( selection.HasReferencePoint() )
>  {
>  // start moving with the reference point attached
> to the cursor
>
>
> And then added it back for the other two cases:
>
>
> @@ -469,11 +467,13 @@ int EDIT_TOOL::Main( const TOOL_EVENT& aEvent )
>  {
>  // Set the current cursor position to the first
> dragged item origin, so the
>  // movement vector could be computed later
> +updateModificationPoint( selection );
>  m_cursor = grid.BestDragOrigin(
> originalCursorPos, curr_item );
>  grid.SetAuxAxes( true, m_cursor );
>  }
>  else
>  {
> +updateModificationPoint( selection );
>  m_cursor = grid.Align( m_cursor );
>  }
>
>
> Patch file attached.
>
>
> Thanks,
> Jose
>
>
> On Sun, Nov 19, 2017 at 6:04 PM, José Ignacio <jose.cyb...@gmail.com>
> wrote:
>
>> I can confirm this, it also affects the movement of graphic items like
>> lines and arcs to very disturbing results. It will always use the
>> centerpoint of an arc or first point of a line, snapping the part to the
>> cursor every time. I ran a git bisect and it looks like the first commit
>> that introduced that behavior was  57310001350ead3a6b7870f19982f77b88ac5b8a,
>> with the introduction of storage of offsets in the SELECTION class.
>>
>> I couldn't find a satisfactory fix because i'm not familiar with the
>> design of the edit tool, the expected behavior is that when you press M
>> with the cursor over an endpoint of a line or arc, kicad will use that
>> endpoint as the reference anchor to move the object around.
>>
>> Thanks,
>> Jose
>>
>> On Sun, Nov 19, 2017 at 3:05 PM, <d...@gmx.de> wrote:
>>
>>> The changes introduced in #931a1ccaff, that bring new features to
>>> copy/paste in pcbnew, change the behaviour of the cursor snapping when
>>> moving footprints:
>>> Before you could move components by either their origin or any pad. This
>>> is a really handy feature that allows the easy alignment of differently
>>> pitched components without the need to constantly change the grid (And I
>>> don't seem to be the only one who enjoyed this feature:
>>> https://electronics.stackexchange.com/a/214072).
>>>
>>>
>>> Changing line 455 of pcbnew/tools/edit_tool.cpp from
>>> > if ( selection.HasReferencePoint() )
>>> to
>>> > if ( false && selection.HasReferencePoint() )
>>>
>>> brings back the old behaviour (but breaks of course other things as
>>> that's just a quick hack). So I prosume it would be quite easy to re-enable
>>> this behaviour, maybe by adding an additional check prior to the query of
>>> selection.HasReferencePoint() to see if the cursor is currently above a
>>> movable pad.
>>>
>>>
>>>
>>> Looking forward to discuss this issue with you guys :)
>>>
>>> Best regards
>>> Daniel
>>>
>>> ___
>>> 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] Changed behaviour: Moving objects by their pads not possible anymore

[José Ignacio]

I think i found a possible fix that avoids interfering with the copy and
paste origin logic added (even on single element pastes):

diff --git a/pcbnew/tools/edit_tool.cpp b/pcbnew/tools/edit_tool.cpp
index bb6fe3f80..f8ff9ce32 100644
--- a/pcbnew/tools/edit_tool.cpp
+++ b/pcbnew/tools/edit_tool.cpp
@@ -450,8 +450,6 @@ int EDIT_TOOL::Main( const TOOL_EVENT& aEvent )

 m_cursor = controls->GetCursorPosition();

-updateModificationPoint( selection );
-

This call guarantees that selection.HasReferencePoint() always returns
true, so the other two code paths never get executed, so i removed it, as
it is not necessary in the first if case:


 if ( selection.HasReferencePoint() )
 {
 // start moving with the reference point attached
to the cursor


And then added it back for the other two cases:


@@ -469,11 +467,13 @@ int EDIT_TOOL::Main( const TOOL_EVENT& aEvent )
 {
 // Set the current cursor position to the first
dragged item origin, so the
 // movement vector could be computed later
+updateModificationPoint( selection );
 m_cursor = grid.BestDragOrigin( originalCursorPos,
curr_item );
 grid.SetAuxAxes( true, m_cursor );
 }
 else
 {
+updateModificationPoint( selection );
 m_cursor = grid.Align( m_cursor );
 }


Patch file attached.


Thanks,
Jose


On Sun, Nov 19, 2017 at 6:04 PM, José Ignacio <jose.cyb...@gmail.com> wrote:

> I can confirm this, it also affects the movement of graphic items like
> lines and arcs to very disturbing results. It will always use the
> centerpoint of an arc or first point of a line, snapping the part to the
> cursor every time. I ran a git bisect and it looks like the first commit
> that introduced that behavior was  57310001350ead3a6b7870f19982f77b88ac5b8a,
> with the introduction of storage of offsets in the SELECTION class.
>
> I couldn't find a satisfactory fix because i'm not familiar with the
> design of the edit tool, the expected behavior is that when you press M
> with the cursor over an endpoint of a line or arc, kicad will use that
> endpoint as the reference anchor to move the object around.
>
> Thanks,
> Jose
>
> On Sun, Nov 19, 2017 at 3:05 PM, <d...@gmx.de> wrote:
>
>> The changes introduced in #931a1ccaff, that bring new features to
>> copy/paste in pcbnew, change the behaviour of the cursor snapping when
>> moving footprints:
>> Before you could move components by either their origin or any pad. This
>> is a really handy feature that allows the easy alignment of differently
>> pitched components without the need to constantly change the grid (And I
>> don't seem to be the only one who enjoyed this feature:
>> https://electronics.stackexchange.com/a/214072).
>>
>>
>> Changing line 455 of pcbnew/tools/edit_tool.cpp from
>> > if ( selection.HasReferencePoint() )
>> to
>> > if ( false && selection.HasReferencePoint() )
>>
>> brings back the old behaviour (but breaks of course other things as
>> that's just a quick hack). So I prosume it would be quite easy to re-enable
>> this behaviour, maybe by adding an additional check prior to the query of
>> selection.HasReferencePoint() to see if the cursor is currently above a
>> movable pad.
>>
>>
>>
>> Looking forward to discuss this issue with you guys :)
>>
>> Best regards
>> Daniel
>>
>> ___
>> 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
>>
>
>
diff --git a/pcbnew/tools/edit_tool.cpp b/pcbnew/tools/edit_tool.cpp
index bb6fe3f80..f8ff9ce32 100644
--- a/pcbnew/tools/edit_tool.cpp
+++ b/pcbnew/tools/edit_tool.cpp
@@ -450,8 +450,6 @@ int EDIT_TOOL::Main( const TOOL_EVENT& aEvent )
 
 m_cursor = controls->GetCursorPosition();
 
-updateModificationPoint( selection );
-
 if ( selection.HasReferencePoint() )
 {
 // start moving with the reference point attached to the cursor
@@ -469,11 +467,13 @@ int EDIT_TOOL::Main( const TOOL_EVENT& aEvent )
 {
 // Set the current cursor position to the first dragged item origin, so the
   

Re: [Kicad-developers] Changed behaviour: Moving objects by their pads not possible anymore

[José Ignacio]

I can confirm this, it also affects the movement of graphic items like
lines and arcs to very disturbing results. It will always use the
centerpoint of an arc or first point of a line, snapping the part to the
cursor every time. I ran a git bisect and it looks like the first commit
that introduced that behavior was
57310001350ead3a6b7870f19982f77b88ac5b8a, with the introduction of storage
of offsets in the SELECTION class.

I couldn't find a satisfactory fix because i'm not familiar with the design
of the edit tool, the expected behavior is that when you press M with the
cursor over an endpoint of a line or arc, kicad will use that endpoint as
the reference anchor to move the object around.

Thanks,
Jose

On Sun, Nov 19, 2017 at 3:05 PM,  wrote:

> The changes introduced in #931a1ccaff, that bring new features to
> copy/paste in pcbnew, change the behaviour of the cursor snapping when
> moving footprints:
> Before you could move components by either their origin or any pad. This
> is a really handy feature that allows the easy alignment of differently
> pitched components without the need to constantly change the grid (And I
> don't seem to be the only one who enjoyed this feature:
> https://electronics.stackexchange.com/a/214072).
>
>
> Changing line 455 of pcbnew/tools/edit_tool.cpp from
> > if ( selection.HasReferencePoint() )
> to
> > if ( false && selection.HasReferencePoint() )
>
> brings back the old behaviour (but breaks of course other things as that's
> just a quick hack). So I prosume it would be quite easy to re-enable this
> behaviour, maybe by adding an additional check prior to the query of
> selection.HasReferencePoint() to see if the cursor is currently above a
> movable pad.
>
>
>
> Looking forward to discuss this issue with you guys :)
>
> Best regards
> Daniel
>
> ___
> 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] [REQUEST] Default library install location

[José Ignacio]

Doing a one-time copy from the system, copy on write like Nick suggested or
just having kicad download the libraries itself would be the only real
solutions IMO. Having the installer write to user directories is a no-no
specially since there can be new users added to the system after kicad gets
installed, who will have a "broken" install. The copying system in kicad
also needs to offer at least the most rudimentary mechanism for upgrading
the user's copies of the library when the system library gets updated (when
kicad gets upgraded). That should NOT be an automatic process though, as it
would be useful and expected that the user could review the change before
touching the libraries.

Also, for users like me that do not use the kicad library, if kicad doesn't
get installed with libraries none of this copying would happen anyway.

On Wed, Nov 8, 2017 at 7:15 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Wayne,
>
> I think you're right that a deeper understanding of how people are using
> and managing the libraries is required.
>
> However, there still seems to be one of two options if KiCad installs libs
> into a location where users cannot write:
>
> a) Users are not able to update the libraries or otherwise edit them
> b) Users have to duplicate the library data to somewhere they *do* have
> access and then reassociate all the library tables
>
> I think there is scope for improvement here. I'm not confident enough to
> say *what* that improvement should be.
>
> On Thu, Nov 9, 2017 at 12:12 AM, Wayne Stambaugh 
> wrote:
>
>> What is the purpose of this change?  In what way will it improve the
>> user experience?  Before we ask the package devs to do a lot of work, we
>> might want to dig deeper into the library management issue.  I fail to
>> see how installing and likely duplicating the entire KiCad library in
>> the user's home folder solves any of the underlying library management
>> issues in KiCad other than having write access to modify the installed
>> libraries which has its own set of issues.  In some respects this has
>> the potential to complicate things even further.  I suspect the real
>> issue is out library editing and management tools.  I suggest we wait
>> until Orson pushes the symbol library editor to see if this improves the
>> library management situation.  Given what I know about it I suspect that
>> it will improve things significant on the library management side of
>> things.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 11/8/2017 2:02 AM, Oliver Walters wrote:
>> > To the package maintainers:
>> >
>> > For v5 release, can the default library install path be set to a user
>> > directory rather than program directory that may require administrator
>> > rights?
>> >
>> > e.g. instead of
>> >
>> > C:\Program Files\KiCad\share\...
>> > or
>> > /usr/share/kicad/...
>> >
>> > something like;
>> >
>> > C:\Users\Oliver\KiCad\...
>> >
>> > /home/Oliver/KiCad
>> >
>> > (Not necessarily those paths but something like that).
>> >
>> > A lot of users are reporting issues with being able to download or
>> > modify library files, due to user privileges.
>> >
>> > How attainable is such a change before v5 release?
>> >
>> > Thanks,
>> > 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
>
>
___
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] [REQUEST] Default library install location

[José Ignacio]

What about installing it in a system directory. and have kicad copy them
over to the user directory on first boot? that would probably work well for
multiuser systems, otherwise you'd have to copy it on every user of the
machine, even future ones.

On Wed, Nov 8, 2017 at 2:46 AM, Nick Østergaard  wrote:

> It is problematic in various ways. There may be some way to achieve this
> in the windows installer, but I need to investigate this. I don't know
> about the macos installer.
>
> On linux, I don't know how this should be done if we want to provide
> normal packages for this. I think it would be better if we integrate a
> better downloaded (AND UPDATER) kicad to handle this. Alternatively it
> could be a user script, for example a python script which we should be able
> to make quite portable, also given that we are sort of sure we have the
> python env for a proper kicad installation.
>
> 2017-11-08 8:02 GMT+01:00 Oliver Walters :
>
>> To the package maintainers:
>>
>> For v5 release, can the default library install path be set to a user
>> directory rather than program directory that may require administrator
>> rights?
>>
>> e.g. instead of
>>
>> C:\Program Files\KiCad\share\...
>> or
>> /usr/share/kicad/...
>>
>> something like;
>>
>> C:\Users\Oliver\KiCad\...
>>
>> /home/Oliver/KiCad
>>
>> (Not necessarily those paths but something like that).
>>
>> A lot of users are reporting issues with being able to download or modify
>> library files, due to user privileges.
>>
>> How attainable is such a change before v5 release?
>>
>> Thanks,
>> 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] [FEATURE] Array 3D models

[José Ignacio]

STEPs don't need to look ugly, a "simple" extension of the step format
could be a mtl file that indexes vrml materials to STEP colors, it would be
ignored by MCAD, but kicad could pick that up to significantly prettify the
step files in the 3d viewer without having to generate a redundant WRL file
(it wouldnt support fancier stuff like mapped textures but if you're
autogenerating models from the STEP anyway, how much better are you gonna
get?). Even when exporting a board to WRL in kicad it would use the 3d
cache data, so WRL models don't need to exist for wrl output for blender,
etc.

my $0.02

On Mon, Nov 6, 2017 at 3:17 PM, Cirilo Bernardo <cirilo.berna...@gmail.com>
wrote:

> I wouldn't worry about the STEP file having numerous small parts;
> this happens all the time anyway unless the model can be fused.
> I don't see us abandoning VRML. I wrote the new parser but never
> use VRML except when testing the VRML parser. However, many
> people out there like to have VRML to make shiny models to show
> people.  I suspect there are more users who want VRML rather
> than STEP and that the STEP models are used mostly by
> professional users and hobbyists who happen to have an MCAD
> package. VRML is also used by some professionals for brochures
> or web page images; there is no disputing that STEP models look
> terribly ugly.
>
> On Mon, Nov 6, 2017 at 4:17 PM, José Ignacio <jose.cyb...@gmail.com>
> wrote:
> > The only thing i really have against this is that it would make a pretty
> > messy step file because the component would be broken up in tiny parts.
> > Wouldn't there be a space saving with just ditching wrl altogether? the
> next
> > stable won't need them
> >
> > On Mon, Nov 6, 2017 at 9:53 AM, Kristoffer Ödmark
> > <kristofferodmar...@gmail.com> wrote:
> >>
> >> To be fair, as it stands now, even if it is "only" for the pin headers,
> >> this is close to half of the 3d library size as of now.
> >>
> >> The pin headers can now be of an arbitrary size as well. Someone can now
> >> create a 4x6 pin header for example, and the current footprints can be
> >> converted to this array system, thus reducing the size.
> >>
> >> Arbitrary pin headers are a step up anyway.
> >>
> >> This being said, I have not tested the patch yet, but even if it is
> "only"
> >> for pin headers, the idea is sound to me.
> >>
> >>
> >>
> >> On 11/06/2017 04:22 PM, easyw wrote:
> >>>
> >>> Hi Oliver,
> >>>
> >>> I'm sorry not to be on your side for this option...
> >>>
> >>> 1) for which kind of modules this array is applicable?
> >>> I see only pin-headers straight and angled...
> >>> for example box headers are not easily done unless you consider to
> manage
> >>> by the code the box for each model
> >>> 2) the problem related to the big 3D library dimension will not be
> >>> covered unless for some little family that can be managed by this on
> the fly
> >>> generator
> >>>
> >>> As I already suggested, the issue with the huge 3D github library can
> be
> >>> managed in a different way:
> >>> 1) give the kicad users only a basic 3D library (i.e. most used smd and
> >>> th families)
> >>> 2) give an option to pcbnew to automatically create a list of the
> missing
> >>> models needed for a project and collecting only them through a wget
> >>> process...
> >>>
> >>> This will give a very low downloading band need and will not increase
> the
> >>> need of disk space for having all the 3D library locally, full of
> unwanted
> >>> models.
> >>>
> >>> Here a conversation of this issue:
> >>> https://github.com/KiCad/kicad-library/issues/1532#
> issuecomment-341707706
> >>>
> >>> my two-cents
> >>> Maurice
> >>>
> >>> On 11/06/2017 3:01 PM, Oliver Walters wrote:
> >>>>
> >>>> To provide an option to reduce the size of the 3D model library, I
> have
> >>>> implemented an "array" feature for 3D models. A module (footprint) can
> >>>> reference a single model multiple times, with a dimensional offset
> between
> >>>> each copy.
> >>>>
> >>>> (Note - just the PinHeader models are currently over 1GB! This feature
> >>>> lets you use a single 3D model for all pin headers or similar
> repetitive
> >>>> footprints w

Re: [Kicad-developers] [FEATURE] Array 3D models

[José Ignacio]

The only thing i really have against this is that it would make a pretty
messy step file because the component would be broken up in tiny parts.
Wouldn't there be a space saving with just ditching wrl altogether? the
next stable won't need them

On Mon, Nov 6, 2017 at 9:53 AM, Kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:

> To be fair, as it stands now, even if it is "only" for the pin headers,
> this is close to half of the 3d library size as of now.
>
> The pin headers can now be of an arbitrary size as well. Someone can now
> create a 4x6 pin header for example, and the current footprints can be
> converted to this array system, thus reducing the size.
>
> Arbitrary pin headers are a step up anyway.
>
> This being said, I have not tested the patch yet, but even if it is "only"
> for pin headers, the idea is sound to me.
>
>
>
> On 11/06/2017 04:22 PM, easyw wrote:
>
>> Hi Oliver,
>>
>> I'm sorry not to be on your side for this option...
>>
>> 1) for which kind of modules this array is applicable?
>> I see only pin-headers straight and angled...
>> for example box headers are not easily done unless you consider to manage
>> by the code the box for each model
>> 2) the problem related to the big 3D library dimension will not be
>> covered unless for some little family that can be managed by this on the
>> fly generator
>>
>> As I already suggested, the issue with the huge 3D github library can be
>> managed in a different way:
>> 1) give the kicad users only a basic 3D library (i.e. most used smd and
>> th families)
>> 2) give an option to pcbnew to automatically create a list of the missing
>> models needed for a project and collecting only them through a wget
>> process...
>>
>> This will give a very low downloading band need and will not increase the
>> need of disk space for having all the 3D library locally, full of unwanted
>> models.
>>
>> Here a conversation of this issue:
>> https://github.com/KiCad/kicad-library/issues/1532#issuecomment-341707706
>>
>> my two-cents
>> Maurice
>>
>> On 11/06/2017 3:01 PM, Oliver Walters wrote:
>>
>>> To provide an option to reduce the size of the 3D model library, I have
>>> implemented an "array" feature for 3D models. A module (footprint) can
>>> reference a single model multiple times, with a dimensional offset between
>>> each copy.
>>>
>>> (Note - just the PinHeader models are currently over 1GB! This feature
>>> lets you use a single 3D model for all pin headers or similar repetitive
>>> footprints within a certain series).
>>>
>>> Features:
>>>
>>> 1. Specify repeat count and repeat step in x/y/z axes
>>> 2. Save / load implemented. (If no repeat option used, no extra output
>>> is generated - old files are not touched)
>>> 3. Render in 3D viewer
>>> 4. Render in raytracing viewer
>>> 5. Export to VRML (multiple references to single file)
>>> 6. Export to STEP
>>>
>>> Notes:
>>>
>>> a. An exported STEP file will now be (possibly) much smaller as it
>>> references a single small object multiple times
>>> b. There were a couple of bugs I found where model offset units were
>>> incorrectly translated between INCHES and MM
>>>
>>> A couple of screenshots:
>>>
>>> https://imgur.com/a/EOwPh
>>>
>>>
>>> Testing:
>>>
>>> Wayne verified that the file units for 3D model data are in mm - I
>>> *think* this means that there was previously a bug regarding 3D model
>>> offset, where the scaling factor in the file was interpreted as inches when
>>> exporting (e.g. to STEP)
>>>
>>> I believe I have fixed this bug - confirmation would be great.
>>>
>>> Cheers,
>>> 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
>>
>
> --
>  -Kristoffer
>
>
> ___
> 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] Add more layers by default when plotting.

[José Ignacio Romero]

This makes the default plotting options more consistent to what one
would need when producing a board in a typical PCB fab, that is,
including solder mask, edge cuts and paste stencil.
---
 pcbnew/pcb_plot_params.cpp | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/pcbnew/pcb_plot_params.cpp b/pcbnew/pcb_plot_params.cpp
index 2e153b330..352d58588 100644
--- a/pcbnew/pcb_plot_params.cpp
+++ b/pcbnew/pcb_plot_params.cpp
@@ -113,7 +113,10 @@ PCB_PLOT_PARAMS::PCB_PLOT_PARAMS()
 m_outputDirectory.clear();
 m_color  = BLACK;
 m_textMode   = PLOTTEXTMODE_DEFAULT;
-m_layerSelection = LSET( 2, F_SilkS, B_SilkS) | LSET::AllCuMask();
+m_layerSelection = LSET( 7, F_SilkS, B_SilkS,
+ F_Mask, B_Mask,
+ F_Paste, B_Paste,
+ Edge_Cuts) | LSET::AllCuMask();
 
 // This parameter controls if the NPTH pads will be plotted or not
 // it is a "local" parameter
___
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] latest GerbView doesn't display test file

[José Ignacio]

I don't know. If anything it would be the most useful to be able to try to
repair broken files like that (maybe a script?). Displaying broken files
"correctly" is dangerous. One of the main uses for a Gerber viewer is to do
a pre-manufacturing check, and if your gerbers are broken and they work in
the viewer anyway it could be a problem.

On Thu, Sep 28, 2017 at 12:47 PM, Seth Hillbrand 
wrote:

> Looking at gerbv right now, it appears to silently handle decimal places
> if they exist.  However, in the absence of an explicit decimal place, it
> treats %FSD as %FSL, which is probably why Clemens' file was correctly
> displayed, as opposed to being oversized by a factor of 100.
>
> Personally, I would love to see Kicad following a robustness principle
> that allows more files to be displayed but with a definite warning message
> detailing the formatting error and cautioning that the file _may_ not be
> correctly displayed because of the bad format.
>
> Best-
> Seth
>
>
>
> On Thu, Sep 28, 2017 at 9:17 AM, jp charras  wrote:
>
>> Le 28/09/2017 à 17:58, Jon Evans a écrit :
>> > Perhaps another route is to improve the messaging given to the user in
>> these cases, so that it's
>> > easy for them to correct the file / report an issue to their tool
>> vendor?
>>
>> Yes.
>>
>> In fact, %FSD is already supported by Gerbview because (a long time ago)
>> I found Gerber files in
>> decimal format (not documented, because %FSD was never a official Gerber
>> format statement).
>>
>> This is the reason no error was reported: coordinates were read as
>> floating numbers (in mm) and valid.
>>
>>
>> >
>> > On Thu, Sep 28, 2017 at 11:53 AM, Wayne Stambaugh > > > wrote:
>> >
>> > On 9/28/2017 10:32 AM, jp charras wrote:
>> > > Le 28/09/2017 à 16:13, Wayne Stambaugh a écrit :
>> > >> On 9/28/2017 9:45 AM, jp charras wrote:
>> > >>> Le 28/09/2017 à 01:27, Clemens Koller a écrit :
>> > 
>> >  On 2017-09-26 13:38, jp charras wrote:
>> > > The Gerber file is broken:
>> > > the line:
>> > > %FSDAX33Y33*%
>> > >
>> > > is incorrect
>> > 
>> >  Thank you!
>> > 
>> >  Since I cannot do anything about this proprietary non
>> compliant EDA tool, would it be
>> > possible to support these wrong but obvious lines anyway (maybe
>> after showing a warning) - so
>> > would you accept a patch to support the %FSD gerber code?
>> > 
>> >  Regards,
>> > 
>> >  Clemens
>> > 
>> > 
>> > >>>
>> > >>> A patch is possible, but the actual issue is:
>> > >>> What is the meaning of %FSD format?
>> > >>>
>> > >>> I saw some "Gerber" files using %FSD for a decimal format
>> (coordinates in floating point
>> > notation),
>> > >>> that differs from your Gerber file ( that is in fact a %FSLA
>> format, nothing else ).
>> > >>>
>> > >>
>> > >> Unless %FSD is an obsolete gerber command, I'm opposed to this
>> idea on
>> > >> principle alone.  KiCad should not be in the business of
>> supporting
>> > >> broken file formats created by other tools.  The gerber file
>> format is a
>> > >> published standard and we should be following it as closely as
>> possible.
>> > >>  You should file a bug report with the vendor of the program that
>> > >> created these gerber files.
>> > >>
>> > >> Cheers,
>> > >>
>> > >> Wayne
>> > >
>> > > In latest Gerber doc, %FSD appears in "Errors and Bad Practices"
>> list and is clearly called
>> > Invalid
>> > > Format Statement in the "Error" section.
>> >
>> > In this case we should not support %FSD.
>> >
>> > >
>> > > only %FSLA and %FSTA exit.
>> > > %FSTA is now on the deprecated list (Kicad uses the %FSLA option).
>> > >
>> > >
>> >
>> > We will have to continue to support these for legacy gerber files.
>>
>>
>> --
>> Jean-Pierre CHARRAS
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Live zone filling

[José Ignacio]

If your traces "choke" a zone out so that it can't fill the other side it
may affect a very large area of the board. And it is the kind of thing
you'd like to watch out for when you're moving traces around. For very good
reasons Kicad will not fill isolated islands of copper if there is no
direct connectivity to the net. (I have seen a case where eagle doesn't do
that and a board went to production with a nonfunctional ground pour -_-)

On Tue, Sep 19, 2017 at 12:51 PM, Kevin Cozens  wrote:

> On 2017-09-19 01:08 PM, Jon Evans wrote:
>
>> Thanks for the detailed feedback. I was definitely thinking of this as a
>> long-term (post 5.0) project.  I will take a look at the various aspects
>> you mention and come back with a more detailed proposal.
>>
>
> Live update of zone fills in the PNS router would be an interesting
> feature to have. As to breaking the fill zone in to segments you don't need
> to go quite that far.
>
> There are only two areas of concern. They are the area where the item used
> to be located, and the area where the item is now located. You can ignore
> the rest of the board when updating the fill zone.
>
> --
> Cheers!
>
> Kevin.
>
> http://www.ve3syb.ca/   |"Nerds make the shiny things that
> distract
> Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
> | powerful!"
> #include  | --Chris Hardwick
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[José Ignacio]

On Mon, Sep 18, 2017 at 7:52 PM, Rene Pöschl <poesc...@gmail.com> wrote:

>
>
> On 19 Sep 2017 2:05 am, "José Ignacio" <jose.cyb...@gmail.com> wrote:
>
> Probably, contributors would need to agree to be attributed as a group
> when the work is embedded in a design (When the library is distributed in
> whole or part they should get attributed individually as the GPL requires).
> Ownership transfer shouldn't be necessary. a CLA is a good idea anyway to
> ensure all contributions are licensed with all the terms you think they
> are, and everyone is given proper attribution.
>
>
> I think ownership transfer happens automatically when opening a pull
> request. But having contributers sign an explicit agreement can't hurt.
>

A pull request is not sufficient to transfer ownership of a copyrighted
work, unless that was specified in an agreement you signed beforehand, all
contributions are owned by the respective contributors, but the project is
granted a GPL license to use the contributed work, which can't be revoked
(unless the project messes up in version 2). But since the GPL does not
allow relicensing, the contributors must all agree to any licensing change.


>
> The attribution requirement for case #2 ideally would be a simple "Using
> symbols/footprints/models for the Kicad project's library, version X" plus
> some permalink where the GPL versions of the libraries can be obtained,
> together with the attribution information (embedded in the GIT history, or
> preferably an AUTHORS file). If that's not agreeable, perhaps an AUTHORS
> file that can be downloaded and bundled with a non-gpl design should comply
> with the attribution requirement.
>
>
> for #2 we used the font exception. We also have a credits file that has a
> dual purpose of documenting where the models come from (script or mcad
> software example freecad) and who made them. I don't think this would be
> practical for other libs though. (it already creates merge conflicts in the
> 3d repo.)
>

That would need to be fixed somehow. It would be nice if GPL+FE compliance
was just a few clicks away rather than having to hunt down lists of
contributors.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[José Ignacio]

Probably, contributors would need to agree to be attributed as a group when
the work is embedded in a design (When the library is distributed in whole
or part they should get attributed individually as the GPL requires).
Ownership transfer shouldn't be necessary. a CLA is a good idea anyway to
ensure all contributions are licensed with all the terms you think they
are, and everyone is given proper attribution.

IANAL but i think something that would make everyone happy is to have these
conditions apply:

1) When distributing the libraries in whole or in part the whole GPL
applies, with it's requirements on disclosure of source, copyleft, and
attribution.
2) In the special case of someone embedding the symbols in their design, a
simpler license would apply, where they can use a simplified attribution
requirement, people are forbidden from separating the symbols from the
design for their own use in other designs.

The attribution requirement for case #2 ideally would be a simple "Using
symbols/footprints/models for the Kicad project's library, version X" plus
some permalink where the GPL versions of the libraries can be obtained,
together with the attribution information (embedded in the GIT history, or
preferably an AUTHORS file). If that's not agreeable, perhaps an AUTHORS
file that can be downloaded and bundled with a non-gpl design should comply
with the attribution requirement.


On Mon, Sep 18, 2017 at 6:46 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> PS: It would be nice to provide a simplified way for non-GPL users to
>> provide attribution for the libraries without having to name every single
>> john doe that made a symbol or footprint. If it's made simple people will
>> probably be more inclined to comply.
>
>
> What would such a thing look like? Something like a CLA -
> https://en.wikipedia.org/wiki/Contributor_License_Agreement ?
>
> On Tue, Sep 19, 2017 at 9:02 AM, José Ignacio <jose.cyb...@gmail.com>
> wrote:
>
>> PS: It would be nice to provide a simplified way for non-GPL users to
>> provide attribution for the libraries without having to name every single
>> john doe that made a symbol or footprint. If it's made simple people will
>> probably be more inclined to comply.
>>
>> On Mon, Sep 18, 2017 at 5:59 PM, José Ignacio <jose.cyb...@gmail.com>
>> wrote:
>>
>>> The GPL with font exception is probably the better of the two, as it is
>>> the least restrictive one contributors seem to agree on.
>>>
>>> On Mon, Sep 18, 2017 at 5:47 PM, Oliver Walters <
>>> oliver.henry.walt...@gmail.com> wrote:
>>>
>>>> A further issue that has cropped up twice in the last hour: Library
>>>> licensing
>>>>
>>>> https://github.com/KiCad/kicad-library/issues/1259#issuecomm
>>>> ent-330374095
>>>>
>>>> https://forum.kicad.info/t/default-libraries-gpl-licencing-v
>>>> s-proprietary-designs/140/8
>>>>
>>>>
>>>> We have been discussing this for a while in this thread -
>>>> https://lists.launchpad.net/kicad-developers/msg28181.html
>>>>
>>>> It initially looked like we had a consensus but then it quickly
>>>> devolved and never reached a conclusion.
>>>>
>>>> *Without entering into the same back-and-forth again, *and with the
>>>> following stipulations:
>>>>
>>>> a) All libraries will have the same license agreeement
>>>> b) A single LICENSE.md file will suffice
>>>>
>>>> What license should we be using?
>>>>
>>>> 1. CC-BY-SA - This is what Wayne originally suggested IIRC
>>>> 2. modified GPL similar to gEDA license?
>>>>
>>>>
>>>> I need a consensus on this so I can add the license files to the
>>>> repositories and add the information to the website.
>>>>
>>>> Cheers,
>>>> Oliver
>>>>
>>>>
>>>> On Mon, Sep 18, 2017 at 11:12 PM, Wayne Stambaugh <stambau...@gmail.com
>>>> > wrote:
>>>>
>>>>> Oliver,
>>>>>
>>>>> Great work!  This is really shaping up nicely.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Wayne
>>>>>
>>>>> On 9/17/2017 12:13 AM, Oliver Walters wrote:
>>>>> > Hugo can use external JSON data during the build step, so I've worked
>>>>> > out how to list the GitHub library releases directly onto the
>>>>> downloads
>>>>> > page!
>>>>> &g

Re: [Kicad-developers] KiCad Libraries (again)

[José Ignacio]

PS: It would be nice to provide a simplified way for non-GPL users to
provide attribution for the libraries without having to name every single
john doe that made a symbol or footprint. If it's made simple people will
probably be more inclined to comply.

On Mon, Sep 18, 2017 at 5:59 PM, José Ignacio <jose.cyb...@gmail.com> wrote:

> The GPL with font exception is probably the better of the two, as it is
> the least restrictive one contributors seem to agree on.
>
> On Mon, Sep 18, 2017 at 5:47 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com> wrote:
>
>> A further issue that has cropped up twice in the last hour: Library
>> licensing
>>
>> https://github.com/KiCad/kicad-library/issues/1259#issuecomment-330374095
>>
>> https://forum.kicad.info/t/default-libraries-gpl-licencing-v
>> s-proprietary-designs/140/8
>>
>>
>> We have been discussing this for a while in this thread -
>> https://lists.launchpad.net/kicad-developers/msg28181.html
>>
>> It initially looked like we had a consensus but then it quickly devolved
>> and never reached a conclusion.
>>
>> *Without entering into the same back-and-forth again, *and with the
>> following stipulations:
>>
>> a) All libraries will have the same license agreeement
>> b) A single LICENSE.md file will suffice
>>
>> What license should we be using?
>>
>> 1. CC-BY-SA - This is what Wayne originally suggested IIRC
>> 2. modified GPL similar to gEDA license?
>>
>>
>> I need a consensus on this so I can add the license files to the
>> repositories and add the information to the website.
>>
>> Cheers,
>> Oliver
>>
>>
>> On Mon, Sep 18, 2017 at 11:12 PM, Wayne Stambaugh <stambau...@gmail.com>
>> wrote:
>>
>>> Oliver,
>>>
>>> Great work!  This is really shaping up nicely.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 9/17/2017 12:13 AM, Oliver Walters wrote:
>>> > Hugo can use external JSON data during the build step, so I've worked
>>> > out how to list the GitHub library releases directly onto the downloads
>>> > page!
>>> >
>>> > Some progress images here:
>>> >
>>> > https://imgur.com/a/2V6E3
>>> >
>>> > Most of the framework is in place now. I need some assistance with
>>> > wording for /discover/libraries but other than that, almost ready to
>>> go :)
>>> >
>>> > Oliver
>>> >
>>> > On Sat, Sep 16, 2017 at 1:52 PM, Oliver Walters
>>> > <oliver.henry.walt...@gmail.com <mailto:oliver.henry.walt...@gmail.com
>>> >>
>>> > wrote:
>>> >
>>> > Some more
>>> > progress: https://github.com/KiCad/kicad-library/issues/1622
>>> > <https://github.com/KiCad/kicad-library/issues/1622>
>>> >
>>> > On Sat, Sep 16, 2017 at 12:53 PM, Oliver Walters
>>> > <oliver.henry.walt...@gmail.com
>>> > <mailto:oliver.henry.walt...@gmail.com>> wrote:
>>> >
>>> > I have worked out how to transfer the KLC page to the Hugo
>>> > templating system (it is SO much harder to use than Jenkins
>>> :p)
>>> >
>>> > Example:
>>> >
>>> > https://i.imgur.com/4kZnvOA.png <https://i.imgur.com/4kZnvOA.p
>>> ng>
>>> >
>>> > The libraries information is also moved across, but that's just
>>> > static content so it's much simpler.
>>> >
>>> > I'll keep you posted.
>>> >
>>> > On Fri, Sep 15, 2017 at 10:41 PM, Wayne Stambaugh
>>> > <stambau...@gmail.com <mailto:stambau...@gmail.com>> wrote:
>>> >
>>> > On 9/14/2017 8:54 PM, Oliver Walters wrote:
>>> > > Ben,
>>> > >
>>> > > That's also an option, I hadn't considered that! Perhaps
>>> I was focused
>>> > > on the GitHub-side solution too closely.
>>> > >
>>> > > Wayne, do you want to weigh in here before I spend too
>>> much further
>>> > > effort developing this? Could the libraries page be
>>> developed on the
>>> > > KiCad website itself?
>>> >
>>> > The libraries page could be develop

Re: [Kicad-developers] KiCad Libraries (again)

[José Ignacio]

The GPL with font exception is probably the better of the two, as it is the
least restrictive one contributors seem to agree on.

On Mon, Sep 18, 2017 at 5:47 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> A further issue that has cropped up twice in the last hour: Library
> licensing
>
> https://github.com/KiCad/kicad-library/issues/1259#issuecomment-330374095
>
> https://forum.kicad.info/t/default-libraries-gpl-licencing-
> vs-proprietary-designs/140/8
>
>
> We have been discussing this for a while in this thread -
> https://lists.launchpad.net/kicad-developers/msg28181.html
>
> It initially looked like we had a consensus but then it quickly devolved
> and never reached a conclusion.
>
> *Without entering into the same back-and-forth again, *and with the
> following stipulations:
>
> a) All libraries will have the same license agreeement
> b) A single LICENSE.md file will suffice
>
> What license should we be using?
>
> 1. CC-BY-SA - This is what Wayne originally suggested IIRC
> 2. modified GPL similar to gEDA license?
>
>
> I need a consensus on this so I can add the license files to the
> repositories and add the information to the website.
>
> Cheers,
> Oliver
>
>
> On Mon, Sep 18, 2017 at 11:12 PM, Wayne Stambaugh 
> wrote:
>
>> Oliver,
>>
>> Great work!  This is really shaping up nicely.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 9/17/2017 12:13 AM, Oliver Walters wrote:
>> > Hugo can use external JSON data during the build step, so I've worked
>> > out how to list the GitHub library releases directly onto the downloads
>> > page!
>> >
>> > Some progress images here:
>> >
>> > https://imgur.com/a/2V6E3
>> >
>> > Most of the framework is in place now. I need some assistance with
>> > wording for /discover/libraries but other than that, almost ready to go
>> :)
>> >
>> > Oliver
>> >
>> > On Sat, Sep 16, 2017 at 1:52 PM, Oliver Walters
>> > > >>
>> > wrote:
>> >
>> > Some more
>> > progress: https://github.com/KiCad/kicad-library/issues/1622
>> > 
>> >
>> > On Sat, Sep 16, 2017 at 12:53 PM, Oliver Walters
>> > > > > wrote:
>> >
>> > I have worked out how to transfer the KLC page to the Hugo
>> > templating system (it is SO much harder to use than Jenkins :p)
>> >
>> > Example:
>> >
>> > https://i.imgur.com/4kZnvOA.png > ng>
>> >
>> > The libraries information is also moved across, but that's just
>> > static content so it's much simpler.
>> >
>> > I'll keep you posted.
>> >
>> > On Fri, Sep 15, 2017 at 10:41 PM, Wayne Stambaugh
>> > > wrote:
>> >
>> > On 9/14/2017 8:54 PM, Oliver Walters wrote:
>> > > Ben,
>> > >
>> > > That's also an option, I hadn't considered that! Perhaps
>> I was focused
>> > > on the GitHub-side solution too closely.
>> > >
>> > > Wayne, do you want to weigh in here before I spend too
>> much further
>> > > effort developing this? Could the libraries page be
>> developed on the
>> > > KiCad website itself?
>> >
>> > The libraries page could be developed on KiCad website
>> > although I'm not
>> > sure how that would work.  I am comfortable with either
>> > solution.  Pick
>> > which ever solution is the most comfortable for you.  Since
>> > you are
>> > doing the work, you should choose the implementation unless
>> > someone else
>> > is willing step up and help out.  Even the basic overview
>> > that you
>> > presented is far better than anything we have at the
>> > moment.  We can
>> > always add more features later.
>> >
>> > >
>> > > The structure could remain largely the same but the
>> formatting would
>> > > need to change from Jekyll to Hugo.
>> > >
>> > > Cheers,
>> > > Oliver
>> > >
>> > > On Fri, Sep 15, 2017 at 1:17 AM, Ben Hest <
>> bombledm...@gmail.com 
>> > >  bombledm...@gmail.com>>> wrote:
>> > >
>> > > Does this method provide an advantage over doing a
>> similar thing
>> > > using Hugo and putting the docs on the kicad-pcb.org
>> 
>> > > 
>> > > website? https://github.com/KiCad/kicad-website
>> > 
>> > > > >

Re: [Kicad-developers] [RFC] Changing default text size

[José Ignacio]

Why not just change eeschema to assume a missing text size is 0.060, and
always write the text size. Then use 0.050 as the default size for new
items. that way it is both forward and backward compatible.

On Thu, Sep 7, 2017 at 5:44 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Wayne,
>
> So are you saying that if a text item has a default text size (hard-coded
> to 0.060") then this text size will *not* be written to the file? i.e. an
> omitted text field size means "use default size"?
>
> Oliver
>
> On Fri, Sep 8, 2017 at 4:30 AM, Wayne Stambaugh 
> wrote:
>
>> If you change the default text size, then users schematics will appear
>> differently the next time they open their schematics and they will have
>> to go back an change them back to .060" which will change their file(s).
>>  Will users even notice?  I don't know but if they do, I'll bet they
>> wont be happy about it.
>>
>> On my todo list is a global text size dialog similar the the one in
>> Pcbnew for setting schematic object text sizes.  This may be a less
>> intrusive way to set schematic texts sizes rather than change the default.
>>
>> On 9/7/2017 12:12 AM, Oliver Walters wrote:
>> > Currently the default text size in eeschema for labels is 60mils.
>> >
>> > The official libs and KLC require 50mils. Users can "easily" change the
>> > default setting to 50mils but it seems an unnecessary step that could be
>> > removed.
>> >
>> > Would changing the default label size from 60mils to 50mils break
>> > anything? For example are label size numbers omitted in a file format if
>> > they are default?
>> >
>> > Cheers,
>> > 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
>
>
___
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] New feature: support for Gerber job file.

[José Ignacio]

Another element of this would be to support an arbitrary amount of stacked
mechanical layers. I've been designing some flexible PCBs lately and using
the user layers to specify stiffeners is a bit clunky. It would be nice if
the 3d renderer could do multiple stacked edges. I've had to make separate
step files and use virtual components to cobble together correct step
output for stiffeners, adhesive pads and liners.

On Fri, Sep 1, 2017 at 1:48 PM, Greg Smith  wrote:

> Here are some references to a variety of stackup information:
>
>  # interesting info on cores, prepreg, and foils
>  # https://www.multi-circuit-boards.eu/en/pcb-design-aid/
> layer-buildup/prepreg-core-foil.html
>  # More terminology:
>  # http://www.edn.com/design/pc-board/4424239/PCB-design-basics
>  # PCB manufacturing info from advanced circuits (4pcb):
>  # http://www.4pcb.com/media/building-printed-circuit-board.pdf
>
>
>
>
> On Friday, September 1, 2017, 5:12:35 AM CDT, Ingo Kletti <
> ikle...@htwg-konstanz.de> wrote:
>
>
>
>
> Am 01.09.2017 um 10:06 schrieb jp charras:
> > Could you give a link to a manufactured that explains applications
> (and show a few boards) where
> > different substrates are used.
> From experience I can say that many (non-ceramic) RF materials are
> rather soft (most common a mix of PTFE and glass fiber reinforcement)
> and thin.
>
> In the designs that I worked on , we therefore created 4-layer PCBs with
> a core consisting of more rigid material (most times FR4).
>
> Another mix of materials might be PCBs with a solid metal backing used
> for cooling applications (think LED lighting, motor drivers, etc.).
>
> And another application for mixed materials are flex-rigid PCBs.
>
> While the different PCBs types are not explained in detail, the brochure
> from Optiprint has some photos of complex designs:
>
> http://www.optiprint.ch/pdf/Optiprint_Imagebroschuere_2014_EN.pdf
>
>
>
> ___
> 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] Dealing with addition to kicad_pcb files

[José Ignacio]

I don't see why you couldn't have both, an embedded version of the actual
setup and the ability to import/export from/to an external file.

On Thu, Aug 31, 2017 at 12:54 PM, Neal Hollingsworth 
wrote:

> Hi all,
>   I've mostly been lurking on the list, but thought I would make a
> suggestion regarding the via stack configuration. It might be nice to store
> the actual configuration/stack-up/DRC settings in an external file. The
> idea is that these are processes paraders that are deaigned to in most
> cases. This would make it possible have have e.g. A configuration file for
> a specific board house and price point. The board file would then only need
> to store a reference to the configuration file. Just a thought, take it for
> whatever it's worth!
>Neal Hollingsworth
>
> On Thu, Aug 31, 2017 at 12:44 PM Wayne Stambaugh 
> wrote:
>
>> On 8/31/2017 1:21 PM, Bastian Neumannn wrote:
>> > Hi,
>> >
>> > I am currently building a feature that lets you input a via stack
>> > configuration.
>> > This information needs to be saved with the pcb data. So I tried putting
>> > it into
>> > the kicad_pcb file.
>> >
>> > Now older versions will not load the file because it has additional
>> > values that
>> > it did not expect.
>> >
>> > How do you deal with that problem?
>>
>> The official policy is that file format changes must be backwards
>> compatible not forwards compatible.  In other words, the user will have
>> to download the version KiCad where the change was made.
>>
>> If you make any changes to any of the file formats, you must increment
>> the file format rev number.  This will cause the appropriate exception
>> to be raised which will warn the user the file version is newer than the
>> file version supported by the version of KiCad they are using.
>>
>> Since this is all very new and has not been planned for the stable 5
>> release, I would most likely merge this into the master branch after the
>> stable 5 branch is created.
>>
>> Cheers,
>>
>> Wayne
>>
>> >
>> > Cheers,
>> > Basti
>> >
>> >
>> > ___
>> > 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
>>
> --
>Neal
>
> ___
> 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] Routing algorithm used in PCB

[José Ignacio]

You already established that you want to extract techniques from kicad for
your own project instead of contributing. The code is all there in the
repo, free to use under the GPL.

On Mon, Aug 28, 2017 at 12:41 AM, Arun Kumar  wrote:

> Hi Team,
>
> Which PCB routing algorithm are used in PCB designing in Kicad?
>
> Thanks
> Arun
>
> ___
> 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] Update Fields in eeschema

[José Ignacio]

YES!

On Fri, Aug 25, 2017 at 8:37 AM, Maciej Sumiński 
wrote:

> The attached patches add to eeschema possibility of updating fields for
> components already placed on schematics sheet using library values.
>
> It is useful for users maintaining additional fields in libraries to
> store information that may change over time (e.g. Obsolete, URL fields).
>
> Regards,
> Orson
>
> ___
> 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] simplied right click menu icons

[José Ignacio]

Most if not all of kicad is in US english, that can go in the en_UK
localization, together with spelling color as colour and -ise instead of
-ize.

On Wed, Jul 19, 2017 at 8:51 AM, Chris Goddard <ch...@oofus.co.uk> wrote:

> Just to add my 2p, Counter-clockwise is an American term. In the UK it's
> Anticlockwise.
>
> Cheers
>
> Chris
>
>
> On 19/07/2017 14:35, Wayne Stambaugh wrote:
>
>> On 7/19/2017 6:17 AM, Fabrizio Tappero wrote:
>>
>>> Hi Wayne,
>>> Thanks for the many messages. I did not know that devs were so into
>>> translation...
>>>
>>> My overall effort is to uniformise the Kicad UI and make it consistent
>>> and as correct as possible.
>>>
>>> Currently in Kicad we are using "Rotate 90 deg CW" and "Rotate 90 deg
>>> CCW" in many many menus (see below). This expression is also used in
>>> Inkscape, a pretty high standard software for vector image manipulation.
>>> I personally think that consistency is the most important aspect of my
>>> contributions and, despite loving internal conversations about
>>> translations, etc I think we need to pick what is considered the best
>>> expression and use it coherently in all kicad menus. I have the feeling
>>> that if I submit a similar patch in few months, this kind of discussion
>>> will come up again. In a way this is typical of open-source software, so
>>> maybe it is not a bad thing.
>>>
>>
>> I'm fine with consistent but consistently incorrect or confusing is no
>> better than inconsistent.
>>
>>
>>> In my opinion I think it would be good not to reinvent expressions. I
>>> think "CW" and "CCW" is a perfectly understandable and usable expression.
>>>
>>
>> CW and CCW are not expressions.  They are abbreviations which may not be
>> understood outside of English.  I would prefer not to use abbreviations
>> except for units unless space is at a premium.  In this case, I don't
>> think there is a space issue.  Please use terms clockwise and
>> counterclockwise.  These are the correct English terms for rotation
>> direction.
>>
>>
>>> The custom-defined rotation value is a new piece of info, thanks Wayne
>>> for that! does it apply to all rotations?
>>>
>>
>> This only applies when the user changes the default rotation angle from
>> 90 to something else.  The rotation angle is fixed to 90 in the
>> schematic, symbol library, and footprint library editors and is user
>> configurable in the board editor.
>>
>>
>>> Please advise how to modify this patch to make it submittable.
>>>
>>
>> Use clockwise and counter clockwise instead of CW and CCW.  Either
>> remove the 90 deg rotation angle or use the user rotation angle in the
>> board editor menu string.  I don't have a preference.
>>
>>
>>> Cheers
>>> Fabrizio
>>>
>>>
>>>
>>> Inline image 1
>>>
>>>
>>> On Wed, Jul 19, 2017 at 2:47 AM, Wayne Stambaugh <stambau...@gmail.com
>>> <mailto:stambau...@gmail.com>> wrote:
>>>
>>>  On 7/18/2017 8:24 PM, Chris Pavlina wrote:
>>>  >> (remember, this is localization, not literal translation)
>>>  >
>>>  > Thank you! en_US should be "counterclockwise" and "clockwise" (or
>>>  > even CCW/CW would be easily understood), and different phrasings
>>>  > should be used in different languages. Don't avoid "clockwise" in
>>>  > English because the French don't use it. It's up to the
>>> translators
>>>  > to decide how things should be phrased in their locale.
>>>
>>>  Yes!  This is how it should be done.
>>>
>>>  >
>>>  > On Tue, Jul 18, 2017 at 07:19:35PM -0500, José Ignacio wrote:
>>>  >> Clockwise and counter-clockwise are the most usual term in
>>> American
>>>  >> Engish, other localizations should use the most usual term in
>>> their
>>>  >> respective locales (remember, this is localization, not literal
>>>  >> translation). For example in Argentinian Spanish it should be
>>>  >> "Horario" and "Antihorario". Encoding information in the icons
>>> only
>>>  >> is not a good idea, as users can disable them (or the system can
>>>  >> disable them by default) also screen readers can't r

Re: [Kicad-developers] [PATCH] simplied right click menu icons

[José Ignacio]

Clockwise and counter-clockwise are the most usual term in American Engish,
other localizations should use the most usual term in their respective
locales (remember, this is localization, not literal translation). For
example in Argentinian Spanish it should be "Horario" and "Antihorario".
Encoding information in the icons only is not a good idea, as users can
disable them (or the system can disable them by default) also screen
readers can't read icons (though i doubt many blind people would be using
kicad to lay out circuits).

On Tue, Jul 18, 2017 at 4:00 PM, Clemens Koller  wrote:

> Hi!
>
> If we want to avoid clockwise (CW) and counterclockwise (CCW) I suggest to
> add a sign to the rotation, which should be trivial to translate:
>
> Mathematics/complex plane stuff tells that:
> CCW = positive rotation =  rotate + = rot+
> CW = negative rotation = rotate - = rot-
>
> In german we can use "rotieren +" und "rotieren -".
>
> Regards,
>
> Clemens
>
>
> On 2017-07-18 19:34, jp charras wrote:
> > Le 18/07/2017 à 19:14, "Jörg Hermann" a écrit :
> >> Translation of Clockwise and Counterclockwise are long texts in many
> languages:
> >> Uhrzeigersinn and Gegenuhrzeigersinn in german for example.
> >>
> >> If the icon depicts (dynamically) the sense of rotation, the text can
> be short as "Rotate" - which
> >> is short in many languages.
> >> Just an idea?
> >>
> >> Jörg Hermann
> >>
> >
> > I agree icons should show the rotation.
> >
> > However Rotate Clockwise (or Counter Clockwise ) is still needed (just
> "Rotate" is not acceptable)
> > because icons are not always displayed:
> > - On OSX by default (although they can be shown, this is an option in
> Kicad, now)
> > - On Linux, some WM do not display icons in menus.
> >
> > Besides, English language is know for its short words and sentences.
> > Translations are using most of time longer words and sentences, and this
> is sometimes an issue in menus.
> > We (translators) have to live with that.
> >
>
> ___
> 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] simplied right click menu icons

[José Ignacio]

Well, WM is technically incorrect, but GTK3 has icons off by default unless
the application forces them on (vs on by default in GTK2)

On Tue, Jul 18, 2017 at 12:35 PM, Chris Pavlina 
wrote:

> On Tue, Jul 18, 2017 at 07:34:25PM +0200, jp charras wrote:
> > Le 18/07/2017 à 19:14, "Jörg Hermann" a écrit :
> > > Translation of Clockwise and Counterclockwise are long texts in many
> languages:
> > > Uhrzeigersinn and Gegenuhrzeigersinn in german for example.
> > >
> > > If the icon depicts (dynamically) the sense of rotation, the text can
> be short as "Rotate" - which
> > > is short in many languages.
> > > Just an idea?
> > >
> > > Jörg Hermann
> > >
> >
> > I agree icons should show the rotation.
> >
> > However Rotate Clockwise (or Counter Clockwise ) is still needed (just
> "Rotate" is not acceptable)
> > because icons are not always displayed:
> > - On OSX by default (although they can be shown, this is an option in
> Kicad, now)
> > - On Linux, some WM do not display icons in menus.
>
> What? WM has no control over menus.
>
> >
> > Besides, English language is know for its short words and sentences.
> > Translations are using most of time longer words and sentences, and this
> is sometimes an issue in menus.
> > We (translators) have to live with that.
> >
> > --
> > Jean-Pierre CHARRAS
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] LOCALE_IO sucks

[José Ignacio]

Please go ahead, it makes the code hard to read when instancing an object
in the middle of a function causes a global change in the application.
Encoding should be encapsulated in the streams themselves. Without that,
the ugly hack is the only way to make the even uglier global locale setting
hack be exception safe.

On Mon, Jul 17, 2017 at 7:44 PM, Chris Pavlina 
wrote:

> If I somehow found the time to strip LOCALE_IO completely out of the
> footprint parser without changing the behavior, would anyone have any
> religious objections or otherwise mourn the loss?
>
> --
> Chris
>
> ___
> 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] Improving SCM behaviour of kicad_pcb

[José Ignacio]

I've noticed another annoying churn in eeschema, when annotating the
schematics power flags get re-annotated even if they already had refs
assigned from before and the annotate command is not set to overwrite. I
don't know if it does it all the time but it does it fairly often in my
experience.

On Mon, Jul 10, 2017 at 11:52 AM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> Forward compatibility is highly unlikely given our limited manpower.
>
> There is a fundamental misunderstanding about net names.  Pcbnew does
> not have anything to do with naming them.  Pcbnew on reads the net names
> from the net list.  The net names are generated by Eeschema and passed
> to Pcbnew so the issue is with Eeschema.  Currently, Eeschema does not
> save undefined (unlabeled) net names.  It automatically renumbers them
> each time a new netlist is generated.  One work around is to label every
> net in Eeschema using some type of label.  I do this so I know which
> signals I'm routing.  I've never found net names such as N-# very
> useful.
>
> I am considering saving automatically assigned net names in the new
> schematic file format but that is still uncertain at this point.
>
> On 7/10/2017 11:26 AM, José Ignacio wrote:
> > The problem is that you can't make old kicad read the new format, unless
> > a patch gets backported.
> >
> > On Mon, Jul 10, 2017 at 10:19 AM, Kristoffer Ödmark
> > <kristofferodmar...@gmail.com <mailto:kristofferodmar...@gmail.com>>
> wrote:
> >
> > Could we not support reading both formats, but only write one format?
> >
> > - Kristoffer
> >
> >
> > On 2017-07-10 09:36, Maciej Sumiński wrote:
> >
> > I think there is a lot of code that assumes consecutive net
> > numbering.
> > Instead, we could simply save net names instead of net numbers
> > and let
> > KiCad use net codes as convenient. One significant problem is it
> > would
> > cause the .kicad_pcb file format change, making it completely
> > unreadable
> > by the current stable.
> >
> > Regards,
> > Orson
> >
> > On 07/01/2017 04:49 AM, hauptmech wrote:
> >
> >
> > We have a fairly complex board that needs to be done
> > yesterday. We've
> > been experimenting with simultaneous editing of the pcb with
> > moderate
> > success.
> >
> > We are using git. Each person works in a different area of
> > the board,
> > and we merge the results periodically.
> >
> > Because of the time crunch, we are only focusing on what
> > works in this
> > process, and staying away from edits that do not work.
> > Moving footprints
> > and laying tracks works fine.
> >
> > A couple things I've noticed that could improve things:
> >
> > net indexes of nets are not stable. Maybe
> > eeschema/netlist.cpp:369
> > Maybe we could wait until we get close to running out of
> > integers before
> > we do this?
> >
> > module order gets changed in some edits (Not sure but
> > probably "fix
> > module file details and update modules in pcb" type edits).
> > Ordering
> > modules by reference would fix this.
> >
> >
> > We are getting enough benefit that we'll keep refining the
> > technique.
> >
> >
> >
> >
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > <https://launchpad.net/~kicad-developers>
> > Post to : kicad-developers@lists.launchpad.net
> > <mailto:kicad-developers@lists.launchpad.net>
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > <https://launchpad.net/~kicad-developers>
> > More help   : https://help.launchpad.net/ListHelp
> > <https://help.launchpad.net/ListHelp>
> >
> >
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > <https://launchpad.net/~kicad-developers>
> > Post to : kicad-developers@lists.launchpad.ne

Re: [Kicad-developers] Improving SCM behaviour of kicad_pcb

[José Ignacio]

The problem is that you can't make old kicad read the new format, unless a
patch gets backported.

On Mon, Jul 10, 2017 at 10:19 AM, Kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:

> Could we not support reading both formats, but only write one format?
>
> - Kristoffer
>
>
> On 2017-07-10 09:36, Maciej Sumiński wrote:
>
>> I think there is a lot of code that assumes consecutive net numbering.
>> Instead, we could simply save net names instead of net numbers and let
>> KiCad use net codes as convenient. One significant problem is it would
>> cause the .kicad_pcb file format change, making it completely unreadable
>> by the current stable.
>>
>> Regards,
>> Orson
>>
>> On 07/01/2017 04:49 AM, hauptmech wrote:
>>
>>>
>>> We have a fairly complex board that needs to be done yesterday. We've
>>> been experimenting with simultaneous editing of the pcb with moderate
>>> success.
>>>
>>> We are using git. Each person works in a different area of the board,
>>> and we merge the results periodically.
>>>
>>> Because of the time crunch, we are only focusing on what works in this
>>> process, and staying away from edits that do not work. Moving footprints
>>> and laying tracks works fine.
>>>
>>> A couple things I've noticed that could improve things:
>>>
>>> net indexes of nets are not stable. Maybe eeschema/netlist.cpp:369
>>> Maybe we could wait until we get close to running out of integers before
>>> we do this?
>>>
>>> module order gets changed in some edits (Not sure but probably "fix
>>> module file details and update modules in pcb" type edits). Ordering
>>> modules by reference would fix this.
>>>
>>>
>>> We are getting enough benefit that we'll keep refining the technique.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> 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] [RFC] 3D models repository

[José Ignacio]

Unfortunately that doesn't seem to be the intent of the people who made the
3d model generators, as they inject the license into the model files, and
explicitly stated that they indeed want to restrict some uses of the
mechanically generated models so people can't compile them in their own
libraries with different usage terms. They do have a point as people could
theoretically improve the scripts, not contribute back and lock down their
generated models. The GPL cant force them to contribute back their script
modifications if they just run it themselves and not give it out to
anyone*. It is within their right as copyright holders to try and prevent
that and all I can do is to just avoid using their library.

* Including guts of the copylefted work into the output to force the
production of a "combined work", and thus extend the copyleft to the output
might not be successfully enforceable anyway. So the "license" would need
to be a good deterrent at best, or perhaps something else could be used.
Recently when i needed CAD data from manufacturers they would not let me
download it unless i signed a contract with them (i guess their legal
realized that copyright would not be enough for functional models of their
parts) so they could use contract law to go after me if i used the model in
ways they don't like. (I am of course not suggesting doing anything like
that as it's absolutely dreadful).

On Fri, Jun 30, 2017 at 6:21 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Cirilo,
>
> Can we stipulate as part of the license file that any contributors agree
> implicitly that their generated models are released as public domain? i.e.
> don't require explicit release from every contributor, as it is inherent to
> the library LICENSE?
>
> a) If you contribute model / footprint / symbol to KiCad libraries, they
> can be distributed in accordance with [whatever license we choose here]
>
> b) KiCad assumes no responsibility for the accuracy of the model data
>
> c) Library data may be shared freely*
>
> * Here "freely" is the current source of contention. I am all for having
> as permissive a license as possible - I don't see any benefit from locking
> the library down.
>
> Oliver
>
> On Sat, Jul 1, 2017 at 8:25 AM, Cirilo Bernardo  > wrote:
>
>> On Thu, Jun 29, 2017 at 8:16 AM, Oliver Walters
>>  wrote:
>> > Would it be sufficient to drop the "Copyright (C) 2017 KiCad" header?
>> >
>>
>> No, because we have no idea who holds copyright. KiCad cannot be a
>> copyright holder
>> because it is not a legal entity (person or corporation). We would
>> need to maintain a text
>> file which is a register of the copyright holders of each file.  To
>> complicate things, many
>> models are generated from parametric scripts.  The scripts themselves
>> are copyright
>> material but the models produced is a different matter. If you can get
>> all script contributors
>> to agree, then I think it would be best to release the generated
>> models as Public Domain.
>> Even this is not so simple because we would need to maintain a
>> directory with declarations
>> from script contributors to state that the output of the scripts are
>> Public Domain. Even
>> that is not so simple because some jurisdictions may not accept that
>> mechanism.
>>
>> - Cirilo
>>
>> > On Thu, Jun 29, 2017 at 5:28 PM, Javier Serrano
>> >  wrote:
>> >>
>> >> On Thu, Jun 29, 2017 at 3:27 AM, Oliver Walters
>> >>  wrote:
>> >>>
>> >>> Wayne, others,
>> >>>
>> >>> A lot of input here, thanks everyone.
>> >>>
>> >>> Based on the suggestions above, my proposal is as follows:
>> >>>
>> >>>
>> >>> 
>> 
>> >>>
>> >>> symbols licence file:
>> >>>
>> >>>
>> >>> 
>> 
>> >>> Copyright (C) 2017 KiCad
>> >>>
>> >>
>> >>  I agree with Simon that "KiCad" cannot be the copyright holder.
>> Imagine
>> >> for the sake of argument I need to contact the copyright holder. Say I
>> would
>> >> like to negotiate with him/her a change of licence. I want to use the
>> >> material without being subject to the CC-BY-SA licence, and I am
>> willing to
>> >> pay for it. So I'd like to benefit from some kind of dual-licensing
>> scheme,
>> >> whereby I receive e.g. a copy of a 3D model file with a special
>> licence just
>> >> for me. Only the copyright holder can do that. Now I go to the file
>> and I
>> >> read "Copyright KiCad." Who should I speak to? Who has the right to do
>> what
>> >> I need? That's just an example. For any action where you would need the
>> >> copyright holder to do something, you'd bump against the same issue.
>> One
>> >> could conceivably define KiCad as a valid legal entity, and then you
>> could
>> >> have KiCad be the copyright holder, as the FSF 

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

[José Ignacio]

Part of my argument is that for footprints and symbols there isn't much to
improve, they are either correct or they aren't, once a footprint is done
it probably should not be ever modified individually, most changes you
usually want to do to a library are sweeping and probably even automated,
those tools to manipulate the libraries should be copylefted, as any
improvements contributed back to them would be a great help for maintaining
the library and since the license of those scripts would not influence the
output people can use them not only in the publicly available symbols but
their own internal libraries too (allowing for people like me to use their
paid time to work on such tools). Here is the commit count for the
footprints in Chris' library: https://pastebin.com/raw/XjSggYJR virtually
all the manually created footprints were only edited once or not at all
since created. The larger changes happened to the IPC footprints, which
were automatically generated from a script tracked in the same repository.
A cursory look at the official kicad footprint repos shows a similar
pattern. You really want people to publish their footprints rather than
just "improvements", and copyleft is not enough to enforce that since
people can just put their footprints in their own library and not share
them with anyone.

 All in all probably the largest incentive to make people contribute back
to the commons is to make it very convenient rather than just choosing a
license that mandates it and letting people figure it out.

PS: another inconvenience for the license is section 3.a, attribution.
There is no automated way to generate a proper attribution list from the
schematic/layout, since each library is housed in a different repository
with different contributors it can get pretty unwieldy. Also, even though
section 3.b is waived by that addendum you are still required by section
3.a.1.B to "indicate if You modified the Licensed Material and retain an
indication of any previous modifications" Untracked modifications are easy
to do when you have an embedded footprint in the board and you do things
like changing a pad size, hole size or layers. Keeping track of all that
information is pretty onerous in my opinion.

On Thu, Jun 29, 2017 at 9:21 AM, Javier Serrano <
javier.serrano.par...@gmail.com> wrote:

> On Thu, Jun 29, 2017 at 3:28 PM, Simon Richter 
> wrote:
>
>> Hi,
>>
>> On 29.06.2017 12:18, Javier Serrano wrote:
>>
>> > I agree the creative side is stronger for symbols than for footprints.
>> > Copyrightability is, as you well point out, a subject of debate in
>> > various areas. However, I think the real debate we should have is
>> > whether we want to make the official libraries permissive or weak
>> > copyleft.
>>
>> I'd be completely fine with PD/CC0 for symbols and footprints, because
>> they need to be available to users without having to check license
>> compatibility first.
>>
>> If people are using 3D models for more than nice renderings (e.g. to
>> determine the cutout from the case), then a permissive license would be
>> required here as well in order to avoid complications for the
>> manufacturing files.
>>
>
> Please see my comment below on the paragraphs we proposed.
>
>
>
>>
>> > I am not sure I understand the argument. There are clearly more risks of
>> > proprietarization whenever you use a permissive license, because you are
>> > explicitly giving permission to improve and not share back.
>>
>> Designing a license that would require people to share library
>> improvements but not their PCB designs would be difficult.
>>
>>
> Wait, what you describe as "difficult" is what the paragraphs we submitted
> do. They are written by a lawyer, and I don't see how they could be
> misinterpreted. Incidentally, geda does the same, except taking GPL as a
> basis instead of CC-BY-SA:
>
> http://wiki.geda-project.org/geda:license
>
> Again, for me the question is: do we want to *explicitly* allow people to
> take components of a library, improve them and not share the improvements
> back? If yes, CC0. If not, CC-BY-SA with the proposed paragraphs to clarify
> that the license provisions do not extend to the whole schematics, layout
> or circuit model.
>
> Cheers,
>
> Javier
>
> ___
> 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] 3D models repository

[José Ignacio]

My two cents. All this copyleft licensing stuff for _libraries_ is
over-complicating things, copyright on stuff like footprints and accurate
3d models is fairly tenuous as the representation of the work is very
tightly constrained by engineering concerns and standardization, and a good
chunk are (or can be) machine generated from databases already in the
public domain.

There are already two repositories of kicad footprints and symbols in the
public domain (or CC0 where not allowed) that I use heavily and
occasionally contribute to: https://github.com/cpavlina/kicad-schlib
https://github.com/cpavlina/kicad-pcblib I am not trying to undermine the
official kicad library effort, but I mention this if people are not aware,
and would like to contribute to the public domain.

My kicad use is almost exclusively commercial but I contribute every new
symbol and footprint I make (except the ones that are so project specific
that would be absolutely useless for anyone else, or by client's specific
request) back to the public domain in my fork of those repos (
https://github.com/iromero91/kicad-pcblib
https://github.com/iromero91/kicad-schlib) partly because of the way those
libraries are intended to be used, it is much easier to publish stuff than
hoard it, no license needs to compel me to do it.

Just to clarify, I have no issues with copyleft in general, specially I
think copyleft is beneficial for software and tools like kicad, or even
tools like footprint, symbol and model generators, I just feel it is not
quite right to have their license extend to generated items when the input
data could be part of a public domain database; Or to worry too much about
claiming copyright on each little symbol or footprint whose main design
elements are either copied from manufacturer recommendations or
mechanically/slavishly derived from such and current industry standards.

I understand that generating and maintaining a database of components is a
lot of work, and people don't like being taken advantage of, but copyright
might be the wrong tool for the job. What would be the real risk we are
protecting ourselves against with a defensive license on the libraries? For
kicad itself there is a risk people like some pcb manufacturers that like
to have their own branded tools could take it, add things to it, build an
userbase and then not contribute back to the main project. I don't feel the
same would happen with libraries, how would it fragment the community? If
something is public domain people can't just slap their copyright on top of
it and try to enforce it, specially if the whole public domain database is
already included with the software for everyone to see.

Sorry for the long ramble,
Jose


On Wed, Jun 28, 2017 at 6:24 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Wayne, Maciej, et al,
>
> This has been sitting in my //todo for a while. Can I get some
> clarification on the LICENSE issue and then I will ensure it is applied to
> the repos:
>
> Am I correct in my understanding that the following text is ALL that is
> required (placed within a LICENSE file in each repo)?
>
> "This work is licensed under the Creative Commons CC-BY-SA 4.0 License.
>> To the extent that circuit schematics that use Licensed Material can be
>> considered to be ‘Adapted Material’, then the copyright holder waives
>> article 3.b of the license with respect to these schematics."
>
>
> Or is this an addendum required to be made and I am required to include
> the entire CC-BY-SA text?
>
> Regards,
> Oliver
>
> On Tue, Apr 11, 2017 at 6:41 AM, Wayne Stambaugh 
> wrote:
>
>> I prefer the former.  Adding the license to fields would be cumbersome.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 4/10/2017 4:43 PM, Maciej Suminski wrote:
>> > The easiest way to include the license is to put a file containing the
>> > text in the libraries repository. Alternatively, the text could be
>> > stored in the 'License' field for symbols or 'Doc' property for
>> > footprints, but it feels a bit too wordy to me.
>> >
>> > Cheers,
>> > Orson
>> >
>> > On 04/07/2017 11:55 AM, Javier Serrano wrote:
>> >> On Sun, Feb 26, 2017 at 6:21 PM, Wayne Stambaugh > >
>> >> wrote:
>> >>
>> >>> I'm still waiting for our friends at CERN for an answer on library
>> >>> licensing.  We are leaning towards CC-SA with the use exception
>> clause.
>> >>> I turning out to be the longest time ever to write a single sentence.
>> ;)
>> >>>
>> >>
>> >> OK, better late than never. Here are the proposals:
>> >>
>> >> For schematics symbols and for complete symbol libraries:
>> >>
>> >> "This work is licensed under the Creative Commons CC-BY-SA 4.0 License.
>> >> To the extent that circuit schematics that use Licensed Material can be
>> >> considered to be ‘Adapted Material’, then the copyright holder waives
>> >> article 3.b of the license with respect to these schematics."
>> >>
>> >> For footprints and libraries of footprints:
>> >>
>> >> "This 

Re: [Kicad-developers] menu icons

[José Ignacio]

Menu icons are disabled by default in gnome 3 in an effort to make it look
more like an Apple product. You can enable them (on gtk 3.10+) with:

gsettings set org.gnome.settings-daemon.plugins.xsettings overrides
"{'Gtk/ButtonImages': <1>, 'Gtk/MenuImages': <1>}"

On Mon, Jun 5, 2017 at 5:11 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> I have also noticed this on Linux version
>
> On Tue, Jun 6, 2017 at 8:07 AM, Marco Ciampa  wrote:
>
>> I work under Linux.
>> I do not see any menu icon, either with the git compiled version or the
>> snpy one.
>> Is this normal?
>>
>> TIA
>>
>> Regards,
>>
>> --
>>
>>
>> Marco Ciampa
>>
>> I know a joke about UDP, but you might not get it.
>>
>> 
>>
>>  GNU/Linux User #78271
>>  FSFE fellow #364
>>
>> 
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
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] kicad right click menu corrections and few icons corrections

[José Ignacio]

The use of "..." for menu items that show a dialog with extra options
necessary to perform the operation has been in Microsoft's UX guidelines
and apple's HIG since time immemorial:

https://msdn.microsoft.com/en-us/library/dn742392.aspx#usingellipses

https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/OSXHIGuidelines/TerminologyWording.html#//apple_ref/doc/uid/2957-CH15-SW3

https://developer.gnome.org/hig/stable/writing-style.html.en#ellipses

It is a very well known and traditional convention and Kicad shouldn't
break it. As the guidelines say, the ellipsis (...) is reserved for
commands that need further input from the user to proceed, showing a modal
dialog shouldn't be enough to warrant adding the ellipsis (though I've seen
several programs be ellipsis-happy and put it on everything that calls a
dialog...)

On Fri, Jun 2, 2017 at 8:20 AM, Fabrizio Tappero  wrote:

> Hi JP,
>
> thanks a lot!!
>
> I am a little unsure about this "Save as..." three dots thing used every
> time the menu item takes you to a second window. but I will investigate
> about UI stuff a little.
>
> cheers
> Fabrizio
>
>
>
>
> On Fri, Jun 2, 2017 at 12:44 PM, jp charras  wrote:
>
>> Le 30/05/2017 à 14:54, Fabrizio Tappero a écrit :
>> > Hello Wayne,
>> > In attachment you can find a good review of approx 30 icons and a global
>> > simplification of approx 30 icons.
>> > I have also corrected some menu labels.
>> >
>> > Since there is a lot of corrected text that is very much related to
>> > English, it would be great if you could review it before submitting it.
>> A
>> > not so fun work but I think it will make kicad a much better tool.
>> >
>> > I think it would be recommendable to avoid "a" and "the" in button and
>> menu
>> > tooltips. So that it way easier to understand what the button or
>> tooltip is
>> > about. The use of singular plural is also inconsistent and I tried to
>> fix
>> > it. Please Wayne feel free to make any changes you think is important.
>> >
>> > I have also notices that several menus are a little inconstant. I will
>> try
>> > work on it since I think the current kicad UI is very usable but it
>> needs
>> > to be more consistent.
>> >
>> > I have tried to fixed a lot of icons so that their meaning is more
>> > immediate to understand. I have as well started a process of
>> simplification
>> > of many redundant icons. I think it is important that we begin
>> simplifing
>> > the kicad icon set because at the moment is really too large.
>> >
>> > Here below a detailed description of the changes.
>> >
>> > Cheers
>> > Fabrizio
>>
>>
>> Hi Fabrizio,
>>
>> I committed your icons.
>> Thanks.
>>
>>
>> --
>> Jean-Pierre CHARRAS
>>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [FEATURE] Partial selection in pcbnew

[José Ignacio]

Or switching between object and grid snap :)

On Mon, May 8, 2017 at 5:34 PM, Wayne Stambaugh 
wrote:

> I tend to lean toward Oliver's approach.  Most CAD tools I've used have
> this type of includes vs intersects selection paradigm.  I don't see the
> need to tie up the modifier key if we don't have to.  I would prefer
> that we keep a modifier key open for something like orthogonal move.
>
> On 5/8/2017 5:51 PM, Oliver Walters wrote:
> > I was approaching this from having used mechanical CAD tools where the
> > direction of selection is the standard approach. Whatever function is
> > chosen, it will still be required that the users adjust to the new
> > style, manuals updated, etc.
> >
> > Is assigning what is essentially the last remaining modifier key worth
> > it for this?
> >
> > On 8 May 2017 23:55, "Nick Østergaard"  > > wrote:
> >
> > 2017-05-08 14:59 GMT+02:00 Maciej Sumiński  > >:
> > > Hi Oliver,
> > >
> > > I took your set of patches for a test drive. I am glad that you
> > thought
> > > about the subtractive mode in the selection tool, it really fits
> > there.
> > > Regarding different selection modes - I like the idea, but I think
> the
> > > two modes should be more distinct, changing the selection direction
> > > might be not enough.
> > >
> >
> > I personally prefer modifier keys as we are used to in Gimp and
> > Inkscape.
> >
> > > I observed another user trying out the tool and he could not tell
> how
> > > does it work, but noticed it is a bit different than the old tool.
> > >
> > > Perhaps one of the following would work:
> > >
> > > - change the selection box colors so they are easier to tell apart
> (my
> > > mate was surprised to find out there were two colors for the
> > selection box)
> > >
> > > - change the mode using a key modifier (I think only Alt is left
> free)
> > > or mouse button
> > >
> > > - add an option to select the default mode (though I do not really
> > like
> > > having too many options to set)
> > >
> > > I agree with Tom about the geometry library. IIRC currently it is
> only
> > > used by the PNS router, but ultimately we would like to use it in
> the
> > > primary model. The library already provides methods to check for
> > > collisions between basic shapes, yet we still need a few more.
> > > It would be a pity to drop your code now, so perhaps we could
> > merge the
> > > code as is and fix the methods during the model refactor.
> > >
> > > Just to let you know, there are a few code formatting violations
> > (mostly
> > > not keeping two empty lines between method definitions in .cpp
> files),
> > > but as they are infrequent - I can handle them myself.
> > >
> > > Regards,
> > > Orson
> > >
> > > On 05/07/2017 02:11 AM, Oliver Walters wrote:
> > >> Maciej,
> > >>
> > >> That was it! Thanks for the hint.
> > >>
> > >> #0016 attached, which fixes both issues:
> > >>
> > >> a) No more double-selection of module and module-items (pads /
> > lines / etc)
> > >> in PCBNEW
> > >> b) Disable selection of entire module in MODEDIT
> > >>
> > >> As far as I can tell this patchset is now working very well.
> > >>
> > >> Regards,
> > >> Oliver
> > >>
> > >> On Sat, May 6, 2017 at 10:21 PM, Oliver Walters <
> > >> oliver.henry.walt...@gmail.com
> > > wrote:
> > >>
> > >>> Maciej,
> > >>>
> > >>> Thanks, I'll look into that. If you have a chance to look over
> > what I've
> > >>> done, I'd appreciate that :)
> > >>>
> > >>> On Sat, May 6, 2017 at 10:17 PM, Maciej Suminski
> > >
> > >>> wrote:
> > >>>
> >  Hi Oliver,
> > 
> >  I have not tested the patches yet, but my gut feeling says that
> > you miss
> >  calling SELECTION_TOOL::selectable() to filter out redundant
> items.
> > 
> >  Regards,
> >  Orson
> > 
> >  On 05/06/2017 09:21 AM, Oliver Walters wrote:
> > > Three further patch files attached:
> > >
> > > - Different color select box based on direction
> > > - Fixed HitTest for EDA_TEXT
> > > - Control modifier unselects anything in rectangle.
> > >
> > > The major piece of feedback I need right now is how to perfect
> the
> > > behaviour of the tool in PCBNEW and MODEDIT:
> > >
> > > a) PCBNEW
> > >
> > > Selecting part of a MODULE (right to left) will select both
> > the entire
> > > module and also any parts of the module that you touched
> > (lines, 

Re: [Kicad-developers] [FEATURE] Component table viewer

[José Ignacio]

Perhaps one feature request regarding custom fields would be (if possible)
to select which field is used for grouping components, instead of just the
value field. Either a custom field or one of the standard ones like
footprint name or symbol name. Think editing all 0402 resistors, or all the
connectors with the same footprint but different value, etc.

Thank you very much for your excellent work!
Jose

On Fri, May 5, 2017 at 7:56 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Steven,
>
> Unless you mean something different to what I think "custom fields" means,
> then this is already the case - any extra fields (beyond REFERENCE /
> FOOTPRINT / DATSHEET / VALUE) are preesnt to be edited in the table...
>
> On Fri, May 5, 2017 at 10:51 PM, Strontium  wrote:
>
>> Hi Oliver,
>>
>> Just had a chance to check out your component table viewer, its nice.
>> Great work.
>>
>> Is it on your roadmap to be able to view/edit a components custom fields?
>>
>> Regards,
>> Steven
>>
>> On 03/05/17 05:35, Oliver Walters wrote:
>>
>>> Wayne,
>>>
>>> Thanks for merging!
>>>
>>> I will address those points at some stage - there are other ideas I have
>>> too but I thought it was better to get the first iteration done and make
>>> incremental improvements.
>>>
>>> Regards,
>>> 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] Move point on pcbnew

[José Ignacio]

The attachments got scrubbed (probably too large), i'd recommend you upload
the videos to youtube or some other video sharing site.

On Fri, May 5, 2017 at 3:07 AM, Carlo Maragno  wrote:

> Hi there,
>
> I done some tests, including a full system wipe and the behavior is still
> the same. I tried to compile 096d9f & c70adc and I got similar results.
>
> In the attachments you can find two video: the kicad_bug one was done with
> 096d9f while the kicad_working one was done on 7034ea.
>
> Cheers,
> Carlo
>
> 2017-05-03 22:15 GMT+02:00 Carlo Maragno :
>
> > Hi Guys,
> >
> > While I was using an old developer version of Kicad (the build date was
> > 28-2-2017), in pcbnew the move tool would grab the component from the
> point
> > closer to the cursor when M was pressed. In other word, if the cursor was
> > closer to a pad the center of the pad would become the grabbing point.
> >
> > On the last developer release from the Ubuntu PPA, this behavior
> > disappeared. I'm trying to figure out at which point it was deleted but
> as
> > I was quite far away from master head this could be a very long process.
> > Now I am at commit #bbaa29, made by Chris Pavlina.
> >
> > Can someone of the developers point to me at which point this feature was
> > removed?
> >
> > My ultimate goal would be to make a push request in order to get this
> > feature added again. So if someone could help that would be great!
> >
> > Thanks again to all,
> > Carlo
> >
>
> ___
> 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] [FEATURE] Partial selection in pcbnew

[José Ignacio]

the way autocad did it since about when computer mice started coming out
for computers was to use a continuous border for the rectangle when doing a
"window" select (that is, all objects must be completely enclosed to be
part of the selection), when dragging the other way the outline is dashed
for a "cross" selection (all objects touching get selected). I remember
when i first used Autocad 2000 that was one of the first features i
discovered on my own and it was pretty nice. More modern versions of
Autocad also tint the inside of the selection rectangle, blue for window
selection and green for cross selection. I suggest to just use this as it
is good enough and consistent for people that are already familiar to CAD,
without it being a huge barrier for newcomers.

[image: Inline image 1]


On Thu, May 4, 2017 at 10:05 AM, Wayne Stambaugh 
wrote:

> On 5/4/2017 10:53 AM, Marco Ciampa wrote:
> > On Thu, May 04, 2017 at 02:36:06PM +0200, Kristoffer Ödmark wrote:
> >> Personally I would like the box select to update selections online while
> >> dragging, this would be very informative. I also think that maybe this
> >> functionality would be better with a modifier button now that I think
> about
> >> it, since sometimes I cannot starta a drag move in one corner due to a
> large
> >> footprint residing there and then getting selected.
> >
> > +1
> >
> > I like the GIMP way:
> >
> >  - CTRL+drag means substract objects from the selecion
> >and appears little minus symbol near the pointer to feedback this
> >
> >  - SHIFT+drag means add objects to the selection
> >and appears little plus symbol near the pointer to feedback this
>
> Custom cursors for inside versus intersect selection could be a good way
> to make the different selection bounding box feature discover-able
> without being too distracting to the user.
>
> >
> >> But the hidden features problem is one that is starting to affect more
> and
> >> more of pcbnew since functionality is added continuosly.
> >
> > agree
> >
> >> I know there is a manual for pcbnew, maybe tools should have some
> shortcut
> >> to go to the relevant section of that manual? Or the tools have a
> shortcut
> >> to go a "tool manual" I have no clue on how to achieve this, but It
> would be
> >> nice.
> >
> > again this would be very handy as it is already present for instance in
> GIMP.
> >
> > We should figure out how to obtain this, at least for HTML... I have some
> > ideas about how it can be obtained but I have to check for those
> > feasibility...
> >
> > Regards,
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Move point on pcbnew

[José Ignacio]

It used to be that kicad was too sensitive to pads and it would almost
never use the anchor in smaller components, now it works much better. I
don't see anything needing to be fixed. Could you show a test case where it
doesn't behave correctly and file a bug on launchpad? Just reverting
whatever changed the behavior will not be a fix :(

On Wed, May 3, 2017 at 3:15 PM, Carlo Maragno  wrote:

> Hi Guys,
>
> While I was using an old developer version of Kicad (the build date was
> 28-2-2017), in pcbnew the move tool would grab the component from the point
> closer to the cursor when M was pressed. In other word, if the cursor was
> closer to a pad the center of the pad would become the grabbing point.
>
> On the last developer release from the Ubuntu PPA, this behavior
> disappeared. I'm trying to figure out at which point it was deleted but as
> I was quite far away from master head this could be a very long process.
> Now I am at commit #bbaa29, made by Chris Pavlina.
>
> Can someone of the developers point to me at which point this feature was
> removed?
>
> My ultimate goal would be to make a push request in order to get this
> feature added again. So if someone could help that would be great!
>
> Thanks again to all,
> Carlo
>
> ___
> 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] [FEATURE] Partial selection in pcbnew

[José Ignacio]

Yay!

On Tue, May 2, 2017 at 2:25 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> I have attached a patch-set that implements "partial selection" of objects
> when the selection box is dragged right-to-left.
>
> L -> R = Objects must be completely enclosed to be selected
> R -> L = Objects that intersect the selection rectangle will be selected.
>
> To achieve this I had to fix a lot of the HitTest implementations as this
> was broken for most shapes, under a variety of edge cases (some HitTest
> code did not work at all).
>
> There are two issues I see as outstanding, and am unsure how to proceed:
>
> 1. When editing a PCB, selecting part of a footprint (e.g. a line of the
> courtyard) selects both that line and the entire footprint. This causes
> some issues when the footprint is dragged around the PCB. I believe that
> the line should not be selected separately, but the entire footprint should.
>
> 2. The inverse of 1. In the footprint editor, selecting a single graphical
> item selects the entire footprint. Somehow I would like to filter the
> selection such that individual items are selected but NOT the entire
> footprint.
>
> Feedback please! :)
>
> I have fixed hit testing (both for wxPoint and EDA_RECT comparison) for:
>
> - Pads (all shapes)
> - Lines
> - Circles
> - Arcs
> - Text items
> - Zones
> - Footprints
>
> Cheers,
> 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] [FEATURE] Component table viewer

[José Ignacio]

I've done a bit of testing on this branch and it works great for me, it cut
the time it takes to release a board to production significantly.

Thanks!
Jose

On Mon, May 1, 2017 at 7:42 AM, Wayne Stambaugh 
wrote:

> Hey Oliver,
>
> I just need to find the time to test and review your changes.  I will
> let you know as soon as I can.
>
> Cheers,
>
> Wayne
>
> On 4/30/2017 5:41 PM, Oliver Walters wrote:
> > Hi Wayne,
> >
> > Anything else you need me to do here?
> >
> > Cheers
> >
> > On 25 Apr 2017 18:22, "Oliver Walters"  > > wrote:
> >
> > Wayne,
> >
> > I have reattached all patches including a new one which does the
> > following:
> >
> > a) Removes BOM export
> > b) Removes Save/Cancel dialog as per JP's request
> > c) Fixes speed issue as per JP's request
> > d) Small bugfix
> >
> > These should apply directly to latest master branch.
> >
> > Cheers
> >
> > On Tue, Apr 25, 2017 at 12:43 AM, Wayne Stambaugh
> > > wrote:
> >
> > Oliver,
> >
> > Thank you for your understanding on this issue.  Once you
> > include the
> > patch to remove the BOM code, I will merge this into the master
> > branch.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 4/23/2017 5:41 PM, Oliver Walters wrote:
> > > Wayne,
> > >
> > > I tend to agree actually, as I have been developing this the
> less I
> > > think having a BoM export is appropriate:
> > >
> > > 1. Separation of tasks - it's simpler and cleaner just as an
> editing table
> > > 2. Python (etc) is way better at data manipulation
> > > 3. External scripts are by design much more flexible.
> > >
> > > I have some ideas for improving BOM output but I am now
> thinking they
> > > would be best served not integrated here.
> > >
> > > I will remove the buttons and leave those thoughts for another
> conversation.
> > >
> > > Oliver
> > >
> > > On 24 Apr 2017 01:47, "Wayne Stambaugh"  
> > > >>
> > wrote:
> > >
> > > Oliver,
> > >
> > > I finally got a chance to test your patch set and was a
> > bit surprised
> > > what I saw after following the conversation on the mailing
> > list.  I was
> > > under the impression that this was a generic component
> > properties
> > > editing grid not a BOM tool which is what it really is.  I
> > like the idea
> > > of being able to edit component fields in table form.  I'm
> > less thrilled
> > > about the BOM export options.  For those of you who
> > haven't been around
> > > very long, Eeschema used to have a BOM dialog.  It didn't
> > allow for
> > > editing field values but it contained options for various
> > BOM output
> > > types.  Initially this dialog was simple and contained
> > only a few BOM
> > > output types and options.  Of course everyone has their
> > own idea of how
> > > a BOM should be formatted so gradually over time, the BOM
> > dialog and the
> > > underlying BOM output code became a huge mess.  It was
> > finally decided
> > > that the design was no longer maintainable and removed.
> > It was replaced
> > > by the current system along with samples that provided all
> > of the same
> > > BOM output options from the old BOM dialog.  Except for
> > the field
> > > editing grid, your dialog and BOM code looks a lot like
> > the original BOM
> > > dialog.  I can see the same thing happening all over
> > again.  Why no use
> > > the existing BOM generation code in your dialog rather
> > than re-implement
> > > code that does the exact same thing?  I'm not opposed to
> > field editing
> > > part of the dialog, but I see the BOM output part heading
> > the same
> > > direction as the old BOM dialog.
> > >
> > > On 4/20/2017 1:59 AM, Oliver Walters wrote:
> > > > Wayne,
> > > >
> > > > Is the behaviour I have implemented acceptable?
> > > >
> > > > Regards,
> > > > Oliver
> > > >
> > > > On Wed, Apr 19, 2017 at 12:13 AM, Oliver Walters
> > > >  > 
> > > 

Re: [Kicad-developers] Tools in post-v5 legacy canvas

[José Ignacio]

It's been established that new features have to work with GAL, but they
don't need to work with legacy. What's not allowed yet is to BREAK legacy
by implementing a new GAL-only feature.

On Sun, Apr 30, 2017 at 9:43 PM, Simon Richter 
wrote:

> Hi,
>
> what is the current outlook on the legacy canvas past v5?
>
> Specifically, I have a feature branch that targets v6 because it
> certainly won't be in time for v5. Does it make sense to invest effort
> here to get it working with the legacy canvas?
>
>Simon
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
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