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

[Brian Sidebotham]

I've been away from the coal face for so long. I've just been catching up
with the list and can't wait to compile the latest!

Good work to all who've been doing some amazing work recently!

Hopefully I'll be able to start contributing again soon. :)

Brian.

On 10 May 2017 at 10:41, Maciej Sumiński  wrote:

> Hi Oliver,
>
> Thank you very much for your effort, I have just pushed your patches to
> the master branch.
>
> Regards,
> Orson
>
> On 05/09/2017 09:32 AM, Oliver Walters wrote:
> > Two more patches for this set (attached)
> >
> > 0017 - Slight fix for arc segment hit test (line width was not accounted
> > for)
> > 0018 - SELECTION_AREA color now indicates selection mode as discussed
> above:
> >
> > a) Normal selection = BLUE
> > b) Addition selection = GREEN (Shift modifier)
> > c) Subtraction selection = RED (Control modifier)
> >
> > Additionally the line color indicates whether it is window selection
> (left
> > to right) or crossing selection (right to left). This is in lieu of
> making
> > the line dashed which does not seem to be possible unless that is added
> to
> > GAL_CAIRO and GAL_OPENGL.
> >
> > Regards,
> > Oliver
> >
> > On Tue, May 9, 2017 at 3:22 PM, Andrey Kuznetsov 
> > wrote:
> >
> >> What's CTRL taken by?
> >> I thought CTRL would be used to toggle grid snapping?
> >>
> >> On Mon, May 8, 2017 at 3:39 PM, José Ignacio 
> >> wrote:
> >>
> >>> 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 <
>  maciej.sumin...@cern.ch
> > >:
> > > 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.
> > >>
> 

Re: [Kicad-developers] [RFC] Standard field for manufacturer part number in schematic symbols

[Brian Sidebotham]

Hi Kasper,

Sorry - I've been out of action with regards to KiCad for a long while.
Just about getting back up to speed.

Is there any reason you can't use Template Field Names for this:
http://docs.kicad-pcb.org/stable/en/eeschema.html#options-of-the-schematic-editor

This allows you to specify fields that are common to all symbols that you
create. If the value is anything other than blank, the field is saved with
the symbol.

The easiest way to specify multiples is probable to suffix with a number,
like Manufacturer-1, PartNumber-1, Manufacturer-2, PartNumber-2, etc.

Best Regards,

Brian.


On 7 January 2017 at 16:14, Kaspar Emanuel  wrote:

>
> On 22 December 2016 at 14:01, Strontium  wrote:
>>
>> The issue with the keys isnt that they are customisable, its that they
>>> are easy to type wrong/get inconsistent, you have to remember what keys you
>>> are using, did you leave any out, etc, etc.
>>>
>>> In this situation, we could define a "default" set of standard keys,
>>> like "MPN", etc.  Users would be able to define their own sets, add or
>>> delete from the "default" set, etc.  Tool writers would invariably use the
>>> defaults, unless there was a good reason not to.  Its not proscriptive,
>>> just suggestive.
>>>
>>> So, rather than a change to the schematic file, its a UI change and a
>>> change to an existing config file, or a (my preference) new config file.
>>>
>>
> On 23 December 2016 at 14:25, Kaspar Emanuel 
> wrote:
>
>> I am happy with this solution and would be willing to work towards a
>> patch. Would a patch for this be accepted?
>>
> Could someone with write access please chime in as to whether work in this
> direction would be accepted?
>
>
>
>
> ___
> Mailing list: https://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] 3D plugin for STEP/IGES via OCE

[Brian Sidebotham]

I would create the plugin as a separate project. That's really the
idea of plugins afterall. I wouldn't bother rolling much more than the
bare essential plugins into the KiCad source. This would be a great
example of how to externally develop a plugin.

Best Regards,

Brian.

On 10 March 2016 at 09:11, Cirilo Bernardo  wrote:
> Hi folks,
>
>  I have a 3D plugin built to support STEP and IGES visualization via OCE
> and have linked 3 screenshots below.
>
> https://drive.google.com/open?id=0By_XTJN-s8aXS1pKSE5uNVp0VG8
> https://drive.google.com/open?id=0By_XTJN-s8aXclV4enBueWhnaGM
> https://drive.google.com/open?id=0By_XTJN-s8aXclV4enBueWhnaGM
>
>  The HackRF STEP model was created by Maurice via his KiCad StepUP
> tools for FreeCAD.
>
>  If people would like this plugin to be pushed into 3d_initial_merge then
> let me know; I would need to add a CMake option to build it since it
> depends on OCE and should not be built by default. Just remember that
> these models will not be visible in 3DViewer until the current 3DViewer
> has been replaced by one which uses the scenegraph objects from
> 3d_initial_merge.  Mario is making a lot of progress with his 3DViewer
> branch, so hopefully it won't be too long before we have all the latest
> 3D visualization codes. :)
>
>  One note: although the new 3D viewer will be able to directly use the
> STEP/IGES models (no need to convert to VRML), actual MCAD
> exports is still a long way away since it depends on the implementation
> of a plugin system for reading and manipulating the PCB data itself.
>
>  Thanks to Tom Wlostowski for the initial OCE investigations and his
> sample c++ code for converting STEP to VRML.
>
> - Cirilo
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

Re: [Kicad-developers] Github is down...

[Brian Sidebotham]

It's up here...

On 28 January 2016 at 01:08, Adam Wolf  wrote:
> It probably won't last long, but if you get any users having issues today,
> before starting complicated troubleshooting, check to see if Github is back
> up.
>
> Adam Wolf
>
>
> ___
> Mailing list: https://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 PATCH] No more boost::context

[Brian Sidebotham]

On 21 January 2016 at 13:42, Tomasz Wlostowski
 wrote:
> Hi,
>
> This patch replaces boost::context with a small library called
> libcontext (derived from boost::context sources). It drops the
> dependency on boost for the cost of one additional header file and cpp
> file (taking inspiration from ClipperLib).
>
> I've tested the new context switching code on Linux, OSX (El Capitan) &
> Windows (all OS 32-bit and 64-bit Intel). Supported compilers are GCC
> and Clang.
>
> Let me know if Kicad builds and works correctly on your platforms...
>
> Cheers,
> Tom

A big thumbs up from me Tom! Pulling this in stabalises the co-routine
code nicely.

Best Regards,

Brian.

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

[Brian Sidebotham]

Excellent News! Welcome Chris! :D

On 7 January 2016 at 15:53, Duane Johnson  wrote:
> Go Chris! And go Kicad!
>
> Thanks for all you devs are doing.
>
> Duane Johnson
>
> On Jan 7, 2016 8:47 AM, "Adam Wolf"  wrote:
>>
>> Congrats!
>>
>> On Thu, Jan 7, 2016 at 9:45 AM, Wayne Stambaugh 
>> wrote:
>>>
>>> Please join me in congratulating Chris Pavlina as the newest member of
>>> the KiCad development team with commit privileges to the KiCad product
>>> repo.  This is a decision that I did not make lightly.  Chris has proven
>>> that he has both the programming skills and just as importantly the team
>>> player temperament that I look for in a developer.  Thank you Chris for
>>> efforts in helping to improve KiCad.
>>>
>>> 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
>

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

[Brian Sidebotham]

Instructions for translators are here:
https://github.com/KiCad/kicad-doc/blob/master/translation_instructions.adoc

Hopefully everything you need should be there.

Best Regards,

Brian.

On 21 December 2015 at 11:02, André S.  wrote:
> Hi everyone!
>
> I'm planning translating some of the kicad-doc to German.
> However I could not find any information if there is a "head of translation"
> or any German translation team.
> Is there anyone I could approach for checking my results if done?
>
> Also: I'm not quite sure what's the current source and how to go from there.
> I did fork and then clone https://github.com/KiCad/kicad-doc from github.
> The different translations seem to live in src/$program_module/po/
> Is it enough to copy one of the existing translation files {it|ja|pl}.po to
> de.po and then just put in there the German translation?
> Is poedit (on Ubuntu) the right tool to use? Or can this do some unwanted
> stuff?
>
> Thanks for reading and waiting for answers.
>
> Best regards,
>   André
>
> ___
> Mailing list: https://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] Translation team

[Brian Sidebotham]

Hi André,

Yes, the makefile was recently removed from the doc repository because
it was deemed unnecessary now the CMake build system is in place. So
we'll have to update the documentation there to detail the cmake
generated target name.

Please start a GitHub issue against KiCad/kicad-doc and someone will
be able to update the documentation for you to follow.

Best Regards,

Brian.

On 21 December 2015 at 12:14, André S. <list.dev.ki...@nospamail.de> wrote:
> Hi Brian,
>
> the instructions on that page do not fit to the actual available data.
> I only cloned the "kicad-doc"
> There are only addendum.xx files in the corresponding $program_module/po
> directories.
>
> There is not a single Makefile in the src path that could be used to
> generate some output via make.
>
> So either the repository is missing some files or the
> translation_instructions are made for a different installation...
>
> Regards,
>   André
>
> may be right for the GUI translation, but in the documentation there is no
> makefile
>
>
> Am 21.12.2015 um 12:12 schrieb Brian Sidebotham:
>>
>> Instructions for translators are here:
>>
>> https://github.com/KiCad/kicad-doc/blob/master/translation_instructions.adoc
>>
>> Hopefully everything you need should be there.
>>
>> Best Regards,
>>
>> Brian.
>>
>> On 21 December 2015 at 11:02, André S. <list.dev.ki...@nospamail.de>
>> wrote:
>>>
>>> Hi everyone!
>>>
>>> I'm planning translating some of the kicad-doc to German.
>>> However I could not find any information if there is a "head of
>>> translation"
>>> or any German translation team.
>>> Is there anyone I could approach for checking my results if done?
>>>
>>> Also: I'm not quite sure what's the current source and how to go from
>>> there.
>>> I did fork and then clone https://github.com/KiCad/kicad-doc from github.
>>> The different translations seem to live in src/$program_module/po/
>>> Is it enough to copy one of the existing translation files {it|ja|pl}.po
>>> to
>>> de.po and then just put in there the German translation?
>>> Is poedit (on Ubuntu) the right tool to use? Or can this do some unwanted
>>> stuff?
>>>
>>> Thanks for reading and waiting for answers.
>>>
>>> Best regards,
>>>André
>>>
>>> ___
>>> Mailing list: https://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] default kicad_common to environment variables

[Brian Sidebotham]

As a packager, you get good control over what happens. Solving this
problem could be done with a batch file:

@ECHO OFF

IF "%KISYSMOD%"=="" SET KISYSMOD=%~dp0\..\share\kicad\modules
IF "%KISYS3DMOD%"=="" SET KISYS3DMOD=%~dp0\..\share\kicad\modules\packages3d

start kicad.exe

which fixes the Windows install wherever it's been installed with the
desktop shortcut and start menu items needing the bat file reference
instead of the kicad executable. You'd just have to figure out setting
the icon of the shortcut now because it won't be the KiCad icon, but
you should be able to create a shortcut using the exe as an icon
reference.

Anyway, good luck!

Brian.

On 7 December 2015 at 22:05, Mark Roszko  wrote:
> That's what the patch does now.. Someone using msys2  for anything other
> than compiling is a bit strange though.
>
> On Dec 7, 2015 4:59 PM, "Wayne Stambaugh"  wrote:
>>
>> On 12/7/2015 3:48 PM, Mark Roszko wrote:
>> > Updated patch to use AssignDir instead of me stupidly assigning to
>> > wxFilename.
>> >
>> > I added an empty var check(so it uses default instead) but it's
>> > pointless. Windows disallows
>> > empty env vars. On other systems if its empty you have configuration
>> > issues and you should be fixing them, not kicad.
>>
>> Using the msys2 environment you can assign an empty env variable so we
>> should definitely test the return string to see if it's empty and fall
>> back to the default if it is empty.
>>
>> >
>> >
>> >
>> > ___
>> > Mailing list: https://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 patch] replace avhttp with libcurl

[Brian Sidebotham]

I haven't had a look at the patch, but I'm a fan of libcurl and use it
quite a lot - it's been great for implementing cloud services for me.
So I'm in favour of the switch!

Best Regards,

Brian.

On 3 December 2015 at 13:28, Kristian Nielsen  wrote:
> Mark Roszko  writes:
>
>> I have written a replacement implementation that drops avhttp in favor
>> of libcurl.
>
> Works for me on Debian stable.
>
> And as a bonus, broken network connection now causes a timeout rather than
> an infinite hang:
>
>   Errors were encountered loading footprints
>   IO_ERROR: 
> https://codeload.github.com/KiCad/Relays_ThroughHole.pretty/zip/master
>   Cannot get/download Zip archive: 
> 'https://github.com/KiCad/Relays_ThroughHole.pretty'
>   for library path: 'IO_ERROR: CURL Request Failed: Timeout was reached
>
> You seem to have trailing whitespace lines in your patch, you might want to
> remove those.
>
> And you left a comment about avhttp on the function
> GITHUB_GETLIBLIST::remoteGetJSON() when you moved/renamed it, probably that
> comment should be deleted now?
>
> Thanks,
>
>  - Kristian.
>
> ___
> Mailing list: https://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 Release.

[Brian Sidebotham]

Hi Mark,

SetProcessDpiAware (Now SetProcessDpiAwareness) can be overidden by
including a manifest that says the app is not DPI aware - and
wxWidgets with bitmap icons certainly isn't DPI aware - god knows why
they thought they were!

Anyway, I've attached a manifest file which may or may not help you
out - but give it a go, it's the correct (MS) way of setting the DPI
awareness anyway and you can just sit it alongside the exe as far as
I'm aware...

Best Regards,

Brian.


On 28 November 2015 at 21:23, Mark Roszko  wrote:
> KiCad is graphically really broken on high DPI screens like my Surface
> Book and Surface Pro. (I literally just got a Book a few days ago so I
> never knew)
>
> On the high DPI display, it gets really bad with say the pcbcalculator
> where the images are tiny and unreadable.
>
>
> But if anything should be a "blocker" we should commit the change I
> suggested here to at least enable GAL to function on high DPI:
> https://bugs.launchpad.net/kicad/+bug/1519590
>
>
> Cairo is also broken but I haven't had to the time to debug what is
> bugging it out.
>
> Windows is supposed to be able to scale UI (which it does, everything
> else that I have that isn't KiCad functions perfectly, QT apps, etc),
> from what I am reading wxWidgets was setting a flag that it was DPI
> aware and thus Windows doesn't scale UI. In 3.1.x they apparently
> removed it but right now on 3.0.x I am not sure what is going on.
>
>
>
> High DPI screens are only going to get more common, if we want to push
> off fixing it for next year then its fine. But the surfaces are really
> exploding in popularity :3
>
>
>
>
>
> On Sat, Nov 28, 2015 at 3:03 PM, Wayne Stambaugh  wrote:
>> If there is any reason not to roll out the stable release tomorrow,
>> speak now or forever hold your peace.  I will roll it out tomorrow
>> evening assuming there are no serious bugs between now and then.  If you
>> have any last minute bug fixes, please submit or commit them.
>>
>> If you have any developers that need to be added to the credits in the
>> about dialog, please make list with the authors name and email address
>> and send them to me directly to avoid posting email addresses to the
>> mailing list.  I will add them to the about dialog before I roll out the
>> stable release.  Please keep in mind that credits should be given to
>> developers who have contributed more than just a couple of patches.
>>
>> For repo maintainers, I am going to use tag "4.0.0" to tag the product
>> repo.  Please use the same tag so packagers only need to define a single
>> tag in their build scripts.
>>
>> Hopefully all goes well and tomorrow we will have a new stable release.
>>
>> Cheers,
>>
>> Wayne
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
>
>
> --
> Mark
>
> ___
> Mailing list: https://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.exe.manifest
Description: Binary data
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] RC2 has been released.

[Brian Sidebotham]

Wayne, You've released the source tarball against the RC1 milestone.
I'd delete it from there and re-release it against the RC2 milestone.

Best Regards,

Brian.

On 9 November 2015 at 08:17, Nick Østergaard  wrote:
> I just jumped directly to https://launchpad.net/kicad  and hovering on
> the download links on the right you can see those links.
>
> 2015-11-09 2:37 GMT+01:00 Wayne Stambaugh :
>> That is strange.  I wonder if the path has something to do with what
>> page is open when you upload it.  As long as users can download the file
>> it should be OK.  If I get some time, I'll mess around with it and see
>> if I can get it in the https://launchpad.net/kicad/4.0 path.
>>
>> On 11/8/2015 6:01 PM, Nick Østergaard wrote:
>>> Hi Wayne
>>>
>>> Thank you for realasing. Although the download link is a bit strange..
>>> it still partly refers to rc1.
>>>
>>> https://launchpad.net/kicad/4.0/4.0.0-rc1/+download/kicad-4.0.0-rc2.tar.xz
>>>
>>> But anyway, I guess we can just say that the docs, and their
>>> translations, and the GUI translations shall be done in two weeks if
>>> they want to be included with the release. The same witht he libs, if
>>> anything is is left to be done, and we can just take a snapshot of the
>>> libs and put it on the download page.
>>>
>>> 2015-11-08 23:11 GMT+01:00 Wayne Stambaugh :
 I just finished up getting all of the relevant code for RC2 uploaded to
 launchpad so let's fire up those autobuilders and get some rc2 packages
 out there for testing.  I'm hoping this will be the last rc before the
 stable release.  Let's keep our fingers crossed.  We need start thinking
 about branching or tagging the library, documentation, and translation
 repos so that packagers can build consistent packages for their
 respective platforms.  Thanks to everyone who made this possible.  I'm
 going to step away from my computer for a while and enjoy the adult
 beverage of my choice.

 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

[Kicad-developers] KiCad-Winbuilder killed off on Launchpad

[Brian Sidebotham]

I've just killed KiCad-Winbuilder on launchpad (
https://launchpad.net/kicad-winbuilder ), but fear not!

Nick Østergaard is now maintaining the MSYS2/mingw-w64 version of
KiCad-Winbuilder on GitHub (
https://github.com/nickoe/KiCad-Winbuilder )

Thanks to Nick who's been working on the MSYS2 version of the tool
tool such that it's capable of creating the release candidate
installer and is now being used for providing snapshot releases via
the KiCad website ( http://kicad-pcb.org/download/windows/ ) and
thanks to anyone who's provided patches/pull requests and the like to
get it sorted out.

Thanks also to Orson for his support when we needed it to get the GAL
up and running on Windows.

With the addition of the Recent Builds to the KiCad website there's no
need for users to build their own using KiCad-Winbuilder anymore -
just download a recent build and don't suffer the pain of building on
Windows; Building on Windows is really no fun for anyone!

I'm surprised the latest download on Launchpad had reached 30,000+
downloads! That's a lot of computing power that's been directed at
building KiCad so I'm sure the Recent Builds part of the website is
going to be really popular.

Best Regards,

Brian.

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

Re: [Kicad-developers] Packaging the python footprint wizards for the release

[Brian Sidebotham]

On 30 September 2015 at 21:19, Wayne Stambaugh  wrote:
> I just committed a fix so at least the python plugins will get installed
> in share/kicad/scripting which seems to work properly on msys2/mingw64
> builds.  I'll test it on Linux when I get a chance.  I'm going to pass
> on the python scripting example folder unless someone can confirm that
> all of the example python scripts work correctly.

It's broken on Linux too, the script path is broken. I've attached a
patch to fix it ( a one liner )

There's also a patch which helps when you install locally rather than
globally (like me!) so I can have more than one install at a time, but
it's tied specifically to a python version so is useless. We can fix
all this properly after the stable release. For now the one-liner fix
will work for system-wide installs.

Best Regards,

Brian.
=== modified file 'pcbnew/pcbnew.cpp'
--- pcbnew/pcbnew.cpp   2015-08-08 13:54:32 +
+++ pcbnew/pcbnew.cpp   2015-09-30 22:55:40 +
@@ -282,7 +282,7 @@
 
 #else
 // Add this default search path:
-path_frag = wxT( "/usr/local/kicad/bin/scripting/plugins" );
+path_frag = Pgm().GetExecutablePath() + wxT( 
"../share/kicad/scripting/plugins" );
 #endif
 
 if( ! pcbnewInitPythonScripting( TO_UTF8( path_frag ) ) )

=== modified file 'pcbnew/pcbnew.cpp'
--- pcbnew/pcbnew.cpp   2015-08-08 13:54:32 +
+++ pcbnew/pcbnew.cpp   2015-09-30 22:47:38 +
@@ -281,10 +281,22 @@
 wxSetEnv( "PYTHONPATH", pypath );
 
 #else
+/* Linux-specific setup */
+wxString pypath;
+
+pypath = Pgm().GetExecutablePath() + wxT( "../lib/python2.7/dist-packages" 
);
+
+if( !wxIsEmpty( wxGetenv("PYTHONPATH") ) )
+pypath = wxString( wxGetenv("PYTHONPATH") ) + wxT( ":" ) + pypath;
+
+wxSetEnv( "PYTHONPATH", pypath );
+
 // Add this default search path:
-path_frag = wxT( "/usr/local/kicad/bin/scripting/plugins" );
+path_frag = Pgm().GetExecutablePath() + wxT( 
"../share/kicad/scripting/plugins" );
 #endif
 
+printf( "python: %s\n", static_cast(path_frag) );
+
 if( ! pcbnewInitPythonScripting( TO_UTF8( path_frag ) ) )
 {
 wxLogError( wxT( "pcbnewInitPythonScripting() failed." ) );

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

Re: [Kicad-developers] Packaging the python footprint wizards for the release

[Brian Sidebotham]

On 29 September 2015 at 14:03, LordBlick <lordbl...@gmail.com> wrote:
> In response to a message written on 29.09.2015, 10:46, from Brian
> Sidebotham:
>>
>> For Windows, we can package the contents of
>> kicad-source/pcbnew/scripting/plugins into the bin/scripting/plugins
>> directory and it'll work for 4.0.0 as-is.
>
> It's a complete mess, or something is binary or a script.

Sorry I don't understand apart from "It's a complete mess". In
response to that, no it's not. These are simply files installed that
the PCBNEW makes use of, no-one ever need edit them or even see them.
They provide functionality to the installed program. We do need a
separate user area for picking up user-supplied plugins however.

Working out where these truly belong can easily wait until after a
stable release because it really doesn't matter much.

Best Regards,

Brian.

___
Mailing list: https://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] Paths on the Windows 4.0.0 RC1

[Brian Sidebotham]

GetExecutablePath() has a fallback which is poor but not too
unreasonable: 
https://github.com/wxWidgets/wxWidgets/blob/master/src/common/stdpbase.cpp#L67

For Linux it grabs /proc/self/exe which seems reasonable(ish):
https://github.com/wxWidgets/wxWidgets/blob/master/src/unix/stdpaths.cpp#L120

For Windows it uses the Module path which is fine:
https://github.com/wxWidgets/wxWidgets/blob/master/src/msw/stdpaths.cpp#L343
https://github.com/wxWidgets/wxWidgets/blob/master/include/wx/msw/private.h#L894

For OSX the code looks ok, though I can't test it at all:
https://github.com/wxWidgets/wxWidgets/blob/master/src/osx/core/stdpaths_cf.cpp#L142

The only problem I see if the BSD range of OS, which is basically
where /proc/self/exe is not available because that will fall back to
the base implementation. Although the base implementation is not too
bad either. We could do a pull request for wxWidgets to fix up
GetExecutablePath() for those by testing for /proc/curproc/exe and
/proc/curproc/file and using if one exists - that should cover most of
the BSD range better.

I think GetExecutablePath() is accurate enough for us to use without
problem. It's so common to tie installed files relative the executable
path it's virtually standard for me. This means we can run sandboxed
versions, i.e. without having to have a global config file which is
awkward when you're trying to test different things at once. Otherwise
a /etc/kicad.conf would be perfect, but has no equivalent on Windows.

Best Regards,

Brian.

On 18 September 2015 at 00:40, Cirilo Bernardo
<cirilo.berna...@gmail.com> wrote:
>
>
> On Fri, Sep 18, 2015 at 8:20 AM, Brian Sidebotham
> <brian.sidebot...@gmail.com> wrote:
>>
>> As mentioned in the bug report here
>> https://bugs.launchpad.net/kicad/4.0/+bug/1496049 there's a problem
>> with paths on the Windows 4.0.0-RC1.
>>
>> So far the paths that don't work:
>>
>> (1) Searching for help files fails
>> (2) Default paths in the "Path configuration" dialog all point to
>> places in c:\msys64\mingw64, etc.
>> (3) Python footprint wizards don't load
>>
>> and probably more. Needless to say, the KiCad experience out of the
>> box because of this is very poor.
>>
>> We need to fix up the path search which started with the help in the
>> bug report. The current consensus is to have (yet another) env var
>> called something like KIHELP which can default on Windows to the
>> literal string "${KICAD}\share\doc\kicad\help" which alleviates the
>> previous problem of trying to guess the install path at compile time
>> which is clearly flawed.
>>
>
> There are problems for sure but I don't believe in adding yet another
> env var if it can be helped, but this may be a complex enough issue that
> an env var would be the best option for the release. On MSWin documents
> and such should go into an appropriate one of MSWin's Known Folders -
> the question then is can we access these folder names via some library
> in MSys/MinGW?
>
>
>> My personal preference would have just to have checked
>> "BINDIR\..\share\doc\kicad\help" where BINDIR is gathered from
>> ::wxStandardPaths::Get().GetExecutablePath();
>>
>
> I have my doubts here; there are too many ways that GetExecutablePath()
> can give you the wrong result - certainly on *NIX there is no guarantee
> what result you will get (but on Linux there are tricks to get it right -
> assuming wxWidgets has a good implementation), but I'm not so sure of
> the behavior on MSWin. Short story: inspect the wx implementation
> before believing the results.
>
>>
>> However, the decision appears to be to add another configurable path.
>>
>> While adding the new KIHELP env var solves part of the problem, the
>> Windows installer should be updated to set the KICAD env var to the
>> chosen install path while installing. et. voila, paths fixed.
>>
>> Best Regards,
>>
>> Brian.
>>
>
>  I think a well-known path is preferable to yet another configurable path;
> this is true for all platforms. In my 3D refactoring branch there is some
> code which attempts to find a plugins directory using a number of
> known paths. I think for all items specifically associated with the
> kicad install, known paths should be used. For other items like
> 3D models some user configuration should be supported (though
> any 3D models installed by a kicad installer should be put into a
> known path).
>
> - Cirilo

___
Mailing list: https://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] Paths on the Windows 4.0.0 RC1

[Brian Sidebotham]

Hey Wayne,

Thanks for those. My timescales may not match when you want to achieve RC2.
Basically I'm on holiday from tomorrow until the 28th so can't work on this
until then. If RC2 is not planned until after that then I can work on this
as soon as I get back.

If you need it done quicker, or are just itching to fix with other path
fixes please do go ahead, otherwise I'll pick it up as soon as I'm back off
hols...

Best Regards,

Brian.
On 18 Sep 2015 15:46, "Wayne Stambaugh" <stambau...@gmail.com> wrote:

> On 9/18/2015 7:59 AM, Mark Roszko wrote:
> > Speaking of paths, there's invalid default paths(%PROGRAM
> > FILES%/KiCad) being used for Save and Open dialogs thoroughout KiCad
> > which need to be changed to the user's document folder. Wayne said he
> > was working on it awhile ago but its something to fix.
>
> I'm still am working on it.  I hope to commit it tomorrow.  As soon as
> Brian gets the help search path stuff fixed I'll roll out rc2 unless
> some other major bug pops up.
>
> @Brian, attached are patches for search_stack.cpp and
> searchhelpfilefullpath.cpp which should solve the help problem.
> Actually, some of the changes should be moved into the system search
> stack which should solve all of the search path issues not just the help
> path.  Feel free to cherry pick these changes or ignore them.  One thing
> that is broken in both cases is that the KICAD env var is not always the
> first entry in the search stack when it's defined and it should be.
> User defined paths should *always* take precedence.
>
> >
> > On Fri, Sep 18, 2015 at 6:03 AM, Brian Sidebotham
> > <brian.sidebot...@gmail.com> wrote:
> >> GetExecutablePath() has a fallback which is poor but not too
> >> unreasonable:
> https://github.com/wxWidgets/wxWidgets/blob/master/src/common/stdpbase.cpp#L67
> >>
> >> For Linux it grabs /proc/self/exe which seems reasonable(ish):
> >>
> https://github.com/wxWidgets/wxWidgets/blob/master/src/unix/stdpaths.cpp#L120
> >>
> >> For Windows it uses the Module path which is fine:
> >>
> https://github.com/wxWidgets/wxWidgets/blob/master/src/msw/stdpaths.cpp#L343
> >>
> https://github.com/wxWidgets/wxWidgets/blob/master/include/wx/msw/private.h#L894
> >>
> >> For OSX the code looks ok, though I can't test it at all:
> >>
> https://github.com/wxWidgets/wxWidgets/blob/master/src/osx/core/stdpaths_cf.cpp#L142
> >>
> >> The only problem I see if the BSD range of OS, which is basically
> >> where /proc/self/exe is not available because that will fall back to
> >> the base implementation. Although the base implementation is not too
> >> bad either. We could do a pull request for wxWidgets to fix up
> >> GetExecutablePath() for those by testing for /proc/curproc/exe and
> >> /proc/curproc/file and using if one exists - that should cover most of
> >> the BSD range better.
> >>
> >> I think GetExecutablePath() is accurate enough for us to use without
> >> problem. It's so common to tie installed files relative the executable
> >> path it's virtually standard for me. This means we can run sandboxed
> >> versions, i.e. without having to have a global config file which is
> >> awkward when you're trying to test different things at once. Otherwise
> >> a /etc/kicad.conf would be perfect, but has no equivalent on Windows.
> >>
> >> Best Regards,
> >>
> >> Brian.
> >>
> >> On 18 September 2015 at 00:40, Cirilo Bernardo
> >> <cirilo.berna...@gmail.com> wrote:
> >>>
> >>>
> >>> On Fri, Sep 18, 2015 at 8:20 AM, Brian Sidebotham
> >>> <brian.sidebot...@gmail.com> wrote:
> >>>>
> >>>> As mentioned in the bug report here
> >>>> https://bugs.launchpad.net/kicad/4.0/+bug/1496049 there's a problem
> >>>> with paths on the Windows 4.0.0-RC1.
> >>>>
> >>>> So far the paths that don't work:
> >>>>
> >>>> (1) Searching for help files fails
> >>>> (2) Default paths in the "Path configuration" dialog all point to
> >>>> places in c:\msys64\mingw64, etc.
> >>>> (3) Python footprint wizards don't load
> >>>>
> >>>> and probably more. Needless to say, the KiCad experience out of the
> >>>> box because of this is very poor.
> >>>>
> >>>> We need to fix up the path search which started with the help in the
> >>>> bug report. The current consensus is to have (yet anot

[Kicad-developers] Paths on the Windows 4.0.0 RC1

[Brian Sidebotham]

As mentioned in the bug report here
https://bugs.launchpad.net/kicad/4.0/+bug/1496049 there's a problem
with paths on the Windows 4.0.0-RC1.

So far the paths that don't work:

(1) Searching for help files fails
(2) Default paths in the "Path configuration" dialog all point to
places in c:\msys64\mingw64, etc.
(3) Python footprint wizards don't load

and probably more. Needless to say, the KiCad experience out of the
box because of this is very poor.

We need to fix up the path search which started with the help in the
bug report. The current consensus is to have (yet another) env var
called something like KIHELP which can default on Windows to the
literal string "${KICAD}\share\doc\kicad\help" which alleviates the
previous problem of trying to guess the install path at compile time
which is clearly flawed.

My personal preference would have just to have checked
"BINDIR\..\share\doc\kicad\help" where BINDIR is gathered from
::wxStandardPaths::Get().GetExecutablePath();

However, the decision appears to be to add another configurable path.

While adding the new KIHELP env var solves part of the problem, the
Windows installer should be updated to set the KICAD env var to the
chosen install path while installing. et. voila, paths fixed.

Best Regards,

Brian.

___
Mailing list: https://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] Problem of kicad-source and kicad-doc Packaging Help Documents

[Brian Sidebotham]

Actually the help documentation is broken on Windows too in the RC.

The help is at C:\Program Files\KiCad\share\doc\kicad\help\en\kicad.pdf

The searched paths are like this:

Path
C:\msys64\mingw64
C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en_GB
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en_GB
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\doc\help\en
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\doc\help\en
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\doc\help\en
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\doc\help\en
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.html
C:\Program Files\KiCad
C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad
C:\Program Files\KiCad\kicad.pdf
C:\Program Files\KiCad

It looks like a two-fold problem. The packaging is putting the docs
under share\doc... where I guess it should be share\kicad\doc along
with everything else shared for KiCad.

Secondly the paths being search by the program include
share\kicad\template... which appears wrong. I'd expect it to be
\share\kicad\doc...

Are these assumptions correct? If so, I can file a bug to be fixed.

Best Regards,

Brian.

On 15 September 2015 at 15:37, Brian Sidebotham
<brian.sidebot...@gmail.com> wrote:
> On 15 September 2015 at 15:03, Wayne Stambaugh <stambau...@gmail.com> wrote:
>>
>>
>> On 9/14/2015 1:08 AM, Joseph Chen wrote:
>>> On 09/13/2015 01:36 PM, Wayne Stambaugh wrote:
>>> The failure above is inevitable, because the running pcbnew is looking
>>> for file name "pcbnew.pdf", while the actual doc file name installed as
>>> "Pcbnew.pdf", noticing the mixed-case capital P in the actual file name.
>>
>> Good catch.  The new documentation pdf generation code must have
>> inadvertently used Pcbnew.pdf instead of pcbnew.pdf.  I just looked at
>> this in the github kicad-doc repo and this also seems to be the case for
>> the other pdf files as well.  Would one of our doc devs please fix this
>> before the stable release?  Thanks.
>
> I've created the issue: https://github.com/KiCad/kicad-doc/issues/156
>
> I'll sort this out so it at least the documentation build produces the
> correctly named files.
>
> Best Regards,
>
> Brian.

___
Mailing list: https://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] Problem of kicad-source and kicad-doc Packaging Help Documents

[Brian Sidebotham]

I filed a bug report for the Windows version so people using RC1 may
trip over the bug report.

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

Best Regards,

Brian.

On 15 September 2015 at 17:04, Brian Sidebotham
<brian.sidebot...@gmail.com> wrote:
> As a PS - I think RC2 looks like it's just round the corner because
> not being able to look the help documents is pretty poor.
>
> There's no links to the documentation in the start menu either so we'd
> have to point people to the install directory\share\doc\kicad... etc.
>
> Best Regards,
>
> Brian.
>
> On 15 September 2015 at 17:01, Brian Sidebotham
> <brian.sidebot...@gmail.com> wrote:
>> Actually the help documentation is broken on Windows too in the RC.
>>
>> The help is at C:\Program Files\KiCad\share\doc\kicad\help\en\kicad.pdf
>>
>> The searched paths are like this:
>>
>> Path
>> C:\msys64\mingw64
>> C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
>> C:\Program Files\KiCad\kicad.html
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\kicad.html
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
>> C:\Program Files\KiCad\kicad.pdf
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\kicad.pdf
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en_GB
>> C:\Program Files\KiCad\kicad.html
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\kicad.html
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en_GB
>> C:\Program Files\KiCad\kicad.pdf
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\kicad.pdf
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\share\kicad\template\doc\help\en
>> C:\Program Files\KiCad\kicad.html
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\kicad.html
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\share\kicad\template\doc\help\en
>> C:\Program Files\KiCad\kicad.pdf
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\kicad.pdf
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
>> C:\Program Files\KiCad\kicad.html
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\kicad.html
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
>> C:\Program Files\KiCad\kicad.pdf
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\kicad.pdf
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\share\kicad\template\doc\help\en
>> C:\Program Files\KiCad\kicad.html
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\kicad.html
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\share\kicad\template\doc\help\en
>> C:\Program Files\KiCad\kicad.pdf
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\kicad.pdf
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
>> C:\Program Files\KiCad\kicad.html
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\kicad.html
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
>> C:\Program Files\KiCad\kicad.pdf
>> C:\Program Files\KiCad
>> C:\Program Files\KiCad\kicad.pdf
>> C:\Program Files\KiCad
>>
>> It looks like a two-fold problem. The packaging is putting the docs
>> under share\doc... where I guess it should be share\kicad\doc along
>> with everything else shared for KiCad.
>>
>> Secondly the paths being search by the program include
>> share\kicad\template... which appears wrong. I'd expect it to be
>> \share\kicad\doc...
>>
>> Are these assumptions correct? If so, I can file a bug to be fixed.
>>
>> Best Regards,
>>
>> Brian.
>>
>> On 15 September 2015 at 15:37, Brian Sidebotham
>> <brian.sidebot...@gmail.com> wrote:
>>> On 15 September 2015 at 15:03, Wayne Stambaugh <stambau...@gmail.com> wrote:
>>>>
>>>>
>>>> On 9/14/2015 1:08 AM, Joseph Chen wrote:
>>>>> On 09/13/2015 01:36 PM, Wayne Stambaugh wrote:
>>>>> The failure above is inevitable, because the running pcbnew is looking
>>>>> for file name "pcbnew.pdf", while the actual doc file name installed as
>>>>> "Pcbnew.pdf", noticing the mixed-case capital P in the actual file name.
>>>>
>>>> Good catch.  The new documentation pdf generation code must have
>>>> inadvertently used Pcbnew.pdf instead of pcbnew.pdf.  I just looked at
>>>> this in the github kicad-doc repo and this also seems to be the case for
>>>> the other pdf files as well.  Would one of our doc devs please fix this
>>>> before the stable release?  Thanks.
>>>
>>> I've created the issue: https://github.com/KiCad/kicad-doc/issues/156
>>>
>>> I'll sort this out so it at least the documentation build produces the
>>> correctly named files.
>>>
>>> Best Regards,
>>>
>>> Brian.

___
Mailing list: https://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 RC1 crash! (PCB Calculator) Windows x64

[Brian Sidebotham]

Dan, you may run http://www.dependencywalker.com/ to see if there's
anything funny going on with your system in particular. Perhaps some
runtime component is being picked up outside of the KiCad install
that's causing a bit of instability.

Post the results if you're not used to the output so we can see if
anything funny's going on.

Best Regards,

Brian.

On 15 September 2015 at 10:17, Dan Walmsley  wrote:
> In RC1 on Windowx x64, simply launch PCB Calculator from KiCad and then
> close it.
>
> The whole of Kicad will crash.
>
> Dan
>
> ___
> Mailing list: https://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] Problem of kicad-source and kicad-doc Packaging Help Documents

[Brian Sidebotham]

As a PS - I think RC2 looks like it's just round the corner because
not being able to look the help documents is pretty poor.

There's no links to the documentation in the start menu either so we'd
have to point people to the install directory\share\doc\kicad... etc.

Best Regards,

Brian.

On 15 September 2015 at 17:01, Brian Sidebotham
<brian.sidebot...@gmail.com> wrote:
> Actually the help documentation is broken on Windows too in the RC.
>
> The help is at C:\Program Files\KiCad\share\doc\kicad\help\en\kicad.pdf
>
> The searched paths are like this:
>
> Path
> C:\msys64\mingw64
> C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en_GB
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en_GB
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en_GB
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\doc\help\en
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.html
> C:\Program Files\KiCad
> C:\Program Files\KiCad\share\kicad\template\share\doc\kicad\help\en
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
> C:\Program Files\KiCad\kicad.pdf
> C:\Program Files\KiCad
>
> It looks like a two-fold problem. The packaging is putting the docs
> under share\doc... where I guess it should be share\kicad\doc along
> with everything else shared for KiCad.
>
> Secondly the paths being search by the program include
> share\kicad\template... which appears wrong. I'd expect it to be
> \share\kicad\doc...
>
> Are these assumptions correct? If so, I can file a bug to be fixed.
>
> Best Regards,
>
> Brian.
>
> On 15 September 2015 at 15:37, Brian Sidebotham
> <brian.sidebot...@gmail.com> wrote:
>> On 15 September 2015 at 15:03, Wayne Stambaugh <stambau...@gmail.com> wrote:
>>>
>>>
>>> On 9/14/2015 1:08 AM, Joseph Chen wrote:
>>>> On 09/13/2015 01:36 PM, Wayne Stambaugh wrote:
>>>> The failure above is inevitable, because the running pcbnew is looking
>>>> for file name "pcbnew.pdf", while the actual doc file name installed as
>>>> "Pcbnew.pdf", noticing the mixed-case capital P in the actual file name.
>>>
>>> Good catch.  The new documentation pdf generation code must have
>>> inadvertently used Pcbnew.pdf instead of pcbnew.pdf.  I just looked at
>>> this in the github kicad-doc repo and this also seems to be the case for
>>> the other pdf files as well.  Would one of our doc devs please fix this
>>> before the stable release?  Thanks.
>>
>> I've created the issue: https://github.com/KiCad/kicad-doc/issues/156
>>
>> I'll sort this out so it at least the documentation build produces the
>> correctly named files.
>>
>> Best Regards,
>>
>> Brian.

___
Mailing list: https://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] Problem of kicad-source and kicad-doc Packaging Help Documents

[Brian Sidebotham]

On 15 September 2015 at 15:03, Wayne Stambaugh  wrote:
>
>
> On 9/14/2015 1:08 AM, Joseph Chen wrote:
>> On 09/13/2015 01:36 PM, Wayne Stambaugh wrote:
>> The failure above is inevitable, because the running pcbnew is looking
>> for file name "pcbnew.pdf", while the actual doc file name installed as
>> "Pcbnew.pdf", noticing the mixed-case capital P in the actual file name.
>
> Good catch.  The new documentation pdf generation code must have
> inadvertently used Pcbnew.pdf instead of pcbnew.pdf.  I just looked at
> this in the github kicad-doc repo and this also seems to be the case for
> the other pdf files as well.  Would one of our doc devs please fix this
> before the stable release?  Thanks.

I've created the issue: https://github.com/KiCad/kicad-doc/issues/156

I'll sort this out so it at least the documentation build produces the
correctly named files.

Best Regards,

Brian.

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

[Brian Sidebotham]

My humble suggestion is to just create the RC1 branch now because I've
been through all of those bugs, and they're all either incomplete or
not repeatable for me. In which case we need more information in order
to be able to fix them.

In order to get more information, it's better to have a larger
user-base. Plus, a user-base on a pre-built rc candidate. It's
possible for example that some people's systems are a bit screwy when
building and so we're really chasing phantoms that are down to their
specific build. With an RC we're at least debugging a single sane
thing.

That's what an RC is for in my opinion - it has known issues, but we
need help moving forward. Plus, these issues will become insignificant
compared the waft of new bugs that are going to come out of the
woodwork when we make an RC build for mass people to test. I don't
think that work should be delayed for a few bugs that are almost
unrepeatable.

I have a patch holding for adding the interactive routing options to
the draw toolbar. It makes no sense to me for those brilliant tools to
be available only in a menu option - they should be in the draw
toolbar and disabled when in legacy canvas mode so people know what
they're missing out on! ;)

Sorry, I've only just managed to get some time together to be able to
work on KiCad again, so bad timing!

Best Regards,

Brian.

On 6 September 2015 at 21:11, Wayne Stambaugh  wrote:
> This is a reminder to *all* developers, please do not send any patches
> or merge requests unless it is specifically to fix an existing bug
> report.  Also, please don't bother fixing the build scripts or any of
> the CMake dependency library build code as they will be removed during
> the next development cycle.  My preference is that we focus on the
> critical bug reports that are keeping me from creating an rc1 branch.
> They can be found here:
>
> https://bugs.launchpad.net/kicad/+bugs?field.searchtext==-importance=Search%3Alist=NEW%3Alist=CONFIRMED%3Alist=TRIAGED%3Alist=INPROGRESS%3Alist=INCOMPLETE_WITH_RESPONSE%3Alist=INCOMPLETE_WITHOUT_RESPONSE%3Alist=CRITICAL%3Alist=HIGH_option=any=_reporter=_commenter==_subscriber==_combinator=ANY_cve.used=_dupes.used=_dupes=on_me.used=_patch.used=_branches.used=_branches=on_no_branches.used=_no_branches=on_blueprints.used=_blueprints=on_no_blueprints.used=_no_blueprints=on
>
> This list needs to get to zero before I'm willing to create any rc1 branch.
>
> Thank you for your cooperation.
>
> Cheers,
>
> Wayne
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [PATCH] Add axis origin marker to Footprint Editor

[Brian Sidebotham]

On 4 September 2015 at 08:43, Jon Neal  wrote:
> I'm a stickler for code that uses the same conventions when possible.
> m_drawatzero should be camelCase instead of all lowercase. :)

I'll change that, no worries.

> +switch( m_style & 0xFF )
>   I'm curious as to what that is doing. m_style is of type MARKER_STYLE
> which is an enum with 7 items in it.

Sorry, as mentioned that's an old artefact from when I had used CIRCLE
as a flag as to whether or not to draw the circle of the marker. That
looked horrid though, so I removed it (or at least I thought I'd
removed all of it!)

> In enum MARKER_STYLE it may be nice to spell out more explicitly CIRCLE_DOT,
> CIRCLE_CROSS, CIRCLE_X (I'm assuming the C means circle) to make the code a
> bit more readable.

Yeah, may be better - it's how it started, but then I shortened it.

Best Regards,

Brian.

___
Mailing list: https://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 axis origin marker to Footprint Editor

[Brian Sidebotham]

To match functionality of the Legacy canvas I propose we extend the
GAL ORIGIN_VIEWITEM class to allow us to add an axis origin marker
when using the Footprint Editor. I'm sure even while in the stable
feature-lock this is okay to commit, but an ack will be good before I
go ahead.

Also, Orson, thanks for your information about this, can you also ack
that you're happy with the class extension? Otherwise feel free to
contact me to implement this in another way if you'd rather...

Best Regards,

Brian.
=== modified file 'common/origin_viewitem.cpp'
--- common/origin_viewitem.cpp  2015-06-18 15:51:53 +
+++ common/origin_viewitem.cpp  2015-09-03 21:19:45 +
@@ -30,7 +30,7 @@
 
 ORIGIN_VIEWITEM::ORIGIN_VIEWITEM( const COLOR4D& aColor, MARKER_STYLE aStyle, 
int aSize, const VECTOR2D& aPosition ) :
 EDA_ITEM( NOT_USED ),   // this item is never added to a BOARD so it needs 
no type
-m_position( aPosition ), m_size( aSize ), m_color( aColor ), m_style( 
aStyle )
+m_position( aPosition ), m_size( aSize ), m_color( aColor ), m_style( 
aStyle ), m_drawatzero( false )
 {
 }
 
@@ -45,8 +45,9 @@
 
 void ORIGIN_VIEWITEM::ViewDraw( int, GAL* aGal ) const
 {
-// Legacy canvas does not draw markers if they are located in the (0, 0) 
point
-if( m_position.x == 0 && m_position.y == 0 )
+// Nothing to do if the target shouldn't be drawn at 0,0 and that's where 
the target is. This
+// mimics the Legacy canvas that doesn't display most targets at 0,0
+if( !m_drawatzero && ( m_position.x == 0 ) && ( m_position.y == 0 ) )
 return;
 
 aGal->SetIsStroke( true );
@@ -54,25 +55,31 @@
 aGal->SetLineWidth( 1 );
 aGal->SetStrokeColor( m_color );
 VECTOR2D scaledSize = m_view->ToWorld( VECTOR2D( m_size, m_size ), false );
-aGal->DrawCircle( m_position, scaledSize.x );
-
-switch( m_style )
+
+// Draw a circle around the marker's centre point if the style demands it
+if( ( m_style == CCROSS ) || ( m_style == CDOT ) || ( m_style == CX ) )
+aGal->DrawCircle( m_position, scaledSize.x );
+
+switch( m_style & 0xFF )
 {
 case NONE:
 break;
 
 case CROSS:
+case CCROSS:
 aGal->DrawLine( m_position - VECTOR2D( scaledSize.x, 0 ), 
m_position + VECTOR2D( scaledSize.x, 0 ) );
 aGal->DrawLine( m_position - VECTOR2D( 0, scaledSize.y ), 
m_position + VECTOR2D( 0, scaledSize.y ) );
 break;
 
 case X:
+case CX:
 aGal->DrawLine( m_position - scaledSize, m_position + scaledSize );
 scaledSize.y = -scaledSize.y;
 aGal->DrawLine( m_position - scaledSize, m_position + scaledSize );
 break;
 
 case DOT:
+case CDOT:
 aGal->DrawCircle( m_position, scaledSize.x / 4 );
 break;
 }

=== modified file 'include/origin_viewitem.h'
--- include/origin_viewitem.h   2015-06-18 15:51:53 +
+++ include/origin_viewitem.h   2015-09-03 20:52:14 +
@@ -42,10 +42,11 @@
 {
 public:
 ///> Marker symbol styles
-enum MARKER_STYLE { NONE, CROSS, X, DOT };
+enum MARKER_STYLE { NONE, CROSS, X, DOT, CCROSS, CX, CDOT };
 
-ORIGIN_VIEWITEM( const COLOR4D& aColor = COLOR4D( 1.0, 1.0, 1.0, 1.0 ), 
MARKER_STYLE aStyle = X,
- int aSize = 16, const VECTOR2D& aPosition = VECTOR2D( 0, 
0 ) );
+ORIGIN_VIEWITEM( const COLOR4D& aColor = COLOR4D( 1.0, 1.0, 1.0, 1.0 ),
+ MARKER_STYLE aStyle = CX, int aSize = 16,
+ const VECTOR2D& aPosition = VECTOR2D( 0, 0 ) );
 
 const BOX2I ViewBBox() const;
 
@@ -71,6 +72,11 @@
 return wxT( "ORIGIN_VIEWITEM" );
 }
 
+inline void SetDrawAtZero( bool aDrawFlag )
+{
+m_drawatzero = aDrawFlag;
+}
+
 inline void SetPosition( const VECTOR2D& aPosition )
 {
 m_position = aPosition;
@@ -123,6 +129,9 @@
 
 ///> Marker symbol.
 MARKER_STYLEm_style;
+
+///> If set, the target will be drawn even if it's position is 0,0
+boolm_drawatzero;
 };
 
 } // namespace KIGFX

=== modified file 'pcbnew/moduleframe.cpp'
--- pcbnew/moduleframe.cpp  2015-08-26 09:50:16 +
+++ pcbnew/moduleframe.cpp  2015-09-03 19:21:09 +
@@ -931,6 +931,7 @@
 m_toolManager->GetTool()->EditModules( true );
 m_toolManager->GetTool()->EditModules( true );
 m_toolManager->GetTool()->EditModules( true );
+m_toolManager->GetTool()->EditModules( true );
 
 m_toolManager->ResetTools( TOOL_BASE::RUN );
 m_toolManager->InvokeTool( "pcbnew.InteractiveSelection" );

=== modified file 'pcbnew/tools/pcb_editor_control.cpp'
--- pcbnew/tools/pcb_editor_control.cpp 2015-08-03 09:53:58 +
+++ pcbnew/tools/pcb_editor_control.cpp 2015-09-03 20:56:09 +
@@ -85,7 +85,7 @@
 TOOL_INTERACTIVE( "pcbnew.EditorControl" ), m_frame( NULL ), m_zoneMenu( 
NULL )
 {
 m_placeOrigin = new KIGFX::ORIGIN_VIEWITEM( KIGFX::COLOR4D( 0.8, 0.0, 0.0, 
1.0 ),
-

Re: [Kicad-developers] Helping out with Kicad

[Brian Sidebotham]

Just wanted to say - Thank-you so much everyone who's contributed to
the new site because it looks great! Static makes so much sense. It's
a great effort and I can't wait for that to become live - it should
sort out all of the confusion users have with where KiCAD is at and
has a well-focussed place to get the latest release.

Brian.

On 21 August 2015 at 02:58, Mark Roszko mark.ros...@gmail.com wrote:
 Actually, the 3d viewer image has been sorted out now.

 ___
 Mailing list: https://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] Doc: po4a-updatepo removes numeric lists

[Brian Sidebotham]

Hi Martin,

Thanks for the report!

Could you please copy this into an issue on the kicad-doc github repo
please? https://github.com/ciampix/kicad-doc/issues

Best Regards,

Brian.

On 21 June 2015 at 00:00, Martin d'Allens martin.dall...@gmail.com wrote:
 Hi all,

 It seems that po4a-updatepo currently removes the numeric lists from
 the documentation.
 Compare these two generated files :
 http://ci.kicad-pcb.org/job/any-kicad-doc-head/lastSuccessfulBuild/artifact/src/Getting_Started_in_KiCad/Getting_Started_in_KiCad-fr.html#draw-electronic-schematics
 http://ci.kicad-pcb.org/job/any-kicad-doc-head/lastSuccessfulBuild/artifact/src/Getting_Started_in_KiCad/Getting_Started_in_KiCad.html#draw-electronic-schematics

 The faulty command is at line 93 of the Makefile and amounts to this:
po4a-updatepo -f asciidoc -v -M utf-8 -m
 Getting_Started_in_KiCad.adoc -p po/fr.po

 For the following source:
1. Under Windows run kicad.exe. Under Linux type 'kicad' in your ...
 The output becomes:
Under Windows run kicad.exe. Under Linux type 'kicad' in your ...
 https://github.com/ciampix/kicad-doc/blob/master/src/Getting_Started_in_KiCad/po/fr.po#L462

 I haven't found a fix yet, does someone have a better understanding of
 the issue?


 Martin

 ___
 Mailing list: https://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] 3D Scale settings

[Brian Sidebotham]

On 31 May 2015 at 23:25, Cirilo Bernardo cirilo.berna...@gmail.com wrote:
 Hi Brian,

  I suggest we leave the scaling etc until after the stable release; it's a
 nightmare.

  Historically the scaling allowed users to reuse similar models if they
 didn't already
 have a suitable model, for example grow or shrink a THT 0.25W resistor to
 pretend
 it's a 0.5/1.0/2.0W type or a small glass-encapsulated diode. I think with
 the
 currently available tools and numerous models there is no need to support
 this
 intended behavior and the GUI should only have a Z rotation and a Z offset;
 to
 remove all ambiguity we do need to specify the units of the Z offset.

Changing  the way scaling works is not on the table here. Only a
user-helper which is to fill in the pre-existing scale UI with values
that are awkward to work out for a normal user (and laborious to type
for everyone). That's all I'm proposing - as well as a documentation
update.

I noticed when I linked to it that the Modedit documentation was quite
out-of-date. That needs sorting out regardless.

Best Regards,

Brian.

___
Mailing list: https://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] 3D Scale settings

[Brian Sidebotham]

On 1 June 2015 at 10:46, Brian Sidebotham brian.sidebot...@gmail.com
wrote:
 On 31 May 2015 at 23:25, Cirilo Bernardo cirilo.berna...@gmail.com
wrote:
 Hi Brian,

  I suggest we leave the scaling etc until after the stable release; it's
a
 nightmare.

  Historically the scaling allowed users to reuse similar models if they
 didn't already
 have a suitable model, for example grow or shrink a THT 0.25W resistor to
 pretend
 it's a 0.5/1.0/2.0W type or a small glass-encapsulated diode. I think
with
 the
 currently available tools and numerous models there is no need to support
 this
 intended behavior and the GUI should only have a Z rotation and a Z
offset;
 to
 remove all ambiguity we do need to specify the units of the Z offset.

 Changing  the way scaling works is not on the table here. Only a
 user-helper which is to fill in the pre-existing scale UI with values
 that are awkward to work out for a normal user (and laborious to type
 for everyone). That's all I'm proposing - as well as a documentation
 update.


Like this:


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

[Kicad-developers] 3D Scale settings

[Brian Sidebotham]

Hey guys,

I only just got round to using 3D with KiCad. Mainly because I
normally use Solid Edge for 3D solid modelling, and I could never be
bothered to use FreeCAD at home because, well, it's not Solid Edge!
Anyway, I just compiled FreeCAD on my Mint box and I have to say it
works really well these days - so I should put it to use.

I designed my part in metric in FreeCAD, exported to WRL and used that
in KiCad (All works well there, so thanks to everyone who's been
working on that part of KiCad, it now just works). The problem I had
was one of scale. To get the scale right, the scale needs to be input
as 0.393701 (1/2.54).

The units in the WRL are in mm. Can I put some buttons in to set the
scale? Buttons like mm, cm, inches, and feet which would be useful
to me. Is this something can happen pre-stable release?

It seems like a usability thing to me. Not many people are going to
guess at 1/2.54.

There's very minimal impact on the manuals. Perhaps more people are
using FreeCAD compared to Wings3D these days anyway?

All thoughts or other ideas are welcome! :D

Best Regards,

Brian.

___
Mailing list: https://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] 3D Scale settings

[Brian Sidebotham]

On 31 May 2015 at 21:19, Brian Sidebotham brian.sidebot...@gmail.com wrote:
 On 31 May 2015 at 21:16, Nick Østergaard oe.n...@gmail.com wrote:

 Den 31/05/2015 22.11 skrev Brian Sidebotham brian.sidebot...@gmail.com:

 Hey guys,

 I only just got round to using 3D with KiCad. Mainly because I
 normally use Solid Edge for 3D solid modelling, and I could never be
 bothered to use FreeCAD at home because, well, it's not Solid Edge!
 Anyway, I just compiled FreeCAD on my Mint box and I have to say it
 works really well these days - so I should put it to use.

 I designed my part in metric in FreeCAD, exported to WRL and used that
 in KiCad (All works well there, so thanks to everyone who's been
 working on that part of KiCad, it now just works). The problem I had
 was one of scale. To get the scale right, the scale needs to be input
 as 0.393701 (1/2.54).

 The units in the WRL are in mm. Can I put some buttons in to set the
 scale? Buttons like mm, cm, inches, and feet which would be useful
 to me. Is this something can happen pre-stable release?

 Where do you want to out these buttons? In the dialog where you set the
 position an dstuff?

 How do you want to save this information?

 Of you check a box, you would that to be checked when you reload the pcb.


 Where the scale is set in the footprint properties dialog...

This dialog screenshot needs updating, but here it is in the current
documentation:

https://github.com/ciampix/kicad-doc/blob/master/src/Pcbnew/Pcbnew_creating_editing_modules.adoc#3-dimensional-visualisation

Best Regards,

Brian.

___
Mailing list: https://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] 3D Scale settings

[Brian Sidebotham]

On 31 May 2015 at 21:38, easyw ea...@katamail.com wrote:
 Hi Brian,
 just a question for 3d modeling...
 Do you use to export 3d vrml plain pcb plus modules to Solid Edge?
 Do you convert them in some way to manipulate the board in SE? (e.g. step or
 iges)
 thank you
 Maurice

Hi Maurice,

I've only ever used KiCAD and Solid Edge separately. i.e. design a 3D
view of the board in Solid Edge and make a PCB design in KiCAD. I
never bothered trying to link the two together; That was 5-6 years
ago.

These days we use OrCAD and CADSTAR at work coupled with, again,
separate design in Solid Edge.

At home is where I want to couple FreeCAD and KiCad to work
efficiently to create 3D models for some of my CNC projects.

Best Regards,

Brian.

___
Mailing list: https://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] 3D Scale settings

[Brian Sidebotham]

On 31 May 2015 at 21:16, Nick Østergaard oe.n...@gmail.com wrote:

 Den 31/05/2015 22.11 skrev Brian Sidebotham brian.sidebot...@gmail.com:

 Hey guys,

 I only just got round to using 3D with KiCad. Mainly because I
 normally use Solid Edge for 3D solid modelling, and I could never be
 bothered to use FreeCAD at home because, well, it's not Solid Edge!
 Anyway, I just compiled FreeCAD on my Mint box and I have to say it
 works really well these days - so I should put it to use.

 I designed my part in metric in FreeCAD, exported to WRL and used that
 in KiCad (All works well there, so thanks to everyone who's been
 working on that part of KiCad, it now just works). The problem I had
 was one of scale. To get the scale right, the scale needs to be input
 as 0.393701 (1/2.54).

 The units in the WRL are in mm. Can I put some buttons in to set the
 scale? Buttons like mm, cm, inches, and feet which would be useful
 to me. Is this something can happen pre-stable release?

 Where do you want to out these buttons? In the dialog where you set the
 position an dstuff?

 How do you want to save this information?

 Of you check a box, you would that to be checked when you reload the pcb.


Where the scale is set in the footprint properties dialog when you're
creating a module, information is saved as the scale. No need for a
checkbox, just a button that sets the appropriate scale for a given
input 3d unit to be correct. i.e. mm button sets scale to 0.393701.

Best Regards,

Brian.

___
Mailing list: https://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] translation of the kicad manuals

[Brian Sidebotham]

The CMake documentation build system is now pretty much complete. I
have a pull request nearly ready for dealing with images in FOP where
we need to blanket them with scale-down-to-fit so that they fit on
the page properly. Currently you could consider the FOP build to be
broken because images often go off the page.

For information on the CMake build system see here:
https://github.com/ciampix/kicad-doc/blob/master/cmake-readme.adoc

It builds on Windows (SLOWLY!) and Linux.

Best Regards,

Brian.

On 20 May 2015 at 18:09, Nick Østergaard oe.n...@gmail.com wrote:
 Whenever it is the correct time, please consider the transferring repos 
 method.
 https://help.github.com/articles/transferring-a-repository/

 No that ti is highly important.

 2015-05-20 18:22 GMT+02:00 Wayne Stambaugh stambau...@gmail.com:
 Thank you everyone for making this possible.  Now that most of the
 pieces are in place, hopefully more help will arrive on the
 documentation front.

 Cheers,

 Wayne

 On 5/19/2015 8:07 PM, Marco Ciampa wrote:
 Hello devs!
 KiCad multilingual manuals are almost completed, make + cmake build
 systems are improving every day but almost all source docs are in-place.

 What is missing?

 Revisioners and translators. There are many holes in the docs for the new
 features, old and outdated screenshots and unmeaningful image names, and
 small syntax errors here and there, and ... there are just two
 translators active! Polish and Italian.

 Please contribute here: https://github.com/ciampix/kicad-doc

 Please note that, for now, the Makefile method under Linux is the most
 complete build system. Cmake is in an alpha but promising stage...

 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

___
Mailing list: https://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] translation of the kicad manuals

[Brian Sidebotham]

On 27 May 2015 at 09:42, Brian Sidebotham brian.sidebot...@gmail.com wrote:
 The CMake documentation build system is now pretty much complete. I
 have a pull request nearly ready for dealing with images in FOP where
 we need to blanket them with scale-down-to-fit so that they fit on
 the page properly. Currently you could consider the FOP build to be
 broken because images often go off the page.

 For information on the CMake build system see here:
 https://github.com/ciampix/kicad-doc/blob/master/cmake-readme.adoc

 It builds on Windows (SLOWLY!) and Linux.


Testing on MAC would be useful if anyone fancies doing that?

Also, Issue 63[1] regarding documentation version suffix may want to
be discussed on-list?

[1] https://github.com/ciampix/kicad-doc/issues/63

Best Regards,

Brian.

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

[Brian Sidebotham]

On 18 April 2015 at 17:36, Wayne Stambaugh stambau...@gmail.com wrote:
 Brian,

 How did you get po4a to build?  I tried everything I could think of (I'm
 no Perl expert so take that with the appropriate grain of salt) but no
 luck.  I did manage to get the some of the dependencies to build using
 msys2 but po4a is still giving me grief.  I would rather not have to
 install externally built binary if I don't have to.

 Thanks,

 Wayne


Hi Wayne,

The trick is not to build po4a because it's not required to be
built. So long as po4a is in your path, kicad-doc's FindPO4A will be
able to find it and use it.

I found the easiest thing to do is not to install po4a as a perl
module, but rather just run it with the perl interpreter from source.
The only dependency it requires for us to use it is Unicode:GCString;
You must install that perl module using cpan or similar.

Once that dependency is in place, you can simply run the po4a utilities like so:

perl -IC:/path/to/po4a/lib po4a

That's what we do in the kicad-doc CMake. In msys2, perhaps you want
to do a helper script in /usr/bin or something that as having the po4a
source directory in your PATH may seem a bit odd, whereas in Windows
the PATH variable is usually just full of this sort of junk! ;)

By the way, I too spent a few days trying to get it to build properly
on Windows, using various versions of Perl, but with no luck until I
had the epiphany of not building it!

For dblatex, please see the appropriate notes in
https://github.com/BrianSidebotham/kicad-doc/blob/master/cmake-readme.adoc

Best Regards,

Brian.

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

[Brian Sidebotham]

I'm nearly ready for a pull request. I've just committed changes to my
repo so that PDF and HTML can be built on Windows and Linux.

Both dblatex and FOP are supported for PDF generation on Linux and
Windows, however I cannot get the dblatex PDF build to complete on
Windows because of a problem with the xlstproc I'm using. Perhaps
someone will have better luck than me. Because of that, I've noted in
cmake-readme.adoc in my repo that only FOP is suppored under Windows.

CMake just does feature checking, not platform checking, so you can
give anything that's supported a go. Getting the full dblatex tool
chain seutp on Windows is a bit of a pain!

Best Regards,

Brian.

On 14 April 2015 at 00:52, Nick Østergaard oe.n...@gmail.com wrote:
 Great.

 Den 13/04/2015 22.57 skrev Brian Sidebotham brian.sidebot...@gmail.com:

 I sync'd with Marco's repo so that's now reflected in my repo.

 I just need to do the po update stuff I think and then I'll do a pull
 request to get the repo's aligned.

 Best Regards,

 Brian.

 On 12 April 2015 at 23:12, Nick Østergaard oe.n...@gmail.com wrote:
  I have now done this.
 
  2015-04-11 13:48 GMT+02:00 Nick Østergaard oe.n...@gmail.com:
  So now is a good time to remove the src/markdown and src/rest and move
  src/asciidoc to src?
 
  If so, I can do that now, such that you can pull those changes.
 
  2015-04-11 13:43 GMT+02:00 Brian Sidebotham
  brian.sidebot...@gmail.com:
  On 11 April 2015 at 12:32, Brian Sidebotham
  brian.sidebot...@gmail.com wrote:
  On 11 April 2015 at 12:11, Nick Østergaard oe.n...@gmail.com wrote:
  Great. I just looked briefly on the cmake setup. It seems to me like
  you intend to include a CMakeLists.txt inside each doc dir with the
  only change being the name or path of the root adoc file. Would it
  not
  mere more sense to have a common CMakeLists.txt in the src/asciidoc
  dir (to be renamed just src when we remove the markdown and rest
  variants), which searches the folders or is just given an array of
  root doc files?
 
 
  Things will change, I've just begun the start of adding macros to
  create pdf and html targets. There's plenty more work to do yet.
  Certainly there'll be a lot of common code that can be shared through
  higher level cmake files.
 
 
  The initial plan was to get CvPcb translation and generation complete.
  Once the repo achieves that, I can pull request it into Marco's repo
  and then hopefully there'll be plenty of resource to complete the
  CMake stuff, then Marco's repo will come under the KiCad umbrella.
 
  Best Regards,
 
  Brian.

___
Mailing list: https://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] S3D Mesh Smart Pointer

[Brian Sidebotham]

I just tested with VRML 1 and VRML 2 and stuff has appeared not to
break, so I just committed this change.

I opted for the boost::shared_ptr as we're not yet C++11 and there is
quite a bit of standard container work going on.

Best Regards,

Brian.


On 11 April 2015 at 00:04, Brian Sidebotham brian.sidebot...@gmail.com wrote:
 Hi Guys,

 Could someone who has access to both vrml1 and vrml2 models please
 test the attached patch which uses a smart pointer rather than
 S3D_MESH* to get rid of some coverity issues and feedback whether it
 makes your computer explode, or carry on working normally?

 Alternatively, could someone email a couple of vrml files that would
 exercise it and I'll put it through it's paces...

 Sorry, there's white space deletions going on in the patch so it's a bit 
 noisy.

 Thanks,

 Brian.

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

[Brian Sidebotham]

I sync'd with Marco's repo so that's now reflected in my repo.

I just need to do the po update stuff I think and then I'll do a pull
request to get the repo's aligned.

Best Regards,

Brian.

On 12 April 2015 at 23:12, Nick Østergaard oe.n...@gmail.com wrote:
 I have now done this.

 2015-04-11 13:48 GMT+02:00 Nick Østergaard oe.n...@gmail.com:
 So now is a good time to remove the src/markdown and src/rest and move
 src/asciidoc to src?

 If so, I can do that now, such that you can pull those changes.

 2015-04-11 13:43 GMT+02:00 Brian Sidebotham brian.sidebot...@gmail.com:
 On 11 April 2015 at 12:32, Brian Sidebotham brian.sidebot...@gmail.com 
 wrote:
 On 11 April 2015 at 12:11, Nick Østergaard oe.n...@gmail.com wrote:
 Great. I just looked briefly on the cmake setup. It seems to me like
 you intend to include a CMakeLists.txt inside each doc dir with the
 only change being the name or path of the root adoc file. Would it not
 mere more sense to have a common CMakeLists.txt in the src/asciidoc
 dir (to be renamed just src when we remove the markdown and rest
 variants), which searches the folders or is just given an array of
 root doc files?


 Things will change, I've just begun the start of adding macros to
 create pdf and html targets. There's plenty more work to do yet.
 Certainly there'll be a lot of common code that can be shared through
 higher level cmake files.


 The initial plan was to get CvPcb translation and generation complete.
 Once the repo achieves that, I can pull request it into Marco's repo
 and then hopefully there'll be plenty of resource to complete the
 CMake stuff, then Marco's repo will come under the KiCad umbrella.

 Best Regards,

 Brian.

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

[Brian Sidebotham]

On 11 April 2015 at 12:11, Nick Østergaard oe.n...@gmail.com wrote:
 Great. I just looked briefly on the cmake setup. It seems to me like
 you intend to include a CMakeLists.txt inside each doc dir with the
 only change being the name or path of the root adoc file. Would it not
 mere more sense to have a common CMakeLists.txt in the src/asciidoc
 dir (to be renamed just src when we remove the markdown and rest
 variants), which searches the folders or is just given an array of
 root doc files?


Things will change, I've just begun the start of adding macros to
create pdf and html targets. There's plenty more work to do yet.
Certainly there'll be a lot of common code that can be shared through
higher level cmake files.

Best Regards,

Brian.

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

[Brian Sidebotham]

On 11 April 2015 at 12:32, Brian Sidebotham brian.sidebot...@gmail.com wrote:
 On 11 April 2015 at 12:11, Nick Østergaard oe.n...@gmail.com wrote:
 Great. I just looked briefly on the cmake setup. It seems to me like
 you intend to include a CMakeLists.txt inside each doc dir with the
 only change being the name or path of the root adoc file. Would it not
 mere more sense to have a common CMakeLists.txt in the src/asciidoc
 dir (to be renamed just src when we remove the markdown and rest
 variants), which searches the folders or is just given an array of
 root doc files?


 Things will change, I've just begun the start of adding macros to
 create pdf and html targets. There's plenty more work to do yet.
 Certainly there'll be a lot of common code that can be shared through
 higher level cmake files.


The initial plan was to get CvPcb translation and generation complete.
Once the repo achieves that, I can pull request it into Marco's repo
and then hopefully there'll be plenty of resource to complete the
CMake stuff, then Marco's repo will come under the KiCad umbrella.

Best Regards,

Brian.

___
Mailing list: https://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] S3D Mesh Smart Pointer

[Brian Sidebotham]

Hi Guys,

Could someone who has access to both vrml1 and vrml2 models please
test the attached patch which uses a smart pointer rather than
S3D_MESH* to get rid of some coverity issues and feedback whether it
makes your computer explode, or carry on working normally?

Alternatively, could someone email a couple of vrml files that would
exercise it and I'll put it through it's paces...

Sorry, there's white space deletions going on in the patch so it's a bit noisy.

Thanks,

Brian.
=== modified file '3d-viewer/3d_mesh_model.cpp'
--- 3d-viewer/3d_mesh_model.cpp 2015-03-29 16:13:58 +
+++ 3d-viewer/3d_mesh_model.cpp 2015-04-01 21:58:33 +
@@ -68,13 +68,6 @@
 
 S3D_MESH::~S3D_MESH()
 {
-for( unsigned int idx = 0; idx  childs.size(); idx++ )
-{
-if( childs[idx] )
-{
-delete childs[idx];
-}
-}
 }
 
 
@@ -82,7 +75,7 @@
 {
 if( !m_BBox.IsInitialized() )
 calcBBoxAllChilds();
-
+
 return m_BBox;
 }
 
@@ -100,7 +93,7 @@
 // Calc transformation matrix
 glm::mat4 fullTransformMatrix;
 glm::mat4   translationMatrix   = glm::translate( glm::mat4(),   
m_translation );
-
+
 if( m_rotation[3] != 0.0f )
 {
 glm::mat4   rotationMatrix  = glm::rotate(translationMatrix, 
glm::radians( m_rotation[3] ),
@@ -110,7 +103,7 @@
 else
 fullTransformMatrix = glm::scale( translationMatrix, m_scale );
 
-
+
 // Apply transformation
 m_BBox.Set( S3D_VERTEX( fullTransformMatrix * glm::vec4( tmpBBox.Min(), 
1.0f ) ),
 S3D_VERTEX( fullTransformMatrix * glm::vec4( tmpBBox.Max(), 
1.0f ) ) );
@@ -243,7 +236,7 @@
 if ( m_MaterialIndex.size()  idx )
 {
 bool isTransparent = m_Materials-SetOpenGLMaterial( 
m_MaterialIndex[idx], useMaterial );
-
+
 if( isTransparent  aIsRenderingJustNonTransparentObjects )
 continue;
 
@@ -652,7 +645,7 @@
 l,
 (unsigned int)m_CoordIndex[idx].size()) );
 */
-
+
 if( ( cross_prod.x  cross_prod.y )  ( cross_prod.x  
cross_prod.z ) )
 {
 cross_prod.x = 0.0f;
@@ -713,7 +706,7 @@
 for( unsigned int each_face_A_idx = 0; each_face_A_idx  
m_CoordIndex.size(); each_face_A_idx++ )
 {
 glm::vec3 initVertexFaceNormal = 
m_PerFaceNormalsRaw_X_PerFaceSquaredArea[each_face_A_idx];
-
+
 std::vector glm::vec3  face_A_normals = 
m_PerFaceVertexNormals[each_face_A_idx];
 
 for( unsigned int each_vert_A_idx = 0; each_vert_A_idx  
m_CoordIndex[each_face_A_idx].size(); each_vert_A_idx++ )
@@ -722,7 +715,7 @@
 }
 }
 
-
+
 #ifdef USE_OPENMP
 #pragma omp parallel for
 #endif /* USE_OPENMP */
@@ -732,7 +725,7 @@
 {
 // n = face A facet normal
 std::vector glm::vec3  face_A_normals = 
m_PerFaceVertexNormals[each_face_A_idx];
- 
+
 // loop through all vertices
 // for each vert in face A
 for( unsigned int each_vert_A_idx = 0; each_vert_A_idx  
m_CoordIndex[each_face_A_idx].size(); each_vert_A_idx++ )

=== modified file '3d-viewer/3d_mesh_model.h'
--- 3d-viewer/3d_mesh_model.h   2015-03-29 10:59:53 +
+++ 3d-viewer/3d_mesh_model.h   2015-04-10 22:50:03 +
@@ -24,12 +24,14 @@
 
 /**
  * @file 3d_mesh_model.h
- * @brief 
+ * @brief
  */
 
 #ifndef __3D_MESH_MODEL_H__
 #define __3D_MESH_MODEL_H__
 
+#include memory
+#include boost/shared_ptr.hpp
 #include vector
 #define GLM_FORCE_RADIANS
 #include gal/opengl/glm/glm.hpp
@@ -37,9 +39,14 @@
 #include 3d_material.h
 #include CBBox.h
 
-
 class S3D_MESH;
 
+/** A smart pointer to an S3D_MESH object */
+typedef boost::shared_ptrS3D_MESH S3D_MESH_PTR;
+
+/** A container of smar S3D_MESH object pointers */
+typedef std::vectorS3D_MESH_PTR S3D_MESH_PTRS;
+
 class S3D_MESH
 {
 public:
@@ -60,7 +67,7 @@
 std::vector S3D_VERTEXm_PerFaceNormalsNormalized;
 std::vector S3D_VERTEXm_PerVertexNormalsNormalized;
 std::vector int   m_MaterialIndex;
-std::vector S3D_MESH *childs;
+S3D_MESH_PTRS   childs;
 
 S3D_VERTEX  m_translation;
 glm::vec4   m_rotation;

=== modified file '3d-viewer/modelparsers.h'
--- 3d-viewer/modelparsers.h2015-03-29 16:13:58 +
+++ 3d-viewer/modelparsers.h2015-04-01 23:08:49 +
@@ -30,6 +30,7 @@
 #define MODELPARSERS_H
 
 #include map
+#include memory
 #include vector
 #include wx/string.h
 #include 3d_mesh_model.h
@@ -71,11 +72,11 @@
  * @param aFilename = the full file name of the file to load
  * @return true if as succeeded
  */
-virtual bool Load( const wxString aFilename ) { 
+virtual bool Load( const wxString aFilename ) {
 return false;
 };
 
-std::vector S3D_MESH*  childs;
+S3D_MESH_PTRS childs;
 
 private:
 S3D_MASTER* master;
@@ 

Re: [Kicad-developers] Documentation update

[Brian Sidebotham]

On 8 April 2015 at 14:08, Wayne Stambaugh stambau...@gmail.com wrote:
 On 4/8/2015 4:51 AM, Brian Sidebotham wrote:
 On 4 April 2015 at 16:23, Wayne Stambaugh stambau...@gmail.com wrote:
 Now that we are in feature freeze, I need an update on where we stand as
 far as the asciidoc documentation conversion process is concerned.  I
 did a git pull yesterday and now `make html` fails for a missing po
 directory.  I have a few questions about the current state of the
 documentation.

 1) Is all of the legacy ODT documentation converted to asciidoc?

 2) Does all the English language asciidoc build in both html and
pdf at least on Linux?

 3) Do all of the supported translations build?

 4) I didn't see any CMake configuration files yet.  Are we making any
progress on that front?

 Hi Wayne,

 Sorry, I've been really busy doing other stuff, but the CMake stuff is
 underway: https://github.com/BrianSidebotham/kicad-doc

 It's still experimental and not fully functional yet, but it can now
 progress better. Nick has fixed the msys2 KiCad-Winbuilder which was
 broken for a while and had me stumped! That project is now close to
 being able to provide decent installers. At the moment it can create
 the installers, but I think there's still some outstanding work to
 make the installers complete.

 Hopefully I'll be able to get the CMake stuff up and running pretty
 soon. I'll concentrate on Linux and then make sure things work through
 msys2. PDF generation under msys2 is a pain, but could be possible
 through either asciidoctor-pdf or else a2x and Apache fop.

 What development isn't painful on windows?  Kudos to the msys2 folks for
 significantly improving the situation.  It's come a long way from all
 the set up work required to get the old msys/mingw32 system to work.
 I'll see if I can take a look at your CMake work this weekend.


Hi Wayne,

I did a few commits tonight and at least under Linux it'll now build
the equivalent of the Makefile stuff for CvPcb and package it up, so
that includes all languages in both HTML and PDF.

Best Regards,

Brian.

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

[Brian Sidebotham]

On 4 April 2015 at 16:23, Wayne Stambaugh stambau...@gmail.com wrote:
 Now that we are in feature freeze, I need an update on where we stand as
 far as the asciidoc documentation conversion process is concerned.  I
 did a git pull yesterday and now `make html` fails for a missing po
 directory.  I have a few questions about the current state of the
 documentation.

 1) Is all of the legacy ODT documentation converted to asciidoc?

 2) Does all the English language asciidoc build in both html and
pdf at least on Linux?

 3) Do all of the supported translations build?

 4) I didn't see any CMake configuration files yet.  Are we making any
progress on that front?

Hi Wayne,

Sorry, I've been really busy doing other stuff, but the CMake stuff is
underway: https://github.com/BrianSidebotham/kicad-doc

It's still experimental and not fully functional yet, but it can now
progress better. Nick has fixed the msys2 KiCad-Winbuilder which was
broken for a while and had me stumped! That project is now close to
being able to provide decent installers. At the moment it can create
the installers, but I think there's still some outstanding work to
make the installers complete.

Hopefully I'll be able to get the CMake stuff up and running pretty
soon. I'll concentrate on Linux and then make sure things work through
msys2. PDF generation under msys2 is a pain, but could be possible
through either asciidoctor-pdf or else a2x and Apache fop.

Best Regards,

Brian.

___
Mailing list: https://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] Bug fixing and Coverity scan errors.

[Brian Sidebotham]

On 31 March 2015 at 21:53, Wayne Stambaugh stambau...@gmail.com wrote:
 On 3/31/2015 4:03 PM, Simon Richter wrote:
 Hi,

 On 31.03.2015 13:29, Brian Sidebotham wrote:

 delete m_model;

 should really be:

 delete m_model;
 m_model = NULL;

 Other functions (namely read_DEF) make assignment from m_model. It's
 too complicated to try and rely on knowing the logical order of
 functions in a file format parser to guarantee that it won't break. At
 least if the assignment from m_model assigns NULL, debugging is
 reasonably sane.

 I'd rather like to see a smart pointer instead.

 If my object deletes another object, this implies that it has a rough
 idea of the ownership semantics, but these are never explicitly spelled
 out. auto_ptr/unique_ptr could then be used to denote exclusive
 ownership, shared_ptr for shared ownership, or intrusive_ptr for
 reference counted objects with internal counters. Naked pointers could
 then mean no ownership.

Simon

 This is my preference as well.  Although I would veto unique_ptr for
 now.  I'm not ready to make kicad c++ 0x11 compliant yet.


Yep, I also think that sounds like a better plan! I'll fix CID 108646
using auto_ptr then.

Thanks Simon.

Best Regards,

Brian.

___
Mailing list: https://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] Bug fixing and Coverity scan errors.

[Brian Sidebotham]

I've just been going through the Coverity thing during a break at work
and tagged a few things ready to fix at home. The second I noticed is
because we use delete on a member variable pointer without
re-assignment.

I think it would be good policy to say unless the scope of the pointer
variable is the local code block, delete must be immediately followed
by a NULL assignment. i.e. from what I'm looking at now in the
vrml_v2_modelparser.cpp:241 or :263

delete m_model;

should really be:

delete m_model;
m_model = NULL;

Other functions (namely read_DEF) make assignment from m_model. It's
too complicated to try and rely on knowing the logical order of
functions in a file format parser to guarantee that it won't break. At
least if the assignment from m_model assigns NULL, debugging is
reasonably sane.

As an aside, I came across code ( pcbnew/eagle_plugin.cpp:1406 :1504,
etc ) in which the coding style policy 4.2.3 has been applied to else
if clauses. Is that intended? There's both types in that file. I was
going to do some tidying as I went along fixing Coverity items and
don't know which to go for. The coding style policy 4.7 has an example
where there's no blank line above them for reference...

Best Regards,

Brian.



On 30 March 2015 at 19:15, Wayne Stambaugh stambau...@gmail.com wrote:
 Now that we are in feature freeze, the next big task is to fix all of
 our critical and high importance bugs in the bug tracker.  To me,
 critical bugs are anything that causes a crash and/or data
 loss/curruption and high importance bugs are memory leaks.  These must
 be fixed before release.  Everything else is medium, low, or wishlist
 and do not need to be fixed for the stable release.  It doesn't look
 like there are many critical/high importance bugs that are not tagged as
 fix released.  However, I'm not sure all of the bugs that are
 critical/high importance have been tagged correctly so we need to make
 sure nothing has fallen through the cracks.  We also need to tagged any
 of the these bugs as fix committed if they have been fixed.

 All Coverity scan errors with a high impact need to be address.  If they
 are false positives, please mark them as such.  I still see some
 resource leaks in there so those should be given priority.  All other
 errors can be fixed when convenient.

 I would like to have at a minimum of one month after the last of the
 these issues is resolved so users can test to make sure there are no
 other issues lurking just beneath the surface.

 Thank you everyone for your hard work.  Hopefully we can make the stable
 release happen sometime around the middle of the year.

 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] Launchpad bug status

[Brian Sidebotham]

On 12 March 2015 at 20:53, Wayne Stambaugh stambau...@gmail.com wrote:


 On 3/12/2015 2:10 PM, Nick Østergaard wrote:
 But now to my real comment on this: I don't think we should do this. I
 might seem like a great concept at first, but rember the limited man
 power, and not to forget it will not be too motivating for people in
 the long run to do housekeeping on the tracker that, IMHO does not
 really add any information, other than blur where the bugfix is
 available. This is way more manual work, and this takes time and it
 will even make it possible for some bugs not to be closed (here closed
 means Fix Released) at all anyway.

 I don't see it that way.  Take bug

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

 for instance.  This bug fix has been release to the public in the
 product branch and nightly builds.  This bug has no meaning to the
 current stable release and only ever effected the product branch after
 the differential pair router code was merged.  I defy you to show me
 where in the bug report that shows which branch the bug report was filed
 against and what other branches it may or may not effect.  If we
 continue with the current system, it looks like we never fix any bugs
 when we actually fix most bugs fairly quickly.  There has got to a less
 confusing way to manage our bug tracker.

lp:kicad is the branch. Launchpad words things a bit weird in my
opinion. The fact is that you *can* target any of your series per bug.
This would not necessarily be the job the bug reporter, but instead
would be the job of a triager. Using the bug tracker effectively is
not just having a mass on untargetted bugs. So for each bug you get a
target to series link.

From the target to series you can select any of the series to place
this bug against. For the bug you linked to, just select product. If
you select both product and stable you get two sets of status for the
bug.

For KiCad, fix committed makes no sense for the product series, so
once a fix is committed you will probably go straight to fix released.
In Stable at the same time, assuming the fix is immediately
back-ported you would select Fix committed, then when you do a release
on that series, Launchpad marks all bugs set as Fix committed on the
stable series to Fix Released automatically. Of course, we currently
don't want to backport bugfixes to the stable branch and do bugfix
releases, but when someone's wanting to see if the bug is filed they
will (should?) search for bugs against the stable series and expect to
find a fix committed report.

All this takes careful resource though. To use the bug tracker
properly takes a lot of management, but if there are volunteers and
the system can be explained you'll have a much better view of what
bugs are currently against the product series. At the moment, there's
only 1 bug targeted at the product series! So it will take a large
triage effort to make sense of what's already there.

I created a quick dual-series targetted bug on KiCad-Winbuilder so you
can see what it looks like:
https://bugs.launchpad.net/kicad-winbuilder/+bug/1398881

Resource, Resource, Resource ( as I keep telling my bosses! )

Best Regards,

Brian.

___
Mailing list: https://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] Diff Pairs Length tuning in the product branch

[Brian Sidebotham]

On 3 March 2015 at 13:44, Tomasz Wlostowski tomasz.wlostow...@cern.ch wrote:
 Dear all,

 We've just merged the new features of the Interactive Router to the
 product branch:
 - Routing differential pairs (in pushshove mode too).
 - Tuning trace length.
 - Tuning differential pair length and skew.

 There's a video tutorial and a demo available on YouTube [1].

 The merge also includes some improvements to the selection/edit tools
 that we've developed alongside the new router features:
 - Snapping to the origin axes when moving (allowing to move an item
 exactly vertically/horizontally wrt its former position)
 - Editing footprint pad properties directly on PCB.
 - Moving pads of a footprint directly on PCB.
 - Opening the footprint editor for selected footprint on a PCB in GAL mode.
 - Dragging footprints by origin, pad 1 or pad nearest the cursor.
 - Guessing the best selection candidate instead of displaying the
 disambiguation menu every time.

 We did our best to make sure the branch compiles and runs correctly, and
 we'll greatly appreciate your feedback - be that bugs, feature requests
 or suggestions for improvements. Please keep in mind this is the first
 public release of the Diff Pairs, so some fine tuning may be needed in
 the future.

 Many thanks to all developers, funders  users for your help and support!

 Cheers,
 Tom  Orson

 [1] https://www.youtube.com/watch?v=chejn7dqpfQ


Lovely work! Thank-you so much for this contribution, it's really
excellent. I just had a chance to watch the video, thanks very much
for that Tomasz, it's really good at showing off the new features!

Best Regards,

Brian.

___
Mailing list: https://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] correct some snprintf usage

[Brian Sidebotham]

On 22 February 2015 at 03:00, Mark Roszko mark.ros...@gmail.com wrote:
 Fixes some cases where n-1 bytes was used as a size but snprintf
 protects against that internally. Also some hardcoded constant sizes
 changed to sizeof()

 And made a case where sprintf was used into snprintf as the path input
 as aUserPluginsPath could in theory be very stupid long if someone has
 a very stupid filesystem. Would be best if there was error handling if
 it exceeds ( snprintf will return greater than sizeof(buf) ) but I
 have no clue how that section needs cleanup.

The MinGW compiler uses the Microsoft system version of snprintf which
is not C99 compliant. I've attached a fix so that we can use snprintf
as per the C99 spec as per your patch.

I can't commit it until I can do a test compile to check everything
works okay with it. I'll have to wait until I'm home tonight. The
proper use of snprintf is much more sane!

The MS version is a real pain, it returns -1 if the contents do not
fit in the buffer and more importantly it does NOT guarantee to NULL
terminate even if it returns a positive result!!

Best Regards,

Brian.
=== modified file 'CMakeLists.txt'
--- CMakeLists.txt  2015-02-20 13:46:12 +
+++ CMakeLists.txt  2015-02-23 11:04:26 +
@@ -223,6 +223,10 @@
 endif()
 endif()
 
+# The MinGW compiler can use the microsoft system snprintf as standard 
and it has a broken
+# API with respect to the C99 standard, so make sure we force it to 
use its own compliant
+# snprintf
+add_definitions(-D__USE_MINGW_ANSI_STDIO=1)
 else()
 # We build DLL/DSOs from static libraries, so create position 
independent
 # code for all cases, since we do not have DLL/DSO specific static

___
Mailing list: https://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] wxPython version check

[Brian Sidebotham]

On 18 February 2015 at 14:26, Miguel Ángel Ajo majop...@redhat.com wrote:



 Hmm, this crashes in the fedora nightly build during pcbnew startup, I need
 to investigate why.

 https://github.com/KiCad/kicad-source-mirror/commit/69553d6fa31a60a4694395f0dcadfdbd787c21a8#diff-cdb8e872a96e63280c27292a5845cfbeR147

 snprintf( cmd, 1023, import wxversion; wxversion.select('%s'),
 WXPYTHON_VERSION );
 PyRun_SimpleString( cmd );


Probably a missing

PyLock lock;

Also, we don't need to use snprintf here, we can simply use:

const char* cmd = import wxversion; wxversion.select('
WXPYTHON_VERSION ');

instead.

Sorry I don't have time to investigate the crash right now. Good Luck.

Best Regards,

Brian.

___
Mailing list: https://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] wxPython version check

[Brian Sidebotham]

On 16 February 2015 at 17:44, Wayne Stambaugh stambau...@gmail.com wrote:
 On 2/16/2015 11:44 AM, Brian Sidebotham wrote:
 On 16 February 2015 at 15:42, Brian Sidebotham
 brian.sidebot...@gmail.com wrote:
 On 16 February 2015 at 14:17, Wayne Stambaugh stambau...@gmail.com wrote:
 Brian,

 How are you telling the kicad configuration where wxPython build is
 located during you winbuilder configuration?  Would Garth's solution
 below solve your problem?  The only issue I see with Garth's solution is
 that if you install wxPython somewhere other than where you defined
 PYTHON_SITE_PACKAGE_PATH, you would be right back to where you started.
  In other words you could build kicad but when you launched the python
 console, it would most likely crash because wxPython would not be
 located at PYTHON_SITE_PACKAGE_PATH or worse a different version of
 wxPython would be loaded.

 Hi Wayne,

 These days however packages like mingw-w64-python2 exist and so really
 we should be able to make use of that in KiCad-Winbuilder instead of
 the custom projects. I'll look into it.


 I just checked 
 http://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/mingw-w64-i686-python2-2.7.9-2-any.pkg.tar.xz/download

 Unfortunately we get: libgcc_s_dw2-1.dll is missing. This is a
 show-stopper in my opinion because dwarf-2 is known to be broken with
 regards to throwing exceptions across DLL boundaries. Since the Kiway
 work there's no real option but to support exception throwing across
 DLL boundaries otherwise exceptions cannot propagate correctly.

 After all this time, this issue hasn't been addressed?  This was an
 issue over 10 years ago.  This makes me feel better about the bug fixing
 rate in KiCad.  I'm not sure which code in KiCad would cause this error.
  Most of the exceptions that I can think of do not cross DLL boundaries.
  They only cross from the DLL to the main executable which does not
 fail.  I just tested the pretty library parser which throws an IO_ERROR
 from _pcbnew.kiface to pcbnew.exe without any issues.  I don't think
 wxWidgets raises any an most of Boost is the header libraries so that
 wouldn't be an issue either.  Do Python exceptions cross over into C++
 land?  If so, that could be an error.


Hi Wayne,

Thanks so much for doing a quick sanity check. I forget the check I
used to do. Perhaps it is no longer an issue these days and I'm worry
about a past issue. I'll try and re-base KiCad-Winbuilder off the
MSYS2 project MINGW repos for wxPython and python.

With regards to Python throwing exceptions, it's written entirely in C
so there's no risk of it throwing exceptions.

Best Regards,

Brian.

___
Mailing list: https://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] wxPython version check

[Brian Sidebotham]

On 16 February 2015 at 15:42, Brian Sidebotham
brian.sidebot...@gmail.com wrote:
 On 16 February 2015 at 14:17, Wayne Stambaugh stambau...@gmail.com wrote:
 Brian,

 How are you telling the kicad configuration where wxPython build is
 located during you winbuilder configuration?  Would Garth's solution
 below solve your problem?  The only issue I see with Garth's solution is
 that if you install wxPython somewhere other than where you defined
 PYTHON_SITE_PACKAGE_PATH, you would be right back to where you started.
  In other words you could build kicad but when you launched the python
 console, it would most likely crash because wxPython would not be
 located at PYTHON_SITE_PACKAGE_PATH or worse a different version of
 wxPython would be loaded.

 Hi Wayne,

 These days however packages like mingw-w64-python2 exist and so really
 we should be able to make use of that in KiCad-Winbuilder instead of
 the custom projects. I'll look into it.


I just checked 
http://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/mingw-w64-i686-python2-2.7.9-2-any.pkg.tar.xz/download

Unfortunately we get: libgcc_s_dw2-1.dll is missing. This is a
show-stopper in my opinion because dwarf-2 is known to be broken with
regards to throwing exceptions across DLL boundaries. Since the Kiway
work there's no real option but to support exception throwing across
DLL boundaries otherwise exceptions cannot propagate correctly.

That's why the KiCad-Winbuilder toolchain uses mingw-w64 sjlj
throughout (including dependencies) because it's not broken,
regardless of whether it's regarded as slower than dwarf-2. x86_64
should be good though as it uses SEH.

Is the KiCad msys2 package built using the same, I guess it must be?
Really it means it's broken because there are plenty of places in the
KiCad code when exceptions go across DLL boundaries. While it will
work until an exception occurs, it will simply crash rather than
handle the exception *if* the exception goes across a DLL boundary. I
used to know how to trigger that in the KiCad code, but I cannot
remember what I used to do. It is testable.

Therefore msys2 packages are not usable by KiCad-Winbuilder for now
anyway, unless I move it to 64-bit only. (Does anyone still run 32-bit
these days?)

Best Regards,

Brian.

___
Mailing list: https://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] Coverity scan.

[Brian Sidebotham]

On 15 February 2015 at 20:11, Wayne Stambaugh stambau...@gmail.com wrote:
 Mark Roszko was kind enough to set up a Coverity scan for KiCad at
 https://scan.coverity.com/projects/3606?tab=analysis_settings.  Thank
 you Mark.  I would at least like my lead developers to sign up and have
 Mark give you access to see the scan results.  If you see a high
 severity issue that is in your code, please make sure it's not a false
 positive and tag it as such or fix it if the issue is legitemate.  At
 the very least, we should shoot for no high severity issues.  Obviously,
 zero issues of any severity should be the goal but we have to start
 somewhere.

 On the whole, the KiCad error rate is not as bad as I thought it might
 be.  We are currently at 1.52 per 1000 lines of code.  The average for
 open source projects larger than 1M lines of code is 0.65.  Let's see if
 we can do better than average.

 Cheers,

 Wayne


Thanks for setting this up Mark, Can you give me access?

I signed up with my GitHub account, so username should be
BrianSidebotham or brian.sidebotham[at]gmail,com

Best Regards,

Brian.

___
Mailing list: https://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] Coverity scan.

[Brian Sidebotham]

On 16 February 2015 at 13:18, Wayne Stambaugh stambau...@gmail.com wrote:
 On 2/16/2015 7:15 AM, Brian Sidebotham wrote:
 On 15 February 2015 at 20:11, Wayne Stambaugh stambau...@gmail.com wrote:
 Mark Roszko was kind enough to set up a Coverity scan for KiCad at
 https://scan.coverity.com/projects/3606?tab=analysis_settings.  Thank
 you Mark.  I would at least like my lead developers to sign up and have
 Mark give you access to see the scan results.  If you see a high
 severity issue that is in your code, please make sure it's not a false
 positive and tag it as such or fix it if the issue is legitemate.  At
 the very least, we should shoot for no high severity issues.  Obviously,
 zero issues of any severity should be the goal but we have to start
 somewhere.

 On the whole, the KiCad error rate is not as bad as I thought it might
 be.  We are currently at 1.52 per 1000 lines of code.  The average for
 open source projects larger than 1M lines of code is 0.65.  Let's see if
 we can do better than average.

 Cheers,

 Wayne


 Thanks for setting this up Mark, Can you give me access?

 I signed up with my GitHub account, so username should be
 BrianSidebotham or brian.sidebotham[at]gmail,com

 Best Regards,

 Brian.


 Brian,

 I just gave you access this morning so you should be good to go.  Have fun!

 Cheers,

 Wayne


Perfect, cheers Wayne.

Best Regards,

Brian.

___
Mailing list: https://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] wxPython version check

[Brian Sidebotham]

On 16 February 2015 at 14:17, Wayne Stambaugh stambau...@gmail.com wrote:
 Brian,

 How are you telling the kicad configuration where wxPython build is
 located during you winbuilder configuration?  Would Garth's solution
 below solve your problem?  The only issue I see with Garth's solution is
 that if you install wxPython somewhere other than where you defined
 PYTHON_SITE_PACKAGE_PATH, you would be right back to where you started.
  In other words you could build kicad but when you launched the python
 console, it would most likely crash because wxPython would not be
 located at PYTHON_SITE_PACKAGE_PATH or worse a different version of
 wxPython would be loaded.

Hi Wayne,

First off, I just had a look and this is an easy fix; In the
environment I set up for building KiCad I just need to add the
wxpython base dir to the PYTHONPATH. Easy peasy. I will roll a new
version of KiCad-Winbuilder to fix this and also the dependencies of
the keyword lexers are now correct so parallel build jobs can be used
for the first compilation of KiCad too, so there are a few fixes that
can be released. I need to bump wxPython up now too.

Currently, I just point wxWidgets_ROOT_DIR to the root directory of
the wxpython-cmake archive (I won't call it an install because it's
just a decompressed release from https://launchpad.net/wxwidgets-cmake
). This has previously been enough to complete the build.

If we wind the clock back to when wxPython was being integrated with
KiCad life was different to what it is now. wxPython and Python on
Windows were both built using MSVC. The official distributions still
are of course. Dick made the commendable effort of providing a CMake
system for building Python with gcc on Windows, so this meant we could
link against libpython and pass around FILE* objects without fear of
the dreaded C-Runtime version mismatch crashes.

After that, I did the same for wxPython because the gcc build using
python on Windows was completely broke. That's not surprising as I
just said, gcc python modules couldn't be linked to libpython after
v2.4 ( or thereabouts ).

Those two projects got us everything we needed to link against
wxPython and produce a working KiCad with python scripting on Windows.
KiCad-Winbuilder became the testbed for it, in part to make sure the
Windows install was going to be valid.

Because of the MSVC compilation of the official distributions of
Python and wxPython we cannot use pre-installed versions and
pragmatically enable wxPython support as far as I know. Hence, KiCad
will have to bundle its own local Python and wxPython install that it
was linked against. Hence, there's no need to worry about crossing
over versions.

Boost is really the same, generally on Windows it's only available
officially as an MSVC compiled target.

It's very much safest to build and link everything with the same
compiler, ensuring that the ABI and C-Runtime remain constant across
the whole build. These days I think these packages are available in a
format we can use elsewhere, but they certainly weren't at the time.
We had a load of problems with C-Runtime versioning and also C++ DLL
ABI changes (That's just compiling with different versions of gcc!)

These days however packages like mingw-w64-python2 exist and so really
we should be able to make use of that in KiCad-Winbuilder instead of
the custom projects. I'll look into it.

Sorry for the long diatribe!

 I appreciate that you are providing external builders and I'm not trying
 to make your life miserable.  Although I'm sure at times it must seem
 that way.  I'm trying to find robust solutions for configuring and
 building kicad.  I wish we had never gone down the download_foo path,
 even for Boost.  It has been a tremendous support burden and a constant
 source of headaches.  We should have provided separate external builders
 for each dependency for problem the problem child platforms (OSX and
 windows) and kept the kicad source build configuration clean of any
 dependency building.  Hindsight is always 20/20.  The more I have to
 deal with this issue, the more I'm inclined to rip out all of the
 dependency build stuff once and for all.  It probably wont happen for
 the next stable release but it's priority continues to move up my todo
 list for the next development cycle.

No problem, don't worry about it too much. Everything is a moving
target. Wait until Windows 10 is out! ;)

I think the only thing that should be absolute is whatever clever
package searching we do is to provide a *_ROOT_DIR= be provided for
all packages we're using.

Certainly what we did have in mind were projects similar to the
https://launchpad.net/inkscape-devlibs project. That way, if anyone
wants to get developing KiCad fast they can grab the devlibs project
to satisfy all dependencies.

Sorry for the long email!

Best Regards,

Brian.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : 

Re: [Kicad-developers] Build options for asciidoc documentation

[Brian Sidebotham]

On 13 February 2015 at 22:36, Marco Ciampa ciam...@libero.it wrote:
 On Fri, Feb 13, 2015 at 08:52:28PM +, Brian Sidebotham wrote:
 Hi Marco,

 To bring more people in on the documentation effort, I'd like to
 create a GitHub repo under the KiCad organisation so that people know
 it's the official place to work on the documentation.

 Do you think that's a good idea too?

 No problem for me as long as I have direct write access to it for
 convenience (=speed) and to continue my port.

Hi Marco,

Sorry for the delayed response. No problem.

 Do you want me to do recruitment for translation or documentation
 conversion or do you want me to just let you carry on doing the
 conversion and italian translation for a while?

 Well if it will be placed into an official place, during the
 announcement could be a good idea to stress to the fact that anyone is
 willing to help is welcome (but of course this is always true, isn'it?
 There is always paucity of hands in the open/free source world... ;-)

 It's up to you, I don't want to step on your amazing documentation
 effort.

 From the start I said that I will be grateful for every help I receive...
 and this is not amazing if you understand my motivation...

 1) First of all I am lazy
 2) I was willing to start translating in Italian KiCad docs
 because
  a) I was willing to know more about KiCad and this is a good method
 to read all docs throughly,
  b) I find that translating into my native language all the KiCad docs,
 I understand them better.
 3) updating a translation from ODT is a nightmare and I am not willing to
 wasting my time translating something that in a few months could become
 obsolete and not easy to update

 so my motivations comes down to spare my time (and yes, hoping at the
 same time to do the same for other people too).

 I'm just going to be adding a CMake build system to it.

 I know, and I thank you since I really do not know anything about CMake
 (and my knowledge of make is scarce too anyway...)

 I'd like the repo to be under the KiCad organisation umbrella though
 so people know it's now official.

 Don't worry I understand and agree.

 I have only one concern: I reckon (but I could be totally wrong) that
 converting a makefile into CMake could be difficult for you if you do not
 understand completely why it works the way it does.

 My stupid toolchain with just make and a few scripting is working in a
 satisfactory way for my goal to have it working on my Ubuntu.

 I really do not know how to convert it into CMake without breaking its
 functionality and I am going to miss it if I want to continue updating it
 while you are working on it.

 I am afraid that could not be possible to mix and match two build sistems
 (make and CMake) without affecting the functionality of one or the other.

 So, maybe its better for you to just try and make a toolchain working for
 just a little document, say CvPcb, (that I already have completely
 translated into Italian), in the same way as I have done myself from the
 start. When it fully works, producing multiple language and multiple
 format versions correctly, it will be really easy to add all the other
 docs to your CMake toolchain.

 So for now you can start an unofficial dev branch with the CMake
 toolchain and CvPcb and its translation(s) with it. When it works I will
 add all the other docs that I can continue update in the meantime. We can
 test it with all the docs and if it works satisfactorily we can bless
 it and merge it into the official git doc repo.

 What do you think about it?

This sounds absolutely fine, so I can get to know the toolchain well.
I will start with Fat-Zer's latest commits, I'll just fork from there
and get the toolchain working on Windows as well as Linux. It's much
easier starting from an already working build system!

Best Regards,

Brian.

___
Mailing list: https://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] Build options for asciidoc documentation

[Brian Sidebotham]

On 14 February 2015 at 19:25, Nick Østergaard oe.n...@gmail.com wrote:
 2015-02-14 17:43 GMT+01:00 Fat-Zer fatz...@gmail.com:
 2015-02-13 14:17 GMT+03:00 Brian Sidebotham brian.sidebot...@gmail.com:
 Hi Guys,

 I was going to start the CMake stuff soon for the asciidoc
 documentation, but I'd like to know what toolchains people want to
 support. I'll start a Github repo and we can get stuck in. I'll try
 and base it on Fat-Zer's starting point where possible.

 HTML can be done via:

 asciidoc (python)
 asciidoctor (ruby)

 PDF can be done via:

 a2x
 a2x --fop (useful toolchain on Windows)
 asciidoctor-pdf (The lightest-weight toolchain on Windows and lovely
 output but doesn't yet support images so it's still in alpha dev)

 So these were the toolchains I was going to support along with
 whatever Marco has done in his Makefiles up til now.

 Is there any other toolchain people are already using for either HTML
 or PDF output from asciidoc that they want supported or just want to
 recommend?

 Best Regards,

 Brian.


 Sorry, I was absent for some time... I've pushed to github several
 commits just now to finalize the cmake stuff...

 Where on github? I can't find it.


Hi Nick,

Here's Alexander's repo:

https://github.com/Fat-Zer/kicad-doc

Best Regards,

Brian.

___
Mailing list: https://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] Build options for asciidoc documentation

[Brian Sidebotham]

On 14 February 2015 at 16:43, Fat-Zer fatz...@gmail.com wrote:
 2015-02-13 14:17 GMT+03:00 Brian Sidebotham brian.sidebot...@gmail.com:
 Hi Guys,

 I was going to start the CMake stuff soon for the asciidoc
 documentation, but I'd like to know what toolchains people want to
 support. I'll start a Github repo and we can get stuck in. I'll try
 and base it on Fat-Zer's starting point where possible.

 HTML can be done via:

 asciidoc (python)
 asciidoctor (ruby)

 PDF can be done via:

 a2x
 a2x --fop (useful toolchain on Windows)
 asciidoctor-pdf (The lightest-weight toolchain on Windows and lovely
 output but doesn't yet support images so it's still in alpha dev)

 So these were the toolchains I was going to support along with
 whatever Marco has done in his Makefiles up til now.

 Is there any other toolchain people are already using for either HTML
 or PDF output from asciidoc that they want supported or just want to
 recommend?

 Best Regards,

 Brian.


 Sorry, I was absent for some time... I've pushed to github several
 commits just now to finalize the cmake stuff...
 IMHO now it can be considered as a full-featured build system (on
 linux). Including the updatepo functionality, configuration time tests
 etc.

 Please take a look if you haven't gone too far in your implementation...

Excellent, thank-you for the efforts. I'll fork from yours and just do
pull requests as necessary. We should be able to get something up and
running pretty quick. It's really just a bunch of tests for available
tools. I'll just concentrate on making sure the build system works for
Windows and isn't tied to Linux.

Thanks and Best Regards,

Brian.

___
Mailing list: https://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] wxPython version check

[Brian Sidebotham]

This commit broke KiCad-Winbuilder because of the same reason as
Garth. wxPython is not installed in the compilation environment. It
gets installed by the build system. We will be installing wxPython
locally to the KiCad installation on Windows, there's no other way to
distribute it.

I haven't had time to investigate the issue at all, I've just seen bug
reports against KiCad-Winbuilder to this effect. Most likely I can fix
it in KiCad-Winbuilder.

Best Regards,

Brian.


On 16 February 2015 at 01:39, Garth Corral gcor...@abode.com wrote:
 There is a variable that is already in use in CMakeLists.txt, 
 PYTHON_SITE_PACKAGE_PATH, that can be used to point to an alternate library 
 path.  I don’t know where this variable came from but I believe it was being 
 used by KicadOSXbuilder for this purpose at one point.

 This (or something) just needs to be prepended to the path of the python 
 performing the check.

 -set( _py_cmd import wxversion;print 
 wxversion.checkInstalled('${_wxpy_version}') )
 +set( _py_cmd import sys;sys.path.insert(0, 
 \${PYTHON_SITE_PACKAGE_PATH}\);import wxversion;print 
 wxversion.checkInstalled('${_wxpy_version}') )

 This works for me but if anyones sees an issue with this please speak up.  If 
 I got the quoting right then an unset PYTHON_SITE_PACKAGE_PATH would simply 
 prepend an empty path and search the default sys.path as usual.

 Garth


 On Feb 15, 2015, at 4:55 PM, Wayne Stambaugh stambau...@gmail.com wrote:

 On 2/15/2015 7:42 PM, Garth Corral wrote:
 I’m pretty sure you do not understand what I’m saying.

 Perhaps you are right.  To better understand how you would use CMake to
 ensure the the correct version of wxPython is somewhere on you system
 and gets installed along with KiCad, please modify CMakeList.txt and
 send me a patch.  Maybe then I will understand how you would solve the
 problem.  Ignoring wxPython as a build dependency is not an option and
 neither is the download_foo ugliness that we currently have.  That
 should be moved to a higher level outside of the kicad source like
 kicad-winbuilder.



 On Feb 15, 2015, at 4:41 PM, Wayne Stambaugh stambau...@gmail.com wrote:

 On 2/15/2015 7:27 PM, Garth Corral wrote:
 I think perhaps we’re having a miscommunication.  I don’t think it’s
 thin ice at all to build a version of a dependency and then pointing my
 kicad build at it.  I think it’s more of an issue to assume that
 whatever is installed on your system is the right thing.  What if I
 needed different versions of wxWidgets for other developement work and
 also wanted to build kicad with a different version?  It seems perfectly
 reasonable to build wxPython specifically for kicad.

 It is.  I do it all the time.  I build and install the latest versions
 wxPython, wxWidgets, Boost, etc. and set up my build environment to
 build kicad against these custom builds without touching my default
 system configuration.  The key action is the install and configure part.
 Just building the correct version of a dependency is not enough.


 I also think that the build time and runtime behavior are being
 conflated.  There is nothing other than the version check that requires
 wxPython to ‘run’ at build time.  Prior to this it was enough to build
 it and put everything int the right place and then tell the python
 interpreter where to look a runtime.  At least that’s what’s been
 happening all along on OS X.

 This has been happening on all platform all along and it has bitten
 other devs because their wxWidgets and wxPythons version did not match
 causing pcbnew to crash.  There was even a bug report filed against it.
 That is why the change was made.


 This version check just assumes that it will be instaled on the system,
 and I think that’s wrong.

 That's exactly what build configuration tools like CMake and autotools
 are designed for not just creating Makefiles.  Why would you even
 attempt to build any software if the prerequisites cannot be found on
 your system?  How would you even know if the software was correctly
 built?  You have been doing this manually except in the wrong order.


 Garth

 On Feb 15, 2015, at 4:16 PM, Wayne Stambaugh stambau...@gmail.com
 mailto:stambau...@gmail.com wrote:

 On 2/15/2015 7:06 PM, Garth Corral wrote:
 Well, yes, you’ve sort of explained the problem.  Unless wxPython is
 on the library path or using PYTHONPATH it isn’t going to work, and I
 don’t have wxPython installed on my system for any other purpose.
 So, invoking the system python as is done in the version check isn’t
 going to work without first pointing it to a path that contains the
 wxPython library.

 I’ve been building wxPython as part of my kicad builds and passing
 -DPYTHON_SITE_PACKAGE_PATH to cmake with the built wxPython library.
 Up to now this has worked for me.

 This should have never worked in the first place.  Would you expect
 kicad to build if a valid version of wxWidgets or Boost could not be
 found?  The build configuration 

[Kicad-developers] Build options for asciidoc documentation

[Brian Sidebotham]

Hi Guys,

I was going to start the CMake stuff soon for the asciidoc
documentation, but I'd like to know what toolchains people want to
support. I'll start a Github repo and we can get stuck in. I'll try
and base it on Fat-Zer's starting point where possible.

HTML can be done via:

asciidoc (python)
asciidoctor (ruby)

PDF can be done via:

a2x
a2x --fop (useful toolchain on Windows)
asciidoctor-pdf (The lightest-weight toolchain on Windows and lovely
output but doesn't yet support images so it's still in alpha dev)

So these were the toolchains I was going to support along with
whatever Marco has done in his Makefiles up til now.

Is there any other toolchain people are already using for either HTML
or PDF output from asciidoc that they want supported or just want to
recommend?

Best Regards,

Brian.

___
Mailing list: https://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] on documentation format ...

[Brian Sidebotham]

On 9 February 2015 at 11:01, Marco Ciampa ciam...@libero.it wrote:
 On Mon, Feb 09, 2015 at 10:09:04AM +, Brian Sidebotham wrote:
 On 7 February 2015 at 00:09, Marco Ciampa ciam...@libero.it wrote:
  On Sat, Feb 07, 2015 at 09:56:36AM +1100, Cirilo Bernardo wrote:
  What a nuisance that po4a does not recognize include. Maybe we should
  submit a patch to po4a?
 
  That would be the best thing to do.
 
  Otherwise my own preference would be to continue to use individual text
  files for chapters and to use other tools to glue them together before
  invoking asciidoc.
 
  I think that that would resolve the problem in the meantime that po4a devs
  patch the program.
 
  That would be the simpler thing to do, but we could have to introduce the
  convention of, for example, call the docs with include directive in it
  docname-master.adoc to obtain a fusion of
  docname_master.adoc+docname_chapter_01.adoc+docname_chapter_02.adoc...
  into -docname.adoc
 
  nevermind... I've already resolved with some makefile+scripting+sed magic
  :-) pushing it in a few minutes...
 
  We just have to follow the convention of calling the chapters
 
  DOCNAME_chapter_NN.adoc
 
  etc. as we already do.
 
  UNIX systems usually have several tools installed
  which can do the job of stringing the files together (even most shell
  environments have such built-in facilities). MinGW/MSys would also have
  such facilities.
 
  sed you mean?

 We definitely won't be using sed,

 Why not? Sed is nearly ubiquitous in the Unix environment...

 so don't worry too much about the building of the docs.

 I find that building the docs is useful to check the results...

 We don't need sed 'foo' or anything as we have
 CMake and it can do everything we need *cross platform*.

 We already settled for not caring too much for the doc building *cross
 platform* since actually there is no (even using sphinx) tool able to
 build docs *cross platform*. This is due to the fact that the majority of
 the tools use docbook as an intemediate format, that use xml stylesheets
 transformations, latex and other tricks to produce pdf and epub.

No, as a project we have not decided this, or if we did, I missed it
so please point me to the decision. The CMake build system must be
cross-platform and I'm sure has been specified in several other
emails. As always, email is a poor communication tool!

 CMake can read files into variables and it can process configure
 files[1] which can produce any intermediate file we require for
 processing.

 ok but I am not using and I am not able to use cmake anyway. I will try
 to port all the docs into this new format. When the port will be complete
 cmake people can (if they will) step in. I do not mean to be rude, mind
 me, just keep on discussing since I am not sure to see your point and
 that is probably my fault anyway...

 Personally I really dislike documentation that's chopped up into
 separate pages,

 not pages, chapters. So for this point we have find an agreement.
 See below...[XX]

Each chapter is a page...

 the old CMake documentation is much better than the
 new (presumably Sphinx generated) documentation for me.

 I do not have access to the CMake docs, I do not know and I cannot adjudicate.

I included them in a reference and if you have access to the web you
have access to the CMake docs!?

 One search of
 the page always results in me getting results, whereas it doesn't in
 the newly separated docs.

 Uhm that could be really a point to unite all the docs into one big file
 but perhaps it can be circunvented using the trick to unite all the docs
 into one big format before compiling... [XX] I am sure I am not the
 onlyone that find handier to have the big docs separated into chapters
 ... that could really kill two birds with one stone...

 I'll start the CMake and will try and make use of Fat-Zer's starting
 point. We have to test for a lot of features though to make it easy
 for documentation builders.

 do you have a git report to follow your work?

No not yet, because as I said, I will start the work... I will let you
know when I have a repo together...

 I assume that translators will simply use something like poedit which
 they'll be used to on the po files, is that right?

 right

 So really, unless they're keen to see the built output,
 the documentation build system shouldn't really trip them up anyway.

 well, seeing the output finished *before* committing the work is a really
 *plus* that I am not willing to renounce without a very good reason.

I am not suggesting that they *cannot* see it, I'm just saying that to
translate the documentation you don't necessarily *have* to go through
the build process, you can just edit the po files, and send a
patch/commit/pull request.

Thank-you for all your work on the text format documentation!

Best Regards,

Brian.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers

Re: [Kicad-developers] on documentation format ...

[Brian Sidebotham]

On 7 February 2015 at 00:09, Marco Ciampa ciam...@libero.it wrote:
 On Sat, Feb 07, 2015 at 09:56:36AM +1100, Cirilo Bernardo wrote:
 What a nuisance that po4a does not recognize include. Maybe we should
 submit a patch to po4a?

 That would be the best thing to do.

 Otherwise my own preference would be to continue to use individual text
 files for chapters and to use other tools to glue them together before
 invoking asciidoc.

 I think that that would resolve the problem in the meantime that po4a devs
 patch the program.

 That would be the simpler thing to do, but we could have to introduce the
 convention of, for example, call the docs with include directive in it
 docname-master.adoc to obtain a fusion of
 docname_master.adoc+docname_chapter_01.adoc+docname_chapter_02.adoc...
 into -docname.adoc

 nevermind... I've already resolved with some makefile+scripting+sed magic
 :-) pushing it in a few minutes...

 We just have to follow the convention of calling the chapters

 DOCNAME_chapter_NN.adoc

 etc. as we already do.

 UNIX systems usually have several tools installed
 which can do the job of stringing the files together (even most shell
 environments have such built-in facilities). MinGW/MSys would also have
 such facilities.

 sed you mean?


We definitely won't be using sed, so don't worry too much about the
building of the docs. We don't need sed 'foo' or anything as we have
CMake and it can do everything we need *cross platform*.

CMake can read files into variables and it can process configure
files[1] which can produce any intermediate file we require for
processing.

Personally I really dislike documentation that's chopped up into
separate pages, the old CMake documentation is much better than the
new (presumably Sphinx generated) documentation for me. One search of
the page always results in me getting results, whereas it doesn't in
the newly separated docs.

I'll start the CMake and will try and make use of Fat-Zer's starting
point. We have to test for a lot of features though to make it easy
for documentation builders.

I assume that translators will simply use something like poedit which
they'll be used to on the po files, is that right? So really, unless
they're keen to see the built output, the documentation build system
shouldn't really trip them up anyway. Hopefully we'll get CI building
of the docs and an automatic upload of at least one format to the web.

[1] http://www.cmake.org/cmake/help/v2.8.12/cmake.html#command:configure_file

Best Regards,

Brian.

___
Mailing list: https://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] Documentation format is AsciiDoc

[Brian Sidebotham]

On 9 February 2015 at 12:46, Brian Sidebotham
brian.sidebot...@gmail.com wrote:
 I didn't see an /official/ announcement so I wanted to just put it out
 there clearly, that AsciiDoc is the chosen format for KiCad's
 documentation (user manuals and the like).

 More information about asciidoc can be is available from the asciidoc
 homepage: http://www.methods.co.nz/asciidoc/

Jeez, I should take more time to proof-read emails!

More information about asciidoc is available from the asciidoc
homepage: http://www.methods.co.nz/asciidoc/

Best Regards,

Brian.

___
Mailing list: https://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] Documentation format is AsciiDoc

[Brian Sidebotham]

I didn't see an /official/ announcement so I wanted to just put it out
there clearly, that AsciiDoc is the chosen format for KiCad's
documentation (user manuals and the like).

More information about asciidoc can be is available from the asciidoc
homepage: http://www.methods.co.nz/asciidoc/

..and also see the more active asciidoctor implementation which is
written in Ruby and is providing things like direct PDF compilation of
asciidoc documents: http://asciidoctor.org/

NOTE: asciidoctor-pdf is currently considered alpha stage.

Best Regards,

Brian.

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

[Brian Sidebotham]

On 5 February 2015 at 10:03, Fat-Zer fatz...@gmail.com wrote:
 2015-02-04 19:52 GMT+03:00 Wayne Stambaugh stambau...@gmail.com:

 CMake should be used as the build configuration tool which is used to
 verify all of the required tools are installed on the system and
 automatically generate the appropriate Makefiles. CMake files would go
 in the kicad-doc repo and replace the current Makefiles.

 It would be nice if everything was in one place. That may be a goal for
 the distant future. For now, we have more important issues to worry about.

 Hi, I've done some cmake macro scripting for building asciidoc based
 on Marco's repository some time ago:
 https://github.com/Fat-Zer/kicad-doc
 It's ready to use for generate output in several formats like docbook,
 pdf, html and other.
 But, by the word, it doesn't check some special additional
 dependencies for specific formats... may be I'll add a test if
 specified format may be build in future...

 I've gonna to report it after I'll add some macro to update the *.po
 files but have not finished it yet...

Hi Fat-Zer,

I cannot see any CMakeLists.txt in that repo, am I missing something?

Best Regards,

Brian.

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

[Brian Sidebotham]

On 5 February 2015 at 10:54, Miguel Ángel Ajo majop...@redhat.com wrote:
 https://github.com/Fat-Zer/kicad-doc/tree/cmake

 It’s in a separate branch :-)

 Miguel Ángel Ajo

Ah, I was missing something! lol.

Thanks Miguel...

Best Regards,

Brian.

___
Mailing list: https://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 pythonic scripting API for pcbnew

[Brian Sidebotham]

On 15 January 2015 at 10:20, Miguel Ángel Ajo majop...@redhat.com wrote:
 Yesterday I wrote a proposal for discussion here:

 http://pads.kicad-pcb.org/p/kicad-scripting-layer  (please write your name
 for your color
 using the top right icon, so what you write can be identified to you).

 I tried not to look too much into the original Piers proposal,
 to do a true top-down design (“how do I like to interact with kicad
 objects?”)

 In the end, it looks quite much like Piers proposal, just with the
 difference
 of Point/Size objects receiving the unit.

 I was trying to be as pythonic as possible avoiding set_/get_ methods,
 and instead rely on attributes and implicit setters/getters.

 The listed options are not exclusive, just different ways of doing the same.

 Please feel free to write about other use cases, or copy, paste, then modify
 my blocks
 to provide different possible interactions.

 Best,
 Miguel Ángel.

 Miguel Ángel Ajo

Hi Miguel,

I thought I'd add my thoughts here instead of changing what others have done.

I see that someone doesn't like the Point( 10, 10, unit=MM ) paradime
for creating a 2D vector.

Personally, I prefer that construct compared to the proposed point_mm(
10, 10 ) by quite a long way.

But, it's of course a pain to always use unit=MM. Generally we know
the units we're going to work with when we start with pcbnew scripting
so it would be good to be able to do something like
pcbnew.default_units = MM somewhere near the start of the script and
then all 2D vectors can be created without the unit=MM additional
argument, such as: Point( 10, 10 ) instead.

That would make a nicer interface in my opinion. I only had a chance
to have a quick look at it. Thanks for getting something together for
people to look at.

Best Regards,

Brian.

___
Mailing list: https://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] Adding .gitignore file.

[Brian Sidebotham]

On 6 January 2015 at 14:08, Wayne Stambaugh stambau...@gmail.com wrote:
 A bug report and patch has been submitted to add a .gitignore file to
 the repo.  I think it's a good idea to make life easier for our
 developers using git so I'm OK with committing the patch.  Before I do
 so, I want to make sure there are no objections.  Adding this patch does
 not mean we are moving to git any time soon so please refrain from the
 usual git fanfare that seems to happen every time git is mentioned.

 Thanks,

 Wayne


I think it's a really good idea to include it in the repo.

Best Regards,

Brian.

___
Mailing list: https://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: Setting OS X KISYSMOD value in bundle

[Brian Sidebotham]

On 8 January 2015 at 13:44, Wayne Stambaugh stambau...@gmail.com wrote:
 Fully defined paths can be used in the fp-lib-table if that is your
 preference.  Environment variable substitution is optional.  You are
 free to use any environment variable you want.  KISYSMOD is merely the
 variable name used for the default footprint library path.  I use
 KILCLMOD to point to the path of my custom footprint libraries.  I set
 these paths to the same disk partition and and path in both windows and
 linux so I'm always using the same footprint libraries when I'm
 developing on either platform.

I think it's clear that users of a GUI, and environment variables do
not mix well. Personally I like them as they offer me a lot of
flexibility and I can make scripts to set-up environments that are
useful to me, but I'm a developer and user.

I think the best enhancement we could do here is to have an editor for
expandable variables in kicad. That is, rather than KISYSMOD having to
be an environment variable (which most users appear to think of as a
bad disease!) it could instead be a variable set in the KiCad
settings. The variable in the KiCad settings with the same name taking
precedence, or vice-versa.

It's a simple key-value pair editor that means variables can be
defined in KiCad options through the GUI. This achieves the same thing
as environment variables without the stigma associated with them and
offers the interface for editing the values of those variables in the
GUI that they're associated with.

Add this to my to-do list if you think it's a reasonable idea. It
shouldn't take too long to do.

These variables would be saved to the kicad config. Of course, we
could also complicate things further in the future and have
per-project overrides for the variables too if necessary. I think
something has to be done before the stable release so we're not
swamped with support questions about this.

Best Regards,

Brian.

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

[Brian Sidebotham]

Hi Guys,

Sorry I've been AWOL for so long. The new year has been extremely
hectic for me. I hope everyone had a good new year.

I've tried to fit FOSDEM into my schedule, but it would be flying out
early Saturday morning and flying back late Sunday and then back to
work on Monday which is not something I can fit in right now I'm
afraid. I'm so sorry not to be able to make it. I hope you all get to
meet and discuss all the issues while you're over there.

I'm sure the presentations will go fine, but good luck with them anyway.

I've already written FOSDEM 2016 into our calendar though, so I'll
definitely be there for that one. I missed last year too! :(

Best Regards,

Brian.

On 5 January 2015 at 10:38, Maciej Sumiński maciej.sumin...@cern.ch wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Hi Miguel,

 There is a small group from CERN that arrives on Friday evening. We
 have already booked places at La Madeleine Hotel (most of us, I think).
 Finally we are going to meet people who have contributed so much to
 the project!

 See you there,
 Orson

 On 01/02/2015 11:57 AM, Miguel Angel wrote:
 Hi, I was planning over going to FOSDEM this year.

 Is anybody going?, if so, can I ask where will you be staying?
 (thinking of kicad-breakfasts ;) ),

 I had a look over nearby hotels/hostels and I see a few
 interesting options.


 Best regards, Miguel Ángel.

 --- irc: ajo / mangelajo Miguel Angel Ajo Pelayo +34 636 52 25 69
 skype: ajoajoajo



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


 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBCAAGBQJUqmmiAAoJEBRwGu1hpbJ1iDwH/jB3KJxJnT3HsJaYqzlZcW4V
 9X0yPlaTe1+zHUJJ8ZwHCB7SoXuxoCny+mqO3TMKES6OQ9saLFwL+kUJ6iYADcJx
 9fJtcnL1BDiZu3H88uO/NZ04en5q9XDuKaXLi4K88gxXI4p9VZVB5i2uXrQw5zAM
 USJcQjuwbHHYEj0P9d7Ifke58vff8opiaz+wMvw6XH5MrV5Rt8Mmfvtq9HUtbIHJ
 onWMX3/oRYIC1LVLu/c4kXWfA7Qm31NpI/GG1/S3ImbXiQbF5quuwky6aZJz2dcY
 EY34GwylkY0dSCWdOZodUMIG7BQg28olTzCm6jNJ+bkM62w3T2BsFsSykPI5IqU=
 =LlCM
 -END PGP SIGNATURE-

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

___
Mailing list: https://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] emacs switches to Git

[Brian Sidebotham]

Here's my musing on the subject ( which we'll have to visit after a
stable release ):

Firstly, the version control system - any distributed system is fine
really for me. bzr is not dead - it works. I find git a pain on the
command line, but it's as powerful as it is confusing to use - it's
just another learning curve. Changing VCS doesn't really give us much
gain or loss as far as I can see.

As I remember, the last change was more moving to Launchpad from
Sourceforge. That made sense, at the time Launchpad was awesome, the
ability to browse the code repository and generate html diff views in
Launchpad was amazing and Sourceforge couldn't offer anything like the
functionality. Launchpad also came with good issue tracking.

It appears we're thinking that Launchpad is open and free software. I
disagree with that because of pages like this:
https://bugs.launchpad.net/launchpad/+bug/786212

We could never transition to our own hosted version because it's nigh
on impossible to setup your own.

We also use Confluence on kicad-pcb.org - it's not particularly nice
tbh. These days a bootstrap style site for the project works better
really. But someone else is providing the horse power for that site
and it's their chosen platform. Thanks very much to them for getting
on with it and providing us with something! My available time these
days is approximating 0!.

I've contributed to a couple of small projects recently on Github to
see what the usability is like and it's absolutely incredible! I'd be
hard pushed to find anything that didn't work as it should. Pull
requests were a joy to use and extremely interactive without any
effort. I think it was a record time between generating a request and
the code being in the project. You're able to converse on there very
easily with nothing seemingly getting in your way, cross referencing
commits, branches and pretty much anything is possible without effort.

At the moment I think that not being on Github is costing us a large
developer audience. However, I also appreciate the pain it would be to
make the switch!!

Best Regards,

Brian.

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

[Brian Sidebotham]

On 4 November 2014 15:30, Milan Horák stran...@tiscali.cz wrote:
 Hi,

 IMHO the NSIS installer is already available as I am using it to make
 Windows packages on http://kicad.nosoftware.cz

 Or am I missing something here?

 Milan


No not at all. Sounds like Jean-Pierre has been keeping it much more
up-to-date than I thought. So props to Jean-Pierre! :D

Best Regards,

Brian.

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

[Brian Sidebotham]

On 4 November 2014 16:57, Milan Horák stran...@tiscali.cz wrote:
 Hi,

 I am using the NSIS script originating from the sources. Before compiling I
 just change date and revision and run it.

 How can I find out if it includes Python scripting support?

 Milan


I downloaded BZR5228 install and tested and python scripting is
included. So looks like everything is good. I thought we had all that
packaging stuff still to do for Windows! Excellent.

Best Regards,

Brian.

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

Re: [Kicad-developers] [PATCH] pcbnew export position file

[Brian Sidebotham]

Hi Wayne,

It was on tonights list (for me that's around 6~7hrs from now). If
you've got time, by all means put it through now, that would be great.

Best Regards,

Brian.

On 31 October 2014 13:59, Wayne Stambaugh stambau...@verizon.net wrote:
 On 10/29/2014 8:47 AM, Brian Sidebotham wrote:
 On 29 October 2014 09:15, Michal Jahelka michal.jahe...@pavelek.cz wrote:
 Hello,

 I found small problem when generating position file. It was good before
 complete library name was used. It is shorted, and it is mainly impossible
 to understand which package has any footprint - there is mainly only part of
 library name. for example:

 # RefVal  Package PosX   PosYRot
 Side
 C5   1u   Capacitor-sm_cap   -0.1800-1.2100 270.0
 F.Cu
 C8   100u/6.3VB   Capacitor-sm_cap   -0.1800-1.0300 180.0
 F.Cu
 C9   100n Capacitor-sm_cap   -0.1000 0.2150 180.0
 F.Cu
 C12  100n Capacitor-sm_cap   -0.0250 0.9550   0.0
 F.Cu
 C13  100n Capacitor-sm_cap0.3200 0.8050  90.0
 F.Cu
 C14  100n Capacitor-sm_cap0.4700 0.5100 270.0
 F.Cu
 C16  100n Capacitor-sm_cap   -0.4600 1.2600   0.0
 F.Cu
 C17  T22u/10V Capacitor-sm_cap0.1000 0.2400   0.0
 F.Cu
 C18  1u   Capacitor-sm_cap   -0.1250 1.0600 180.0
 F.Cu
 C19  100n Capacitor-sm_cap   -0.4500-0.8150 180.0
 F.Cu
 Q1   IRLML0030libcms:SOT23GDS 0.0950-0.6950 180.0
 F.Cu
 U1   LP2951   Vlastni-SM-IC:SO   -0.4000-1.2100  90.0
 F.Cu

 So after patch is visible only package, without library (I think that for
 machine component placing is library name not important).

 # RefVal  Package PosX   PosYRot
 Side
 C5   1u   c_1206 -0.1800-1.2100 270.0
 F.Cu
 C8   100u/6.3VB   c_tant_B   -0.1800-1.0300 180.0
 F.Cu
 C9   100n c_0805 -0.1000 0.2150 180.0
 F.Cu
 C12  100n c_0805 -0.0250 0.9550   0.0
 F.Cu
 C13  100n c_0805  0.3200 0.8050  90.0
 F.Cu
 C14  100n c_0805  0.4700 0.5100 270.0
 F.Cu
 C16  100n c_0805 -0.4600 1.2600   0.0
 F.Cu
 C17  T22u/10V c_tant_B0.1000 0.2400   0.0
 F.Cu
 C18  1u   c_1206 -0.1250 1.0600 180.0
 F.Cu
 C19  100n c_0805 -0.4500-0.8150 180.0
 F.Cu
 Q1   IRLML0030SOT23GDS0.0950-0.6950 180.0
 F.Cu
 U1   LP2951   SOG8   -0.4000-1.2100  90.0
 F.Cu

 Michal Jahelka


 I agree. The package is what matters, the library that comes from is
 unknown to most people anyway. It is only a hint as to what to expect.
 The start of the library name doesn't really give you any hint at all.

 Perhaps some people aggregate all of the different Packages and
 Val combinations there are to roughly determine the number of reels
 they'll need to use on the machine.

 If no-one objects I'll commit the change for you.

 Best Regards,

 Brian.


 Brian,

 Are you going to commit this patch soon?  I think it makes sense not to
 include the library nickname in the position file.  If not, I have some
 time to take care of it.

 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

Re: [Kicad-developers] [PATCH] pcbnew export position file

[Brian Sidebotham]

Committed in 5246.

Thanks for your contribution Michal!

Best Regards,

Brian.

On 31 October 2014 18:00, Wayne Stambaugh stambau...@verizon.net wrote:
 Hey Brian,

 Go ahead and commit this.  I'm just about ready to pull the trigger on
 the changes required to build the full MSYS2 package.

 Thanks,

 Wayne

 On 10/31/2014 10:25 AM, Brian Sidebotham wrote:
 Hi Wayne,

 It was on tonights list (for me that's around 6~7hrs from now). If
 you've got time, by all means put it through now, that would be great.

 Best Regards,

 Brian.

 On 31 October 2014 13:59, Wayne Stambaugh stambau...@verizon.net wrote:
 On 10/29/2014 8:47 AM, Brian Sidebotham wrote:
 On 29 October 2014 09:15, Michal Jahelka michal.jahe...@pavelek.cz wrote:
 Hello,

 I found small problem when generating position file. It was good before
 complete library name was used. It is shorted, and it is mainly impossible
 to understand which package has any footprint - there is mainly only part 
 of
 library name. for example:

 # RefVal  Package PosX   PosYRot
 Side
 C5   1u   Capacitor-sm_cap   -0.1800-1.2100 270.0
 F.Cu
 C8   100u/6.3VB   Capacitor-sm_cap   -0.1800-1.0300 180.0
 F.Cu
 C9   100n Capacitor-sm_cap   -0.1000 0.2150 180.0
 F.Cu
 C12  100n Capacitor-sm_cap   -0.0250 0.9550   0.0
 F.Cu
 C13  100n Capacitor-sm_cap0.3200 0.8050  90.0
 F.Cu
 C14  100n Capacitor-sm_cap0.4700 0.5100 270.0
 F.Cu
 C16  100n Capacitor-sm_cap   -0.4600 1.2600   0.0
 F.Cu
 C17  T22u/10V Capacitor-sm_cap0.1000 0.2400   0.0
 F.Cu
 C18  1u   Capacitor-sm_cap   -0.1250 1.0600 180.0
 F.Cu
 C19  100n Capacitor-sm_cap   -0.4500-0.8150 180.0
 F.Cu
 Q1   IRLML0030libcms:SOT23GDS 0.0950-0.6950 180.0
 F.Cu
 U1   LP2951   Vlastni-SM-IC:SO   -0.4000-1.2100  90.0
 F.Cu

 So after patch is visible only package, without library (I think that for
 machine component placing is library name not important).

 # RefVal  Package PosX   PosYRot
 Side
 C5   1u   c_1206 -0.1800-1.2100 270.0
 F.Cu
 C8   100u/6.3VB   c_tant_B   -0.1800-1.0300 180.0
 F.Cu
 C9   100n c_0805 -0.1000 0.2150 180.0
 F.Cu
 C12  100n c_0805 -0.0250 0.9550   0.0
 F.Cu
 C13  100n c_0805  0.3200 0.8050  90.0
 F.Cu
 C14  100n c_0805  0.4700 0.5100 270.0
 F.Cu
 C16  100n c_0805 -0.4600 1.2600   0.0
 F.Cu
 C17  T22u/10V c_tant_B0.1000 0.2400   0.0
 F.Cu
 C18  1u   c_1206 -0.1250 1.0600 180.0
 F.Cu
 C19  100n c_0805 -0.4500-0.8150 180.0
 F.Cu
 Q1   IRLML0030SOT23GDS0.0950-0.6950 180.0
 F.Cu
 U1   LP2951   SOG8   -0.4000-1.2100  90.0
 F.Cu

 Michal Jahelka


 I agree. The package is what matters, the library that comes from is
 unknown to most people anyway. It is only a hint as to what to expect.
 The start of the library name doesn't really give you any hint at all.

 Perhaps some people aggregate all of the different Packages and
 Val combinations there are to roughly determine the number of reels
 they'll need to use on the machine.

 If no-one objects I'll commit the change for you.

 Best Regards,

 Brian.


 Brian,

 Are you going to commit this patch soon?  I think it makes sense not to
 include the library nickname in the position file.  If not, I have some
 time to take care of it.

 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] problems running kicad-install.sh

[Brian Sidebotham]

On 29 October 2014 12:18, Wayne Stambaugh stambau...@verizon.net wrote:
 On 10/28/2014 4:51 PM, Marco Ciampa wrote:
 On Sun, Oct 26, 2014 at 10:59:20PM -0700, Jake wrote:
 [...]
 So i deleted the folder entirely with rm -rf ~/kicad_sources/kicad-lib.bzr/

 and when i ran the script again, now it seems to be working.

 i don't know anything about how bzr works, i am just competent with
 git, so hopefully some bash scripting and bzr experts can think of a
 way to restructure the install script to more consistently deal with
 incomplete installations.  I think that a less intrepid user than me
 (imagine!) would either have to delete all of ~/kicad_sources and
 start over, or give up entirely.

 please let me know if i should post this problem in the bugtracker
 or something else to make it easier to deal with, or if i have done
 it right.

 Bazaar is virtually dead. Its userbase decrease day by day.
 There are some bugs in it that presumably will never be fixed.

 For example, and this seems to be this case, if you stop a bzr up
 command abruptly, chances are that it will not be able to recover by
 himself, and you have to delete all and restart downloading afresh.

 I keep on thinking that a git migration of all kicad project repos should
 be considered for sometime in the (near?) future...

 Not until after the next stable release.  Then we can discuss the matter
 further.  I personally don't have a preference other than I don't want
 to be guy that has to do all of the work.  I was around when we made the
 switch from subversion/sourceforge to bazaar/launchpad.  It was not a
 trivial amount of work.


Also, this work is now compounded by the amount of bzr used during the
build process in general. Several repos are created on-the-fly and
patched and so on and so forth.

I like git and particularly git patchsets for linux kernel work. I
dislike git in most other circumstances as it just appears to
obfuscate standard version control features in my opinion. However,
that could be down to lack of experience with it really.

Github however is something I really like.

Best Regards,

Brian.

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

Re: [Kicad-developers] [PATCH] pcbnew export position file

[Brian Sidebotham]

On 29 October 2014 09:15, Michal Jahelka michal.jahe...@pavelek.cz wrote:
 Hello,

 I found small problem when generating position file. It was good before
 complete library name was used. It is shorted, and it is mainly impossible
 to understand which package has any footprint - there is mainly only part of
 library name. for example:

 # RefVal  Package PosX   PosYRot
 Side
 C5   1u   Capacitor-sm_cap   -0.1800-1.2100 270.0
 F.Cu
 C8   100u/6.3VB   Capacitor-sm_cap   -0.1800-1.0300 180.0
 F.Cu
 C9   100n Capacitor-sm_cap   -0.1000 0.2150 180.0
 F.Cu
 C12  100n Capacitor-sm_cap   -0.0250 0.9550   0.0
 F.Cu
 C13  100n Capacitor-sm_cap0.3200 0.8050  90.0
 F.Cu
 C14  100n Capacitor-sm_cap0.4700 0.5100 270.0
 F.Cu
 C16  100n Capacitor-sm_cap   -0.4600 1.2600   0.0
 F.Cu
 C17  T22u/10V Capacitor-sm_cap0.1000 0.2400   0.0
 F.Cu
 C18  1u   Capacitor-sm_cap   -0.1250 1.0600 180.0
 F.Cu
 C19  100n Capacitor-sm_cap   -0.4500-0.8150 180.0
 F.Cu
 Q1   IRLML0030libcms:SOT23GDS 0.0950-0.6950 180.0
 F.Cu
 U1   LP2951   Vlastni-SM-IC:SO   -0.4000-1.2100  90.0
 F.Cu

 So after patch is visible only package, without library (I think that for
 machine component placing is library name not important).

 # RefVal  Package PosX   PosYRot
 Side
 C5   1u   c_1206 -0.1800-1.2100 270.0
 F.Cu
 C8   100u/6.3VB   c_tant_B   -0.1800-1.0300 180.0
 F.Cu
 C9   100n c_0805 -0.1000 0.2150 180.0
 F.Cu
 C12  100n c_0805 -0.0250 0.9550   0.0
 F.Cu
 C13  100n c_0805  0.3200 0.8050  90.0
 F.Cu
 C14  100n c_0805  0.4700 0.5100 270.0
 F.Cu
 C16  100n c_0805 -0.4600 1.2600   0.0
 F.Cu
 C17  T22u/10V c_tant_B0.1000 0.2400   0.0
 F.Cu
 C18  1u   c_1206 -0.1250 1.0600 180.0
 F.Cu
 C19  100n c_0805 -0.4500-0.8150 180.0
 F.Cu
 Q1   IRLML0030SOT23GDS0.0950-0.6950 180.0
 F.Cu
 U1   LP2951   SOG8   -0.4000-1.2100  90.0
 F.Cu

 Michal Jahelka


I agree. The package is what matters, the library that comes from is
unknown to most people anyway. It is only a hint as to what to expect.
The start of the library name doesn't really give you any hint at all.

Perhaps some people aggregate all of the different Packages and
Val combinations there are to roughly determine the number of reels
they'll need to use on the machine.

If no-one objects I'll commit the change for you.

Best Regards,

Brian.

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

[Brian Sidebotham]

On 24 October 2014 16:31, Wayne Stambaugh stambau...@verizon.net wrote:
 Brian,

 I restored the custom FindPythonLibs.cmake file.  I found an issue with
 the stock version when configuring on MSYS2.  I made some minor changes
 to it which should make it more robust when looking for mingw python
 builds.  Please test it out when you get a chance and let me know if you
 find any problems.

 Thanks,

 Wayne


Hi Wayne,

Thanks for doing that. I found just one issue in the find_path() used
to find the include file Python.h.

I've committed a change for it as it's trivial and this fixes
KiCad-Winbuilder again. Thanks for restoring the custom find, I'm glad
it now works on MSYS2.

I expect the other two PATH_SUFFIXES supplied to that find_path() are
wrong by the way, I've not removed them in case they are actually
correct, but generally the only suffixes searched should be the
include directories that contain the headers files.

Best Regards,

Brian.

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

[Brian Sidebotham]

On 25 October 2014 17:22, Wayne Stambaugh stambau...@verizon.net wrote:
 I've been working on packaging KiCad on MSYS2 with mingw64 and mingw32.
  I have everything building including the full Python scripting.
 Unfortunately our current install paths when building with mingw don't
 match up with the msys/mingw file structure.  The msys/mingw file
 structure is the same as linux except for the library binaries which get
 installed in the bin/ folder in order for the executable to be able to
 find the libraries.  I propose that we change our windows install paths
 to be the same as linux except for the kiface libraries.  Our path
 search code can be simplified since windows and linux have the same
 relative install paths.  Our windows install would look like

 # Path for executable and shared objects.
 ${CMAKE_INSTALL_PREFIX}/bin

 # Path for documentation.
 ${CMAKE_INSTALL_PREFIX}/share/kicad/doc

 # Path for demo projects.
 ${CMAKE_INSTALL_PREFIX}/share/kicad/demos

 # Path for project templates.
 ${CMAKE_INSTALL_PREFIX}/share/kicad/templates

 # Path for component libraries.
 ${CMAKE_INSTALL_PREFIX}/share/kicad/library

 # Path for plugings.
 ${CMAKE_INSTALL_PREFIX}/share/kicad/plugins

 # Path for data files.
 ${CMAKE_INSTALL_PREFIX}/share/kicad

 # Path for footprint library files when no GitHub.
 ${CMAKE_INSTALL_PREFIX}/share/kicad/modules

 # Path for 3D model libraries.
 ${CMAKE_INSTALL_PREFIX}/share/kicad/share/modules/packages3D

I presume this would be ${CMAKE_INSTALL_PREFIX}/share/kicad/modules/packages3D

I think both modules directories should be changed now to footprint.
We've made the decision to move to footprint, so let's give the user
an easier life by being consistent. We probably need the code to drop
back to the modules directory to maintain compatibility though.

Other than that, the paths all look sane to me.


 If no one objects to these changes, I will update our install paths
 accordingly and submit the kicad package build file to the msys2
 project.  Hopefully, soon you will be able to install msys2 and install
 kicad by running the `pacman -S`.

Sounds good.

I really don't want to get to a point where KiCad on Windows has MSYS
as a dependency. I have a pretty big dislike of MSYS myself.

I think we should start a new project. Something like
KiCad-Wininstaller or simiar, it doesn't really matter what it's
called. It's normal for the binary packages to be provided by separate
projects and not by the main project itself, it's not unusual.

I was hoping someone would step up and take KiCad-Winbuilder there,
really there's not much more to do for it other than globbing the
output into an installer. I believe that's pretty much what Milan has
been doing.

Once we have a lightweight stable release marked it'll make more sense
for someone to take on the Windows packaging role.

Best Regards,

Brian.

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

[Brian Sidebotham]

On 25 October 2014 15:52, Wayne Stambaugh stambau...@verizon.net wrote:
 Marco,

 Great work on the conversion analysis.  I finally go around to testing
 this and I have to say that I prefer the asciidoc format better than the
 markdown and rst formats for plain text readability.  I also could not
 convert the asciidoc format to pdf using your example.  I always get an
 error about dblatex failing even though I have it installed on my Debian
 partition.  None of the section headers or table of contents were
 converted so there would obviously be some hand work involved.  That's
 not a big deal for the cvpcb documentation but for all of the
 documentation there is a lot of work to do.  Windows support is iffy.
 Even though MSYS2 has an asciidoc package, the optional bits to create
 pdfs is missing so that is an issue.

 I guess the next steps are:

 * Make the final decision on the format.
 * Pick a VCS and a host server.  Obvious choices are bzr/launchpad
   and git/github.
 * Convert all of the documentation over to asciidoc.
 * Write CMake build configuration support to handle dependency
   checking, out building, translation file creation, and installation.
 * Create initial repo and let the document fixing begin.

 Any volunteers?

 Wayne

As I was pushing for us to make this move, and as I use asciidoc
almost everyday for documenting projects at work, you can count on me
to provide some horsepower.

We should decide on our output format too. I was thinking we'd
probably move to HTML output rather than PDF, but either is really
okay with me.

Best Regards,

Brian.

___
Mailing list: https://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] Proper python qa exit code

[Brian Sidebotham]

On 24 October 2014 21:17, Nick Østergaard oe.n...@gmail.com wrote:
 Hello

 Some background info:
 I was allowed by Ajo to play around on the Jenkins build server [1] to
 add automatic building of the doxygen documatation for the purpose of
 having it online and always up to date. I have dumped the links to
 theese three documentaions, the doxygen-docs, dev-docs and
 doxygen-python make targets on [2] under the Developer documentation
 section. That is probably not the best place to put them, but none the
 less where they are linked right now. I talked with Ajo about copying
 them to somewhere on dev.kicad-pcb.org to get a shorter and easier to
 remember URL.

 Now regarding the patch:
 After I got familiar with Jenkins I also made it actually build the
 whole kicad, not just _pcbnew as the kicad-qa job did. In that process
 I found that the python qa test script did not return anything if it
 actually found errors in the unittests, which means that the Jenkins
 server did not know it failed -- hence no warning to the devs. To fix
 this I have made the attached patch, which catches the number of
 errors from the unittest and if there are errors returns the exit code
 1, which will make Jenkins notice that the build failed. The error
 that was fixed in [5214] is not detected by Jenkins without this
 patch. So the according patch:

 Adds exit code to the qa test.py script if there are errors found in
 the qa unittests.

 Regards
 Nick Østergaard

 [1] http://ci.kicad-pcb.org/
 [2] http://www.kicad-pcb.org/display/KICAD/KiCad+Documentation
 [5214] 
 http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/5214


Thank-you very much Nick, Committed in 5223 with a very minor changes.

Best Regards,

Brian.

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

[Brian Sidebotham]

On 25 October 2014 22:29, Wayne Stambaugh stambau...@verizon.net wrote:
 On 10/25/2014 4:59 PM, Brian Sidebotham wrote:

 I expect the other two PATH_SUFFIXES supplied to that find_path() are
 wrong by the way, I've not removed them in case they are actually
 correct, but generally the only suffixes searched should be the
 include directories that contain the headers files.

 If you are using the native install of python with a mingw link library
 (it can be done but is a major headache) then the the paths python2.7
 and python27 could be the path to find the proper python.h path.  I
 didn't test this so my assumption may be incorrect.


That's right, they're in the PATHS list, however they are also in
PATH_SUFFIXES which I'm sure is not right because the include file's
always going to be under the include directory.

The documentation
http://www.cmake.org/cmake/help/v3.0/command/find_path.html says it
only searches PATHS and doesn't append anything, but we can be sure
(it works!) that actually it tries each item in PATHS and each item in
PATHS suffixed with each item in PATH_SUFFIXES.

Best Regards,

Brian.

___
Mailing list: https://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] parallel builds?

[Brian Sidebotham]

On 23 October 2014 00:28, Wayne Stambaugh stambau...@verizon.net wrote:
 Adam,

 I just committed the fix with my original patch along with a fix for the
 missing files generated by make_lexer() in r5216.  Hopefully, this
 solves the problem.

 Thanks,

 Wayne

Excellent work Wayne!

The duplicate specctra keywords lexer is what meant KiCad-Winbuilder
always had to use a single job as the first build pass and then move
to parallel jobs afterwards because otherwise you'd end up with a
malformed specctra keywords lexer.

So multiple issues are fixed with this commit! Thanks.

Best Regards,

Brian.

___
Mailing list: https://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 release version numbers.

[Brian Sidebotham]

On 21 October 2014 23:25, Wayne Stambaugh stambau...@verizon.net wrote:

 3.0.0 sounds good to me.

 Wayne

I'm good with the triplet, and any number sounds fine to me! :D

Best Regards,

Brian.

___
Mailing list: https://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] Updates to authors.txt

[Brian Sidebotham]

 On 21 October 2014 04:37, Andrew Zonenberg azonenb...@drawersteak.com wrote:
 Hi all,

 While browsing recent commits I saw some updates to authors.txt which
 prompted me to take a look at the file and noticed two minor issues.

 1) maintener (line 15) should be spelled maintainer
 2) Neither Cirillo Bernardo nor myself are listed as contributors.

 Thanks :)

 --
 Andrew Zonenberg
 PhD student, security group
 Computer Science Department
 Rensselaer Polytechnic Institute
 http://colossus.cs.rpi.edu/~azonenberg/


Added in BZR 5212.

Thanks for you contributions Andrew!

Best Regards,

Brian.

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

[Brian Sidebotham]

On 21 October 2014 22:58, Marco Ciampa ciam...@libero.it wrote:
 Hello,

 talking about the project of switching the KiCad documentation to an
 easier to maintain and translate format, after some experiments, (I know,
 I am slow ... I am not a real programmer) I have produced something
 to check.

 This is in effect something like an RFC: I need your comments,
 suggestions, improvements (and patches are welcome).

 I started writing an email, this:

 https://github.com/ciampix/kicad-doc/blob/master/doc/kicad-doc-doc.adoc

 it got bigger and bigger and it is not finished, but I though that it
 could be useful to publish it before being closed because I do not want
 to write it all alone.

 Along with this text there are two dirs in src: asciidoc and rest.
 Basically these folders contain the cvpcb manual converted into asciidoc
 and rest and the small example scripts to create docs into html/pdf/epub.

 The complete cycle is:

 (odt-)asciidoc/rest
 -translation extraction
 -(translation)
 -merge-nationalized pdf/html/epub

 The examples are in asciidoc and rest but the asciidoc toolchain is
 almost the same for markdown. I have reported some comments about
 txt2tags, textile and sisu but I do not have studied these tools enough
 to have a clear idea about.

 So I ask you to:

  - have a say about the work
  - try my examples
  - express your preferences about:

   a. the documentation text format
   b. the data organization of the manuals, in particular:
- file name/extension conventions
- source files folders,
- image folders
- makefiles/cmake configuration (I do not know anything about cmake...)
- any other thing

 If you have any doubt or problem about anything please express yourself.

 I do not think we are in a hurry so I think that we can our time to
 decide and clear out any quandary.

 When we will have decided the source text format we will start converting
 all the manuals. Please bear in mind that *anything written in a foreign
 language that is not strictly adherent to the english reference manual
 will have to be removed*.

 So, if you think that something you have written in a localized manual is
 not present in the reference, try to translate it in English for the
 inclusion in the reference: doing this may save your translation and give
 a hand to the whole project.

 PS: ... and please forgive my terrible English.

 --


 Marco Ciampa

Excellent work Marco, firstly your English is not terrible, my Italian is!

Thank-you for doing a thorough job in looking at the various tools
available and it's great to have the view of a translator looking from
the ease of internationalising a document properly as that's not an
easy task.

I've managed to read most of your document and everything looks sound
to me, I agree with your conclusions, but then I use asciidoc every
day of the week, so it's easy for me to agree with! At least, asciidoc
is not very intrusive into the text of the document, it is
light-weight.

I was worried that po4a was not available on Windows, but it appears
it's pretty easy to get going on windows. I'm sure the rest of the
toolchain is easy to get running on Windows. See some information here
with regards to po4a on windows:
http://ehc.ac/p/ourorgan/svn/754/tree//trunk/HOWTO-build-help-on-Windows

I'm excited for us to move to a text based documentation format as
soon as possible.

I imagine our workflow after we've decided on the markup source format
needs to be:

(1) Convert odt to text-based markup
(2) Get a document writer (could be a current dev(s)) to go through
the manuals and tidy up grammar, out-of-date screenshots, layout
issues, etc.
(3) Make sure the documentation build process is documented (which
you've already done an excellent job starting, thanks!!)
(4) Create the po files ready for translation and that should lead to
translators being able to start translating the new manuals.

The fact that everything, including images drops back to the master
English version if there's not a specific language version is
absolutely excellent.

Before reading your article I was pro-Markdown as the solution we
should use, but I am very convinced by your extensive work around the
translation of the documentation and I understand the limitations of
Markdown, so asciidoc is a fine conclusion to me.

Thanks again for the update and hard work!!

Best Regards,

Brian.

___
Mailing list: https://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] Updates to authors.txt

[Brian Sidebotham]

On 22 October 2014 11:11, Nick Østergaard oe.n...@gmail.com wrote:
 Hi

 I also think that Cirilo Bernardo should not be forgotten, he made
 great contributions especially in regard to the 3D tools.

 Nick


Oh, so sorry - that was mentioned in the original email!!

Will be there in a minute...

Best Regards,

Brian.

___
Mailing list: https://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] Updates to authors.txt

[Brian Sidebotham]

On 22 October 2014 11:22, Brian Sidebotham brian.sidebot...@gmail.com wrote:
 On 22 October 2014 11:11, Nick Østergaard oe.n...@gmail.com wrote:
 Hi

 I also think that Cirilo Bernardo should not be forgotten, he made
 great contributions especially in regard to the 3D tools.

 Nick


 Oh, so sorry - that was mentioned in the original email!!

 Will be there in a minute...

 Best Regards,

 Brian.

Done in 5213, Sorry Cirilo!

Best Regards,

Brian.

___
Mailing list: https://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] Incremental build speeds.

[Brian Sidebotham]

On 22 October 2014 14:01, Tim Hutt tdh...@gmail.com wrote:
 Hi,

 I'm trying to do some kicad development on windows. I initially downloaded 
 built it with kicad-winbuilder which went without a hitch. Kicad runs fine.

 However, if I perform a null-rebuild (i.e. I don't change anything and just
 run `make` again), it takes about 70 seconds to run. That's quite a while
 isn't it? My PC is pretty fast (quad core 3.3 GHz i5, 16GB RAM), so I
 wouldn't have expected it to take so long. Is this just a feature of cmake?

 Build output is below. How long does it take for you guys? Am I doing
 something wrong?

 Cheers,

 Tim

 -

 C:\Users\Tim\Local\kicad-winbuilder-3.4\build\Releasemingw32-make
 [  0%] Built target boost
 [ 30%] Built target bitmaps
 [ 30%] Built target lib-dependencies
 [ 38%] Built target common
 [ 38%] Generating headers containing GLSL source code
 Headers are up-to-date
 [ 38%] Built target shader_headers
 [ 39%] Built target gal
 [ 43%] Built target pcbcommon
 [ 44%] Built target 3d-viewer
 [ 44%] Built target polygon
 [ 45%] Built target pcad2kicadpcb
 [ 46%] Built target openssl
 [ 46%] Built target avhttp
 [ 46%] Built target github_plugin
 [ 47%] Built target cvpcb_kiface
 [ 47%] Built target cvpcb
 [ 57%] Built target eeschema_kiface
 [ 58%] Built target eeschema
 [ 61%] Built target gerbview_kiface
 [ 61%] Built target gerbview
 [ 61%] Built target lib_dxf
 [ 62%] Built target idf3
 [ 64%] Built target pnsrouter
 [ 79%] Built target _pcbnew
 [ 79%] Fixing swig_import_helper in Kicad scripting modules
 swig_import_helper fixed for
 C:/Users/Tim/Local/kicad-winbuilder-3.4/build/Relea
 se/pcbnew/pcbnew.py
 [ 79%] Built target FixSwigImportsModuleScripting
 [ 94%] Built target pcbnew_kiface
 [ 94%] Built target pcbnew
 [ 95%] Built target pl_editor_kiface
 [ 95%] Built target pl_editor
 [ 96%] Built target potrace
 [ 96%] Built target bitmap2component
 [ 98%] Built target pcb_calculator_kiface
 [ 98%] Built target pcb_calculator
 [100%] Built target kicad
 [100%] Built target dxf2idf
 [100%] Built target idf2vrml
 [100%] Built target idfcyl
 [100%] Built target idfrect


Hi Tim,

You can specify parallel jobs with make using the -j option. That will
speed things up for you.

gcc on Windows is slow however, it really does take much more time to
compile on Windows compared to Linux on the same hardware. You will
certainly get down to perhaps 15s using parallel jobs.

Best Regards,

Brian.

___
Mailing list: https://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] Fwd: Re: new documentation format

[Brian Sidebotham]

-- Forwarded message --
From: Brian Sidebotham brian.sidebot...@gmail.com
Date: 22 Oct 2014 22:50
Subject: Re: [Kicad-developers] new documentation format
To: Marco Ciampa ciam...@libero.it
Cc:


On 22 Oct 2014 22:02, Marco Ciampa ciam...@libero.it wrote:

 On Wed, Oct 22, 2014 at 05:57:22PM +0200, Kerusey Karyu wrote:
  To: kicad-developers
  From: Marco Ciampa
  Date: Tue, 21 Oct 2014 23:58:17 +0200
 
   If you have any doubt or problem about anything please
   express yourself.
  
 
  I consider that the use of formats to create documentation using
  translations in the form of translation database (.po files) will,
  despite the many advantages, also some disadvantages for translators.
 
  While the use of such forms of translations for the UI is quite
  comfortable, the use of that form for translating a continuous text
  (which is result of the train of thoughts) can be very uncomfortable
  for translators.
 
  Why? The main difficulty will be limited visibility of the logic of the
  text and its layout (indentation, spacing). There will be situations
  where we will need to translate a fragment out of context. I as a
  translator prefer also see more of the text to be able to, among
  others, eliminate repetition of words and the use of synonyms. My
  native language is very flexible in this topic.
 
  Taking also the specificity of translated texts, unfortunately, it is
  in so many cases impossible to translate word for word. Sometimes you
  have to break down complex sentence into two (or even three) sentences
  that the reader can easily assimilate them.
  By translating KiCad user manual I had to just do that many times.
  Sometimes adding something from each other to avoid ambiguity.
 
  So. That’s my (maybe wrong) doubts.

 Good point but I think that it is more a theoretical problem than a real
 one since such tools such as po4a, xml2po, etc. do not break paragraphs
 and in fact aggregate contiguous paragraphs. See for example the GIMP

Excellent, that was the answer I was hoping for! So long as that's true,
which I'm sure it should be, we should be on to a winner with the workflow.

Best Regards,

Brian.
___
Mailing list: https://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-winbuilder fails.

[Brian Sidebotham]

Kicad-Winbuilder was broke a few commits ago by removing some custom python
finding cmake module. I've not had the time to replace it with another
working version. I was hoping to replace it before it was removed.

Hopefully it should be fixed soon!

Best Regards,

Brian.
On 22 Oct 2014 21:30, Tim Hutt tdh...@gmail.com wrote:

 Hi, I have previously used kicad-winbuilder successfully, but I just tried
 it again (in a fresh directory) and get the error below. I tried it in a
 much shorter path too and it still fails (and it worked with that path
 before so I'm pretty sure it's not the path).

 Anyone have any ideas?

 Cheers,

 Tim

 

 C:\Users\Tim\Local\kicad-winbuilder-3.4make
 -- KiCad-Winbuilder V3.4
 CMake Warning at KiCadWinbuilder.cmake:182 (message):
   Your install path maybe too long to be able to successfully build KiCad.
   Try re-installing to a root directory if the build fails!


 -- Build type: Release
 -- Checking for environment problems
 -- Checking for installed Bazaar
 -- Checking for wxPython
 -- Downloading wxPython
 -- Decompressing wxPython
 -- Downloading Latest Library Archive...
 -- Checking out KiCad Documentation source (BZR head)
 You have not informed bzr of your Launchpad ID, and you must do this to
 write to Launchpad or access private data.  See bzr help launchpad-login.
 bzr: ERROR: No such file: '
 http://bazaar.launchpad.net/~kicad-developers/kicad/d
 oc/.bzr/repository/pack-names'
 ERRORChecking out the Documentation source!
 -- Checking for BZIP2
 -- Downloading BZIP2 Source
 -- Building BZIP2 Library
 -- Checking for GLEW
 -- Downloading
 You have not informed bzr of your Launchpad ID, and you must do this to
 write to Launchpad or access private data.  See bzr help launchpad-login.
 -- Building GLEW/s - Build phase:Apply phase:adding file 10/17
 -- GLEW build finished
 -- Checking for Cairo
 -- Downloading cairo-dev_1.10.2-2_win32.zip
 -- Decompressing Cairo
 -- Checking out KiCad source code (BZR head)
 You have not informed bzr of your Launchpad ID, and you must do this to
 write to Launchpad or access private data.  See bzr help launchpad-login.
 -- Cleaning PCBNEW Python files to ensure good build...e 50/604
 -- Using KiCad Options:
 -- -DKICAD_SCRIPTING=ON
 -- -DKICAD_SCRIPTING_MODULES=ON
 -- -DKICAD_SCRIPTING_WXPYTHON=ON
 -- -DPYTHON_ROOT_DIR=C:/Users/Tim/Local/kicad-winbuilder-3.4/env/python
 -- -DBUILD_GITHUB_PLUGIN=ON
 --
  Configuring KiCad ( Release )
 -- Building Release version of KiCad revision: 5215

 -- Installing KiCad locally. Use RunKiCad.bat to run this version
 CMake Error at KiCadWinbuilder.cmake:1040 (file):
   file COPY cannot find
   C:/Users/Tim/Local/kicad-winbuilder-3.4/kicad/bin/pylib/_pcbnew.pyd.

 ___
 Mailing list: https://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] proposal of adjusted netlist dialog

[Brian Sidebotham]

The re-designed layout us much more appealing. It looks much better than
the previous layout.

On 22 Oct 2014 19:14, Mark Roszko mark.ros...@gmail.com wrote:

 Actually I planned to do this:

 Rename the netlist dialog to Netlist Options
 Add a Generate Netlist menu option which does the immediate
 netlisting with saved settings unless its the first time and theres no
 saved settings.

This type of behaviour would get my vote, although I also think it's
perhaps better to swap to a netlist button that is a fixed filename and
netlist type (pcbnew) and have this dialog under the heading export
enlist.

That's because there are other areas like this that need cleaning up in the
same way, e.g eeschema options dialog which asks you for the project file
to save the project specific setting to, whilst at the same time updating
the eeschema (non-project specific) options too! It's really quite awkward
to be asked for these standard named files in a normal workflow.

 The plan was also to add a menu option for Annotation, a Silent
 Forward Annotation which annotates with saved settings and only does
 new items. Akin to what Altium lets you do.

This also sounds good. Optimising the normal workflow can be a great
bonus, but it may take a hit of hammering out as to the actual workflow and
operation of these options.

Thanks for your work Mark!

Best Regards,

Brian.

___
 Mailing list: https://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] proposal of adjusted netlist dialog

[Brian Sidebotham]

On 22 Oct 2014 23:03, Brian Sidebotham brian.sidebot...@gmail.com wrote:

 The re-designed layout us much more appealing. It looks much better than
the previous layout.

 On 22 Oct 2014 19:14, Mark Roszko mark.ros...@gmail.com wrote:
 
  Actually I planned to do this:
 
  Rename the netlist dialog to Netlist Options
  Add a Generate Netlist menu option which does the immediate
  netlisting with saved settings unless its the first time and theres no
  saved settings.

 This type of behaviour would get my vote, although I also think it's
perhaps better to swap to a netlist button that is a fixed filename and
netlist type (pcbnew) and have this dialog under the heading export
enlist.

 That's because there are other areas like this that need cleaning up in
the same way, e.g eeschema options dialog which asks you for the project
file to save the project specific setting to, whilst at the same time
updating the eeschema (non-project specific) options too! It's really quite
awkward to be asked for these standard named files in a normal workflow.

  The plan was also to add a menu option for Annotation, a Silent
  Forward Annotation which annotates with saved settings and only does
  new items. Akin to what Altium lets you do.

 This also sounds good. Optimising the normal workflow can be a great
bonus, but it may take a hit of hammering out as to the actual workflow and
operation of these options.

 Thanks for your work Mark!

 Best Regards,

 Brian.


Sorry for all the spelling mistakes, I replied via my phone!

Best Regards,

Brian.
___
Mailing list: https://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: new documentation format

[Brian Sidebotham]

On 22 Oct 2014 23:00, Marco Ciampa ciam...@libero.it wrote:

 Sorry I forgot to show directly the .po files. See by yourself:


https://github.com/ciampix/kicad-doc/blob/master/src/asciidoc/cvpcb/po/cvpcb.pot

 You will see that there are many big paragraphs

Yeah, that po file looks good. Hopefully the document translators will
agree!

Best Regards,

Brian.
___
Mailing list: https://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] Updates to authors.txt

[Brian Sidebotham]

Thank-you for the update Andrew.

When I updated the file I asked for any missing people to come forward
and I'd add them straight to the list. I'll do it tonight and sync the
list on http://www/kicad-pcb.org too.

Best Regards,

Brian.


On 21 October 2014 04:37, Andrew Zonenberg azonenb...@drawersteak.com wrote:
 Hi all,

 While browsing recent commits I saw some updates to authors.txt which
 prompted me to take a look at the file and noticed two minor issues.

 1) maintener (line 15) should be spelled maintainer
 2) Neither Cirillo Bernardo nor myself are listed as contributors.

 Thanks :)

 --
 Andrew Zonenberg
 PhD student, security group
 Computer Science Department
 Rensselaer Polytechnic Institute
 http://colossus.cs.rpi.edu/~azonenberg/

 ___
 Mailing list: https://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] Possible 4.6 gerber issue?

[Brian Sidebotham]

On 17 October 2014 14:10, Wayne Stambaugh stambau...@verizon.net wrote:
 On 10/17/2014 8:44 AM, jp charras wrote:
 Le 17/10/2014 14:22, Mark Roszko a écrit :
 Alright, I've played around. It appears there is many CAM/gerber
 software that cannot handle G75 arcs that are full 360 degrees. I
 tested this with the board from Jon and the 1 pin test board from
 Nick. If I generate 359 degree arcs, the 3d viewer is happy and draws
 good circles. If I generate 360 degrees then the arcs disappear/screw
 up.
 As far as I can tell, the math is right for the arcs regardless of 360
 or 359. I think it's because the start point == end point for a 360
 degree arc, that some viewers may break down due to their graphics
 libraries.

Well done figuring out the cause of the issue Mark!


 Do we really want to be in the business of working around other peoples
 broken software?  I really don't want KiCad to be part of that world.
 It's one of the reasons I am willing to work on KiCad for free.  While I
 appreciate your effort, this is something I would not commit unless we
 are violating the gerber specification which appears not to be the case
 if JP is correct.  What we should be doing is sending high quality bug
 reports including references to the gerber specification, screen shots,
 files that cause the problem, etc. so the developers of the various
 broken gerber viewer apps and make it their responsibility to fix their
 code.


No we don't! This is a clear-cut problem with CAM350. To be fair to
them, CAM350 V9.5 was released in 2007 and there have been a lot of
updates since then. I expect a newer version to have fixed the issue
seen here.

It is a clearly documented case in the Gerber specification and I
checked the gerber output of KiCad which is producing exactly what it
needs to in this case.

I'm more surprised that the fab house didn't see the issue with the
silk screen, it's obviously wrong. But to keep the costs low these
days they're not far off fully automated, so these things no longer
get checked.

Best Regards,

Brian.

___
Mailing list: https://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] My wxFormBuilder build doesn't like the new eeschema options dialog

[Brian Sidebotham]

On 16 October 2014 17:30, Garth Corral gcor...@abode.com wrote:

 Hi, guys.

 After the recent eeschema dialog commit, my build of wxFormBuilder won’t 
 allow me to do anything with dialog_eeschema_options_base.fbp.  It will open 
 it just fine, but after that I can’t use the UI; clicking on anything does 
 basically nothing.  Just prior to this commit I was able to open it an click 
 around and things basically worked.  Anyone else having this issue?

 I’m not a UI guy and I’m normally about as useless as an ashtray on a 
 motorcycle around GUI builders, but I can usually manage to open a file.  
 It’s pure coincidence that I was trying to use wxFormBuilder for the first 
 time just prior to this commit, and that I was interested in that dialog.  
 I’m on a Mac so It’s certainly possible that this is down to my build of 
 wxFormBuilder, but reverting this fbp file to the previous version allows it 
 to work with the file again.

 I saw a brief discussion the other day about .fbp file versions but didn’t 
 quite get the official stance on this.  I’m on the latest version on the 3.x 
 branch, only because a recent version was all I could find that would open 
 all the files that I tried.


 Thanks,

 Garth

Hi Garth,

Sorry you're having grief. That file was generated by the latest
Ubuntu PPA version of wxFormBuilder. I'll check the actual version
number when I get home. As other dialogs had the same FileVersion
setting I think we decided that the FileVersion was okay to use.

Could you try opening any of the other dialogs which have the 1.13
FileVersion setting and see if you experience any similar problems
with then?

Likely it's a wxFormBuilder issue and a difference between the one
you're using and the one I'm using.

Best Regards,

Brian.

___
Mailing list: https://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] Updated AUTHORS.txt in BZR5192

[Brian Sidebotham]

Hi All,

I've just updated the AUTHORS.txt wtih some recent, and some
not-so-recent contributors to the list.

Some notes about the list:

(1) It's not in any order what-so-ever.
(2) It's not complete!

With regard to 2, please do not feel offended if you feel as though
you've made a contribution and you're not in the list; Please feel
free to email me either personally or on-list and I'll sort it out
immediately. I apologise to anyone who falls into this category and
who has fallen through the net, it's not intentional!

I will sync the website list of contributors after the dust settles
around AUTHORS.txt

Thank-you to everyone who has contributed to the project to make it
what it is today!

Best Regards,

Brian.

___
Mailing list: https://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] My wxFormBuilder build doesn't like the new eeschema options dialog

[Brian Sidebotham]

Hi Garth,

The wxFormBuilder version I'm using is 3.5.0-beta. I don't have any
issues on Ubuntu (obviously) and I've just installed the same
3.5.0-beta on Windows and the dialog appears fine.

The only OS I cannot test on is Mac. What OS are you using?

Perhaps another developer can also take a look at the dialog to see if
they're experiencing the same problem.

Best Regards,

Brian Sidebotham.


On 16 October 2014 17:56, Garth Corral gcor...@abode.com wrote:
 Thanks for the quick reply.

 Yes, already tried a sample of files; 1.11, 1.12 and 1.13 files open and 
 seemingly work just fine.  This is the only file that I’ve had trouble with.  
 Not sure what version ppa corresponds to, but I’m also on a pretty recent 
 version.  I built from the head of the 3.x branch (also tried the 3.4.2 and 
 3.5.0 tags) which should be roughly 3.5.x.

 Garth

 On Oct 16, 2014, at 9:48 AM, Brian Sidebotham brian.sidebot...@gmail.com 
 wrote:

 On 16 October 2014 17:30, Garth Corral gcor...@abode.com wrote:

 Hi, guys.

 After the recent eeschema dialog commit, my build of wxFormBuilder won’t 
 allow me to do anything with dialog_eeschema_options_base.fbp.  It will 
 open it just fine, but after that I can’t use the UI; clicking on anything 
 does basically nothing.  Just prior to this commit I was able to open it an 
 click around and things basically worked.  Anyone else having this issue?

 I’m not a UI guy and I’m normally about as useless as an ashtray on a 
 motorcycle around GUI builders, but I can usually manage to open a file.  
 It’s pure coincidence that I was trying to use wxFormBuilder for the first 
 time just prior to this commit, and that I was interested in that dialog.  
 I’m on a Mac so It’s certainly possible that this is down to my build of 
 wxFormBuilder, but reverting this fbp file to the previous version allows 
 it to work with the file again.

 I saw a brief discussion the other day about .fbp file versions but didn’t 
 quite get the official stance on this.  I’m on the latest version on the 
 3.x branch, only because a recent version was all I could find that would 
 open all the files that I tried.


 Thanks,

 Garth

 Hi Garth,

 Sorry you're having grief. That file was generated by the latest
 Ubuntu PPA version of wxFormBuilder. I'll check the actual version
 number when I get home. As other dialogs had the same FileVersion
 setting I think we decided that the FileVersion was okay to use.

 Could you try opening any of the other dialogs which have the 1.13
 FileVersion setting and see if you experience any similar problems
 with then?

 Likely it's a wxFormBuilder issue and a difference between the one
 you're using and the one I'm using.

 Best Regards,

 Brian.

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