Re: [Kicad-developers] _CHECK_SYMBOL_EXISTS?

[Simon Wells]

do they really need to if its an “internal” cmake macro

> On 31/03/2018, at 10:24 AM, Wayne Stambaugh  wrote:
> 
> I'm using 3.10 so that's why I haven't seen this yet.  I guess we are
> going to have to fix this.  It's would be nice if the cmake folks would
> have at least provided a substitution and a warning rather than break
> everybody's configuration who uses CHECK_SYMBOL_EXISTS.
> 
> On 3/30/2018 5:15 PM, Seth Hillbrand wrote:
>> Hi Adam-
>> 
>> You will need to downgrade to CMake 3.10 or lower.  In 3.11, they
>> revised the internals of CheckSymbolExists.
>> 
>> Our macro depends on the internal CMake macro _CHECK_SYMBOL_EXISTS (note
>> the underscore at the beginning).  In 3.11, they replaced it with
>> __CHECK_SYMBOL_EXISTS_IMPL.
>> 
>> -S
>> 
>> 2018-03-30 13:24 GMT-07:00 Wayne Stambaugh > 
>> >>:
>> 
>>Hey Adam,
>> 
>>According to the latest cmake (3.11) docs[1], CheckCXXSymbolExists.cmake
>>still contains a CHECK_SYMBOL_EXISTS command.  This has been around for
>>a really long time, I'm not sure why you would be having issues with
>>this now unless you have a broken cmake install.
>> 
>>Wayne
>> 
>>On 3/30/2018 3:56 PM, Adam Wolf wrote:
>>> Hi folks!
>>> 
>>> Normally I wouldn't ask this question on the list, but it's at or past
>>> crunch time on the new macOS packaging, so please forgive me.
>>> 
>>> I have a macOS 10.11 system I use for KiCad packaging sometimes, and
>>> I'm running some tests on it.  It has cmake 3.11.0 on it.
>>> 
>>> 8 days ago, I was able to build kicad master on it.  Today, I can't
>>> configure on it.  I get
>>> 
>>> CMake Error at CMakeModules/CheckCXXSymbolExists.cmake:41
>>> (_CHECK_SYMBOL_EXISTS):
>>>Unknown CMake command "_CHECK_SYMBOL_EXISTS".
>>> Call Stack (most recent call first):
>>>CMakeModules/PerformFeatureChecks.cmake:84 (check_cxx_symbol_exists)
>>>CMakeLists.txt:166 (perform_feature_checks)
>>> 
>>> This machine is just used for KiCad, and this error doesn't really
>>> make sense to me.  It very well could be with the scripts I'm using
>>> for testing, but I'm asking in case anyone has any ideas or has seen
>>> something similar.
>>> 
>>> 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 
>> 
>>> >
>> 
>> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

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

[Simon Wells]

please see https://lists.launchpad.net/kicad-developers/msg31544.html 


There are different minimum versions required of OCCT and nick also had issues 
with occt working iirc

i think i would still prefer being able to set whether to allow occ in place of 
oce as was my initial thoughts but i have not worked on this due to the issues 
experienced by nick


btw as oce is just a fork of occt would that not have the same issues?

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

Re: [Kicad-developers] Libedit and Modedit Icons

[Simon Wells]

I agree with Jeff, Not a fan of the pcbnew/modedit/gerbview icons, I don’t mind 
the eeschema icon, but also not a fan of the bmp2cmp icon, the only way i can 
see bmp2cmp being better would be a (well known) bitmap looking square with an 
arrow pointing to a footprint and/or symbol

Simon

> On 12/01/2018, at 11:47 PM, Jeff Young  wrote:
> 
> I like the more subdued colours in Oliver’s, although I do like your 
> calculator icon (perhaps with Oliver’s pcb colouring in the background).
> 
> Cheers,
> Jeff.
> 
> 
>> On 12 Jan 2018, at 10:22, Константин Барановский 
>> > 
>> wrote:
>> 
>> Hi Everybody!
>> As you know (or not) I'm work on new icons for KiCad for a long time:
>> https://code.launchpad.net/~baranovskiykonstantin/kicad/+git/kicad/+ref/new_icons_rebased
>>  
>> 
>> 
>> And inspired by changes in app icons I made my variant.
>> Please, leave feedback.
>> 
>> 2018-01-12 5:28 GMT+02:00 Andrey Kuznetsov > >:
>> Awesome, thanks!
>> 
>> Looks good.
>> 
>> On Thu, Jan 11, 2018 at 7:27 PM Oliver Walters 
>> > 
>> wrote:
>> Andrey,
>> 
>> Here's all I can provide currently (at work!)
>> 
>> 
>> 
>> I have sent the entire patch to Wayne and JP privately so the merging is now 
>> in their capable hands :)
>> 
>> On Fri, Jan 12, 2018 at 2:20 PM, Andrey Kuznetsov > > wrote:
>> Also the attached image of the final icon set was discarded, can you please 
>> resend the final icon image set?
>> 
>> Thank you
>> 
>> On Thu, Jan 11, 2018 at 8:35 AM, jp charras > > wrote:
>> Le 11/01/2018 à 08:54, Oliver Walters a écrit :
>> > Wayne,
>> >
>> > I have taken further suggestions and final icon set is shown below:
>> >
>> > [image: Inline image 1]
>> >
>> > The attached patch incorporates all of the icon changes thus far
>> > implemented.
>> >
>> > Thanks,
>> > Oliver
>> >
>> 
>> Oliver,
>> 
>> For some unknown reason, your mail was blocked by Launchpad.
>> And the attached patch was discarded.
>> 
>> 
>> --
>> Jean-Pierre CHARRAS
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> 
>> Post to : kicad-developers@lists.launchpad.net 
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> 
>> More help   : https://help.launchpad.net/ListHelp 
>> 
>> 
>> 
>> 
>> -- 
>> Remember The Past, Live The Present, Change The Future
>> Those who look only to the past or the present are certain to miss the 
>> future [JFK]
>> 
>> kandre...@gmail.com 
>> Live Long and Prosper,
>> Andrey
>> 
>> -- 
>> Remember The Past, Live The Present, Change The Future
>> Those who look only to the past or the present are certain to miss the 
>> future [JFK]
>> 
>> kandre...@gmail.com 
>> Live Long and Prosper,
>> Andrey
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> 
>> Post to : kicad-developers@lists.launchpad.net 
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> 
>> More help   : https://help.launchpad.net/ListHelp 
>> 
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> 
>> Post to : kicad-developers@lists.launchpad.net 
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> 
>> More help   : https://help.launchpad.net/ListHelp 
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~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] Libedit and Modedit Icons

[Simon Wells]

if the modedit/libedit icons are to be reverted then i believe the pencils 
should be removed, seeing as they were used to portray edit i believe but now 
that pcbnew/eeschema don’t have them they just seem odd

> On 7/01/2018, at 2:28 PM, Nick Østergaard  wrote:
> 
> I have been intending to revert the annotate icon in eeschema to the old one, 
> which made much more sense to me thatn the current one.
> 
> 2018-01-07 1:24 GMT+01:00 Oliver Walters  >:
> I have attached a patchset which performs the following:
> 
> 1. Revert libedit icon to previous version
> 2. Revert modedit icon to previous version
> 3. Updates pcbnew icon to look more like a PCB
> 4. Update colors of eeschema icon
> 5. Various (almost imperceptible) tweaks to a number of icons to fix graphic 
> alignment issues
> 
> Here is a screenshot of the updated icons:
> 
> 
> 
> 
> 
> 
> 
> On Sun, Jan 7, 2018 at 8:34 AM, Oliver Walters 
> > 
> wrote:
> On 7 Jan 2018 05:04, "Chris Pavlina"  > wrote:
> I wish we had something resembling a policy for icons. It seems like
> someone always wants to change them. We had decent icons for these
> _before_, and then someone submitted new ones, and they were accepted
> because... I don't know? Many of the new icons are really ambiguous and
> kind of useless. Shouldn't have been merged.
> 
> This is why I'm pushing for *a* change and not *my* change, I remember how 
> the argument went last time, before they were silently merged. 
> 
> I also note that there is a lack of consistency between similar icons. e.g. 
> there are many icons which incorporate an arrow but the style/shape of the 
> arrows varies. 
> 
> For the record, I like these proposed ones. They bring back the ability
> to recognize them at a glance.
> 
> On Sat, Jan 06, 2018 at 05:52:49PM +, kristoffer Ödmark wrote:
> > I would love to see improved icons, I still never get used to them so i read
> > the tooltip, newer know which one is pcb and which one is module editor.
> >
> > Luckily most of the time I only need to double click the kicad_pcb file
> > anyway :)
> >
> >
> > On 2018-01-06 15:08, Nick Østergaard wrote:
> > > 2018-01-06 14:15 GMT+01:00 Jeff Young  > > 
> > > >>:
> > >
> > > +1
> > >
> > > And I like Oliver’s proposed icons.  I’d suggest two further
> > > changes though:
> > >
> > > 1) The schematic icon (which Oliver didn’t change) should really
> > > use the default colours (dark red symbols, green wires).  Then
> > > there’s a stronger tie-in with the libedit icon.
> > >
> > > 2) I think I’d drop the dimensions from the modedit icon, and
> > > change the pad colour to the default (yellow).
> > >
> > >
> > > The default pad color is not yellow, that is only what you see for THT
> > > pads. Default pad color is green for bottom and red for top copper
> > >
> > >
> > > 3) Projects should use the current New Project icon, rather than
> > > the application icon.
> > >
> > >
> > > I have considered to submit a patch for this for some time, but I guess
> > > it is an appropiate time to do this with a major version bump.
> > >
> > >
> > > 4) Both the New Project and New Project from Template icons should
> > > get yellow “new” star.
> > >
> > > 5) New Footprint in modedit also needs the star, and the star on
> > > New Symbol in libedit made more prominent.
> > >
> > > Cheers,
> > > Jeff.
> > >
> > >
> > > > On 6 Jan 2018, at 12:30, Oliver Walters
> > > >  > > > 
> > > >  > > > >> wrote:
> > > >
> > > > I think there is a need to tweak the libedit and modedit icons,
> > > > as identified below:
> > > >
> > > > 
> > > >
> > > > 
> > > >
> > > > 1. The blue 'textured' background is out of place with the other
> > > > icons
> > > > 2. They are very cluttered and hard to read
> > > > 3. Weirdly specific callout of dimensions and part names (out of
> > > > character with other icons)
> > > >
> > > > Further, I think that the pcbnew icon could be adjusted slightly
> > > > to make it look a bit more like a PCB
> > > >
> > > > Even as someone who uses KiCad on a regular basis I find myself
> > > > double checking which icon I am about to click on (and still
> > > > getting it wrong half of the time).
> > > >
> > > > Below is a /**suggestion**/ of some improvements. I am not trying
> > > > to back my own horse here, I'd be happy for anyone else to
> > > > suggest a better design for any of these. But I feel that
> > > > changing these icons 

Re: [Kicad-developers] Libedit and Modedit Icons

[Simon Wells]

just following on from Nick’s comments, do we really need the page around the 
schematic icon? i realise its more suitable than anywhere there but could it 
not be described just as well by having multiple schematic components?

funnily enough a lot of these things were bought up the last time there was an 
argument over the icons on the list but as can be seen a lot of irrelevant 
things got added to the icons regardless.

Simon

> On 7/01/2018, at 8:50 AM, Jeff Young  wrote:
> 
> Ooops, showing my age there.  (What’s all this SMD stuff?)
> 
>> On 6 Jan 2018, at 14:08, Nick Østergaard > > wrote:
>> 
>> 2) I think I’d drop the dimensions from the modedit icon, and change the pad 
>> colour to the default (yellow).
>> 
>> The default pad color is not yellow, that is only what you see for THT pads. 
>> Default pad color is green for bottom and red for top copper
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~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] Patches consistency

[Simon Wells]

ah found the issue, build wx with “—disable-mediactrl” as its incompatible with 
macOS >= 10.12


> On 1/01/2018, at 12:26 PM, Anton Shevchenko <in...@sancoder.com> wrote:
> 
> There were 3 issues while running patch utility on all files in patches 
> subfolder.
> 
> 1. regarding wxwidgets-3.0.2_macosx_unicode_pasteboard.patch
> The patch could not be applied for the simple reason there was no "#if 0" 
> lines in the source code of wxwidgets-3.0.2 (downloaded from sourceforge.net 
> <http://sourceforge.net/>).
> 
> 2. regarding wxwidgets-3.0.2_macosx_sierra.patch
> This patch contains CR/LF (ie, Windows style) line endings.
> 
> 3. regarding wxwidgets-3.0.0_macosx.patch
> While applying this patch to 3.0.2 source code the patch utility complained 
> about offsets. That's ok since source code could have changed between 3.0.0 
> and 3.0.2.
> 
> I thought first is critical and the other 2 are not critical as patch utility 
> can fix these problems.
> You may have got no issues since script in documentation doesn't care about 
> error codes returned from patch utility.
> 
> I have fixed all of the issues above but not sure if I should submit them 
> (along with documentation fix on how to build on macOS). If anyone is up for 
> including wxwidgets into kicad's repo I would step aside. If not, I can 
> submit the patch for building wxWidgets 3.0.2 version with patches included 
> on macOS.
> 
> --
>   Sincerely,
>   Anton Shevchenko
>   in...@sancoder.com <mailto:in...@sancoder.com>
> 
> 
> On Sun, Dec 31, 2017, at 1:55 PM, Simon Wells wrote:
>> whats the error when you try applying it on 3.0.2 i don’t think i have any 
>> issues? (jsut fyi i did a build last night with it being patched without 
>> issues)
>> 
>> Simon
>> 
>>> On 1/01/2018, at 5:22 AM, Anton Shevchenko <in...@sancoder.com 
>>> <mailto:in...@sancoder.com>> wrote:
>>> 
>>> Thanks Jess for pointing this. My mistake.
>>> I meant the wxwidgets-3.0.2_macosx_unicode_pasteboard.patch could not be 
>>> applied.
>>> Neither on top of 3.0.2 nor on top of 3.0.3.
>>> 
>>> --
>>>   Sincerely,
>>>   Anton Shevchenko
>>>   in...@sancoder.com <mailto:in...@sancoder.com>
>>> 
>>> 
>>> On Sat, Dec 30, 2017, at 3:42 AM, Jeff Young wrote:
>>>> Hi Anton,
>>>> 
>>>> The staticbox_tabbing patch is one of the git patches.  Use:
>>>> 
>>>> git apply 
>>>> path-to-kicad-src/patches/wxwidgets-3.0.0_macosx_staticbox_tabbing.patch
>>>> 
>>>> to apply it.
>>>> 
>>>> Cheers,
>>>> Jeff.
>>>> 
>>>> 
>>>> 
>>>>> On 30 Dec 2017, at 01:42, Simon Wells <swel...@gmail.com 
>>>>> <mailto:swel...@gmail.com>> wrote:
>>>>> 
>>>>> you don’t have to get a < 10.11 SDK you can just remove the include and 
>>>>> all works iirc, there is a patch floating around for that as well
>>>>> 
>>>>>> On 30/12/2017, at 2:25 PM, Anton Shevchenko <in...@sancoder.com 
>>>>>> <mailto:in...@sancoder.com>> wrote:
>>>>>> 
>>>>>> I have completed the quest of compiling wxWidgets with kicad patches.
>>>>>> Here are my notes.
>>>>>> 
>>>>>> First, as noted before, not all patches were included in script in 
>>>>>> documentation.
>>>>>> 
>>>>>> Second, the file wxwidgets-3.0.0_macosx_staticbox_tabbing.patch could 
>>>>>> not be applied to 3.0.2 version. The solution is to delete the file at 
>>>>>> all.
>>>>>> 
>>>>>> Third, on macOS 10.12+ the QTKit framework has been deprecated. To 
>>>>>> compile it successfully one has to obtain an SDK for 10.11 or lower. I 
>>>>>> found it is enough to get it from here 
>>>>>> https://github.com/phracker/MacOSX-SDKs/releases 
>>>>>> <https://github.com/phracker/MacOSX-SDKs/releases>
>>>>>> and add this option
>>>>>> 
>>>>>> ../configure \
>>>>>> [skip]
>>>>>>--with-macosx-sdk=$MACOS_SDK_PATH \
>>>>>> [skip]
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>>   Sincerely,
>>>>>>   Anton Shevchenko
>>>>>>   in...@sancoder.com <mailto:in...@s

Re: [Kicad-developers] Default Canvas for v5

[Simon Wells]

the big problem i have with setup wizards is it is not always obvious which 
options will be or were set by the setup dialog

Simon

> On 1/01/2018, at 11:08 AM, Kristoffer Ödmark <kristofferodmar...@gmail.com> 
> wrote:
> 
> There is still some functionality in it that is missing from what I gather.
> 
> I do like the idea that just having an "enable hw acceleration" button or 
> switch in the nagdialog, it feels proffessional, and most people will try it 
> i think.
> 
> Also, these problems seems like there could be some benefit of having a setup 
> wizard, IE a series of nagdialogs that is only run once, and can be reenabled 
> when new user choices are mandated( download libraries, dark/light theme, 
> standard projects folder, hardware/software rendering)
> 
> I think changing so that the only option is to run with or without HW 
> acceleration should be a good goal for v6, along with _maybe_ having a setup 
> wizard.
> 
> -Kristoffer
> 
> On 12/31/2017 07:09 PM, Jon Evans wrote:
>> Do we actually need the legacy canvas anymore? I know we need the code in
>> it for printing, but do we need the option to render the UI in legacy mode
>> or could we hide that in some place less prominent than the view menu? It
>> would be a lot less confusing if the only choice was between hardware
>> acceleration or not.
>> On Dec 31, 2017 13:07, "Jon Evans" <cdaw...@gmail.com> wrote:
>>> How about "Modern" instead of GAL for user-facing stuff?
>>> 
>>> "Legacy"
>>> "Modern (Accelerated)"
>>> "Modern (Fallback)"
>>> 
>>> On Dec 31, 2017 12:38, "Nick Østergaard" <oe.n...@gmail.com> wrote:
>>> 
>>>> I don't think the term standard for Cairo is good. It is better to call
>>>> it fallback or faillsafe.
>>>> 
>>>> Calling it standard gives the impression that this is what they should
>>>> choose, but really we want them to select OpenGL.
>>>> 
>>>> Den 31. dec. 2017 18.12 <20%2017%2018%2012> skrev "Wayne Stambaugh" <
>>>> stambau...@gmail.com>:
>>>> 
>>>>> Looks good to me.
>>>>> 
>>>>> On 12/31/2017 12:04 PM, Jon Evans wrote:
>>>>>> How about something like this?
>>>>>> 
>>>>>> Inline image 1
>>>>>> 
>>>>>> (N.B. I agree with Andy, and think we could consider renaming the
>>>>>> options in the View menu to "Legacy", "Accelerated (OpenGL)" and
>>>>>> "Standard (Cairo)" or something like that)
>>>>>> 
>>>>>> -Jon
>>>>>> 
>>>>>> On Sun, Dec 31, 2017 at 11:40 AM, Andy Peters <de...@latke.net
>>>>>> <mailto:de...@latke.net>> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Dec 31, 2017, at 6:49 AM, Simon Wells <swel...@gmail.com
>>>>>>> <mailto:swel...@gmail.com>> wrote:
>>>>>>> 
>>>>>>> What about having the default set to cairo, and when the
>>>>>>> first/once run dialog runs it talks about openGL (this goes
>>>>>>> against you already set to GAL) but it allows a default that even
>>>>>>> if it crashes won’t require manually editing a configuration to
>>>>>>> make it workable
>>>>>> 
>>>>>> User perspective:
>>>>>> 
>>>>>> The names for the canvases are “engineering terms,” that is,
>>>>>> something named by the developers for their own internal use but
>>>>>> were never renamed for the end user who might have no idea what is
>>>>>> meant by “Cairo canvas” or what “GAL” stands for. I say that
>>>>> because
>>>>>> early on I asked myself, “WTF is this ‘Cairo’ thing?”
>>>>>> 
>>>>>> I now understand (I think …) that Cairo and GAL implement the same
>>>>>> features but the latter requires proper OpenGL hardware and
>>>>> drivers,
>>>>>> and Cairo does not.
>>>>>> 
>>>>>> So perhaps better terms for these options is “Standard” and
>>>>>> “Accelerated (OpenGL).” Users know what OpenGL means (I hope, it’s
>>>>>> nothing new). As for why a user wi

Re: [Kicad-developers] Patches consistency

[Simon Wells]

whats the error when you try applying it on 3.0.2 i don’t think i have any 
issues? (jsut fyi i did a build last night with it being patched without issues)

Simon

> On 1/01/2018, at 5:22 AM, Anton Shevchenko <in...@sancoder.com> wrote:
> 
> Thanks Jess for pointing this. My mistake.
> I meant the wxwidgets-3.0.2_macosx_unicode_pasteboard.patch could not be 
> applied.
> Neither on top of 3.0.2 nor on top of 3.0.3.
> 
> --
>   Sincerely,
>   Anton Shevchenko
>   in...@sancoder.com <mailto:in...@sancoder.com>
> 
> 
> On Sat, Dec 30, 2017, at 3:42 AM, Jeff Young wrote:
>> Hi Anton,
>> 
>> The staticbox_tabbing patch is one of the git patches.  Use:
>> 
>> git apply 
>> path-to-kicad-src/patches/wxwidgets-3.0.0_macosx_staticbox_tabbing.patch
>> 
>> to apply it.
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>> 
>>> On 30 Dec 2017, at 01:42, Simon Wells <swel...@gmail.com 
>>> <mailto:swel...@gmail.com>> wrote:
>>> 
>>> you don’t have to get a < 10.11 SDK you can just remove the include and all 
>>> works iirc, there is a patch floating around for that as well
>>> 
>>>> On 30/12/2017, at 2:25 PM, Anton Shevchenko <in...@sancoder.com 
>>>> <mailto:in...@sancoder.com>> wrote:
>>>> 
>>>> I have completed the quest of compiling wxWidgets with kicad patches.
>>>> Here are my notes.
>>>> 
>>>> First, as noted before, not all patches were included in script in 
>>>> documentation.
>>>> 
>>>> Second, the file wxwidgets-3.0.0_macosx_staticbox_tabbing.patch could not 
>>>> be applied to 3.0.2 version. The solution is to delete the file at all.
>>>> 
>>>> Third, on macOS 10.12+ the QTKit framework has been deprecated. To compile 
>>>> it successfully one has to obtain an SDK for 10.11 or lower. I found it is 
>>>> enough to get it from here 
>>>> https://github.com/phracker/MacOSX-SDKs/releases 
>>>> <https://github.com/phracker/MacOSX-SDKs/releases>
>>>> and add this option
>>>> 
>>>> ../configure \
>>>> [skip]
>>>>--with-macosx-sdk=$MACOS_SDK_PATH \
>>>> [skip]
>>>> 
>>>> 
>>>> --
>>>>   Sincerely,
>>>>   Anton Shevchenko
>>>>   in...@sancoder.com <mailto:in...@sancoder.com>
>>>> 
>>>> 
>>>> On Fri, Dec 29, 2017, at 4:23 PM, Jeff Young wrote:
>>>>> Having a single place I could do a simple git clone (as opposed to 
>>>>> applying patches) would be the biggest win.  I don’t think it matters 
>>>>> that much where the single place is.
>>>>> 
>>>>> If there are no legal/etc. issues then the kicad org would be best.  But 
>>>>> even if it has to be in the wxWidgets org, that would be better than what 
>>>>> we have now.
>>>>> 
>>>>> Cheers,
>>>>> Jeff.
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 30 Dec 2017, at 00:14, Adam Wolf <adamw...@feelslikeburning.com 
>>>>>> <mailto:adamw...@feelslikeburning.com>> wrote:
>>>>>> 
>>>>>> Sounds fine to me!
>>>>>> 
>>>>>> Adam
>>>>>> 
>>>>>> On Dec 29, 2017 5:45 PM, "Nick Østergaard" <oe.n...@gmail.com 
>>>>>> <mailto:oe.n...@gmail.com>> wrote:
>>>>>> We could have a fork of wx in the kicad org with a branch where we 
>>>>>> rebase the patches to. Then it is easy to fetch for others. The osx devs 
>>>>>> could maintain this. But having it in the kicad org gives more 
>>>>>> visibility and we don't need to habe them directly in the kicad source. 
>>>>>> 
>>>>>> This is just an idea, this proposal might need some more thought.
>>>>>> 
>>>>>> Den 29. dec. 2017 23.36 skrev "Wayne Stambaugh" <stambau...@gmail.com 
>>>>>> <mailto:stambau...@gmail.com>>:
>>>>>> This seems like a reasonable solution.  Although pointing macOS
>>>>>> developers to the repo might be an issue.
>>>>>> 
>>>>>> On a related note, I was just updating the compiling.md 
>>>>>> <http://compiling.md/> file and noticed
>>>>>> that there seem to be quite a few of 

Re: [Kicad-developers] Default Canvas for v5

[Simon Wells]

What about having the default set to cairo, and when the first/once run dialog 
runs it talks about openGL (this goes against you already set to GAL) but it 
allows a default that even if it crashes won’t require manually editing a 
configuration to make it workable

Simon

> On 1/01/2018, at 2:48 AM, Wayne Stambaugh  wrote:
> 
> I spite of my disdain for nagware, I'll tolerate this under the
> following conditions:
> 
> The current canvas is not already on one of the gal canvases.  If the
> user is already using a gal canvas, a dialog to inform the user about
> the gal canvas is silly.
> 
> It's a one shot dialog that never appears again.
> 
> If the gal canvas crashes, the user isn't going to have to manually edit
> a configuration file to restore the legacy canvas.  This requirement may
> prevent us from setting the opengl canvas as the default so the solution
> may not be as easy as it seems.
> 
> On 12/31/2017 07:34 AM, Jeff Young wrote:
>> +1 to the startup dialog idea.
>> 
>> I think we also need to set reasonable transparencies in the layers so that 
>> it looks more like the default legacy canvas.
> 
> I don' think this is necessary given that the gal canvas layer colors
> and transparencies are completely user configurable but I'm not opposed
> to a default layer color/transparency configuration that looks more like
> the legacy canvas.
> 
>> 
>>> On 31 Dec 2017, at 10:09, Clemens Koller  wrote:
>>> 
>>> On 2017-12-31 03:53, Jon Evans wrote:
 I know this would be work for someone to do and maybe I'd offer to do it 
 if the project leaders approve...
 What about a one-time pop-up when first installing a release 5.0 that 
 appears if the config says the user was using legacy canvas, telling them 
 about how to switch and that they should check it out?
 
 -Jon
>>> 
>>> +1
>>> An initial start-up dialog to setup the "users default" after a first 
>>> install or after a "reset Kicad to defaults, as I messed something up I 
>>> don't remember" seems very helpful to me. If OpenGL might still crash in 
>>> rare cases, warn the user in advance and explain, how he can safely step 
>>> back from using OpenGL in case it doesn't work and how to file a bug 
>>> report...
>>> 
>>> Regards,
>>> 
>>> Clemens
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~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] Patches consistency

[Simon Wells]

is there not also issues with python scripting/swig?

Simon

> On 31/12/2017, at 1:59 AM, Bernhard Stegmaier  wrote:
> 
> It won’t be that easy to switch to wx3.1:
> * They added (previously non-existing) overlay code. It does basically work 
> but is slow as hell - and quite different from the overlay patch we have. I 
> didn’t have time yet to see whether it is more easy to fix or just replace by 
> our patch (which is also in the bug tracker, don’t know why they didn’t take 
> it as is).
> * Currently all dialogs don’t close when you hit enter in a text box. I also 
> didn’t have time to investigate… :(
> 
> And still some other patches needed (e.g., Retina support).
> 
> 
> Regards,
> Bernhard
> 
>> On 30. Dec 2017, at 13:04, Jeff Young  wrote:
>> 
>> Some of them are already up-stream, but we would have to move to wxWidgets 
>> 3.1 (when it comes out in a month or so) to get them.  The wxWidgets folks 
>> won’t back-port header changes, for instance.
>> 
>> I don’t know how many of the existing patches are in 3.0.3, but I don’t 
>> think very many (IIRC only 1 or 2 of them failed when I tried to apply them 
>> to 3.0.3).
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>>> On 30 Dec 2017, at 11:58, Carsten Schoenert  wrote:
>>> 
>>> Hi,
>>> 
>>> Am 30.12.2017 um 00:45 schrieb Nick Østergaard:
 We could have a fork of wx in the kicad org with a branch where we
 rebase the patches to. Then it is easy to fetch for others. The osx devs
 could maintain this. But having it in the kicad org gives more
 visibility and we don't need to habe them directly in the kicad source.
>>> 
>>> in a longterm it's never a good idea to maintain such patches as this
>>> always costs time and energy, has some someone tried to upstream these
>>> patches? That what I normally would do.
>>> 
>>> -- 
>>> Regards
>>> Carsten Schoenert
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~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] Patches consistency

[Simon Wells]

most if not all of the patches have been sourced from upstream, the only one 
that hasn’t i can easily say is the pinch-to-zoom which is a really nice 
feature, so its not really an issue for these patches

> On 31/12/2017, at 12:58 AM, Carsten Schoenert  wrote:
> 
> Hi,
> 
> Am 30.12.2017 um 00:45 schrieb Nick Østergaard:
>> We could have a fork of wx in the kicad org with a branch where we
>> rebase the patches to. Then it is easy to fetch for others. The osx devs
>> could maintain this. But having it in the kicad org gives more
>> visibility and we don't need to habe them directly in the kicad source.
> 
> in a longterm it's never a good idea to maintain such patches as this
> always costs time and energy, has some someone tried to upstream these
> patches? That what I normally would do.
> 
> -- 
> Regards
> Carsten Schoenert
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


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

Re: [Kicad-developers] macOS & New Zone Filling?

[Simon Wells]

I thought it did if you can find the right lib as it was only the lib that was 
missing?

> On 9/12/2017, at 3:48 AM, Bernhard Stegmaier  wrote:
> 
> … I looked around a bit and from that it seems to be pretty sure that stock 
> Xcode Apple clang (which I use) doesn’t support OpenMP.
> 
> 
> Regards,
> Bernhard
> 
>> On 8. Dec 2017, at 14:05, Bernhard Stegmaier > > wrote:
>> 
>> Hi Tom,
>> 
>>> On 8. Dec 2017, at 13:59, Tomasz Wlostowski >> > wrote:
>>> 
>>> Wonderful.
>>> 
>>> I thought a workaround for Windows OpenMP/wxWidgets support will be
>>> sufficient. Time to get a macbook...
>>> 
>>> Bernard, could you try building kicad with OpenMP disabled?
>> 
>> Hmm… how do I do this?
>> 
>> I get from cmake
>> <<<
>> …
>> -- Performing Test COMPILER_SUPPORTS_WSUGGEST_OVERRIDE
>> -- Performing Test COMPILER_SUPPORTS_WSUGGEST_OVERRIDE - Failed
>> -- Performing Test COMPILER_SUPPORTS_WSHADOW
>> -- Performing Test COMPILER_SUPPORTS_WSHADOW - Success
>> -- Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES) 
>> (found version "1.0")
>> -- Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS 
>> OpenMP_CXX_LIB_NAMES) (found version "1.0")
>> -- Found wxWidgets: 
>> -L/Volumes/OSXData/bstegmaier/KiCad/wx-master/lib;;;-framework 
>> IOKit;-framework Carbon;-framework Co
>> …
>> >>>
>> 
>> So I always thought it doesn’t use OpenMP?
>> 
>> 
>> Regards,
>> Bernhard
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> 
>> Post to : kicad-developers@lists.launchpad.net 
>> 
>> Unsubscribe : https://launchpad.net/~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] Symbol library table remapping question

[Simon Wells]

Ah sorry I misread, I thought you were going to use lstat rather than wxwidgets 
using it,



> On 8/12/2017, at 2:44 AM, Wayne Stambaugh <stambau...@gmail.com> wrote:
> 
> AFAIK, Posix isn't available on windows and I would rather not have ugly
> #ifdef/#endif statements if I can avoid it.
> 
> I discovered that the issue is the library table lookup by uri code so
> fixing this is going to be a bit more complicated than I initially
> thought because uris can be more than just file names.
> 
> On 12/7/2017 8:30 AM, Simon Wells wrote:
>>int
>>  lstat(constchar*restrictpath, structstat*restrictbuf);
>> 
>> 
>> So yes macOS has stat, apparently it came from 4.2 BSD, Is one of the
>> posix functions not able to do what is needed?
>> 
>> 
>>> On 8/12/2017, at 2:21 AM, Wayne Stambaugh <stambau...@gmail.com 
>>> <mailto:stambau...@gmail.com>
>>> <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>> wrote:
>>> 
>>> On 12/7/2017 3:14 AM, Bernhard Stegmaier wrote:
>>>> 
>>>> 
>>>>> On 7. Dec 2017, at 00:27, Wayne Stambaugh <stambau...@gmail.com 
>>>>> <mailto:stambau...@gmail.com>
>>>>> <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>> wrote:
>>>>>>> 
>>>>>> 
>>>>>> Well, technically this is the same library.
>>>>>> It is only reachable by 2 different paths (the real and the
>>>>>> symlinked one).
>>>>> 
>>>>> I could check for symlinks.  I'm not sure how much trouble it would be.
>>>>> I'll take a look at it as soon as I get a chance.
>>>> 
>>>> I never tried, but maybe using realpath(…) on both sides of the
>>>> comparison could just do the trick.
>>>> And maybe eliminates also other weird path constructs…?
>>> 
>>> Thanks for the tip.  I dug through the wxWidget's wxFileName source and
>>> found that wxFileName::SameAs() method does an lstat() on platforms that
>>> support it if the comparison operator between two wxFileName objects
>>> fails.  It should be a simple change (famous last words).  I'm assuming
>>> macos has lstat.  If not, then I will have to find another solution.
>>> 
>>>> 
>>>> 
>>>> Regards,
>>>> Bernhard
>>>> 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>> Post to : kicad-developers@lists.launchpad.net 
>>> <mailto:kicad-developers@lists.launchpad.net>
>>> <mailto:kicad-developers@lists.launchpad.net 
>>> <mailto:kicad-developers@lists.launchpad.net>>
>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>> More help   : https://help.launchpad.net/ListHelp 
>>> <https://help.launchpad.net/ListHelp>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Symbol library table remapping question

[Simon Wells]

   int
 lstat(const char *restrict path, struct stat *restrict buf);


So yes macOS has stat, apparently it came from 4.2 BSD, Is one of the posix 
functions not able to do what is needed?


> On 8/12/2017, at 2:21 AM, Wayne Stambaugh  wrote:
> 
> On 12/7/2017 3:14 AM, Bernhard Stegmaier wrote:
>> 
>> 
>>> On 7. Dec 2017, at 00:27, Wayne Stambaugh  wrote:
> 
 
 Well, technically this is the same library.
 It is only reachable by 2 different paths (the real and the symlinked one).
>>> 
>>> I could check for symlinks.  I'm not sure how much trouble it would be.
>>> I'll take a look at it as soon as I get a chance.
>> 
>> I never tried, but maybe using realpath(…) on both sides of the comparison 
>> could just do the trick.
>> And maybe eliminates also other weird path constructs…?
> 
> Thanks for the tip.  I dug through the wxWidget's wxFileName source and
> found that wxFileName::SameAs() method does an lstat() on platforms that
> support it if the comparison operator between two wxFileName objects
> fails.  It should be a simple change (famous last words).  I'm assuming
> macos has lstat.  If not, then I will have to find another solution.
> 
>> 
>> 
>> Regards,
>> Bernhard
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~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] Potrace update (AGAIN)

[Simon Wells]

And yet the files are also being modified unnecessarily making more effort when 
there is an update available,
The potrace library is not large and so seems pointless to bundle the code with 
the source tree.

If the potrace library is out of date with the distributions that can be 
expressed to the distributions esspecially since its been security updates and 
I am not familiar with a distribution that is currently supported by the 
distromaker to not get security updates

> On 27/11/2017, at 9:37 PM, jp charras <jp.char...@wanadoo.fr> wrote:
> 
> Le 27/11/2017 à 09:00, Maciej Sumiński a écrit :
>> I wonder why do we even keep potrace in the source tree. It is available
>> in mingw, brew and major Linux distributions, so it does not need to be
>> build manually.
>> 
>> Regards,
>> Orson
> 
> We need only potrace library source files (only 200Kbytes).
> They are not a lot ( 20 / 30 files).
> 
> Using potrace lib coming with distros is obviously an option, but it does not 
> fix what is asked:
> potrace update ( and it creates one more (minor) dependency for compiling ).
> 
> For instance
> We are using currently potrace 1.13
> 
> potrace 1.15 fixes a few issues of potrace 1.13,  but on mingw the currently 
> potrace version is 1.13
> 
>> 
>> On 11/27/2017 03:58 AM, Simon Wells wrote:
>>> U I *think* its jp who does the potrace stuff but there has been 
>>> another security update for pot race, while I realise we are in a freeze I 
>>> think that security updates should probably be included.
>>> 
>>> "This release consists of bugfixes and minor portability improvements. Some 
>>> potential buffer overflows and arithmetic overflows were fixed, including 
>>> CVE-2017-12067. A bug triggered by very large bitmaps has been fixed. A new 
>>> configuration option --enable-local-getopt was added. Thanks to Agostino 
>>> Sarubbo, Daniel Macks, and Michael Voříšek for reporting bugs and 
>>> suggesting improvements.”
>>> 
>>> Simon
> 
> 
> -- 
> Jean-Pierre CHARRAS
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <https://help.launchpad.net/ListHelp>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Potrace update (AGAIN)

[Simon Wells]

U I *think* its jp who does the potrace stuff but there has been another 
security update for pot race, while I realise we are in a freeze I think that 
security updates should probably be included.

"This release consists of bugfixes and minor portability improvements. Some 
potential buffer overflows and arithmetic overflows were fixed, including 
CVE-2017-12067. A bug triggered by very large bitmaps has been fixed. A new 
configuration option --enable-local-getopt was added. Thanks to Agostino 
Sarubbo, Daniel Macks, and Michael Voříšek for reporting bugs and suggesting 
improvements.”

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

Re: [Kicad-developers] MacOS 4.0.7 release oopsie

[Simon Wells]

I Think it mainly comes down to, if there is a bug reported on 10.9 do we want 
to be a) trying to sort out why its an issue when we only have newer systems or 
b) scrambling around trying to find an older install to be able to test the 
issue and solve it

Therefore I think its best to at most only support the oldest version that is 
still supported by apple at the time 5.0 is released (or at least when the RC 
is released).

It does not stop someone building for an older version of OSX, but if they have 
issues it is up to them (with the older operating system) to solve them

Simon



> On 27/11/2017, at 1:41 PM, Adam Wolf  wrote:
> 
> I'll definitely be keeping the 4.0 server around for at least 6+ months, but 
> the plan is to generate the 5.0 stable releases from a 10.x VM.  We should 
> have a test image after next weekend.  We had previously discussed using the 
> oldest OS version still getting security updates, which appears to be 10.11.  
> I could do anything from 10.9 on.
> 
> Do people think supporting 10.11 and newer is sufficient?
> 
> Adam Wolf
> 
> On Nov 26, 2017 6:23 PM, "Chris Pavlina"  > wrote:
> With an upcoming 5.0 I'm not sure how necessary it is to re-release
> 4.0.7 - I just want to make sure the same mistake doesn't get made for
> 5.0...
> 
> On Sun, Nov 26, 2017 at 11:03:48PM +, Wayne Stambaugh wrote:
> > 4.0.7-2 seems reasonable if the previous macos version was 4.0.7-1.
> >
> > On 11/26/2017 05:25 PM, Adam Wolf wrote:
> > > 1) I'll take a look at the script, but I suspect Nick is correct.
> > >
> > > 2) What version number should I release this 4.0.7 as? 4.0.7-2?
> > >
> > > Adam Wolf
> > >
> > > On Sun, Nov 26, 2017 at 3:35 PM, Nick Østergaard  > > > wrote:
> > >> It is because of what happened in:
> > >> [Kicad-developers] Yet another 4.0.7 release bug.
> > >> https://lists.launchpad.net/kicad-developers/msg30192.html 
> > >> 
> > >>
> > >> I suspect that the script for the OSX build did not consider that tags 
> > >> could
> > >> move. Which I think could happen like this:
> > >>
> > >> A tag will get pulled down when you pull normally. But if it changes
> > >> upstream you need to fetch with the --tags option
> > >> to sync it.
> > >>
> > >> 2017-11-26 20:12 GMT+01:00 Chris Pavlina  > >> >:
> > >>>
> > >>> Okay people, wtf happened here.
> > >>>
> > >>> Helping someone on IRC figure out a PDF export bug on 4.0.7, when I
> > >>> realized this:
> > >>>
> > >>> https://misc.c4757p.com/pastes/0AOyojEiEE0V.txt 
> > >>> 
> > >>>
> > >>> ^ "Tag stable release" is commit 631f6d5, on July 14. The ACTUAL 4.0.7
> > >>> tag is on 9f35e38, four commits later on August 1.
> > >>>
> > >>> Guess which one got released?
> > >>>
> > >>> Yup, we released the wrong commit for 4.0.7. The older one, missing
> > >>> several bug fixes. How did we manage to release something that wasn't
> > >>> actually tagged as 4.0.7? Doesn't the release build process involve
> > >>> something like "git checkout 4.0.7"? Help me understand what went wrong
> > >>> here...
> > >>>
> > >>> I'm still trying to figure out how a commit titled "tag stable release
> > >>> 4.0.7" and the actual 4.0.7 tag do not point at the same place, let
> > >>> alone how the release build process does not actually directly check out
> > >>> the 4.0.7 tag.
> > >>>
> > >>> --
> > >>> Chris
> > >>>
> > >>> ___
> > >>> Mailing list: https://launchpad.net/~kicad-developers 
> > >>> 
> > >>> Post to : kicad-developers@lists.launchpad.net 
> > >>> 
> > >>> Unsubscribe : https://launchpad.net/~kicad-developers 
> > >>> 
> > >>> More help   : https://help.launchpad.net/ListHelp 
> > >>> 
> > >>
> > >>
> > >>
> > >> ___
> > >> Mailing list: https://launchpad.net/~kicad-developers 
> > >> 
> > >> Post to : kicad-developers@lists.launchpad.net 
> > >> 
> > >> Unsubscribe : https://launchpad.net/~kicad-developers 
> > >> 
> > >> More help   : https://help.launchpad.net/ListHelp 
> > >> 
> > >>
> > >
> > > ___
> > > Mailing list: https://launchpad.net/~kicad-developers 
> > > 
> > > Post to : kicad-developers@lists.launchpad.net 
> > > 
> > > Unsubscribe : https://launchpad.net/~kicad-developers 
> 

Re: [Kicad-developers] Tweaks to about dialog

[Simon Wells]

The other option is change all the “credits tabs” in the about dialog into 
something similar to what freecad uses, then it would just be a text file to 
update thats included in the distribution and is MUCH easier to update, and can 
use multiple files (including one in the package set to include people from 
there

> On 25/11/2017, at 10:01 AM, Oliver Walters <oliver.henry.walt...@gmail.com> 
> wrote:
> 
> Can we have a link to a page on the website where we have a long form list? 
> Updating a binary file with a fluid list of contributors seems hokey. 
> 
> The 3D models for example are now script generated using Maurice's tools but 
> contributed by various people. 
> 
> On 25 Nov 2017 06:37, "Simon Wells" <swel...@gmail.com 
> <mailto:swel...@gmail.com>> wrote:
> Well if you want to keep that panel it should represent all those people who 
> have provided artistry to kicad, as such for those non programmers maybe 
> there needs to be a script or similar that someone can just put their name in 
> and it will spit out a patch that can be submitted to the mailing list
> 
> 
> 
> > On 25/11/2017, at 3:44 AM, Wayne Stambaugh <stambau...@gmail.com 
> > <mailto:stambau...@gmail.com>> wrote:
> >
> > Oliver,
> >
> > I would rather not remove the artists panel from the about dialog.  I
> > know some of those folks haven't contributed recently but many of them
> > contributed a lot of bitmaps and icons over the years so they deserve
> > credit for the efforts.  The remaining changes are fine.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 11/23/2017 08:31 AM, Oliver Walters wrote:
> >> As mentioned in previous thread, I have made some slight changes to the
> >> About dialog.
> >>
> >> 1. Wording / link tweaks
> >> 2. Removed references to outdated links (now better served from the
> >> kicad-pcb.org <http://kicad-pcb.org/> <http://kicad-pcb.org 
> >> <http://kicad-pcb.org/>> site)
> >> 3. Removed "artists" tab - very outdated, 3D models are now community
> >> contributed
> >>
> >> I have also added myself as a developer credit - if this is an
> >> acceptable indulgence.
> >>
> >> Patch attached.
> >>
> >> Regards,
> >>
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers 
> >> <https://launchpad.net/~kicad-developers>
> >> Post to : kicad-developers@lists.launchpad.net 
> >> <mailto:kicad-developers@lists.launchpad.net>
> >> Unsubscribe : https://launchpad.net/~kicad-developers 
> >> <https://launchpad.net/~kicad-developers>
> >> More help   : https://help.launchpad.net/ListHelp 
> >> <https://help.launchpad.net/ListHelp>
> >>
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers 
> > <https://launchpad.net/~kicad-developers>
> > Post to : kicad-developers@lists.launchpad.net 
> > <mailto:kicad-developers@lists.launchpad.net>
> > Unsubscribe : https://launchpad.net/~kicad-developers 
> > <https://launchpad.net/~kicad-developers>
> > More help   : https://help.launchpad.net/ListHelp 
> > <https://help.launchpad.net/ListHelp>
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <https://help.launchpad.net/ListHelp>
> 

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

Re: [Kicad-developers] Tweaks to about dialog

[Simon Wells]

Well if you want to keep that panel it should represent all those people who 
have provided artistry to kicad, as such for those non programmers maybe there 
needs to be a script or similar that someone can just put their name in and it 
will spit out a patch that can be submitted to the mailing list



> On 25/11/2017, at 3:44 AM, Wayne Stambaugh  wrote:
> 
> Oliver,
> 
> I would rather not remove the artists panel from the about dialog.  I
> know some of those folks haven't contributed recently but many of them
> contributed a lot of bitmaps and icons over the years so they deserve
> credit for the efforts.  The remaining changes are fine.
> 
> Cheers,
> 
> Wayne
> 
> On 11/23/2017 08:31 AM, Oliver Walters wrote:
>> As mentioned in previous thread, I have made some slight changes to the
>> About dialog.
>> 
>> 1. Wording / link tweaks
>> 2. Removed references to outdated links (now better served from the
>> kicad-pcb.org  site)
>> 3. Removed "artists" tab - very outdated, 3D models are now community
>> contributed
>> 
>> I have also added myself as a developer credit - if this is an
>> acceptable indulgence.
>> 
>> Patch attached.
>> 
>> Regards,
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


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

Re: [Kicad-developers] [Question] - Artist Credits

[Simon Wells]

The only way I can see any of that information staying relevant is if it is 
collated at run time from a text file or something in each of the individual 
repos that are used, that way when someone submits a lib they can include a 
name in the text file if they so wish, and then the about code could just parse 
the list and dump that information out.



> On 22/11/2017, at 11:45 PM, Oliver Walters  
> wrote:
> 
> In the "About" dialog, under the "Artists" tab, I note that Christophe 
> Boschat and Renie Marquet are credited with creation of the 3D models.
> 
> I believe this is very outdated information, and there have been a few high 
> value contributors of 3D model data in the library repositories.
> 
> Unless anyone objects, I think this information should be redacted, rather 
> than having to play catch up.
> 
> Additionally, there is a fair bit of outdated info on the "Information" tab 
> that could probably just point to the KiCad website...
> 
> At the very least I would like to update this to remove info about (for e.g.) 
> the smisioto libraries. 
> 
> Thoughts? Unless there are any objections I'll issue a patch.
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~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] LIB_TABLE tweaks

[Simon Wells]

please see KICAD_SYS_SYMBOL_DIR != KICAD_SYMBOL_DIR


> On 16/11/2017, at 06:05, Fabrizio Tappero  wrote:
> 
> Hi,
> I am not sure what the problem is but after a recent nightly build update I 
> have lost all my schematic libs. This is the lib table config
> 
> ​​
> 
> all lib files are in /usr/share/kicad/library but when I add components to a 
> new schematic no libraries gets loaded.
> 
> Can anybody help?
> 
> cheers
> Fabrizio
> 
> 
> 
> On Wed, Nov 15, 2017 at 3:42 PM, Wayne Stambaugh  > wrote:
> Gentlemen,
> 
> I'm not sure about breaking the library table file format for the
> version 5 release.  If we do, the footprint library table will not be
> compatible with older versions.  I would prefer that we push this change
> into version 6.
> 
> I'm OK with the progress dialog.  If you split that out as separate
> patch, I will merge it.
> 
> Cheers,
> 
> Wayne
> 
> On 11/15/2017 9:38 AM, Tomasz Wlostowski wrote:
> > On 15/11/17 15:30, Maciej Suminski wrote:
> >> Hi Oliver,
> >>
> >> Thank you for restoring the progress bar dialog. While the library load
> >> time has recently decreased a lot, the UI freeze still happens with long
> >> library lists.
> >> Disclaimer: I have not looked at the code yet, I am just praising the idea.
> >>
> >> As you are looking on the Symbol Library Table dialog, I suppose you
> >> might be also tempted to add a file browser to add new libraries. If
> >> that is the case, please refrain from doing so - it is done in the
> >> library editor refactor branch. If you had no such intention, then
> >> simply ignore this message.
> >
> > Hi Olivier & Orson,
> >
> > I partially implemented the simplified dialog I proposed on the dev list
> > a few days ago. Would anyone be interested in helping me finish it?
> >
> > Tom
> >
> >>
> >> Cheers,
> >> Orson
> >>
> >> On 15/11/2017 12:41 PM, Oliver Walters wrote:
> >>> Wayne, et al,
> >>>
> >>> I am really liking the way that the new symbol table works! Thanks for
> >>> the huge effort that has gone into this.
> >>>
> >>> One thing that I have noticed is that when opening (for e.g.) the
> >>> component chooser, the UI hangs while all the libraries load. Previously
> >>> there was a progress dialog which at least informed the user what was
> >>> going on.
> >>>
> >>> I have re-implemented this dialog in the attached patch set.
> >>>
> >>> Further, I have also implemented a way to individually enable / disable
> >>> each row in the library tables (this works for SYMBOL_LIB and FP_LIB).
> >>>
> >>> This is based on the idea by Tomasz. Example screenshot below:
> >>>
> >>> Inline image 1
> >>>
> >>> I have tweaked the base LIB_TABLE_GRID code such that disabled entries
> >>> are greyed out and made italic. The enabled / disabled status is
> >>> persistent in the sym/fp_lib_table files. Older version of xxx_lib_table
> >>> files are read with all rows enabled by default.
> >>>
> >>> Please find patch set attached.
> >>>
> >>> Regards,
> >>> Oliver
> >>>
> >>>
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~kicad-developers 
> >>> 
> >>> Post to : kicad-developers@lists.launchpad.net 
> >>> 
> >>> Unsubscribe : https://launchpad.net/~kicad-developers 
> >>> 
> >>> More help   : https://help.launchpad.net/ListHelp 
> >>> 
> >>>
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers 
> >> 
> >> Post to : kicad-developers@lists.launchpad.net 
> >> 
> >> Unsubscribe : https://launchpad.net/~kicad-developers 
> >> 
> >> More help   : https://help.launchpad.net/ListHelp 
> >> 
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers 
> > 
> > Post to : kicad-developers@lists.launchpad.net 
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers 
> > 
> > More help   : https://help.launchpad.net/ListHelp 
> > 
> >
> 
> ___
> Mailing list: https://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] Mac packaging plans for V5 and beyond

[Simon Wells]

Assuming its just the symlinks that are the problem i see 2 work arounds

1) do an apple and make it so you can launch the seperate apps from the app 
menu (ala xcode)
2) just have people open the bundle and run the applications from the 
applications directory (ala xcode as well)

It would be nice if you were able to change the app menu in the dock when kicad 
wasn't running and it would also be nice if there were options in the right 
click on the .app to choose alternate launchers, but unfortunately thats not 
possible.

sorry for the double post adam, this was meant to go to the list not to you




> On 15/11/2017, at 12:24, Nick Østergaard  wrote:
> 
> 2017-11-14 23:02 GMT+01.00, Adam Wolf  >:
>> Drats!  I forgot to include the link to the builds page (which is
>> definitely not ready for primetime):
>> https://builder.wayneandlayne.com/job/CompileKiCadOnCleanVM/
>> 
>> Adam Wolf
>> 
>> On Tue, Nov 14, 2017 at 4:02 PM, Adam Wolf
>>  wrote:
>>> Hi folks!
>>> 
>>> I have some things I've been working on for KiCad for quite a long
>>> time, and I'd like to wait to show them off once they're finished, but
>>> I want to announce them before the feature freeze for v5 (and maybe
>>> even get some help).
>>> 
> 
> Nice, good to see that you can still twitch.
> 
>>> 1) Reworking how python is included.  I'm now following the way Apple
>>> suggests, and this seems to fix some long-standing bugs with people
>>> who have already had things installed.  This is basically ready today,
>>> and could be incorporated into our nightlies at almost any time (with
>>> buy-in from Nick and everyone else who does those), but could also
>>> wait until #4.
>>> 
> 
> Well, where is your new work? IIRC we use your scripts from
> https://github.com/wayneandlayne/KiCadMacOSPackaging 
>  to do the
> nightlies...
> 
> Getting the issue fixed where it break if you have installed wxpython
> from elsewhere would be great.
> 
>>> 2) Signing.  I got an Apple key for my business so I can sign binaries
>>> and they won't pop up that annoying warning.  I have this working on
>>> my system, however, it cannot work with the symlink method that we're
>>> using right now for macOS packaging.  Chris and I have been talking
>>> about changing this on and off--it definitely won't happen before V5,
>>> but I'd like to get it in the works so it's finished by V6.
>>> 
>>> The remaining work on this is to document the issues with the symlink
>>> method, brainstorm ideas to see if there's an option Chris and I
>>> missed, and get buy-in and schedule the work before the V6 freeze.
>>> 
>>> 3) Builds!  A good friend of mine tried to get KiCad to build based on
>>> our build page, and he spent nearly two weeks and was unable to get it
>>> to build on macOS or Linux, and he does software development for a
>>> living!  Based on that, I thought I could help out.  I wrote some
>>> simple scripts, and now I am creating a new VM for a variety of OSes
>>> from a clean template, telling them to patch themselves with all the
>>> latest security patches, and then running an extremely minimal build
>>> script that just tests to see if it builds.  I am currently doing this
>>> for Ubuntu 16.04, 16.10, 17.04, 17.10, and macOS 10.12, everyday.  (I
>>> will be adding macOS 10.13 and 10.9-10.11, as well as Fedora 25 and 26
>>> shortly.)  This is not for packaging, this is just for developers to
>>> see that "hey, if you follow this short list of instructions, you
>>> should be able to get kicad building on your system".
>>> 
>>> I remember all the pain we had supporting builds on the developer list
>>> in the past, and I do not want to bring that back, but this should
>>> help warn us if the dependency names change, or if something breaks on
>>> those systems.
>>> 
>>> The remaining work on this is mostly documentation.  I need to
>>> document how other people can use these scripts, and also, if we have
>>> buy-in, rework the builds page so that it's easier for new developers
>>> to get started building KiCad.
>>> 
>>> 4) Reworking the macOS build scripts.  I have been talking about this
>>> for three years.  I am reworking the macOS build scripts, and actually
>>> basing them on CMake :)  I have Python, wxwidgets, wxpython, and kicad
>>> building already working.  Next I will be adding docs, packaging a
>>> dmg, packaging the extras dmg.
>>> 
>>> Right now I'm using them with Clion to add a feature to KiCad, and
>>> they're pretty slick!
>>> 
>>> The next steps here are for me to get it so this has the same output
>>> as the current system, and then get buy-in to switch to it for
>>> nightlies.  Once this has happened, I can use this to make stable
>>> builds in a VM.  This is important, because the way the V4 stable
>>> builds were made, using some tricks with homebrew, has been
>>> discontinued 

Re: [Kicad-developers] [RFC] redesign of Library Table dialog

[Simon Wells]

would it not be better to use one of the types that uses native tables rather 
than wxgrid? what is wxgrid giving you that the native tables aren't?


> On 12/11/2017, at 13:44, Oliver Walters  
> wrote:
> 
> Hi Tom,
> 
> This is a fantastic idea, I think that your mock up has a lot of good UX 
> improvements. 
> 
> In particular I like the idea of "active" for each library. You then do not 
> have to find a library once you have removed it from the table, only tick 
> "active". Brilliant.
> 
> Regarding the "advanced options" button, why not have an extra button (next 
> to Add / Remove / etc) which says "Edit". Clicking on this brings up a dialog 
> for the selected library with all extra options...
> 
> Should the footprints / symbols / etc / all appear in the same list? I like 
> the idea of a single library preferences dialog, but what if the various 
> library types were separated by a panel on the left hand side, as is common 
> in many preferences windows?  I'm thinking of Eclipse as an example.
> 
> Here is an example of something I have in a development branch (that has been 
> wanting my attention for some time). The core code to make this dialog style 
> is pretty solid, so I could share that part with you if you think this is a 
> good idea.
> 
> 
> 
> 
> I'm thinking that the window above would be adapted to have in the left 
> column:
> 
> "Library Options"
> "Symbol Libraries"
> "Footprint Libraries"
> 
> Overall I am really behind your idea :)
> 
> On Sun, Nov 12, 2017 at 11:01 AM, Tomasz Wlostowski 
> > wrote:
> Dear colleagues,
> 
> Now that we have the new library table system in the schematic editor
> (may thanks Wayne!), we also have the library table dialog to configure
> the tables.
> 
> For many users - including myself - these dialogs are a bit too complex.
>  A few days ago I asked the Polish Kicad community of what users find
> annoying and the complexity of the library manager window was heavily
> criticized. The main points were exposing too many advanced functions
> straight away (such as special configuration options for each plugin)
> and requiring the user to type in the library paths by hand or paste
> them instead of selecting the files with a browser. Currently I prefer
> editing the lib-table files by hand instead of using the GUI.
> 
> I believe that the introduction of the new library system into eeschema
> is a good chance to consolidate the library management UI and improve
> Kicad's User Experience. In the attachment, you'll find the example
> design of simplified library setup dialog, with some remarks and
> comments. Your feedback will be greatly appreciated!
> 
> Tom
> 
> PS1. I haven't started coding yet - this is just a mockup.
> PS2. The current library table dialog will remain accessible if the user
> selects the 'show advanced options' checkbox - so if some of you prefer
> the current UI, it's not going to disappear :)
> 
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~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] adding support for OCCT

[Simon Wells]

OCE is the same licence as OCCT which is LGPL since 6.7.0

thanks


> On 12/11/2017, at 02:52, Wayne Stambaugh <stambau...@gmail.com> wrote:
> 
> That's a show stopper unless someone is willing to step up and fix this
> issues.  Just out of curiosity and a bit of laziness, what is the OCCT
> license before we decide to make it a dependency?
> 
> On 11/11/2017 03:43 AM, Nick Østergaard wrote:
>> It did work for me on archlinux, as in it could build. But when
>> exporting with kicad2step it seems like it does not export the complete
>> model.
>> 
>> Den 11. nov. 2017 03.55 skrev "Simon Wells" <swel...@gmail.com 
>> <mailto:swel...@gmail.com>
>> <mailto:swel...@gmail.com <mailto:swel...@gmail.com>>>:
>> 
>>Currently kicad only supports OCE but with FreeCAD moving to occt by
>>default it seems this might not be the best long term solution
>> 
>>Currently OCE (which is 0.18) is based on OCCT 6.9 where as OCCT has
>>released 7.3. This was one of the primary reasons that FreeCAD chose
>>to move to OCCT by default
>> 
>>What i am thinking is
>> 
>>-DKICAD_USE_OCE changes to -DKICAD_USE_CASCADE or
>>-DKICAD_USE_OPENCASCADE or -DKICAD_USE_OCC and the options change
>>from OFF/ON to OFF/OCCT/OCE/ON with ON being autoish.
>> 
>>By default ON would first check for OCE and if its found it would
>>use that, if it was not found then it would check for OCCT. Where
>>OCCT/OCE would force it to use the specific package.
>> 
>>I have checked to see whether kicad can build/run with OCCT and
>>found no issues with OCCT 7.2 except needing to remove 2 #include's,
>>Nick tried it with OCCT 6.9 i believe and found it did not work,
>>then tried with 7.0+ and it did work. but we could say that version
>>7 of OCCT is required.
>> 
>>OCCT/OCE and their version would also be added to the copy version
>>info window to provide additional runtime/buildtime information for
>>debugging.
>> 
>>Regards
>> 
>>Simon
>>___
>>Mailing list: https://launchpad.net/~kicad-developers
>><https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>>
>>Post to : kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>
>><mailto:kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>>
>>Unsubscribe : https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>><https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>>
>>More help   : https://help.launchpad.net/ListHelp 
>> <https://help.launchpad.net/ListHelp>
>><https://help.launchpad.net/ListHelp 
>> <https://help.launchpad.net/ListHelp>>
>> 
>> 
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp 
>> <https://help.launchpad.net/ListHelp>
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <https://help.launchpad.net/ListHelp>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] adding support for OCCT

[Simon Wells]

Currently kicad only supports OCE but with FreeCAD moving to occt by default it 
seems this might not be the best long term solution

Currently OCE (which is 0.18) is based on OCCT 6.9 where as OCCT has released 
7.3. This was one of the primary reasons that FreeCAD chose to move to OCCT by 
default

What i am thinking is

-DKICAD_USE_OCE changes to -DKICAD_USE_CASCADE or -DKICAD_USE_OPENCASCADE or 
-DKICAD_USE_OCC and the options change from OFF/ON to OFF/OCCT/OCE/ON with ON 
being autoish.

By default ON would first check for OCE and if its found it would use that, if 
it was not found then it would check for OCCT. Where OCCT/OCE would force it to 
use the specific package.

I have checked to see whether kicad can build/run with OCCT and found no issues 
with OCCT 7.2 except needing to remove 2 #include's, Nick tried it with OCCT 
6.9 i believe and found it did not work, then tried with 7.0+ and it did work. 
but we could say that version 7 of OCCT is required.

OCCT/OCE and their version would also be added to the copy version info window 
to provide additional runtime/buildtime information for debugging.

Regards

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

Re: [Kicad-developers] pcbnew Append Board functionality not always available

[Simon Wells]

Speaking of append board causing crashes

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



> On 11/11/2017, at 14:03, Wayne Stambaugh  wrote:
> 
> Hey David,
> 
> The main reason is that no one has had the time to look into it.  I
> don't just want to always enable appending a board only to find out it
> crashes kicad in the project mode so it would just take (how much I do
> not know) time for someone to look into it.
> 
> Cheers,
> 
> Wayne
> 
> On 11/10/2017 4:51 PM, David Godfrey wrote:
>> Hi Wayne,
>> 
>> This just cropped up (again) on #kicad irc channel so I thought I'd
>> check and see if there is a reason why
>>  File->Append Board
>> is only accessible if PCBnew is run standalone (as compared to from the
>> Project Interface)
>> 
>> -- 
>> Regards
>> David Godfrey
>> SB Tech Services
>> 
>> chat: with /dcg_mx/ at
>> #sbts:matrix.org  (Computer)
>> #sbts:matrix.org  (mobile Device)
>> 
>> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~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] Symbol library table merged.

[Simon Wells]

I think that the kicad.github.io  interface to the 
libraries have the potential to go a long way to being able to include less 
libraries by default as it will be easier to find the libraries that one needs, 
as before that interface it was a fair bit harder to find out what libraries 
certain parts were in (more so with libs than footprints due to pretty).


> On 11/11/2017, at 01:36, Oliver Walters  
> wrote:
> 
> Wayne,
> 
> You're probably right that there's no good way to decide which libraries are 
> the "default" ones. Maybe this is the best entry-level approach.
> 
> I think that a background library loader will solve a lot of the "freeze" 
> problems, but I imagine that is a lot of work.
> 
> On Fri, Nov 10, 2017 at 11:17 PM, Wayne Stambaugh  > wrote:
> Oliver,
> 
> Including all of the libraries has been requested many times in the
> past.  Personally, I don't work that way but it seems to be the
> preference of a large percentage of users.  My guess is new users will
> prefer to have access to all libraries initially and start removing them
> when they get tired of the the overhead involved in using them.  I
> wouldn't be opposed to removing some of them but I doubt you will get a
> consensus on this issue.
> 
> Cheers,
> 
> Wayne
> 
> On 11/9/2017 10:38 PM, Oliver Walters wrote:
> > Wayne,
> >
> > That's great news, and a welcome addition.
> >
> > Regarding the decision to include all the libraries by default - is this
> > a sensible solution? No project requires all libraries to be added, and
> > some of the libraries are particularly large. Is it really that
> > difficult for new users to understand that libraries are there to be
> > added and removed at will? Personally if I found all libraries loaded by
> > default I would unload most of them straight away...
> >
> > Perhaps I am not aware of the justification for this approach.
> >
> > Cheers,
> >
> > Oliver
> >
> > On Fri, Nov 10, 2017 at 1:35 PM, Wayne Stambaugh  > 
> > >> wrote:
> >
> > I finally got the symbol library table changes merged into the
> > development branch of KiCad so be prepared for some pretty significant
> > changes in the way symbol libraries are handled both from a user and a
> > developer perspective.  Also be prepared for a massive amount of
> > complaining about the change.  I wrote a blog post for the KiCad
> > website[1] with all of the pertinent information you need to know before
> > you remap your schematic symbols.  If users have any questions, please
> > point them to blog post.  One thing I didn't mention in the blog post
> > (although I may add it) is the component (now symbol) chooser dialog
> > took another performance hit.  The default global symbol library table
> > contains all of the symbol libraries of which there are over 90 so the
> > symbol library load time shot up significantly when using the chooser.
> > The Eeschema load time actually go better since like the footprint
> > library table, symbol libraries are now loaded on demand so only the
> > libraries that contain symbols in the schematic get loaded.  The rest of
> > them get loaded as required.  If you find any issues please file a bug
> > report and include a copy of the project files and symbol libraries (if
> > possible) prior to the remapping that are causing the issue so I can fix
> > them.
> >
> > This should be the last major change except for the new symbol library
> > manager before the feature freeze of the stable 5 version.  Thank you
> > for your patience during this transition and enjoy.
> >
> > Cheers,
> >
> > Wayne
> >
> > [1]: http://kicad-pcb.org/post/symbol-lib-table/ 
> > 
> >  > >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers 
> > 
> >  > >
> > Post to : kicad-developers@lists.launchpad.net 
> > 
> >  > >
> > Unsubscribe : https://launchpad.net/~kicad-developers 
> > 
> >  > >
> > More help   : https://help.launchpad.net/ListHelp 
> > 
> >  > >
> >
> >
> 
> 
> 

Re: [Kicad-developers] [REQUEST] Default library install location

[Simon Wells]

i wouldn't particularly call it handholding but i do believe its something that 
should be automatically done by kicad if we are to continue bundling such a 
number of libraries. The extra command in the toolbar is not particularly 
obvious unless you already know about it or it is pointed out to you, i would 
almost prefer it to be something that is not a specific command and the code is 
only used when you go to save to a system library. although it should 
notify/warn that it is a system library and due to this will be copied into 
your local user library/dir


> On 9/11/2017, at 13:04, Wayne Stambaugh <stambau...@gmail.com> wrote:
> 
> Exactly how much hand holding is KiCad expected to do?  There is already
> a "save the current library as" command in the file menu of both the
> symbol and footprint library editors.  There is a small bug in that
> grays out the command until you load a symbol but it allows you to save
> any library to a folder that the user has write access to and modify it
> at will without changing the originally installed libraries which IMO is
> a good thing.  Of course you could do a good old fashion file copy or
> git clone or ...  How many ways to we really need to perform this one
> simple task or am I completely missing something.
> 
> On 11/08/2017 06:15 PM, Simon Wells wrote:
>> ideally if someone tried to save to a bundled library there should be 
>> something that pops up and says you can't/shouldn't and then offers to do 
>> most if not all of that for you, however i would prefer to see it only 
>> saving the footprint to userdir, i think you will find this is how most 
>> other software would handle a similar circumstance
>> 
>>> On 9/11/2017, at 12:12, easyw <ea...@katamail.com> wrote:
>>> 
>>>> I think it's a far more risky that a user makes accidental changes to the
>>>> bundled library. Simple users should not need to touch it, and should
>>>> rather copy or make a new part.
>>> 
>>> so if a user wants to add a missing parts to his/her library he/her needs 
>>> to save it to a different location, close the i.e. fp editor, copy with 
>>> administrative privileges the fp to the Admin folder and restart the sw to 
>>> use it?
>>> I don't think other sw are using this procedure...
>>> This is just my opinion...
>>> 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


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

Re: [Kicad-developers] [REQUEST] Default library install location

[Simon Wells]

ideally if someone tried to save to a bundled library there should be something 
that pops up and says you can't/shouldn't and then offers to do most if not all 
of that for you, however i would prefer to see it only saving the footprint to 
userdir, i think you will find this is how most other software would handle a 
similar circumstance

> On 9/11/2017, at 12:12, easyw  wrote:
> 
>> I think it's a far more risky that a user makes accidental changes to the
>> bundled library. Simple users should not need to touch it, and should
>> rather copy or make a new part.
> 
> so if a user wants to add a missing parts to his/her library he/her needs to 
> save it to a different location, close the i.e. fp editor, copy with 
> administrative privileges the fp to the Admin folder and restart the sw to 
> use it?
> I don't think other sw are using this procedure...
> This is just my opinion...
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~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] Footprint file format question

[Simon Wells]

at some point changing the models to be mm rather than 0.1" or whatever it is 
now needs to be seriously looked at


> On 7/11/2017, at 01:59, Wayne Stambaugh  wrote:
> 
> Be careful here.  If the 3d model offset is currently in some units
> other than mm and you change this, all existing 3d model offsets will be
> broken.
> 
> On 11/6/2017 7:56 AM, Oliver Walters wrote:
>> That's what I expected. It then appears that there is a bug in the 3D
>> code with regard to model offset. I'm working on a related patch set
>> that will fix this, I just wanted to be sure. Thanks Wayne
>> 
>> On Mon, Nov 6, 2017 at 11:53 PM, Wayne Stambaugh > > wrote:
>> 
>>It should be mm like all of the other coordinates.
>> 
>>On 11/6/2017 7:32 AM, Oliver Walters wrote:
>>> With regard to the 3D model offset paramater
>>> 
>>> e.g. 
>>> 
>>> (at (xyz a b c))
>>> 
>>> Are the units stored in the file inches or mm?
>>> 
>>> Cheers,
>>> Oliver
>>> 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>
>>> Post to : kicad-developers@lists.launchpad.net
>>
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>
>>> More help   : https://help.launchpad.net/ListHelp
>>
>>> 
>> 
>>___
>>Mailing list: https://launchpad.net/~kicad-developers
>>
>>Post to : kicad-developers@lists.launchpad.net
>>
>>Unsubscribe : https://launchpad.net/~kicad-developers
>>
>>More help   : https://help.launchpad.net/ListHelp
>>
>> 
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


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

Re: [Kicad-developers] eeschema copy working?

[Simon Wells]

not sure if it changed or not but you are using the paste toolbar button rather 
than cmd+v?


> On 25/10/2017, at 08:21, Wayne Stambaugh  wrote:
> 
> Hey Bernhard,
> 
> Copy (ctrl+c) and paste (ctrl+v) work as expected on windows as does the
> paste button when there is a valid block copied to the clipboard.  I
> seem to recall this working correctly on linux so this looks like yet
> another osx specific issue.
> 
> Cheers,
> 
> Wayne
> 
> On 10/24/2017 2:52 PM, Bernhard Stegmaier wrote:
>> Hi all,
>> 
>> does copy of a selected block in eeschema (master branch) in general 
>> work right now (on Windows, Linux)?
>> For me on macOS it doesn’t seem to work in any way…
>> 
>> I can select a block, then either hit Cmd-C or select copy via context menu.
>> If I try to paste via Cmd-V I just get a warning “No block to paste”.
>> Toolbar buttons also don’t work - just greyed out all the time.
>> I can remember that buttons always had some issues, but at least using 
>> shortcuts did work some while ago...
>> 
>> 
>> Regards,
>> Bernhard
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~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] application for svg to png

[Simon Wells]

it might be worth timing it with rsvg to see how long it takes to
convert from svg to png (also doing the same timing with using
inkscape) as if we can make the time reasonable then regardless of how
we proceed we could even have multiple sizes of each icon as xpm
arrays, can someone who actually has a working version time the cmake
conversion of the svgs to pngs using inkscape as unfortunately it is
broken for me

On 1 September 2017 at 07:07, Jon Evans <j...@craftyjon.com> wrote:
> Could we merge the PNG files into a tilemap like is commonly done for
> mobile/web applications?
>
> On Thu, Aug 31, 2017 at 3:04 PM, jp charras <jp.char...@wanadoo.fr> wrote:
>>
>> Le 31/08/2017 à 20:27, Wayne Stambaugh a écrit :
>> > Is it possible to create image libraries with different size images
>> > using the method you described below?  If so, this could give us a path
>> > forward for high dpi monitor support.  This problem is only going to get
>> > worse as time goes on so it would be nice to have a solution.
>> >
>> > As for using rsvg for the svg to png conversion, I don't have a strong
>> > opinion but then I don't maintain the image files so my opinion carries
>> > less weight on this issue.  If our image maintainers are set on Inkscape
>> > then I support their decision.  I'm guessing you could make using rsvg
>> > optional with some clever CMake hacking.
>>
>> Only for myself, I can say Inkscape is the svg editor, but no need to use
>> it to convert svg to png.
>> As long an other tool is freely and easily available on all platforms, I
>> am fine with it.
>>
>> Currently we use svg (source) -> png -> png filtered -> .cpp file image of
>> png
>> The cpp is used because it is a text file easy to compile and include in
>> binaries.
>>
>> if the svg to png conversion is easy, no need to distribute the
>> intermediate .cpp files.
>> if of course there is a way to support 2 or 3 set of icons with different
>> sizes, this is really good.
>>
>> However I am not especially thrilled by using a lot of png files (500
>> currently, and if 3 sizes
>> (small, normal, high) are available, 1500 files).
>> My concern is due to the fact loading 500 files each time kicad is started
>> could generate a very
>> noticeable loading time.
>> I know some applications with a very long loading time (especially
>> Inscape) and this is really a
>> serious problem.
>> So I am not sure using 500 .png files instead of only one (a .so or a
>> .dll) file is a very good idea.
>> This is especially true on Windows.
>>
>> >
>> > rsvg is packaged for msys2 so on windows there are should be no issues
>> > using it.
>> >
>> > On 8/31/2017 12:46 PM, Simon Wells wrote:
>> >> converting the png to cpp files can be done the same how it is now
>> >> (using cmake), although it would really only be used on linux i would
>> >> also look at making it so that they all went into a single cpp file
>> >> rather than the numerous files it currently is.
>> >>
>> >> On windows the files would end up as part of the "resource file" which
>> >> (not being up to date on windows) is either built into the app in the
>> >> resource part of the binary or there is a file but it still only looks
>> >> for it in once place
>> >>
>> >> On OSX it looks in the resources folder of the application bundle
>> >>
>> >> so there aren't the issues of it possibly being in many place which
>> >> exist with .so files at least and i think the same with dll files, but
>> >> on linux seeing as wxwidgets doesn't seem to like any of the icon
>> >> options they would just be built in as they currently are as xpm. If
>> >> you don't have the icon files on macOS (which is the only one that
>> >> stores them as physical files i believe) then it would be your fault
>> >> as you obviously must have deleted them from the bundle as they would
>> >> be part of the build process. Every other osx application has the
>> >> icons as resources in the resource folder or in one of the
>> >> language-dependent subfolders
>> >>
>> >>
>> >> http://docs.wxwidgets.org/trunk/group__group__funcmacro__gdi.html#ga30fc362d22b3045f58aed54fc808f203
>> >> as can be seen here the wxBITMAP_PNG macro automatically sorts out the
>> >> different places they can be found on each platform.
>> >>
>> >> rsvg is one option for d

Re: [Kicad-developers] application for svg to png

[Simon Wells]

converting the png to cpp files can be done the same how it is now
(using cmake), although it would really only be used on linux i would
also look at making it so that they all went into a single cpp file
rather than the numerous files it currently is.

On windows the files would end up as part of the "resource file" which
(not being up to date on windows) is either built into the app in the
resource part of the binary or there is a file but it still only looks
for it in once place

On OSX it looks in the resources folder of the application bundle

so there aren't the issues of it possibly being in many place which
exist with .so files at least and i think the same with dll files, but
on linux seeing as wxwidgets doesn't seem to like any of the icon
options they would just be built in as they currently are as xpm. If
you don't have the icon files on macOS (which is the only one that
stores them as physical files i believe) then it would be your fault
as you obviously must have deleted them from the bundle as they would
be part of the build process. Every other osx application has the
icons as resources in the resource folder or in one of the
language-dependent subfolders

http://docs.wxwidgets.org/trunk/group__group__funcmacro__gdi.html#ga30fc362d22b3045f58aed54fc808f203
as can be seen here the wxBITMAP_PNG macro automatically sorts out the
different places they can be found on each platform.

rsvg is one option for doing the svg->png conversion (its also fast on
OSX) not sure about other platforms but it is available for
linux/windows/macOS so theres no platform issues, however this could
equally be replaced with imagemagick instead which can use inkscape as
the backend if you have it installed but can also use rsvg as well (or
other options as well including an internal one) but this would not
give the same png/ascii file on all platforms obviously.

there is also the option of commiting the png files in place of the
icon cpp files that are currently committed and then on linux its just
a case of creating the cpp files from the png which shouldn't take too
long as its effectively just catting files. this would avoid the issue
of needing the same png created from the same svg on all platforms, if
we did want to use imagemagick




On 31 August 2017 at 07:21, jp charras <jp.char...@wanadoo.fr> wrote:
> Le 30/08/2017 à 20:54, Simon Wells a écrit :
>> my goal is more to move to using the wxBITMAP_PNG macro which would
>> use real files on osx and some weird resource hybrid on windows and
>> xpms on the other platforms that don't have a decent option. hence i
>> need to convert all the files into png
>>
>
> Perhaps you should explain *exactly* what you want to do.
>
> Before using svg files as sources, icons were stored in .xpm files, often 
> created from a .png icon.
> Only ascii files can be included in .cpp or .h sources.
>
> This was really a pain to maintain icons, and I do do want back to .png files 
> as sources.
> (note of course this is the .png files converted to an equivalent binary tab 
> coded in .cpp file that
> are included in kicad sources, so Kicad uses currently .png icons internally, 
> so I do not really
> understand the meaning of "using the wxBITMAP_PNG macro")
>
> Moreover I am not convinced using real files to store .png icons is a good 
> idea.
> (what happens if these files are for some reason not found?
> We have already issues with .so or .dll or script files not found on all 
> platforms)
>
> So my requirements are:
>
> - source icons must be .svg files.
> - avoid exotic tools to convert .svg files to ascii files. It must be easily 
> available (and run
> without crash) on 3 platforms.
> - png files can be only intermediate files created by the build process (like 
> any object file)
> - ideally, the same .svg file should give the same ascii file on all 
> platforms.
>
>
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

[Kicad-developers] application for svg to png

[Simon Wells]

currently cmake is setup to use inkscape and only inkscape for doing
the svg to png conversion, on osx at least this is broken (only
visibly broken when you enable MAINTAIN_PNGS), its also really slow
loading inkscape on osx,

I was doing some testing and found that rsvg could easily create
comparible files and with some effort likely imagemagick could as
well.

Would anyone be against switching to rsvg for the conversion?

___
Mailing list: https://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 remote lib retrieval to SCH_LEGACY_PLUGIN_CACHE

[Simon Wells]

sorry i mean setting it to 0

On 14 August 2017 at 08:39, Simon Wells <swel...@gmail.com> wrote:
> setting CURLOPT_SSL_VERIFYHOST breaks newer ssl on macOS so likely
> better to not just disable that
>
> On 14 August 2017 at 07:26, Badr Hack <b...@hackinvent.com> wrote:
>> Hi,
>>
>> Here in the attachment the patch that add the remote lib retrieval.
>>
>> Badr
>> Le 2017-08-13 17:29, Badr Hack a écrit :
>>>
>>> Hi,
>>>
>>> Those couple of days I was checking how to update EESCHEMA to add
>>> remote libraries retrieval function.
>>>
>>> Since am familiar with legacy format, I updated the plugin:
>>> SCH_LEGACY_PLUGIN_CACHE in charge of parsing the *.lib files.
>>>
>>> The idea was to create a new type of library EESchema-REMOTELIBRARY (I
>>> put an example in the attachment)
>>> The content of this library is the following:
>>> EESchema-REMOTELIBRARY Version 1.0
>>> URL https://www.example.com/mylib1.lib
>>> URL https://www.example.com/mylib2.lib
>>> ...
>>>
>>> This lib file is saved localy and specify the path of each remote
>>> library you want to retrieve.
>>>
>>> The updated code seemlessly check the type of the library, if it is
>>> EESchema-LIBRARY it parse it like always, else if it is
>>> EESchema-REMOTELIBRARY it download each remote lib and parse it when
>>> it is EESchema-LIBRARY (no recusivity with EESchema-REMOTELIBRARY).
>>>
>>> The impacted files are:  sch_legacy_plugin.cpp and sch_legacy_plugin.h
>>> -> I implemented the algo and made some tweeks to use LINE_READER
>>> instead of FILE_LINE_READER as argument to manage to use
>>> STRING_LINE_READER
>>>
>>> I also modified KICAD_CURL_EASY::KICAD_CURL_EASY() to set the option
>>> CURLOPT_SSL_VERIFYHOST to 0 to disable ssl certificate checking in
>>> https requests. This modification is not required, but was useflul for
>>> our case where our server is behind ssl without certificate on the
>>> domaine, just ip addresses.
>>>
>>> I made a prototype in the attachment, it is woring.
>>>
>>> I don't know if this modification is inline with the arachitecture of
>>> kicad?
>>>
>>> Badr
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~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 remote lib retrieval to SCH_LEGACY_PLUGIN_CACHE

[Simon Wells]

setting CURLOPT_SSL_VERIFYHOST breaks newer ssl on macOS so likely
better to not just disable that

On 14 August 2017 at 07:26, Badr Hack  wrote:
> Hi,
>
> Here in the attachment the patch that add the remote lib retrieval.
>
> Badr
> Le 2017-08-13 17:29, Badr Hack a écrit :
>>
>> Hi,
>>
>> Those couple of days I was checking how to update EESCHEMA to add
>> remote libraries retrieval function.
>>
>> Since am familiar with legacy format, I updated the plugin:
>> SCH_LEGACY_PLUGIN_CACHE in charge of parsing the *.lib files.
>>
>> The idea was to create a new type of library EESchema-REMOTELIBRARY (I
>> put an example in the attachment)
>> The content of this library is the following:
>> EESchema-REMOTELIBRARY Version 1.0
>> URL https://www.example.com/mylib1.lib
>> URL https://www.example.com/mylib2.lib
>> ...
>>
>> This lib file is saved localy and specify the path of each remote
>> library you want to retrieve.
>>
>> The updated code seemlessly check the type of the library, if it is
>> EESchema-LIBRARY it parse it like always, else if it is
>> EESchema-REMOTELIBRARY it download each remote lib and parse it when
>> it is EESchema-LIBRARY (no recusivity with EESchema-REMOTELIBRARY).
>>
>> The impacted files are:  sch_legacy_plugin.cpp and sch_legacy_plugin.h
>> -> I implemented the algo and made some tweeks to use LINE_READER
>> instead of FILE_LINE_READER as argument to manage to use
>> STRING_LINE_READER
>>
>> I also modified KICAD_CURL_EASY::KICAD_CURL_EASY() to set the option
>> CURLOPT_SSL_VERIFYHOST to 0 to disable ssl certificate checking in
>> https requests. This modification is not required, but was useflul for
>> our case where our server is behind ssl without certificate on the
>> domaine, just ip addresses.
>>
>> I made a prototype in the attachment, it is woring.
>>
>> I don't know if this modification is inline with the arachitecture of
>> kicad?
>>
>> Badr
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~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] Build failed in Jenkins: osx-kicad-adam-head #369

[Simon Wells]

don't worry this is a build setup issue rather than a code or build-script issue

On 8 August 2017 at 04:22, Miguel Angel Ajo  wrote:
> See 
>
> --
> Started by user Nick Ostergaard
> Building remotely on c4osx (osx) in workspace 
> 
>  > git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
>  > git config remote.origin.url 
> https://github.com/wayneandlayne/KiCadMacOSPackaging.git # timeout=10
> Fetching upstream changes from 
> https://github.com/wayneandlayne/KiCadMacOSPackaging.git
>  > git --version # timeout=10
>  > git fetch --tags --progress 
> https://github.com/wayneandlayne/KiCadMacOSPackaging.git 
> +refs/heads/*:refs/remotes/origin/*
>  > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
>  > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
> Checking out Revision 7afd9efd5bbbc57165b6be073e37885f62680771 
> (refs/remotes/origin/master)
> Commit message: "Merge pull request #3 from xzcvczx/unicode_pasteboard"
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f 7afd9efd5bbbc57165b6be073e37885f62680771
>  > git rev-list 7afd9efd5bbbc57165b6be073e37885f62680771 # timeout=10
> [osx-kicad-adam-head] $ /bin/sh -xe 
> /var/folders/mp/kcdg3qp93rjcdkv03hk95gz0gp/T/jenkins7327747009972409083.sh
> + sw_vers -productVersion
> 10.11.6
> + xcode-select -p
> /Applications/Xcode.app/Contents/Developer
> + source /Users/kicad/.bashrc
> ++ export HOMEBREW_PREFIX=/Users/kicad/homebrew
> ++ HOMEBREW_PREFIX=/Users/kicad/homebrew
> ++ export 
> PATH=/Users/kicad/homebrew/bin:/Users/kicad/homebrew/opt/gettext/bin:/Users/kicad/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin
> ++ 
> PATH=/Users/kicad/homebrew/bin:/Users/kicad/homebrew/opt/gettext/bin:/Users/kicad/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin
> ++ export 
> PATH=/Users/kicad/homebrew/opt/gettext/bin:/Users/kicad/homebrew/bin:/Users/kicad/homebrew/opt/gettext/bin:/Users/kicad/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin
> ++ 
> PATH=/Users/kicad/homebrew/opt/gettext/bin:/Users/kicad/homebrew/bin:/Users/kicad/homebrew/opt/gettext/bin:/Users/kicad/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin
> + git checkout -- .
> + echo '--- compile_kicad.py2017-03-17 15:03:50.488385700 +0100
> +++ compile_kicad_patched.py2017-03-17 15:05:50.894385700 +0100
> @@ -21,9 +21,9 @@
>
> "-DCMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk",
>"-DCMAKE_OSX_DEPLOYMENT_TARGET=10.9",
>"-DwxWidgets_CONFIG_EXECUTABLE=../wx/wx-bin/bin/wx-config",
> -  "-DKICAD_SCRIPTING=ON",
> -  "-DKICAD_SCRIPTING_MODULES=ON",
> -  "-DKICAD_SCRIPTING_WXPYTHON=ON",
> +  "-DKICAD_SCRIPTING=OFF",
> +  "-DKICAD_SCRIPTING_MODULES=OFF",
> +  "-DKICAD_SCRIPTING_WXPYTHON=OFF",
>"-DPYTHON_EXECUTABLE=" + which("python"),
>"-DPYTHON_SITE_PACKAGE_PATH=" + 
> os.path.realpath("wx/wx-bin/lib/python2.7/site-packages"),
>"-DKICAD_USE_OCE=ON",
> '
> + patch -p0 -i /Users/kicad/test/kicad-mac-packaging/hack6.patch
> patching file compile_kicad.py
> Reversed (or previously applied) patch detected!  Assume -R? [n]
> Apply anyway? [n]
> Skipping patch.
> 2 out of 2 hunks ignored -- saving rejects to file compile_kicad.py.rej
> patching file install_docs.sh
> Reversed (or previously applied) patch detected!  Assume -R? [n]
> Apply anyway? [n]
> Skipping patch.
> 1 out of 1 hunk ignored -- saving rejects to file install_docs.sh.rej
> patching file install_libraries.sh
> Reversed (or previously applied) patch detected!  Assume -R? [n]
> Apply anyway? [n]
> Skipping patch.
> 1 out of 1 hunk ignored -- saving rejects to file install_libraries.sh.rej
> patching file package_extras.sh
> Reversed (or previously applied) patch detected!  Assume -R? [n]
> Apply anyway? [n]
> Skipping patch.
> 1 out of 1 hunk ignored -- saving rejects to file package_extras.sh.rej
> patching file package_kicad.sh
> Reversed (or previously applied) patch detected!  Assume -R? [n]
> Apply anyway? [n]
> Skipping patch.
> 2 out of 2 hunks ignored -- saving rejects to file package_kicad.sh.rej
> patching file setup.sh
> Reversed (or previously applied) patch detected!  Assume -R? [n]
> Apply anyway? [n]
> Skipping patch.
> 1 out of 1 hunk ignored -- saving rejects to file setup.sh.rej
> Build step 'Execute shell' marked build as failure
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : 

Re: [Kicad-developers] Transparent Canvas

[Simon Wells]

(unless this has changed in hte last 2 weeks) you have to double click
on the color swatch/button

On 2 August 2017 at 06:46, Tomasz Wlostowski  wrote:
> On 01.08.2017 20:16, Leonel Caraccioli wrote:
>> Dears:
>>
>> I'm using OpenGL Canvas, but this canvas have not layer transparency. It
>> was a really useful characteristic.
> Leonel,
>
> It does. You can choose the opacity of each layer in the colors
> selection window that pops up if you click on the color swatch on the
> layer selector widget (right side of the screen).
>
> Tom
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] MacOS nightly build failing...

[Simon Wells]

just had a look at the jenkins stuff and it seems the osx build server
is down, i will yell at the build server owner

On 31 July 2017 at 02:23, Simon Wells <swel...@gmail.com> wrote:
> the reason it stopped on the 24th is because the download server was
> full i believe, that issue has since been resolved, and i am doing a
> local build now on osx to see whether osx building is broken or
> whether jenkins just didn't restart uploading the completed files to
> the download server
>
> On 31 July 2017 at 01:39, Ruth Ivimey-Cook <r...@ivimey.org> wrote:
>> Folks,
>>
>> Is it on the radar that the mac build has been failing for a week or so now,
>> at least according to http://downloads.kicad-pcb.org/osx/nightly/
>>
>> Ruth
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~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] MacOS nightly build failing...

[Simon Wells]

the reason it stopped on the 24th is because the download server was
full i believe, that issue has since been resolved, and i am doing a
local build now on osx to see whether osx building is broken or
whether jenkins just didn't restart uploading the completed files to
the download server

On 31 July 2017 at 01:39, Ruth Ivimey-Cook  wrote:
> Folks,
>
> Is it on the radar that the mac build has been failing for a week or so now,
> at least according to http://downloads.kicad-pcb.org/osx/nightly/
>
> Ruth
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~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] Having trouble PCB

[Simon Wells]

you might find the user list or the forums to be more suitable to this request

thanks

On 23 July 2017 at 02:22, ike shields  wrote:
> Hi,
>
> I am using Kicad Version BZR-4027 on Debian 8 see below.
>
> All seems to be Ok until I go to PCBNew and click on “net”. Then it comes up
> with a number of footprints not found. I have checked the files ending in
> CSV, CMP, NET and all seem to me to be ok all the footprint to me are there
> so it should work but it will not. Can you help me please, the print outs
> are below.
>
>
> ike@debiank:~$ cat /proc/version
>
> Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version
> 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.39-1 (2016-12-30)
>
>
> ike@debiank:~$ cat /etc/*-release
>
> PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
>
> NAME="Debian GNU/Linux"
>
> VERSION_ID="8"
>
> VERSION="8 (jessie)"
>
> ID=debian
>
>
> Kicad Version BZR-4027
>
>
> one try
>
>
> Reading Netlist "/home/ike/DIHaz2428VoltsV1/Dihaz28VoltsV1.net"
>
> Using component/footprint link file
> "/home/ike/DIHaz2428VoltsV1/Dihaz28VoltsV1.cmp"
>
> Component [Q5]: footprint  not found
>
> Component [D2]: footprint  not found
>
> Component [Q3]: footprint  not found
>
> Component [U1]: footprint <78xxW> not found
>
>
> another try
>
>
> Reading Netlist "/home/ike/DIHaz2428VoltsV1/Dihaz28VoltsV1.net"
>
> Using component/footprint link file
> "/home/ike/DIHaz2428VoltsV1/Dihaz28VoltsV1.cmp"
>
> Module [U2]: Pad [3] not found
>
> Module [U1]: Pad [3] not found
>
> Module [U1]: Pad [1] not found
>
> Module [U5]: Pad [3] not found
>
> Module [U8]: Pad [3] not found
>
> Module [U3]: Pad [1] not found
>
> Module [U1]: Pad [2] not found
>
> Module [U5]: Pad [2] not found
>
> Module [U8]: Pad [2] not found
>
> Module [U2]: Pad [2] not found
>
> Module [U3]: Pad [2] not found
>
> Module [U8]: Pad [1] not found
>
> Module [U5]: Pad [1] not found
>
> Module [U2]: Pad [1] not found
>
> Module [U3]: Pad [3] not found
>
>
> Regards
>
> Ike Shields
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~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] Bugs in hotkey assignments - cannot differentiate NumPad hotkeys.

[Simon Wells]

probably a stupid question but was your numlock on or off?

On 21 April 2017 at 12:13, Clemens Koller  wrote:
> Hi!
>
> On 2017-04-20 16:56, Maciej Sumiński wrote:
>> We would really appreciate if bug reports were kept on the bug tracker.
>> I am afraid this report will be lost after a few days of mailing list
>> traffic, unless someone fixes the problem right now.
>
> No worries. Is it okay to extend the current report or should I open another 
> one?
> Additionally, I would be glad to get some feedback if there is already 
> someone working on this issue or if it won't get fixed at all in eeschema for 
> some other general redesign reasons.
>
> It would also be okay to point me to some code to get my hands dirty on my 
> own if it makes sense in this case. MMMV.
>
> Regards,
>
> Clemens
>
>
> On 2017-04-20 16:56, Maciej Sumiński wrote:
>> Hi Clemens,
>>
>> We would really appreciate if bug reports were kept on the bug tracker.
>> I am afraid this report will be lost after a few days of mailing list
>> traffic, unless someone fixes the problem right now.
>>
>> Regards,
>> Orson
>>
>> On 04/19/2017 10:49 PM, Clemens Koller wrote:
>>> Hi, there!
>>>
>>> I am starting a new, clean EESchema - latest git of today.
>>> The default Hotkeys are Zoom In = F1, Zoom Out = F2, etc...
>>>
>>> Issue 1:
>>> I was planning to change the Zoom In/Out hotkeys in Preferences - Schematic 
>>> Editor Options - Controls to use
>>> Zoom In = NumPad + and Zoom Out = NumPad -
>>>
>>> The issue is, that the Set Hotkey dialog actually recognizes the NumPad +/- 
>>> keystroke and closes, but it doesn't accepted the Hotkey assignments. F1 
>>> and F2 still stays as before without further notice.
>>>
>>> Using the non-NumPad + and - keys seem to work, but they might be used in a 
>>> different way later on as these are just different keys.
>>> So, why doesn't Kicad recognize the NumPad Keys, why doesn't Kicad 
>>> regognize different keys as such?
>>>
>>>
>>> Issue 2:
>>> The Tooltips of the Zoom buttons don't get updated with the newly assigned 
>>> keys. The still show F1 and F2 for the zooming whereas + and - was assigned.
>>> Can we fix that?
>>>
>>>
>>> This might be related to: https://bugs.launchpad.net/kicad/+bug/1562617
>>>
>>> Regards,
>>>
>>> Clemens
>>>
>>>
>>> Version information:
>>> Application: kicad
>>> Version: (2017-04-19 revision 1366cf6ac)-master, release build
>>> Libraries: wxWidgets 3.0.2
>>>libcurl/7.53.1 OpenSSL/1.0.2k zlib/1.2.11 libpsl/0.17.0 
>>> (+libicu/58.2) libssh2/1.8.0
>>> Platform: Linux 4.10.10-1-ARCH x86_64, 64 bit, Little endian, wxGTK
>>> - Build Info -
>>> wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
>>> Boost: 1.63.0
>>> Curl: 7.53.1
>>> KiCad - Compiler: GCC 6.3.1 with C++ ABI 1010
>>> Settings: USE_WX_GRAPHICS_CONTEXT=OFF
>>>   USE_WX_OVERLAY=OFF
>>>   KICAD_SCRIPTING=ON
>>>   KICAD_SCRIPTING_MODULES=ON
>>>   KICAD_SCRIPTING_WXPYTHON=ON
>>>   KICAD_SCRIPTING_ACTION_MENU=OFF
>>>   BUILD_GITHUB_PLUGIN=ON
>>>   KICAD_USE_OCE=OFF
>>>
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] New wxPython released.

[Simon Wells]

gah wxwidgets 3.0, 3.1 or both was what i was meaning there just to clarify

On 20 April 2017 at 08:16, Simon Wells <swel...@gmail.com> wrote:
> from my quick look i couldn't work out whether it supported 3.0 or 3.1 or both
>
> On 20 April 2017 at 00:50, Nick Østergaard <oe.n...@gmail.com> wrote:
>> Yay, I guess this is good news for python people.
>>
>> 2017-04-19 14:37 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
>>> I just stumbled across this announcement:
>>>
>>> http://wxwidgets.org/news/2017/04/new-major-wxpython-release/
>>>
>>> I was beginning to wonder if this was ever going to happen.  I know it
>>> will be a while before it gets packaged but at some point we will have
>>> to figure out how to build it into KiCad so we can finally support python 3.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] New wxPython released.

[Simon Wells]

from my quick look i couldn't work out whether it supported 3.0 or 3.1 or both

On 20 April 2017 at 00:50, Nick Østergaard  wrote:
> Yay, I guess this is good news for python people.
>
> 2017-04-19 14:37 GMT+02:00 Wayne Stambaugh :
>> I just stumbled across this announcement:
>>
>> http://wxwidgets.org/news/2017/04/new-major-wxpython-release/
>>
>> I was beginning to wonder if this was ever going to happen.  I know it
>> will be a while before it gets packaged but at some point we will have
>> to figure out how to build it into KiCad so we can finally support python 3.
>>
>> Cheers,
>>
>> Wayne
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] disable icons in menus by default on osx

[Simon Wells]

this is only a single #ifdef to default it to off as osx has been as
long as i have been using it, its not compiling the icons out or
anything

On 11 April 2017 at 07:12, Wayne Stambaugh <stambau...@gmail.com> wrote:
> I thought the reason that we added this option is so that users could
> choose if they wanted to show the icons in menus.  I seem to remember
> from the original discussion that some of our osx users didn't like the
> fact that they were compiled out of osx builds.  Do we really need to
> add the ugly #if defined()/#endif code?
>
> As for the icon size, fixing that would likely not be trivial.  A long
> time ago we used 16 X 16 images but users were complaining that they
> were too small as display resolution increased so we increased them to
> 24 X 24.  We could create an image library with multiple size images to
> resolve this issue.
>
> On 4/8/2017 6:55 AM, Simon Wells wrote:
>> also as noticed with this the icons seem overly huge for the menu, are
>> they actually the right size on any platform? as on osx at least if you
>> want the option there they should really be created at the right size so
>> that it fits in with how tall a row should be in a menu rather than
>> making each row huge as seen in screenshot
>>
>>
>>
>>
>> On 8 April 2017 at 22:42, Simon Wells <swel...@gmail.com
>> <mailto:swel...@gmail.com>> wrote:
>>
>> Please see attached patch to disable icons in the menus by default
>> on osx
>>
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~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] disable icons in menus by default on osx

[Simon Wells]

Please see attached patch to disable icons in the menus by default on osx


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

Re: [Kicad-developers] OpenGL fallback and video compat test

[Simon Wells]

Cairo is much faster since the awesome devs at CERN (iirc) had another
go at it. But thats currently only in nightlies and i believe has been
decided to use that instead of trying to make a DC GAL. Have you tried
recentish nightly cairo?

On 24 March 2017 at 21:51, Lorenzo Marcantonio  wrote:
> On Thu, Mar 23, 2017 at 08:11:31PM -0400, Chris Pavlina wrote:
>> Hi,
>>
>> I've been thinking about my intent to make KiCad fall back cleanly to
>> Cairo when OpenGL isn't available. From what I can see, there are
>
> Wouldn't be better to try to make a DC version of the GAL instead of
> cairo since it is... well.. quite slow? (and that's an understatement)
>
> --
> Lorenzo Marcantonio
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~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] OpenGL fallback and video compat test

[Simon Wells]

would this work on the useless 945 chipset or whichever one it is that
reports having hte right opengl features but does not?

On 24 March 2017 at 13:39, Chris Pavlina  wrote:
> Yeah, good autosave helps.
>
> To be fair this is a bit offtopic - what I want really is a properly
> functioning way to check if OpenGL works, not a way to clean up if it
> doesn't. The fact that that involves containing an unavoidable crash in
> a child process is a bit of an implementation detail IMO ;)
>
> On Thu, Mar 23, 2017 at 08:34:39PM -0400, Jon Evans wrote:
>> On Thu, Mar 23, 2017 at 8:30 PM, Chris Pavlina 
>> wrote:
>>
>> > Remember, once a crash has actually
>> > occurred in the main program you're already past the point of no return
>> > for possible data loss.
>> >
>> >
>> One alternative approach which can work quite well (Mentor Graphics does
>> this) is to get a really good auto-save system going.  The better the
>> auto-save system, the less likely it is that any crash could cause data
>> loss.  Of course, crashes in general are a bad user experience, but if you
>> open the program back up and your work is right there, it feels a bit
>> better :-)
>>
>> -J
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~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] UI improvements

[Simon Wells]

one of the things that irks me about component is even though its
meant to only be schematic being component libs a lot of the questions
asked in irc will state component when they use that as either a
generic term for symbols AND footprints or sometimes footprints only,
as to some i guess thats still part of a "component definition".

If at some point down the line we did introduce some sort of package
that was symbol/footprint/model/spice/... i think that would be a
much better thing to call a component.

On 24 March 2017 at 02:30, Chris Pavlina <pavlina.ch...@gmail.com> wrote:
> Ah, interesting. This is a ... fiddly distinction, I don't like it. This
> is one case where I think we really should _not_ follow.
>
> I'm still not flipping from component back to symbol myself though -
> this is just Altium. The rest of them still mostly use "component",
> right?
>
> On Thu, Mar 23, 2017 at 09:19:45AM -0400, Wayne Stambaugh wrote:
>> Here is the Altium library documentation:
>>
>> http://www.altium.com/documentation/17.0/display/ADES/((More+about+Components+and+Libraries))_AD
>>
>> Interestingly the terms component, part, symbol, model, and footprint
>> are all mentioned.
>>
>> It appears that the folks at Altium have answered the is it a symbol or
>> component question:
>>
>> http://www.altium.com/documentation/17.0/display/ADES/((Understanding+Models,+Components+and+Libraries))_AD#!UnderstandingModelsComponentsandLibraries-IsitaSymboloraComponent
>>
>> I was looking at the top level documentation where I saw the term
>> component.  Maybe symbol would be an acceptable term.  In our case it
>> certainly would be more accurate.  The only real difference is in the
>> level of detail added to the the schematic symbol that determines the
>> symbol/component difference and it's pretty grey definition at best.  I
>> retract my original statement and go with my preference of symbol.
>>
>> On 3/23/2017 9:05 AM, Chris Pavlina wrote:
>> > Many of them actually don't have that notion. Surprisingly enough,
>> > Altium of all things has a system that is remarkably similar to our own,
>> > just with a different library management discipline applied in their
>> > standard library.
>> >
>> > On Fri, Mar 24, 2017 at 01:50:08AM +1300, Simon Wells wrote:
>> >> Do most of the other EDA packages not refer to a component as
>> >> something that combines a symbol AND a footprint though?
>> >>
>> >> On 24 March 2017 at 01:34, Wayne Stambaugh <stambau...@gmail.com> wrote:
>> >>> I'm going to weigh in on this because this has been on my radar with the
>> >>> symbol library table work I've been doing.  I do agree that we need to
>> >>> pick one term and use it consistently.  My preference is the term symbol
>> >>> because in my mind this is a component[1] and this is symbolic
>> >>> representation[2] of a component ergo symbol.  However, I spent some
>> >>> time this week checking out the documentation for all of the major and
>> >>> quite a few minor EDA applications and they *all* use the term component
>> >>> when talking about libraries.  This makes me think that for the sake of
>> >>> uniformity with other EDA applications, we should use the term
>> >>> component.  While I'm not a proponent of doing something just because
>> >>> that's what everyone else is doing, in this case using the term
>> >>> component may make users coming from other EDA apps a bit more
>> >>> comfortable.  Personally, I'm comfortable with either term but maybe we
>> >>> should not stray to far from the norm here.
>> >>>
>> >>> [1]:
>> >>> http://www.digikey.com/product-detail/en/stackpole-electronics-inc/CF14JT10K0/CF14JT10K0TR-ND/1741265
>> >>> [2]: https://commons.wikimedia.org/wiki/File:Resistor_symbol_America.svg
>> >>>
>> >>> On 3/23/2017 7:52 AM, Thor-Arne Hovland wrote:
>> >>>> Symbol has been used as long as I can remember.
>> >>>>
>> >>>> The proper names should probably be defined to avoid confusion.
>> >>>>
>> >>>> In my book:
>> >>>> A "symbol" is a generic repesentation for drawing a schematic,
>> >>>> and that is whats used in eeschema right now.
>> >>>>
>> >>>> A "footprint" is the pads and silkscreen ++ used in pcbnew.
>> >>>>
>> >>>> A "hous

Re: [Kicad-developers] UI improvements

[Simon Wells]

Do most of the other EDA packages not refer to a component as
something that combines a symbol AND a footprint though?

On 24 March 2017 at 01:34, Wayne Stambaugh <stambau...@gmail.com> wrote:
> I'm going to weigh in on this because this has been on my radar with the
> symbol library table work I've been doing.  I do agree that we need to
> pick one term and use it consistently.  My preference is the term symbol
> because in my mind this is a component[1] and this is symbolic
> representation[2] of a component ergo symbol.  However, I spent some
> time this week checking out the documentation for all of the major and
> quite a few minor EDA applications and they *all* use the term component
> when talking about libraries.  This makes me think that for the sake of
> uniformity with other EDA applications, we should use the term
> component.  While I'm not a proponent of doing something just because
> that's what everyone else is doing, in this case using the term
> component may make users coming from other EDA apps a bit more
> comfortable.  Personally, I'm comfortable with either term but maybe we
> should not stray to far from the norm here.
>
> [1]:
> http://www.digikey.com/product-detail/en/stackpole-electronics-inc/CF14JT10K0/CF14JT10K0TR-ND/1741265
> [2]: https://commons.wikimedia.org/wiki/File:Resistor_symbol_America.svg
>
> On 3/23/2017 7:52 AM, Thor-Arne Hovland wrote:
>> Symbol has been used as long as I can remember.
>>
>> The proper names should probably be defined to avoid confusion.
>>
>> In my book:
>> A "symbol" is a generic repesentation for drawing a schematic,
>> and that is whats used in eeschema right now.
>>
>> A "footprint" is the pads and silkscreen ++ used in pcbnew.
>>
>> A "housing" is the physical package i.e. the 3D model.
>>
>> The current way of doing things is a bit confusing and causes
>> many "symbols" to be reused in the library.
>> This is not effective when someting is to be changed.
>>
>> It could be a good idea to introduce a "part" that stores all the needed
>> information like symbol, footprint, pin connections between symbol and
>> footprint,
>> 3D modell, documentation.
>>
>> This might be more intuitive for new user who I see repeatedly trying to
>> match a symbol
>> with pins "G-S-D" to a footprint with pins "1-2-3".
>>
>> Just my 2 cent
>>
>> -Original Message- From: Chris Pavlina
>> Sent: Thursday, March 23, 2017 3:30 AM
>> To: Simon Wells
>> Cc: KiCad Developers
>> Subject: Re: [Kicad-developers] UI improvements
>>
>> Are we calling them "symbols" now? Internally they are called with
>> "components" or "parts" depending on whether they are on a schematic...
>>
>> On Thu, Mar 23, 2017 at 03:25:03PM +1300, Simon Wells wrote:
>>> just a slight segue is it not better to refer to symbols rather
>>> than components? as with the footprints being seperated from the
>>> symbols i don't see the justification for calling it a component (will
>>> also require renaming other stuff)
>>>
>>> On 23 March 2017 at 12:12, Chris Pavlina <pavlina.ch...@gmail.com> wrote:
>>> > On Wed, Mar 22, 2017 at 11:53:40PM +0100, Clemens Koller wrote:
>>> >> Hello, Fabrizio!
>>> >>
>>> >> The horizontal + vertical justify radio buttons could possibly be
>>> >> improved by showing the alignment visually as it's done in [1] by
>>> using >> a 3 x 3 radio button matrix. It can also reduce the number of
>>> clicks to >> 1 to adjust hor + vert simultaneously.
>>> >>
>>> >> The timestamp is not human readable. It seems strange to me to dump
>>> it >> as hex-number on the UI. (WTF!?)
>>> >
>>> > I'm struggling to think of a use for this. Maybe for power users, to
>>> > jump quickly to the component in the raw sch file by searching for it -
>>> > but why not just search for the reference?
>>> >
>>> > I wonder how many people would complain if I took that out.
>>> >
>>> >>
>>> >> The Component/Chip Name thingy seems to be lost a bit on the lower
>>> >> left. Maybe some sorting of the elements based on the usage/setup
>>> >> procedure as well as logic dependency could do some good.
>>> >>
>>> >> Regards,
>>> >>
>>> >> Clemens
>>> >>
>>> >> [1] https://wiki.openoffi

Re: [Kicad-developers] UI improvements

[Simon Wells]

just a slight segue is it not better to refer to symbols rather
than components? as with the footprints being seperated from the
symbols i don't see the justification for calling it a component (will
also require renaming other stuff)

On 23 March 2017 at 12:12, Chris Pavlina  wrote:
> On Wed, Mar 22, 2017 at 11:53:40PM +0100, Clemens Koller wrote:
>> Hello, Fabrizio!
>>
>> The horizontal + vertical justify radio buttons could possibly be improved 
>> by showing the alignment visually as it's done in [1] by using a 3 x 3 radio 
>> button matrix. It can also reduce the number of clicks to 1 to adjust hor + 
>> vert simultaneously.
>>
>> The timestamp is not human readable. It seems strange to me to dump it as 
>> hex-number on the UI. (WTF!?)
>
> I'm struggling to think of a use for this. Maybe for power users, to
> jump quickly to the component in the raw sch file by searching for it -
> but why not just search for the reference?
>
> I wonder how many people would complain if I took that out.
>
>>
>> The Component/Chip Name thingy seems to be lost a bit on the lower left. 
>> Maybe some sorting of the elements based on the usage/setup procedure as 
>> well as logic dependency could do some good.
>>
>> Regards,
>>
>> Clemens
>>
>> [1] https://wiki.openoffice.org/wiki/File:WG9-9.png
>>
>>
>>
>>
>> On 2017-03-22 10:32, Fabrizio Tappero wrote:
>> > hi guys,
>> > I am looking at some new icons that were introduced in kicad by the people 
>> > who made the related functionalities and at the user experience in 
>> > general. If any of you guys has any feedback about possible (aesthetic) UI 
>> > improvements I would love to know.
>> >
>> > Specifically I am looking at this menu.
>> >
>> > Inline image 1
>> >
>> > the section "Chip Name" is a part that I use a lot and I find a little 
>> > "mysterious". Before going further with a possible patch to improve a 
>> > little the usability of it I would like to know if there is any of you 
>> > interesting in giving an opinion. I would love to know from the person who 
>> > made it what exactly is the Chip Name section for. I feel it is not so 
>> > evident to the user.
>> >
>> > cheers
>> > Fabrizio
>> >
>> >
>> >
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > Post to : kicad-developers@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [PATCH] Check required libraries in FindwxWidgets.cmake

[Simon Wells]

does this still work if one has chosen a monolithic wxwidgets build?

On 21 March 2017 at 03:16, Jan Mrázek  wrote:
> Both official one and KiCad one version of FindwxWidgets.cmake do not check if
> all the required components are part of the wxWidgets build. This couses 
> trouble
> on Ubuntu when user misses libwxgtk3.0-dev package - CMake succeeds, build 
> does
> not.
>
> Probably only posibility to get a list of components is to grep output of
> wx-config.
>
> Base component is removed from the dependencies as it is not present on GUI
> builds of wxWidgets.
>
> Fixes: lp:1630020
> * https://bugs.launchpad.net/kicad/+bug/1630020
> ---
>  CMakeLists.txt   |  2 +-
>  CMakeModules/FindwxWidgets.cmake | 36 
>  2 files changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 18f2052e1..63f5b17a5 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -511,7 +511,7 @@ add_definitions( -DWX_COMPATIBILITY )
>  # See line 41 of CMakeModules/FindwxWidgets.cmake
>  set( wxWidgets_CONFIG_OPTIONS ${wxWidgets_CONFIG_OPTIONS} --static=no )
>
> -find_package( wxWidgets 3.0.0 COMPONENTS gl aui adv html core net base xml 
> stc REQUIRED )
> +find_package( wxWidgets 3.0.0 REQUIRED gl aui adv html core net xml stc )
>
>  # Include wxWidgets macros.
>  include( ${wxWidgets_USE_FILE} )
> diff --git a/CMakeModules/FindwxWidgets.cmake 
> b/CMakeModules/FindwxWidgets.cmake
> index 9a6e56f7b..cb13bf93a 100644
> --- a/CMakeModules/FindwxWidgets.cmake
> +++ b/CMakeModules/FindwxWidgets.cmake
> @@ -141,6 +141,7 @@
>  #
>  # Miguel A. Figueroa-Villanueva (miguelf at ieee dot org).
>  # Jan Woetzel (jw at mip.informatik.uni-kiel.de).
> +# Jan Mrázek (email at honzamrazek.cz)
>  #
>  # Based on previous works of:
>  # Jan Woetzel (FindwxWindows.cmake),
> @@ -728,6 +729,38 @@ else()
>endforeach()
>  endmacro()
>
> +#
> +# Check if all the required libraries are present in the build. The only 
> way
> +# to find out the list of libraries is to run wx-config and grep its 
> output
> +# - libraries are hardcoded in the help text.
> +#
> +macro(WX_CONFIG_CHECK_LIBS)
> +  execute_process(
> +COMMAND "${wxWidgets_CONFIG_EXECUTABLE}"
> +OUTPUT_VARIABLE _wx_selected_config
> +ERROR_VARIABLE _wx_selected_config
> +RESULT_VARIABLE _wx_result
> +ERROR_QUIET
> +)
> +  string(REGEX MATCH "Available libraries in this build are:\n(.*)\n"
> +   _wx_available_libs ${_wx_selected_config})
> +  string(REGEX REPLACE "Available libraries in this build are:\n(.*)\n"
> +"\\1" _wx_available_libs ${_wx_available_libs})
> +  string(STRIP _wx_available_libs ${_wx_available_libs})
> +  string(REPLACE " " ";" _wx_available_libs "${_wx_available_libs}")
> +  foreach(lib ${wxWidgets_FIND_COMPONENTS})
> +list(FIND _wx_available_libs "${lib}" _index)
> +if (${_index} LESS 0)
> +  list(APPEND _missing ${lib})
> +  DBG_MSG("Library ${lib} not found")
> +endif()
> +  endforeach()
> +  if (_missing)
> +string(REPLACE ";" " " _missing "${_missing}")
> +message(FATAL_ERROR "Missing following wxWidgets libraris: 
> ${_missing}")
> +  endif()
> +endmacro()
> +
>  #-
>  # UNIX: Start actual work.
>  #-
> @@ -741,6 +774,9 @@ else()
>  if(wxWidgets_CONFIG_EXECUTABLE)
>set(wxWidgets_FOUND TRUE)
>
> +  # check if current build supports all required libraries
> +  WX_CONFIG_CHECK_LIBS()
> +
># get defaults based on "wx-config --selected-config"
>WX_CONFIG_SELECT_GET_DEFAULT()
>
> --
> 2.11.0
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://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 to compile _pcbnew.kiface only once

[Simon Wells]

Well unfortunately we can't do much until python build is fixed.

On 18 March 2017 at 01:11, Wayne Stambaugh <stambau...@gmail.com> wrote:
> Thanks Adam and Simon for taking care of this!
>
> On 3/16/2017 6:24 PM, Adam Wolf wrote:
>> I have some time to do testing on this now that the stable package is
>> finished.
>>
>> Simon, please resend if possible and I'll take a look this weekend.
>>
>> Adam Wolf
>>
>> On Thu, Mar 16, 2017, 5:05 PM Simon Wells <swel...@gmail.com
>> <mailto:swel...@gmail.com>> wrote:
>>
>> the problem is most of the python bundling crap is in patches (and
>> yeah it is a bit hackish) wwas passed off to adam for testing but he
>> never came back. but its also reliant on the python build not being
>> broken. It is also as unhackish as it will get due to how cmake works,
>> althought we MAY be able to push something upstream to cmake to fix
>> DUE to the python bundling guidelines released by apple but i don't
>> know whether they give a damn about them. and whats required to follow
>> apples guidelides re python bundling.
>>
>>
>>
>> On 17 March 2017 at 10:35, Bernhard Stegmaier
>> <stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>> wrote:
>> > As I said before, I plan to work on the whole python packaging
>> stuff as discussed below if no one else volunteers to do before.
>> > I had some look around on how to do this, but I didn’t find any
>> out-of-the-box solution which could be integrated quickly.
>> > Unfortunately, I am still busy with other (non KiCad) things and
>> it will still take a few weeks until I can start working on it (I
>> hope during easter holidays)…
>> >
>> >> On 16 Mar 2017, at 22:08, Chris Pavlina <pavlina.ch...@gmail.com
>> <mailto:pavlina.ch...@gmail.com>> wrote:
>> >>
>> >> I'm of two minds on this. On one hand, I'd like to disable
>> scripting on
>> >> the macOS nightlies until it's fixed, so macOS users still *have*
>> >> nightlies. On the other hand, I worry that doing so will remove
>> >> motivation to actually fix it.
>> >>
>> >> Is anyone actually _actively working on a fix_? I keep seeing chatter
>> >> about this, but no actual attempts to fix it.
>> >>
>> >> Honestly I think the patch that broke the build should be
>> reverted until
>> >> a fix can be prepared, but considering who submitted it, I doubt I'll
>> >> have any say there.
>> >>
>> >>
>> >> On Thu, Mar 16, 2017 at 04:56:14PM -0400, Jean-Paul Louis wrote:
>> >>> I agree 150% with Bernhard.
>> >>>
>> >>> A disabled Python is 150% better than no new build at all.
>> >>>
>> >>> I do not understand why OS X users are considered second class
>> citizens.
>> >>>
>> >>> Just my $0.02,
>> >>> Jean-Paul
>> >>> N1JPL
>> >>>
>> >>>
>> >>>
>> >>>> On Mar 16, 2017, at 2:06 PM, Bernhard Stegmaier
>> <stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>> wrote:
>> >>>>
>> >>>> I have just seen people on the forum complaining that OSX
>> nightlies still don’t build.
>> >>>>
>> >>>> @Simon:
>> >>>> Do you intend to push your changes, no matter how hackish?
>> >>>> Might at least be a start to work with.
>> >>>>
>> >>>> Or, just disable python scripting at all until the whole python
>> bundling has been sorted out?
>> >>>> Having no python scripting is better than having no build or a
>> build where it doesn’t work right...
>> >>>>
>> >>>>
>> >>>> Regards,
>> >>>> Bernhard
>> >>>>
>> >>>>> On 21 Feb 2017, at 18:56, Simon Wells <swel...@gmail.com
>> <mailto:swel...@gmail.com>> wrote:
>> >>>>>
>> >>>>> I have previously sent a patch to adam for testing that bundled
>> >>>>> python. but it was a bit hackish as since python is a system lib
>> >>>>> b

Re: [Kicad-developers] Patch to compile _pcbnew.kiface only once

[Simon Wells]

the problem is most of the python bundling crap is in patches (and
yeah it is a bit hackish) wwas passed off to adam for testing but he
never came back. but its also reliant on the python build not being
broken. It is also as unhackish as it will get due to how cmake works,
althought we MAY be able to push something upstream to cmake to fix
DUE to the python bundling guidelines released by apple but i don't
know whether they give a damn about them. and whats required to follow
apples guidelides re python bundling.



On 17 March 2017 at 10:35, Bernhard Stegmaier <stegma...@sw-systems.de> wrote:
> As I said before, I plan to work on the whole python packaging stuff as 
> discussed below if no one else volunteers to do before.
> I had some look around on how to do this, but I didn’t find any 
> out-of-the-box solution which could be integrated quickly.
> Unfortunately, I am still busy with other (non KiCad) things and it will 
> still take a few weeks until I can start working on it (I hope during easter 
> holidays)…
>
>> On 16 Mar 2017, at 22:08, Chris Pavlina <pavlina.ch...@gmail.com> wrote:
>>
>> I'm of two minds on this. On one hand, I'd like to disable scripting on
>> the macOS nightlies until it's fixed, so macOS users still *have*
>> nightlies. On the other hand, I worry that doing so will remove
>> motivation to actually fix it.
>>
>> Is anyone actually _actively working on a fix_? I keep seeing chatter
>> about this, but no actual attempts to fix it.
>>
>> Honestly I think the patch that broke the build should be reverted until
>> a fix can be prepared, but considering who submitted it, I doubt I'll
>> have any say there.
>>
>>
>> On Thu, Mar 16, 2017 at 04:56:14PM -0400, Jean-Paul Louis wrote:
>>> I agree 150% with Bernhard.
>>>
>>> A disabled Python is 150% better than no new build at all.
>>>
>>> I do not understand why OS X users are considered second class citizens.
>>>
>>> Just my $0.02,
>>> Jean-Paul
>>> N1JPL
>>>
>>>
>>>
>>>> On Mar 16, 2017, at 2:06 PM, Bernhard Stegmaier <stegma...@sw-systems.de> 
>>>> wrote:
>>>>
>>>> I have just seen people on the forum complaining that OSX nightlies still 
>>>> don’t build.
>>>>
>>>> @Simon:
>>>> Do you intend to push your changes, no matter how hackish?
>>>> Might at least be a start to work with.
>>>>
>>>> Or, just disable python scripting at all until the whole python bundling 
>>>> has been sorted out?
>>>> Having no python scripting is better than having no build or a build where 
>>>> it doesn’t work right...
>>>>
>>>>
>>>> Regards,
>>>> Bernhard
>>>>
>>>>> On 21 Feb 2017, at 18:56, Simon Wells <swel...@gmail.com> wrote:
>>>>>
>>>>> I have previously sent a patch to adam for testing that bundled
>>>>> python. but it was a bit hackish as since python is a system lib
>>>>> bundleutilies doesn't copy it.
>>>>>
>>>>> On 21 February 2017 at 21:28, Bernhard Stegmaier
>>>>> <stegma...@sw-systems.de> wrote:
>>>>>>
>>>>>> On 21 Feb 2017, at 00:31, Wayne Stambaugh <stambau...@gmail.com> wrote:
>>>>>>
>>>>>> On 2/20/2017 6:27 PM, Nick Østergaard wrote:
>>>>>>
>>>>>> 2017-02-20 23:48 GMT+01:00 Bernhard Stegmaier <stegma...@sw-systems.de>:
>>>>>>
>>>>>> How is this done on Windows?
>>>>>> You also don’t have a global filesystem with one Python there where you 
>>>>>> just
>>>>>> copy it into the right place… where does the Windows installer put those
>>>>>> files and how do you use them from some installed Python? Are there 
>>>>>> issues
>>>>>> with library paths of the library dependencies that come with KiCAD when
>>>>>> used from an external Python?
>>>>>>
>>>>>>
>>>>>> I am not aware of any issues with it on windows, but I don't really use
>>>>>> windows.
>>>>>>
>>>>>> People have requested to include pip with the windows install, and
>>>>>> that is done now, so I assume that at least something works.
>>>>>>
>>>>>> I am not sure if the user uses the shell inside pcbnew or calls the
>>>>>> python bundled 

Re: [Kicad-developers] Environment variables for classroom installation

[Simon Wells]

this is also only in nightly and not in stable

On 17 March 2017 at 02:58, Wayne Stambaugh  wrote:
> The symbol library table is not in play yet.  It will be soon.  You
> should continue to use the current schematic symbol library path search
> until then.
>
> On 3/16/2017 9:37 AM, Ingo Kletti wrote:
>> Hello all
>>
>> and sorry for pushing this to the dev mailing list, but I hope to get an
>> authoritative answer from you:
>>
>>
>> I am preparing the update from KiCad 4.0.4 to 4.0.6 on the approximately
>> 70 PCs used in our classroom installations (all Windows 7 64 Bit).
>>
>> We are using a centrally managed library for schematic symbols and pcb
>> footprints which is stored on a network share.
>>
>> To make that work, the paths in the 'kicad.pro' template file and the
>> environment variables KICAD_PTEMPLATES KISYSMOD and KISYS3DMOD are
>> modified to point to the correct network share folders.
>>
>> My test install shows that for schematic symbols a new file
>> 'sym_lib_table' has been introduced, analog to 'fp_lib_table' for
>> footprints. In that file a variable 'KICAD_SYS_SYMBOL_DIR' is used for
>> path declaration, but the corresponding environment variable is not set
>> during the installation process.
>>
>> Is there any value in setting the environment variable
>> 'KICAD_SYS_SYMBOL_DIR' (like Kicad using it if it is set, otherwise it
>> uses the legacy kicad.pro definitions) or should I even expect
>> interferences with the path declaration from the 'kicad.pro' template
>> when 'KICAD_SYS_SYMBOL_DIR' is set?
>>
>> Regards,
>>
>> Ingo
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~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] Footprint features - stable vs nightly

[Simon Wells]

the only current thing in nightly not in stabel i know of is rounded
pads, this was added a few months ago, and there was a fair amount of
discussion on the list as how best to handle the non-backward
compatibility issues inherit with adding a feature like this. The
general concesus iirc was that no nightly-only footprints would be
merged into the github libs until kicad-5 is released.

I think for the current feature it might just be worth putting
something in a CI script that will be tested pre-merge into the github
libs and in the long term we can look at a better way for handling new
features in footprints/symbols/libs

Simon

On 11 March 2017 at 12:46, Chris Pavlina  wrote:
> This doesn't directly address your question - but couldn't the automated
> library checker actually load the footprints into KiCad, via the Python
> API, to truly verify that they parse in KiCad proper?
>
> On Sat, Mar 11, 2017 at 10:39:37AM +1100, Oliver Walters wrote:
>> Hi all,
>>
>> Can someone tell me a complete list of the differences between footprint
>> "features" in nightly and stable? There is a recent issue where someone
>> added a footprint using roundrect pads and broke a library for someone
>> using stable.
>>
>> I can easily add a search for "roundrect" to the automated library checker
>> but what else should I be looking for?
>>
>> As an aside, I think it would be **very** helpful if the footprint library
>> loader was able to skip over "bad" footprints and continue to load.
>> Currently a single bad footprint prevents any subsequent footprints from
>> loading. If we had the ability to skip bad ones, then we could add "future"
>> footprints and these would simply be ignored by stable version.
>>
>> Cheers,
>> Oliver
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Update on component chooser

[Simon Wells]

I wonder whether it is worth making this a policy that no new
components can use wxTreeListCtrl as the performance on OSX is abysmal
and there are alternatives, granted they are slightly more complicated
but a much better long term solution (not only in osx performance) but
in code structure as well.

On 6 March 2017 at 17:00, Chris Pavlina  wrote:
> Ready for testing, I'll merge tomorrow since it mostly only touches my
> parts. This is a pretty significant improvement, and solves some
> wxTreeListCtrl quirks as well.
>
>
> On Sun, Mar 05, 2017 at 05:02:10PM +0100, Nick Østergaard wrote:
>> Please report back when it is ready for testing...
>>
>> 2017-03-05 15:04 GMT+01:00 Chris Pavlina :
>> > Ongoing refactor of COMPONENT_TREE_SEARCH_CONTAINER into a
>> > model-view-adapter architecture is at [1] (componentchooser branch of my
>> > dev repo). The code is seriously cleaner now and significantly faster.
>> > Should be done later today.
>> >
>> > [1] https://github.com/cpavlina/kicad/tree/componentchooser
>> >
>> >
>> > On Sat, Mar 04, 2017 at 01:38:37PM -0500, Chris Pavlina wrote:
>> >> Hi,
>> >>
>> >> Just thought I'd provide a quick update on what's going on with the
>> >> component chooser. Things have been pretty delayed - I've had more
>> >> issues than expected, and I'm trying to work around my school schedule
>> >> too - but I'm still moving along (and I have almost a full week off now,
>> >> most of which will be spent on this).
>> >>
>> >> Currently, I'm working on resolving a macOS performance issue that
>> >> causes updates to cost about 0.5s per keystroke for large library sets.
>> >> I'm looking at two possible solutions:
>> >>
>> >>  - Implement my own wxDataViewModel, reimplementing most or all of
>> >>COMPONENT_TREE_SEARCH_CONTAINER in the process and making the
>> >>component tree a model/view architecture. This is very much
>> >>preferable, but I'm not 100% sure if this will give the desired
>> >>performance boost. I'll do this first as it's a useful refactoring
>> >>anyway.
>> >>
>> >>  - Implement an optimizing adapter that wraps TWO_COLUMN_TREE_LIST. This
>> >>would populate the underlying list only with visible items,
>> >>intercepting "expand" events and populating the parents with their
>> >>children on demand. This is an ugly hack and I'd like not to resort
>> >>to this.
>> >>
>> >> When I'm done with this, I want to make a couple more changes before
>> >> proceeding, based on user feedback:
>> >>
>> >>  - Make the component info box collapsible.
>> >>  - Also display component info in a rich tooltip
>> >>  - Add a resizable splitter between footprint and symbol display
>> >>
>> >> Once all of this is done, the next steps are:
>> >>
>> >>  - Add footprint filtering and selection
>> >>  - Add 3D preview
>> >>
>> >> Please, feel free to file bug reports even on minor UI quirks - I don't
>> >> always notice or remember them.
>> >>
>> >> --
>> >> Chris
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > Post to : kicad-developers@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://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] Trying to build locally - OS X Sierra

[Simon Wells]

Failed in this context means it was just unable to enable openmp, not
that it failed during the cmake step. If there is another error feel
free to paste the whole cmake output and we can have a look at it. If
you are trying to build the latest nightlies they are currently broken
on OSX

On 28 February 2017 at 08:33, Miron Iancu  wrote:
> Thank you for your help.
> Will look into these.
>
> Regards,
>
> Miron
>
> Pe 27 feb. 2017, la 21:31, Diogo Condeço  a scris:
>
> Hi Miron,
>
> There are some scripts...
> I use these:
>
> https://github.com/xzcvczx/kicad-app
>
>
> For incremental builds:
>
> ./kicad-app.sh kicad_build
>
>
> From scratch:
>
> ./kicad-app.sh kicad_rebuild
>
>
> BR
>
> On Mon, Feb 27, 2017 at 7:22 PM, Miron Iancu  wrote:
>>
>> Thank you all.
>>
>> How do you build OS X distributions ? Boxed, i.e. for example in a XCode
>> IDE or command-line based ?
>> I am trying to figure out the best practices you embrace which might make
>> a bit easier for me to set it up locally.
>>
>> The documentation is not quite straightforward but I assume one is not
>> using XCode at all.
>>
>> Another question -> for Nick: "kicad cmake scripts..." inside CMakeModules
>> ?
>>
>>
>> BR
>> Miron
>>
>> > Pe 27 feb. 2017, la 17:00, Nick Østergaard  a scris:
>> >
>> > Usually, on linux it does build fine without openmp... but it is a
>> > long time since I have tried that. Maybe there is a bad check in the
>> > kicad cmake scripts handling that on osx?
>> >
>> > 2017-02-27 15:58 GMT+01:00 Mário Luzeiro :
>> >> AFAIK if OpenMP is not present (or not enabled..etc), the source code
>> >> (based on OpenMP #pragmas) can still be buidable.
>> >>
>> >> Maybe you can try to force disable it?
>> >>
>> >> Mario
>> >> 
>> >> From: Kicad-developers
>> >> [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf 
>> >> of
>> >> Miron Iancu [mia...@asign.ro]
>> >> Sent: 27 February 2017 14:42
>> >> To: KiCad Developers
>> >> Subject: [Kicad-developers] Trying to build locally - OS X Sierra
>> >>
>> >> Dear All,
>> >>
>> >> I am trying to do a local build on a Mac OS X Sierra (10.12.3)  based
>> >> on the instructions found here but cmake fails with
>> >>
>> >> -- Try OpenMP C flag = [-fopenmp=libomp]
>> >> -- Performing Test OpenMP_FLAG_DETECTED
>> >> -- Performing Test OpenMP_FLAG_DETECTED - Failed
>> >>
>> >> AFAIK since OS X Maverick, clang does not support omp anymore.
>> >>
>> >> Can you, please, provide a bit of support ?
>> >>
>> >> Thank you in advance.
>> >>
>> >> Regards,
>> >>
>> >> Miron
>> >>
>> >>
>> >> ___
>> >> Mailing list: https://launchpad.net/~kicad-developers
>> >> Post to : kicad-developers@lists.launchpad.net
>> >> Unsubscribe : https://launchpad.net/~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
>
>
>
>
> --
> Diogo Condeço
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

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

[Simon Wells]

i don't see why on-install and if it can be done at install time why
not just do it on-demand of the model... if its slow cache but still
ondemand,

providing models that we gen will likely require a full stack of
development as git/github isn't really ideal for stuff like this

On 25 February 2017 at 15:15, Oliver Walters
<oliver.henry.walt...@gmail.com> wrote:
> I personally find the idea of on-demand model creation appealing.
>
> I think that if we are to "promote" this as the preferred method, it should
> be improved through simplification and consolidation.
>
> Scripted models have only been added in the last week. Most of the models
> are legacy (poor quality wrl made in wings etc). There are also now a lot of
> models that have been generated via the spreadsheet functionality in
> Freecad.
>
> So already there are two competing scripting methods. What I want to achieve
> is a simplified and unified library structure.
>
> I realise that due to file size this is not so practical for the 3D models.
>
> Perhaps a good idea is to dictate a scripting architecture that allows us to
> be somewhat forward-compatible, and not actually provide 3D models.
>
> The current scripts could be made more generic and "publish" their
> parameters in such a way that an external tool can have some introspection
> of the scripts. Much like the python footprint wizards currently work in
> KiCad.
>
> Then, a "helper" script can parse the generator scripts, and the user can
> select which models to generate. This could even be run on KiCad install.
>
> e.g. a list of checkboxes to install "all JST connectors" or "R0603".
>
> Alternatively, we host all the generated models, and provide a download tool
> which downloads models as required.
>
> Thoughts?
>
> On 25 Feb 2017 10:48 AM, "Cirilo Bernardo" <cirilo.berna...@gmail.com>
> wrote:
>
> Hi Oliver,
>
>  The scripts will easily generate many GB of data in time and for me it's
> not
> reasonable to download that amount of data. I think new users should simply
> learn to read documentation and generate the models rather than downloading
> them. Package maintainers can automatically run the scripts. Users will
> still
> have access to all the old VRML models and if they want to use the newer
> models, especially the STEP+VRML models, they should learn to set up the
> required tools. As I said, this requires a lot more thought.
>
>  I suspect we can indeed develop our own parametric 3D modeling tools for
> KiCad based on OCE and provide a scheme to specify good material
> appearances for the VRML export as Maurice's tools do, but it's really a
> question of time and planning.  Having scripts available in the official
> repo
> I think is a good start and will keep the expert users happy until someone
> gets around to creating these specialised tools for kicad.
>
> - Cirilo
>
>
> On Sat, Feb 25, 2017 at 10:10 AM, Oliver Walters
> <oliver.henry.walt...@gmail.com> wrote:
>> Cirilo,
>>
>> Unless we made script generation of models completely idiot proof, I think
>> that requiring another niche toolset would only serve to increase the
>> already high barrier to entry for new users.
>>
>> The 3D scripts require, currently:
>>
>> - Freecad
>> - cadquery plugin
>>
>> Plus the scripts themselves are a bit opaque to use.
>>
>> I think that if we are going to distribute recipes for models rather than
>> the models themselves, that should be integrated into KiCad?
>>
>> You're the expert on the 3D code, is there any possibility that we could
>> have a 3D wizard that operates in a similar way to the footprint wizard?
>> Then it would be fantastic to have the repo contain scripts as you say.
>>
>> Connectors are an obvious use for parametric scripts as it takes lots of
>> space to store each of hundreds of variants.
>>
>> Oliver
>>
>>
>> On 25 Feb 2017 8:44 AM, "Cirilo Bernardo" <cirilo.berna...@gmail.com>
>> wrote:
>>
>> On Sat, Feb 25, 2017 at 1:12 AM, Simon Wells <swel...@gmail.com> wrote:
>>> why should packages be a subfolder of modules, it seems that they
>>> don't really belong in there and should be directly in the share/kicad
>>> folder
>>>
>>
>> That would certainly be my preference. Since the root of the 3D models is
>> determined by KISYS3DMOD and hasn't had a hard-coded relation to the
>> *.lib files for quite a few years now, I would move it out of 'modules'
>> and
>> into
>> a 'packages3d' directory. Looking at the structure on github,
>> 'pa

Re: [Kicad-developers] Stable release 4.0.6

[Simon Wells]

can we get an "official" python disabled build for osx of stable(all 3
python options disabled)? you can hide it in some nightmare of subdirs
or in testing it might just help diagnosing python/wxpython issues

On 25 February 2017 at 11:39, Chris Pavlina  wrote:
> Yeah - my general impression from a number of inconsistencies in the
> file format vs. the spec is that KiCad's file format really should be
> considered implementation-defined.
>
> In order to have a _proper_ file format spec, it seems to be that two
> things need to be done:
>
> 1. Put the format spec _in the repository_
> 2. Version it, and require anybody changing the format in the code to:
> a. Update the MMDD version that gets written to the file
>(technically we already require this, but I've seen a couple
>changes go in without doing this...)
> b. Make a new format spec version and document the change
>
> Until we do that, it's implementation-defined with a wannabe spec :P
>
> On Fri, Feb 24, 2017 at 11:23:42PM +0100, Nick Østergaard wrote:
>> Normally when we speak of "the docs" we are not talking about the
>> fileformat specs, but the stuff in https://github.com/KiCad/kicad-doc
>>
>> 2017-02-24 23:22 GMT+01:00 Kevin Cozens :
>> > On 2017-02-23 01:29 AM, Nick Østergaard wrote:
>> >>
>> >> The docs are not quite ready yet,
>> >
>> >
>> > Documentation is (almost) always the last thing to get written or updated. 
>> > I
>> > was making use of the file formats document while working on a project of
>> > mine to convert schematics from another program in to one that can be read
>> > by Kicad. I found a lot of issues with the docs.
>> >
>> > I was told Wayne maintains that document. I'll be emailing him to find out
>> > what the procedure is for providing information about the changes needed.
>> >
>> > --
>> > Cheers!
>> >
>> > Kevin.
>> >
>> > http://www.ve3syb.ca/   |"Nerds make the shiny things that distract
>> > Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
>> > | powerful!"
>> > #include  | --Chris Hardwick
>> >
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > Post to : kicad-developers@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > More help   : https://help.launchpad.net/ListHelp
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

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

[Simon Wells]

why should packages be a subfolder of modules, it seems that they
don't really belong in there and should be directly in the share/kicad
folder

On 25 February 2017 at 02:00, Adam Wolf  wrote:
> Yeah, let me clarify--by "wouldn't be a problem" for OS X, I meant "if
> you did it without saying where it's going and when it's changing", it
> would break the OS X package, but the change would only take a minute
> or two, and would be quickly testable.
>
> On Fri, Feb 24, 2017 at 6:57 AM, Wayne Stambaugh  wrote:
>> On 2/24/2017 3:45 AM, Oliver Walters wrote:
>>> Hi everyone,
>>>
>>> Recently I raised this issue:
>>>
>>> https://lists.launchpad.net/kicad-developers/msg27922.html
>>>
>>> There were some good responses, thanks for the input.
>>>
>>> First task is going to be moving the 3D models, as this will be
>>> significantly easier.
>>>
>>> e.g. something like GitHub.com/KiCad/packages3D
>>>
>>> To this end, I'd like some further information from those in the know:
>>>
>>> A) is there any impediment to having the KISYS3DMOD envvar point to
>>> somewhere different? e.g. ./KiCad/share/packages3D/
>>
>> I believe you mean share/kicad/modules/packages3d.  Why would change the
>> install path?  Irregardless of what repo the 3D models are in, they
>> should always get installed in this location.  Where else would be
>> appropriate to install them?  Changing this path would most likely break
>> everyone's 3D viewing experience.
>>
>>> B) To the package managers, how much effort to package 3D models from a
>>> separate repo?
>>
>> I'll leave this to our package devs.
>>
>>> C) to the docs maintainers, would there be much to change if we
>>> redirected the 3D repo?
>>> D) Generally, what other considerations would be required?
>>>
>>> Essentially, if I made this change right now without telling anyone,
>>> what would I break?
>>
>> I'm sure all of the package builders.  You would need to coordinate this
>> change with the package devs.
>>
>>>
>>> As a side note there have been some great recent contributions to the 3D
>>> data, with a fair bit of momentum over at the forums.
>>>
>>> Regards,
>>> Oliver
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

[Simon Wells]

i believe the curl-multi interface will also remove this inane requirement

On 24 February 2017 at 23:19, Simon Richter  wrote:
> Hi Cirilo,
>
> On 24.02.2017 01:52, Cirilo Bernardo wrote:
>
>> Since I know nothing of the github plugin code and the usage of curl
>> within kicad, I thought I'd ask if that block should be qualified by the
>> BUILD_GITHUB_PLUGIN option or of there's some mysterious
>> reason why it must be there even when the GITHUB plugin is not
>> built.
>
> I thought that was already fixed.
>
> The proper fix is to make sure that only a single thread uses CURL. Then
> we can drop the OpenSSL dependency ourselves, as we only initialize some
> locking functions.
>
> Most people link against curl-gnutls anyway, or use SChannel on Windows.
> The difficulty is that curl will not tell you what implementation it
> uses until a connection is open.
>
>Simon
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

Re: [Kicad-developers] Torrents for KiCad distribution

[Simon Wells]

i still wouldn't call it security, validity yes, security no. nor
is md5 security

On 24 February 2017 at 20:06, Marco Ciampa  wrote:
> On Fri, Feb 24, 2017 at 08:01:38AM +0100, Nick Østergaard wrote:
>> 2017-02-24 7:59 GMT+01:00 Marco Ciampa :
>> > On Thu, Feb 23, 2017 at 11:50:59AM -0500, Mark Roszko wrote:
>> >
>> >> > I have no issue with that but there is no way for KiCad to control
>> >> > what is uploaded to a torrent so I really don't want the project to be
>> >> > responsible for it
>> >>
>> >> The torrent could be autogenerated by the download server when the
>> >> files are transferred over, the download server would act as the
>> >> initial seed server. The torrent once created could be shared on the
>> >> website and then thats it. The contents of the torrent cannot change
>> >> without it being a completely different hash and thus invalid for the
>> >> torrent.
>> >
>> > Agree.
>> > Actually using torrent is _more_ secure than downloading via ftp or http.
>> >
>>
>> Given that you got the correct torrent or magnet link in the first place.
>
> Yes, this is why official torrents seeds from an https site is important...
>
> --
>
>
> Marco Ciampa
>
> I know a joke about UDP, but you might not get it.
>
> 
>
>  GNU/Linux User #78271
>  FSFE fellow #364
>
> 
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Torrents for KiCad distribution

[Simon Wells]

I believe the server is located in France

Being located most distantly from the kicad download servers i have no
issues with the speeds from the download server, If we were qt and had
2.x GB downloads and the speed was complete crap like i get from qt i
would encourage torrents. but from downloads.kicad-pcb.org i normally
max out my connection (ADSL) as such i don't believe they are
necessary

On 24 February 2017 at 08:57, Chris Pavlina  wrote:
> On Thu, Feb 23, 2017 at 08:02:55PM +0100, Ingo Kletti wrote:
>> Am Donnerstag, 23. Februar 2017, 09:49:41 schrieben Sie:
>> > No plans currently. Do you think enough people would use them for it to
>> > really work?
>>
>> I have no idea and, as far as I understood the concept of torrents, you could
>> not tell the number of downloads, just a sum of Bytes transferred (provided
>> the tracker server keeps a record of this).
>>
>> Using torrents to distribute KiCad was an idea that came up today since the
>> next stable release is only a few days away and providing torrents could
>> probably remedy the hammering of the server during the first days.
>
> Agreed, if people would actually use them it'd be a decent way to
> lighten the server's load. I wouldn't mind it myself, certainly, but
> then I'm not a packager
>
>>
>> Regards,
>>
>> Ingo
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Stable release 4.0.6

[Simon Wells]

@adam why do you neeed a libcurl? does 10.7 not come with libcurl?

On 24 February 2017 at 02:35, Wayne Stambaugh  wrote:
> Does the ubuntu package even have the correct docs, translations, and
> libraries?  AFAIK, some of this has not been committed and tagged yet.
> In the future, please hold off making stable packages available until we
> have packages for the three major platforms.  I'm ok if some of the more
> obscure linux distros don't have packages but we should at least have
> windows, osx, and linux (dpkg and rpm) packages ready to go rather than
> release them as they are completed.  All this will do is frustrate users
> of other platforms because there is no 4.0.6 package available and make
> them feel like second class citizens.
>
> Cheers,
>
> Wayne
>
> On 2/23/2017 8:22 AM, Chris Pavlina wrote:
>> In the future we should probably look into making our releases a bit
>> more coordinated.
>>
>> https://forum.kicad.info/t/4-0-6-for-ubuntu-is-out/5441
>>
>> On Tue, Feb 14, 2017 at 09:26:21AM -0500, Wayne Stambaugh wrote:
>>> Are there any outstanding issues to prevent rolling out a 4.0.6 stable
>>> release?  If not, I will set the version string and tag that commit as
>>> 4.0.6.  How much time do our source translators, doc devs, and library
>>> devs need to have everything ready?
>>>
>>> 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] [PATCH] Fix MacOS coroutine segfault

[Simon Wells]

1.62 works fine here

On 24 February 2017 at 02:07, Wayne Stambaugh <stambau...@gmail.com> wrote:
> This is a known issue.  I believe the last valid version of boost that
> doesn't cause a crash is 1.61.  Anything after that causes this issue on
> all platforms not just osx.  @Orson or @Tom, any chance you could take a
> look at this to see what boost changed in the context library?
>
> Cheers,
>
> Wayne
>
> On 2/23/2017 6:49 AM, Simon Wells wrote:
>> just fyi
>>
>> https://bugs.launchpad.net/kicad/+bug/1658249
>>
>> On 24 February 2017 at 00:38, Chris Pavlina <pavlina.ch...@gmail.com> wrote:
>>> Backtrace attached. Boost is 1.63.0.
>>>
>>> On Thu, Feb 23, 2017 at 11:36:02AM +0100, Maciej Sumiński wrote:
>>>> Hi Chris,
>>>>
>>>> Would you give more details about the problem? Boost version, backtrace?
>>>>
>>>> Regards,
>>>> Orson
>>>>
>>>> On 02/23/2017 02:23 AM, Chris Pavlina wrote:
>>>>> Hi,
>>>>>
>>>>> pcbnew is segfaulting on launch on my MacOS Sierra build, due to a null
>>>>> dereference in the coroutine code:
>>>>>
>>>>> coroutine.h
>>>>> 408static CONTEXT_T callerStub( CONTEXT_T caller, INVOCATION_ARGS* 
>>>>> aArgsPtr )
>>>>> 409{
>>>>> 410const auto& args = *aArgsPtr;
>>>>> 411auto* cor = args.destination;
>>>>>
>>>>> aArgsPtr is null and I don't understand WHY. However, I was able to make
>>>>> things appear to work by short-circuiting this function if the argument
>>>>> is null.
>>>>>
>>>>> Patch attached. It Works For Me™, but I'd like someone who knows the
>>>>> coroutine code to look and make sure I haven't made a mess of things.
>>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to : kicad-developers@lists.launchpad.net
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault

[Simon Wells]

just fyi

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

On 24 February 2017 at 00:38, Chris Pavlina  wrote:
> Backtrace attached. Boost is 1.63.0.
>
> On Thu, Feb 23, 2017 at 11:36:02AM +0100, Maciej Sumiński wrote:
>> Hi Chris,
>>
>> Would you give more details about the problem? Boost version, backtrace?
>>
>> Regards,
>> Orson
>>
>> On 02/23/2017 02:23 AM, Chris Pavlina wrote:
>> > Hi,
>> >
>> > pcbnew is segfaulting on launch on my MacOS Sierra build, due to a null
>> > dereference in the coroutine code:
>> >
>> > coroutine.h
>> > 408static CONTEXT_T callerStub( CONTEXT_T caller, INVOCATION_ARGS* 
>> > aArgsPtr )
>> > 409{
>> > 410const auto& args = *aArgsPtr;
>> > 411auto* cor = args.destination;
>> >
>> > aArgsPtr is null and I don't understand WHY. However, I was able to make
>> > things appear to work by short-circuiting this function if the argument
>> > is null.
>> >
>> > Patch attached. It Works For Me™, but I'd like someone who knows the
>> > coroutine code to look and make sure I haven't made a mess of things.
>> >
>> >
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > Post to : kicad-developers@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>>
>>
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

Re: [Kicad-developers] [PATCH] Fix layer color swatches in Linux

[Simon Wells]

I think even if you made a color scheme/etc menu option it would still
be nice if there was a way to easily change the single layer
information. If one was color blind it would be easier to just double
click on the problem row and change the color, and also even if one
isn't trying to find in the menu the option, and then work out which
layer needs to be changed to which color i would find more
frustrating.

The routing schemes/color themes would obviously override any settings
of colours manually per layers.

And i am not really talking about enhancing the current colour dialog,
I am proposing a new dialog which is layed out as

Name: F.Cu (text field - disabled until renaming layers is supported)
Type: Copper(drop down box - contains types like Copper, F/T/B Mask,
F/T/B Silk, User
Color: [] (button that opens up a normal wxColorPicker control (or
a dropdown box that has last used colors+custom which opens up the
wxColorPicker))
Comments: (text field - used to comment on what the layer is used for
for user layers)

and potentially a button to reset to layer/colour theme/routing settings default

On 23 February 2017 at 08:18, Jon Evans <j...@craftyjon.com> wrote:
> I agree with JP.  Move colors out of layer manager into a separate dialog,
> add more powerful features for GAL.  This ties in to my plans to add color
> theme support and also some other ideas I have for new display modes in GAL.
>
> Another feature I want to clone from a commercial product is saved "display
> schemes" which are at a minimum, a set of layers hidden/visible.  So you
> just pick your "routing" scheme or your "placement" scheme, etc, and it
> automatically sets up the layer visibility to your preference.  In addition
> to visibility, this could do things with transparency, etc...
>
> -Jon
>
> On Wed, Feb 22, 2017 at 2:13 PM, jp charras <jp.char...@wanadoo.fr> wrote:
>>
>> Le 22/02/2017 à 19:43, Simon Wells a écrit :
>> > one option is to not have the color indicator as a control at all,
>> > have it as only an indicator and if you double click on the layer
>> > widget row (or right click -> properties) you get another dialog that
>> > then has a real color well control. This will remove the hacky
>> > behaviour on a button and also make it so that later on (when its
>> > supported) you can change the layer name and type. while reducing the
>> > area of single misclick. I have done a very quick gimp mockup where
>> > the color is moved right to the edge, but it is currently missing
>> > visibility and active layer indicators, visibility should probably be
>> > done through an eye rather than checkbox, As the checkbox can also
>> > fool people into thinking its disabling the layer not just changing
>> > its visibility
>> >
>>
>> A similar option is to not have the color indicator as a control at all,
>> and to add in the main menu
>> a new entry like "color management", especially if we consider changing
>> color/transparency layers is
>> not as frequent as changing the active layer.
>>
>> The current color dialog must be redesigned to the GAL, because GAL is by
>> far more powerful than the
>> legacy mode.
>>
>> Especially, currently there is no known way (by users) to adjust the
>> transparency of layers.
>> But this feature exists in GAL since a very long time.
>>
>> And later, add (in this menu/dialog) the ability to manage:
>> * The Hight Contrast mode (adjust the transparency of not active layers)
>> * The transparency of zones (if it is possible in GAL mode)
>> * Manage group of layers colors: for instance the default group like now,
>> but the ability to define
>> a set of visible layers with perhaps transparency for "not visible"
>> layers: for instance to route
>> critical signals, show top and bottom layer with default tranparency/color
>> setup, and other layers
>> with very low transparency (or really invisible).
>>
>> (Choice between groups made by the context right popup menu for fast
>> selection)
>>
>> Trying to just enhance the current color dialog, and trying to modify the
>> clicks in layers managers
>> is for me just write an outdated code.
>>
>>
>> --
>> Jean-Pierre CHARRAS
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

Re: [Kicad-developers] Avoid shadowed variables.

[Simon Wells]

why not just add it to the default cmake files, It won't affect users
if its enabled anyway,

On 23 February 2017 at 01:12, jp charras  wrote:
> I'll very happy if developers could add this option when compiling Kicad:
> -DCMAKE_CXX_FLAGS="-Wshadow"
>
> Shadowed variables do not create issues for a compiler, but human readers are 
> not compilers
> (fortunately)
>
> Using this option, I found at least one serious bug, when a shadowed var is a 
> class member.
>
> In all cases, this is a potential source of bugs, therefore it should be 
> avoided.
>
> Thanks.
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [PATCH] Fix layer color swatches in Linux

[Simon Wells]

haha your advanced life experience must be getting to you you even
commented on it when it was last bought up on the list
https://lists.launchpad.net/kicad-developers/msg23387.html

On 22 February 2017 at 12:39, Wayne Stambaugh <stambau...@gmail.com> wrote:
> Why don't I remember that?  It must not have been that way for very
> long.  In any event, I'm actually fine with changing it to a single left
> click.  We could always undo it if user's absolutely hate it.
>
> On 2/21/2017 1:43 PM, Simon Wells wrote:
>> there was a time where it was single click changes colour and there
>> were no complaints that i saw. JP changed it without consultation or
>> comment on the list
>>
>> On 22 February 2017 at 07:30, Chris Pavlina <pavlina.ch...@gmail.com> wrote:
>>> On Tue, Feb 21, 2017 at 01:26:17PM -0500, Jon Evans wrote:
>>>> Yeah, this is going to be a problem any time there is a situation where
>>>> KiCad does it differently than "the standard", but has been doing it that
>>>> way forever.  No easy fix that pleases both the old users and the new
>>>> users.  Other open source software has had this problem too (GIMP, etc)
>>>
>>> A part of me really wants to fork KiCad, spend a year or so removing ALL
>>> these silly KiCadisms that "users will howl about", and release it as a
>>> new de-crustified project with the understanding that everything will be
>>> different because everything was stupid before. I bet *checks sofa*
>>> $3.24 that users would flock to it.
>>>
>>> Sadly, that part of me lives in a fantasy world where days have 48 hours
>>> and I get paid megabucks to sit on my butt.
>>>
>>>>
>>>> My own thoughts on the matter are that I want to never have to change layer
>>>> using the layer picker, and always have it hidden.  Based on the behavior
>>>> of other tools I have used, I think that it is possible to greatly reduce
>>>> the need to manually change layers, and especially to do so with the mouse
>>>> rather than a hotkey.
>>>>
>>>> -Jon
>>>>
>>>> On Tue, Feb 21, 2017 at 1:18 PM, Wayne Stambaugh <stambau...@gmail.com>
>>>> wrote:
>>>>
>>>>> I can just hear users howling already when they left click the color
>>>>> swatch thinking that they are selecting the layer and then have to
>>>>> dismiss the color select dialog to continue working.  If we cannot come
>>>>> up with a better solution, it may be best to leave sleeping dogs lie.  I
>>>>> wonder how many of the 75% of voters in the poll would response to
>>>>> having to dismiss the color selection dialog every time they
>>>>> inadvertently left clicked the color button?  This may be a case of
>>>>> ignorance being bliss.
>>>>>
>>>>> On 2/21/2017 12:54 PM, Jon Evans wrote:
>>>>>> FWIW, this is what my expecations were as a new user when I started with
>>>>>> KiCad (for what would happen with a single left-click) based on how
>>>>>> things work in other applications with layer managers I have used (ECAD,
>>>>>> graphics, etc):
>>>>>>
>>>>>> http://i.imgur.com/Euh2Gjwl.png
>>>>>>
>>>>>> -Jon
>>>>>>
>>>>>> On Tue, Feb 21, 2017 at 12:04 PM, Chris Pavlina <pavlina.ch...@gmail.com
>>>>>> <mailto:pavlina.ch...@gmail.com>> wrote:
>>>>>>
>>>>>> By the way.
>>>>>>
>>>>>> https://forum.kicad.info/t/developer-feedback-poll-layer-
>>>>> manager/5421 <https://forum.kicad.info/t/developer-feedback-poll-layer-
>>>>> manager/5421>
>>>>>>
>>>>>> Feel free to add your own responses. The results look pretty
>>>>> conclusive
>>>>>> right now ;)
>>>>>>
>>>>>> On Tue, Feb 21, 2017 at 11:40:05AM -0500, Chris Pavlina wrote:
>>>>>> > Sent to wrong recipient.
>>>>>> >
>>>>>> > On Tue, Feb 21, 2017 at 11:38:43AM -0500, Chris Pavlina wrote:
>>>>>> > > On Tue, Feb 21, 2017 at 05:24:14PM +0100, jp charras wrote:
>>>>>> > > > Le 21/02/2017 à 16:07, Chris Pavlina a écrit :
>>>>>> > > > > On Tue, Feb 21, 2017 at 09:35:34AM -0500, Wayne Stambaugh
&g

Re: [Kicad-developers] [PATCH] Fix layer color swatches in Linux

[Simon Wells]

there was a time where it was single click changes colour and there
were no complaints that i saw. JP changed it without consultation or
comment on the list

On 22 February 2017 at 07:30, Chris Pavlina  wrote:
> On Tue, Feb 21, 2017 at 01:26:17PM -0500, Jon Evans wrote:
>> Yeah, this is going to be a problem any time there is a situation where
>> KiCad does it differently than "the standard", but has been doing it that
>> way forever.  No easy fix that pleases both the old users and the new
>> users.  Other open source software has had this problem too (GIMP, etc)
>
> A part of me really wants to fork KiCad, spend a year or so removing ALL
> these silly KiCadisms that "users will howl about", and release it as a
> new de-crustified project with the understanding that everything will be
> different because everything was stupid before. I bet *checks sofa*
> $3.24 that users would flock to it.
>
> Sadly, that part of me lives in a fantasy world where days have 48 hours
> and I get paid megabucks to sit on my butt.
>
>>
>> My own thoughts on the matter are that I want to never have to change layer
>> using the layer picker, and always have it hidden.  Based on the behavior
>> of other tools I have used, I think that it is possible to greatly reduce
>> the need to manually change layers, and especially to do so with the mouse
>> rather than a hotkey.
>>
>> -Jon
>>
>> On Tue, Feb 21, 2017 at 1:18 PM, Wayne Stambaugh 
>> wrote:
>>
>> > I can just hear users howling already when they left click the color
>> > swatch thinking that they are selecting the layer and then have to
>> > dismiss the color select dialog to continue working.  If we cannot come
>> > up with a better solution, it may be best to leave sleeping dogs lie.  I
>> > wonder how many of the 75% of voters in the poll would response to
>> > having to dismiss the color selection dialog every time they
>> > inadvertently left clicked the color button?  This may be a case of
>> > ignorance being bliss.
>> >
>> > On 2/21/2017 12:54 PM, Jon Evans wrote:
>> > > FWIW, this is what my expecations were as a new user when I started with
>> > > KiCad (for what would happen with a single left-click) based on how
>> > > things work in other applications with layer managers I have used (ECAD,
>> > > graphics, etc):
>> > >
>> > > http://i.imgur.com/Euh2Gjwl.png
>> > >
>> > > -Jon
>> > >
>> > > On Tue, Feb 21, 2017 at 12:04 PM, Chris Pavlina > > > > wrote:
>> > >
>> > > By the way.
>> > >
>> > > https://forum.kicad.info/t/developer-feedback-poll-layer-
>> > manager/5421 > > manager/5421>
>> > >
>> > > Feel free to add your own responses. The results look pretty
>> > conclusive
>> > > right now ;)
>> > >
>> > > On Tue, Feb 21, 2017 at 11:40:05AM -0500, Chris Pavlina wrote:
>> > > > Sent to wrong recipient.
>> > > >
>> > > > On Tue, Feb 21, 2017 at 11:38:43AM -0500, Chris Pavlina wrote:
>> > > > > On Tue, Feb 21, 2017 at 05:24:14PM +0100, jp charras wrote:
>> > > > > > Le 21/02/2017 à 16:07, Chris Pavlina a écrit :
>> > > > > > > On Tue, Feb 21, 2017 at 09:35:34AM -0500, Wayne Stambaugh
>> > wrote:
>> > > > > > >> My only issue with this change is that the tooltip letting
>> > > the user know
>> > > > > > >> that a left button double click or a middle button click
>> > > would allow
>> > > > > > >> them to change the color is gone.  Other than that, it
>> > > looks great.  I
>> > > > > > >> like the use of Bind instead of Connect.  Bind has a much
>> > > cleaner
>> > > > > > >> interface than Connect and according to the wx folks is the
>> > > proper way
>> > > > > > >> to handle events.
>> > > > > > >
>> > > > > > > The tooltip is useless, nobody is going to hover over them
>> > > for long
>> > > > > > > enough to see it. I was just talking to someone this morning
>> > > who never
>> > > > > > > found the tooltip because he was too busy clicking on the
>> > > buttons to
>> > > > > > > make them work.
>> > > > > > >
>> > > > > > > Every other color well in every other application opens its
>> > > selection
>> > > > > > > dialog with a single left click. Why can't ours?
>> > > > > >
>> > > > > > First you have to decide if the main purpose is to select the
>> > > active layer or to change the color layer.
>> > > > > > The answer will give also the answer to "Why can't ours".
>> > > > > >
>> > > > > > For me the answer is not obvious, but my opinion is:
>> > > > > > the primary purpose of the layer manager is to select the
>> > > working layer.
>> > > > > > Therefore the single left click should change the layer,
>> > > whatever you are clicking.
>> > > > > >
>> > > > > > If the primary purpose of the layer manager is to select 

Re: [Kicad-developers] [PATCH] Fix layer color swatches in Linux

[Simon Wells]

could just turn it into a real table and use a highlight for selected row

On 22 February 2017 at 06:56, Chris Pavlina  wrote:
> Yup. I'd probably consider moving the elements around a bit so that
> "Select working layer" isn't broken into two sections.
>
> On Tue, Feb 21, 2017 at 12:54:51PM -0500, Jon Evans wrote:
>> FWIW, this is what my expecations were as a new user when I started with
>> KiCad (for what would happen with a single left-click) based on how things
>> work in other applications with layer managers I have used (ECAD, graphics,
>> etc):
>>
>> http://i.imgur.com/Euh2Gjwl.png
>>
>> -Jon
>>
>> On Tue, Feb 21, 2017 at 12:04 PM, Chris Pavlina 
>> wrote:
>>
>> > By the way.
>> >
>> > https://forum.kicad.info/t/developer-feedback-poll-layer-manager/5421
>> >
>> > Feel free to add your own responses. The results look pretty conclusive
>> > right now ;)
>> >
>> > On Tue, Feb 21, 2017 at 11:40:05AM -0500, Chris Pavlina wrote:
>> > > Sent to wrong recipient.
>> > >
>> > > On Tue, Feb 21, 2017 at 11:38:43AM -0500, Chris Pavlina wrote:
>> > > > On Tue, Feb 21, 2017 at 05:24:14PM +0100, jp charras wrote:
>> > > > > Le 21/02/2017 à 16:07, Chris Pavlina a écrit :
>> > > > > > On Tue, Feb 21, 2017 at 09:35:34AM -0500, Wayne Stambaugh wrote:
>> > > > > >> My only issue with this change is that the tooltip letting the
>> > user know
>> > > > > >> that a left button double click or a middle button click would
>> > allow
>> > > > > >> them to change the color is gone.  Other than that, it looks
>> > great.  I
>> > > > > >> like the use of Bind instead of Connect.  Bind has a much cleaner
>> > > > > >> interface than Connect and according to the wx folks is the
>> > proper way
>> > > > > >> to handle events.
>> > > > > >
>> > > > > > The tooltip is useless, nobody is going to hover over them for long
>> > > > > > enough to see it. I was just talking to someone this morning who
>> > never
>> > > > > > found the tooltip because he was too busy clicking on the buttons
>> > to
>> > > > > > make them work.
>> > > > > >
>> > > > > > Every other color well in every other application opens its
>> > selection
>> > > > > > dialog with a single left click. Why can't ours?
>> > > > >
>> > > > > First you have to decide if the main purpose is to select the active
>> > layer or to change the color layer.
>> > > > > The answer will give also the answer to "Why can't ours".
>> > > > >
>> > > > > For me the answer is not obvious, but my opinion is:
>> > > > > the primary purpose of the layer manager is to select the working
>> > layer.
>> > > > > Therefore the single left click should change the layer, whatever
>> > you are clicking.
>> > > > >
>> > > > > If the primary purpose of the layer manager is to select the color,
>> > then a single left click should
>> > > > > open the color dialog.
>> > > >
>> > > > This isn't "the layer manager", it's a color well IN the layer manager.
>> > > >
>> > > > >
>> > > > > If the single left click opens the dialog, be sure many times, when
>> > clicking inside the layer
>> > > > > manager, you will open the dialog, instead of changing the active
>> > layer, especially if you are too
>> > > > > busy clicking on the window to verify the exact position of the
>> > mouse.
>> > > > > (It frequently happened to me when the single click was opening the
>> > dialog)
>> > > > >
>> > > > > A wise decision is never obvious.
>> > > > > (A reason like "other applications do that" is not necessary a good
>> > reason.
>> > > > > Each application has its constraints and its compromises)
>> > > >
>> > > > YES IT IS. Consistency is the single most important way to make an
>> > > > interface understandable. A box containing a color is a color well, and
>> > > > color wells behave the exact same way in everything that isn't kicad.
>> > > >
>> > > > Next you'll tell me "File->Open opening a file in other applications is
>> > > > not a good reason it shouldn't display a photo of a llama in KiCad".
>> > > >
>> > > > >
>> > > > > >
>> > > > > >>
>> > > > > >> On 2/21/2017 8:04 AM, John Beard wrote:
>> > > > > >>> Hi,
>> > > > > >>>
>> > > > > >>> These patches fix the layer/render widget swatches in Linux
>> > under new
>> > > > > >>> GTK+ toolkits. Fix for: https://bugs.launchpad.net/
>> > kicad/+bug/1605411
>> > > > > >>>
>> > > > > >>> The patches remove the "button" nature of the swatches, since
>> > they
>> > > > > >>> weren't actually actuated by a single click, so the button
>> > affordance
>> > > > > >>> was misleading anyway. Also on OSX, the button was invisible, so
>> > it
>> > > > > >>> just looked like a flat swatch anyway.
>> > > > > >>>
>> > > > > >>> * Linux as it was:
>> > > > > >>> https://drive.google.com/file/d/0BxVhl5qZbpYoZlZPeXV1Q0ttT2s/
>> > view
>> > > > > >>> * OSX as it was:
>> > > > > >>> https://launchpadlibrarian.net/274428737/Screen%20Shot%
>> > 202016-07-22%20at%2019.40.14.png
>> > > > > >>> * Linux after this patch: see attachment

Re: [Kicad-developers] Patch to compile _pcbnew.kiface only once

[Simon Wells]

I have previously sent a patch to adam for testing that bundled
python. but it was a bit hackish as since python is a system lib
bundleutilies doesn't copy it.

On 21 February 2017 at 21:28, Bernhard Stegmaier
 wrote:
>
> On 21 Feb 2017, at 00:31, Wayne Stambaugh  wrote:
>
> On 2/20/2017 6:27 PM, Nick Østergaard wrote:
>
> 2017-02-20 23:48 GMT+01:00 Bernhard Stegmaier :
>
> How is this done on Windows?
> You also don’t have a global filesystem with one Python there where you just
> copy it into the right place… where does the Windows installer put those
> files and how do you use them from some installed Python? Are there issues
> with library paths of the library dependencies that come with KiCAD when
> used from an external Python?
>
>
> I am not aware of any issues with it on windows, but I don't really use
> windows.
>
> People have requested to include pip with the windows install, and
> that is done now, so I assume that at least something works.
>
> I am not sure if the user uses the shell inside pcbnew or calls the
> python bundled with the installer. The file system layout is basically
> as on linux, just inside the install destination folder.
>
>
> Would something like this work on osx rather than trying to fit into an
> existing python install?  It might prove to be more reliable.  At least
> you would always have a known python build.
>
>
> Yes, that’s probably the only way to do it in a safe way for the bundle
> (and, as Adam said how Apple requires it).
> Currently only wxPython packages and the pcbnew .so are copied into the
> bundle.
> There is no (matching) python installation contained/copied.
>
> This seems to be sufficient to at least run the python console from inside
> pcbnew with some external python installation - if the python version used
> to build the bundle and the one on the target system are compatible.
> However, the last time I tried it the python console was really unusable for
> me, because you couldn’t even type some keys (menu hotkeys always trigger
> the menu action).
> Don’t know if that has been fixed meanwhile.
>
> So, I think this whole python stuff needs a big overhaul on macOS for both
> types of scripting.
> I will work on it when I have some spare time.
> If someone else is going to work on that please drop me a note, so that we
> don’t do it twice…
>
>
> Regards,
> Bernhard
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~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 to compile _pcbnew.kiface only once

[Simon Wells]

Hi Wayne,

I have already sent my concerns and what i am stuck on and have had no
response so at this point i am unable to help sorry

On 21 February 2017 at 07:28, Wayne Stambaugh <stambau...@gmail.com> wrote:
> Simon,
>
> I'm going to commits Dick's original patch as soon as possible.  I want
> to know if you (or anyone else who can fix the osx part of this) will be
> available to fix the osx part of this before I commit it to minimize the
> amount of time we have broken builds for osx.
>
> Thanks,
>
> Wayne
>
> On 2/13/2017 9:24 AM, Simon Wells wrote:
>> Error copying file "_pcbnew.kiface" to "_pcbnew.so".
>>
>> attached is dicks patch with my changes
>>
>> On 14 February 2017 at 03:15, Wayne Stambaugh <stambau...@gmail.com> wrote:
>>> On 2/12/2017 5:15 PM, Bernhard Stegmaier wrote:
>>>>
>>>>> On 12 Feb 2017, at 22:18, Wayne Stambaugh <stambau...@gmail.com> wrote:
>>>>>
>>>>> On 2/12/2017 5:37 AM, Simon Wells wrote:
>>>>>> i am stuck on the below as i do not understand whats trying to be
>>>>>> achieved doing this
>>>>>>
>>>>>> # For phase 1, copy _pcbnew.kiface to the python module. line onward
>>>>>> (line 733ish)
>>>>>>
>>>>>> until the end of the if, and its broken for me.
>>>>>
>>>>> It should just be a copy of the _pcbnew.kiface to the python library
>>>>> with the correct python extension for python to a folder where python
>>>>> can find it.  I'm not sure what the file extension is or where the
>>>>> python library install path is in osx.  I can check with Dick but I'm
>>>>> pretty sure by looking at the patch that is what it does.
>>>>
>>>> Did this (I guess it is using pcbnew stuff from machines python 
>>>> installation, not the python form inside pcbnew) ever work on macOS?
>>>>
>>>> That doesn’t really make sense on macOS with application bundles (IMHO).
>>>> The install step is just an intermediate step to create the initial bundle 
>>>> on the build machine.
>>>> If you install it to some python folder on the build machine, it won’t get 
>>>> anywhere on a users machine when installing (== copying) the bundle (the 
>>>> bundle is not more than a folder, so you don’t really “install” anything).
>>>>
>>>> One thing would probably be to create an own installer/bundle for this 
>>>> python stuff, which puts things in the right places on the destination 
>>>> machine. I don’t know if this is easily possible, because you could have 
>>>> more than one python installed and I don’t know about paths in libs.
>>>> Or, put it inside the bundle and let user handle it on his own (by 
>>>> symlinking, whatever…).
>>>>
>>>> Same fun will come up on Linux with AppImage stuff (and the other similar 
>>>> approaches)…
>>>>
>>>>
>>>> Regards,
>>>> Bernhard
>>>>
>>>
>>> Please send me the build output for the build failure with this patch.
>>> Dick offered to try to resolve it but he needs the build log.

___
Mailing list: https://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] Future of GitHub libraries

[Simon Wells]

with some effort you can abstract the user interface enough so that
they don't actually need to know anything about git

On 18 February 2017 at 07:51, Andy Peters  wrote:
>
>> On Feb 17, 2017, at 8:31 AM, Clemens Koller  wrote:
>>
>>
>>
>> And: In the long-term we might also think about using git for project and 
>> design management and versioning. (We could even store undo's and redo's in 
>> git?)
>
> Except that not everyone likes or uses git. I use Subversion for my projects.
>
> -a
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~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] rename of kiface to so

[Simon Wells]

> paths, library versioning has to be correct or it's possible that the
>>>> wrong kiface gets linked.  I'm thinking more of users or developers who
>>>> build and install from source rather than packaged installs.  On linux,
>>>> I could install the stable version of kicad in /usr and my dev build in
>>>> /usr/local or /home.  If _pcbnew.so (kiface) exists in multiple ldconfig
>>>> paths with no or identical version information, how does ld know which
>>>> _pcbnew.so to use?
>>>>
>>>> On 2/13/2017 9:30 AM, Chris Pavlina wrote:
>>>>> Can you explain why you think installing them as .so to /usr/lib changes
>>>>> in any way our responsibility for library versioning vs installing them
>>>>> as .kiface to /usr/bin? They still get installed with the whole package,
>>>>> reinstalled on upgrade, uninstalled on package removal, etc...
>>>>>
>>>>> On Mon, Feb 13, 2017 at 09:21:26AM -0500, Wayne Stambaugh wrote:
>>>>>> I'm not opposed to this but once we head down this path, we will forever
>>>>>> be responsible for library versioning and any implications it has with
>>>>>> regard to multiple installed versions of kicad.  I'm not sure we are
>>>>>> ready to open that can of worms just yet.  Keep in mind that .kifaces
>>>>>> are not generic libraries, they can only be linked to a specific kicad
>>>>>> app.  Link to the wrong .kiface and your sure to have issues.
>>>>>>
>>>>>> On 2/12/2017 2:01 PM, Chris Pavlina wrote:
>>>>>>> Please!!:
>>>>>>>
>>>>>>> - Move .kiface into $PREFIX/lib on linux, and the equivalent place on
>>>>>>>   other systems
>>>>>>>
>>>>>>> - Rename them from _foo.kiface to foo.so on linux and osx and foo.dll on
>>>>>>>   windows
>>>>>>>
>>>>>>> - Stop installing them with the executable bit set on linux! Presumably
>>>>>>>   osx too. It's totally unnecessary for shared libs, and ESPECIALLY bad
>>>>>>>   if they're in $PREFIX/bin.
>>>>>>>
>>>>>>> On Mon, Feb 13, 2017 at 07:49:36AM +1300, Simon Wells wrote:
>>>>>>>> As the kifaces are just shared objects/libraries is there any reason
>>>>>>>> they must be named .kiface instead of .so (or other name used on
>>>>>>>> system for dynamic libs), It seems to just be making things more
>>>>>>>> difficult and confusing when people see .kiface and have no ideaa what
>>>>>>>> it means.
>>>>>>>>
>>>>>>>> These should really not be place in bin/ on linux systems either as
>>>>>>>> its really not designed for that sort of thing
>>>>>>>>
>>>>>>>> ___
>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>>> Post to : kicad-developers@lists.launchpad.net
>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>> ___
>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>> Post to : kicad-developers@lists.launchpad.net
>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>
>>>>>> ___
>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>> Post to : kicad-developers@lists.launchpad.net
>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Patch to compile _pcbnew.kiface only once

[Simon Wells]

well i don't actually know what needs to be done, i just sent a chunk
to pass onto dick, i am not fussed if the whole commit is attributed
to dick

On 14 February 2017 at 09:32, Wayne Stambaugh <stambau...@gmail.com> wrote:
> Simon,
>
> This isn't going to work as patch that I can commit because the proper
> credit cannot be attributed to the correct author.  I will commit Dick's
> original patch this evening so you can send me patch for the osx fix
> which will be attributed to you as the commit author.  I don't really
> want to break the osx build but now that you know what needs to be done
> to fix it, you should be able to fix it fairly quickly.
>
> Thanks,
>
> Wayne
>
> On 2/13/2017 9:24 AM, Simon Wells wrote:
>> Error copying file "_pcbnew.kiface" to "_pcbnew.so".
>>
>> attached is dicks patch with my changes
>>
>> On 14 February 2017 at 03:15, Wayne Stambaugh <stambau...@gmail.com> wrote:
>>> On 2/12/2017 5:15 PM, Bernhard Stegmaier wrote:
>>>>
>>>>> On 12 Feb 2017, at 22:18, Wayne Stambaugh <stambau...@gmail.com> wrote:
>>>>>
>>>>> On 2/12/2017 5:37 AM, Simon Wells wrote:
>>>>>> i am stuck on the below as i do not understand whats trying to be
>>>>>> achieved doing this
>>>>>>
>>>>>> # For phase 1, copy _pcbnew.kiface to the python module. line onward
>>>>>> (line 733ish)
>>>>>>
>>>>>> until the end of the if, and its broken for me.
>>>>>
>>>>> It should just be a copy of the _pcbnew.kiface to the python library
>>>>> with the correct python extension for python to a folder where python
>>>>> can find it.  I'm not sure what the file extension is or where the
>>>>> python library install path is in osx.  I can check with Dick but I'm
>>>>> pretty sure by looking at the patch that is what it does.
>>>>
>>>> Did this (I guess it is using pcbnew stuff from machines python 
>>>> installation, not the python form inside pcbnew) ever work on macOS?
>>>>
>>>> That doesn’t really make sense on macOS with application bundles (IMHO).
>>>> The install step is just an intermediate step to create the initial bundle 
>>>> on the build machine.
>>>> If you install it to some python folder on the build machine, it won’t get 
>>>> anywhere on a users machine when installing (== copying) the bundle (the 
>>>> bundle is not more than a folder, so you don’t really “install” anything).
>>>>
>>>> One thing would probably be to create an own installer/bundle for this 
>>>> python stuff, which puts things in the right places on the destination 
>>>> machine. I don’t know if this is easily possible, because you could have 
>>>> more than one python installed and I don’t know about paths in libs.
>>>> Or, put it inside the bundle and let user handle it on his own (by 
>>>> symlinking, whatever…).
>>>>
>>>> Same fun will come up on Linux with AppImage stuff (and the other similar 
>>>> approaches)…
>>>>
>>>>
>>>> Regards,
>>>> Bernhard
>>>>
>>>
>>> Please send me the build output for the build failure with this patch.
>>> Dick offered to try to resolve it but he needs the build log.

___
Mailing list: https://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 to compile _pcbnew.kiface only once

[Simon Wells]

Error copying file "_pcbnew.kiface" to "_pcbnew.so".

attached is dicks patch with my changes

On 14 February 2017 at 03:15, Wayne Stambaugh <stambau...@gmail.com> wrote:
> On 2/12/2017 5:15 PM, Bernhard Stegmaier wrote:
>>
>>> On 12 Feb 2017, at 22:18, Wayne Stambaugh <stambau...@gmail.com> wrote:
>>>
>>> On 2/12/2017 5:37 AM, Simon Wells wrote:
>>>> i am stuck on the below as i do not understand whats trying to be
>>>> achieved doing this
>>>>
>>>> # For phase 1, copy _pcbnew.kiface to the python module. line onward
>>>> (line 733ish)
>>>>
>>>> until the end of the if, and its broken for me.
>>>
>>> It should just be a copy of the _pcbnew.kiface to the python library
>>> with the correct python extension for python to a folder where python
>>> can find it.  I'm not sure what the file extension is or where the
>>> python library install path is in osx.  I can check with Dick but I'm
>>> pretty sure by looking at the patch that is what it does.
>>
>> Did this (I guess it is using pcbnew stuff from machines python 
>> installation, not the python form inside pcbnew) ever work on macOS?
>>
>> That doesn’t really make sense on macOS with application bundles (IMHO).
>> The install step is just an intermediate step to create the initial bundle 
>> on the build machine.
>> If you install it to some python folder on the build machine, it won’t get 
>> anywhere on a users machine when installing (== copying) the bundle (the 
>> bundle is not more than a folder, so you don’t really “install” anything).
>>
>> One thing would probably be to create an own installer/bundle for this 
>> python stuff, which puts things in the right places on the destination 
>> machine. I don’t know if this is easily possible, because you could have 
>> more than one python installed and I don’t know about paths in libs.
>> Or, put it inside the bundle and let user handle it on his own (by 
>> symlinking, whatever…).
>>
>> Same fun will come up on Linux with AppImage stuff (and the other similar 
>> approaches)…
>>
>>
>> Regards,
>> Bernhard
>>
>
> Please send me the build output for the build failure with this patch.
> Dick offered to try to resolve it but he needs the build log.


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

[Kicad-developers] rename of kiface to so

[Simon Wells]

As the kifaces are just shared objects/libraries is there any reason
they must be named .kiface instead of .so (or other name used on
system for dynamic libs), It seems to just be making things more
difficult and confusing when people see .kiface and have no ideaa what
it means.

These should really not be place in bin/ on linux systems either as
its really not designed for that sort of thing

___
Mailing list: https://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 to compile _pcbnew.kiface only once

[Simon Wells]

i am stuck on the below as i do not understand whats trying to be
achieved doing this

 # For phase 1, copy _pcbnew.kiface to the python module. line onward
(line 733ish)

until the end of the if, and its broken for me.


also can we please formalize a policy in the CMakeLists.txt files that

do_this(
INDENTED_STUFFS_HERE
)

specifically that the closing bracket there is place inline with the
start of the line of the opening bracket and not

do_this(
INDENTED_STUFFS_HERE
)

i find its much easier to look at the former than the latter



On 10 February 2017 at 02:58, Wayne Stambaugh <stambau...@gmail.com> wrote:
> Simon,
>
> Have you made any progress on this yet?  I would really like to get this
> committed but I don't want to break osx builds.
>
> Thanks,
>
> Wayne
>
> On 2/2/2017 8:57 PM, Wayne Stambaugh wrote:
>> Thanks Simon.  Please send a patch against Dicks work so I can commit
>> this at the same time.  I don't want to break osx builds.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 2/2/2017 7:28 PM, Simon Wells wrote:
>>> its not good on osx, I will take a look over the weekend, There are a
>>> few things i would like to change in that cmakelists, esspecially in
>>> regards to OSX and the order of things/when things are done
>>>
>>> On 3 February 2017 at 07:28, Wayne Stambaugh <stambau...@gmail.com> wrote:
>>>> Did anyone of our osx devs get a chance to test this patch yet?  I would
>>>> like to get it merged.  It saves a nice chunk of time from builds.
>>>>
>>>> Cheers,
>>>>
>>>> Wayne
>>>>
>>>> On 1/26/2017 11:42 AM, Wayne Stambaugh wrote:
>>>>> Would one of our osx devs please test the attached patch?  Dick sent me
>>>>> this patch to fix the long standing issue of building _pcbnew.kiface
>>>>> twice.  It works fine on windows and linux but the fix requires copying
>>>>> _pcbnew.kiface with the correct python extension and I'm not so sure
>>>>> this isn't going to cause build issues on osx.  Please let me know what
>>>>> I need to change if this patch doesn't work on osx.
>>>>>
>>>>> 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

[Kicad-developers] menu bitmaps

[Simon Wells]

Currently the CMakeLists.txt says that menu icons are 16x16, but many
of the icons which i believe are in the menu and in the menu only are
in the 26x26 list, this includes the lang_* icons (for example) which
i have yet to see outside of the language menu.

which one should it be and can the comment in the CMakeLists be clarified.

Also due to the cmake option disabling the menu bitmaps (esspecially
on osx, where its disabled by default) does it make sense to make a
seperate set of the menu bitmaps so that they can be selectively built
depending on whether the cmake option is actually enabled

Simon

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

Re: [Kicad-developers] RFC: Arbitrary color support

[Simon Wells]

i thought this wasn't possible due to wxDC limitations

On 7 February 2017 at 17:00, Chris Pavlina  wrote:
> I'm working on an eight-layer board and really can't wait for this to
> hit pcbnew too. It's bloody impossible to tell layers apart with KiCad's
> state-of-the-80s-art color system.
>
> On Mon, Feb 06, 2017 at 10:03:11PM -0500, Jon Evans wrote:
>> Hi all,
>>
>> I started working on the idea of a color theme system for KiCad, starting
>> with the schematic editor.
>>
>> This change relies on a complete removal of EDA_COLOR_T from the code, and
>> replacement with a color structure that can handle arbitrary colors.  I
>> think this is important and the right path for the future, but since it's a
>> significant change, I wanted to get buy-in before going any farther down
>> this road.  I can understand the reasons for using an enum for
>> color--especially since it lets the developers restrict the colors to those
>> that will work well with the drawing technique of the legacy canvases.
>> But, since the new canvases will have no problem supporting arbitrary
>> colors, I think it makes sense to start setting up the groundwork for that.
>>
>> In my test code, I have replaced EDA_COLOR_T with wxColour, since that is
>> used internally in a few places already, and it was pretty simple (although
>> somewhat time-consuming) to replace all usages.  wxColour has the nice
>> property of serializing/deserializing from hex color codes like "#80FC62"
>> so that's what I use for storing in the settings for now (eventually I
>> think color settings should be in their own files so that they can be
>> traded by users).  Plus, there is a canned wxColourPicker widget that I can
>> use in place of the custom color picker buttons that are used in the
>> settings today.
>>
>> You can see some screenshots of the (work-in-progress) settings dialog
>> changes, and an example of a custom color theme in the schematic editor,
>> here:
>> http://imgur.com/a/MxMmb
>>
>> So, any feedback from the core team?  Any reason why I shouldn't move
>> forward with preparing a patch to move from EDA_COLOR_T to wxColour across
>> the board?
>>
>> Best,
>> Jon
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Patch to compile _pcbnew.kiface only once

[Simon Wells]

its not good on osx, I will take a look over the weekend, There are a
few things i would like to change in that cmakelists, esspecially in
regards to OSX and the order of things/when things are done

On 3 February 2017 at 07:28, Wayne Stambaugh  wrote:
> Did anyone of our osx devs get a chance to test this patch yet?  I would
> like to get it merged.  It saves a nice chunk of time from builds.
>
> Cheers,
>
> Wayne
>
> On 1/26/2017 11:42 AM, Wayne Stambaugh wrote:
>> Would one of our osx devs please test the attached patch?  Dick sent me
>> this patch to fix the long standing issue of building _pcbnew.kiface
>> twice.  It works fine on windows and linux but the fix requires copying
>> _pcbnew.kiface with the correct python extension and I'm not so sure
>> this isn't going to cause build issues on osx.  Please let me know what
>> I need to change if this patch doesn't work on osx.
>>
>> 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] Autosave BS

[Simon Wells]

It probably wouldn't be too bad, if each file was timestamped, and
then deleted if/when kicad exits cleanly, therefore unless one has a
very crashy kicad there should be very few autosaves and very few
needed. If you exit kicad cleanly and then want the autosave well
thats user fault.

On 24 January 2017 at 12:26, Chris Pavlina  wrote:
> I'm talking to someone on IRC right now who lost two hours of routing
> because pcbnew crashed, then deleted his autosave file before he could
> make use of it. We need to put some new efforts into:
>
> 1. Never delete autosave data. He may have accidentally saved the board
> before loading the autosave, I'm not sure - pcbnew deletes autosave when
> saving - but there should be some proper protection against this.
>
> 2. Never overwrite potentially useful autosave data - if pcbnew is
> reloaded, a previous autosave shouldn't be deleted either. It should
> only be valid to delete autosave data if the board has not been modified
> since the autosave was made.
>
> 3. Better recovery UI when loading after a crash.
>
> It may be necessary to record in the autosave file which run of pcbnew
> it was created in (timestamp at startup?) to distinguish between old
> autosave data from a previous run (possible recovery source) and data
> from the current run (may be overwritten).
>
> I haven't completely thought this through yet, just starting a thread
> for discussion. This is definitely a problem we need to do something
> about.
>
> -- Chris
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Dialog SetFocus patches for OSX

[Simon Wells]

it seems this is just as broke with or without the patch so this patch
can be pushed, will need to check into why its stealing focus on mouse
over though

On 24 January 2017 at 04:01, Simon Wells <swel...@gmail.com> wrote:
> Just a comment on the pad properties dialog, it works fine on init but
> the field loses focus when i mouse over the "preview" part of the
> dialog... is there a way to prevent this? (it should really only lose
> focus if someone clicks in the preview area) although i am unsure of
> the intricacies of wx and osx as to whether you unfocused zooming and
> panning and such work.
>
> On 23 January 2017 at 12:34, Wayne Stambaugh <stambau...@gmail.com> wrote:
>> Would one of our osx devs test these patches and let me know if I should
>> commit them.  I don't see any coding policy violations so as long as
>> they fix the problems on osx then I will commit them.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 1/22/2017 5:52 PM, Diogo Condeço wrote:
>>> Hi all,
>>>
>>> I've attached 2 patches for some SetFocus optimisations on Macos. Tested
>>> also on Linux where there wasn't the issue, and it is still ok. This was
>>> a macos specific problem...
>>>
>>> 0001 fixes the find dialog and pad_properties dialog on pcbnew
>>> 0002 fixes add_component dialog on eeschema
>>>
>>> I've used the recommended wxFB3.5-RC1
>>> (https://github.com/marekr/wxFormBuilder.git
>>> <https://github.com/marekr/wxFormBuilder.git>) to modify the dialogs.
>>> Which isn't also working on macos making it hard to use it...
>>>
>>>
>>>
>>> --
>>> Diogo Condeço
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [PATCH] Signal handlers for SINGLE_TOP and KICAD

[Simon Wells]

this seems broken on pcbnew when python is enabled at least on osx. getting

Air:~ simon$ /Volumes/simon/kicad-app/bin/kicad.app/Contents/MacOS/kicad

^C^C^C^C^C^C^C^C^C^C^C^C^C^C^CError in sys.exitfunc:

Traceback (most recent call last):

  File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/atexit.py",
line 13, in _run_exitfuncs

def _run_exitfuncs():

KeyboardInterrupt

even after i close pcbnew and open eeschema it still doesn't work

On 12 January 2017 at 13:19, John Beard  wrote:
> And here is the patch with the class name in capitals and a class
> comment block. Sorry!
>
> On Wed, Jan 11, 2017 at 11:26 PM, John Beard  wrote:
>> Hi,
>>
>> None of the KiCad programs appear to implement any signal handlers.
>> This means that some of them (e.g. pcbnew) don't respond to things
>> like SIGINT generated by a Ctrl-C in the console its running from
>> (very annoying when running up and down repeatedly), and others (e.g.
>> eeschema) terminate immediately, rather than shutting down.
>>
>> The attached patch implements a graceful shutdown on SIGINT for all of
>> the SINGLE_TOP programs as well as KICAD.
>>
>> I have put it in a separate class (static members because the handlers
>> have to be that way), so that 1) the same handler can be used in both
>> places and 2) in future if the signal handlers grow, any complexity is
>> contained.
>>
>> I have tested this on Linux, and since it's using the standard C++
>>  stuff, I assume it works (or at least compiles) on all
>> platforms, but I can't prove it!
>>
>> Cheers,
>>
>> John
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~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] Dialog SetFocus patches for OSX

[Simon Wells]

Just a comment on the pad properties dialog, it works fine on init but
the field loses focus when i mouse over the "preview" part of the
dialog... is there a way to prevent this? (it should really only lose
focus if someone clicks in the preview area) although i am unsure of
the intricacies of wx and osx as to whether you unfocused zooming and
panning and such work.

On 23 January 2017 at 12:34, Wayne Stambaugh  wrote:
> Would one of our osx devs test these patches and let me know if I should
> commit them.  I don't see any coding policy violations so as long as
> they fix the problems on osx then I will commit them.
>
> Thanks,
>
> Wayne
>
> On 1/22/2017 5:52 PM, Diogo Condeço wrote:
>> Hi all,
>>
>> I've attached 2 patches for some SetFocus optimisations on Macos. Tested
>> also on Linux where there wasn't the issue, and it is still ok. This was
>> a macos specific problem...
>>
>> 0001 fixes the find dialog and pad_properties dialog on pcbnew
>> 0002 fixes add_component dialog on eeschema
>>
>> I've used the recommended wxFB3.5-RC1
>> (https://github.com/marekr/wxFormBuilder.git
>> ) to modify the dialogs.
>> Which isn't also working on macos making it hard to use it...
>>
>>
>>
>> --
>> Diogo Condeço
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~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] downloads.kicad-pcb.org

[Simon Wells]

The download machine seems to be having issues. myself and someone
else have both experienced downloads dying mid way through

can someone who has access take a look please

thanks

___
Mailing list: https://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] Current state of ActionPlugin

[Simon Wells]

well in its current state its not going to build an "invalid
configuration" as it forces KICAD_SCRIPTING to ON, but there is a
question whether an explicit on should override an explicit off, or
lets say down the line that scripting becomes on by default as does
the action menu. If someone explicitly states KICAD_SCRIPTING to OFF
and that setting will be ignored when the other settings are implicit

On Thu, Jan 19, 2017 at 8:37 AM, Wayne Stambaugh <stambau...@gmail.com> wrote:
> On 1/18/2017 11:56 AM, Jean-Samuel Reynaud wrote:
>>
>> For this particular point, I do exactly the same as
>> KICAD_SCRIPTING_MODULES option.
>>
>> But for both option (KICAD_SCRIPTING_MODULES and
>> KICAD_SCRIPTING_ACTION_MENU) you mean that it's better to fail the
>> configuration if the options are not compatibles ?
>
> Yes!  KiCad should not build an invalid configuration.  The config step
> should fail.
>
>>
>>
>>
>>
>> Le 17/01/2017 à 20:53, Simon Wells a écrit :
>>> slightly off-topic (again?) but it just came to mind.
>>>
>>> currently if option X requires Y then Y is forced on if not already
>>> on. is there a way to differentiate between an explicit OFF and an
>>> implicit OFF that we could use to force on if implicit but error if
>>> explicitly off.
>>>
>>> This might be useful if a user/packager/compiler is not aware that X
>>> requires Y but he can't/doesn't want Y for whatever reason.
>>>
>>> i am not sure how much sense i am making so an example maybe
>>>
>>> USER decides to build themselves, he doesn't want or have python but
>>> the action menu sounds interesting.
>>> USER does cmake -DKICAD_PYTHON_SCRIPTING=NO -DKICAD_ACTION_MENU=ON.
>>> kicad build fails due to lack of python. USER gets mad (this ones not
>>> too bad as he can see in build log it was forced on)
>>>
>>> if USER had python (but still didn't want it built in to kicad)
>>> 3months down the line USER has an issue, uses copy version info and
>>> wonders why PYTHON_SCRIPTING=ON when USER said no.
>>>
>>> or from a packagers perspective
>>> PACKAGER likes to add all new features but has a set of packages which
>>> don't require python
>>> PACKAGER does does cmake -DKICAD_PYTHON_SCRIPTING=NO -DKICAD_ACTION_MENU=ON.
>>> PACKAGER doesn't read log as its really long and requires effort
>>> PACKAGER distributes packages saying "No python required, includes action 
>>> menus"
>>> USER downloads PACKAGERs package and doesn't have python and complains
>>> because it doesn't run
>>>
>>> Both of these would make it hard to glimpse at the cmake log unless
>>> the packager makes it available in the latter case to see that it was
>>> forced on (or dig into the source to find out why)
>>>
>>> Simon
>>>
>>> On Wed, Jan 18, 2017 at 7:46 AM, Jean-Samuel Reynaud
>>> <js.reyn...@gmail.com> wrote:
>>>>> yes i was trying to subtly imply that :)
>>>> ok, find attached the patch with the about box updated ;)
>>>>
>>>> Regards,
>>

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

[Kicad-developers] cmake python fix_swig_imports

[Simon Wells]

Due to still getting

pcbnew/CMakeFiles/_pcbnew.dir/build.make:125: warning: overriding
commands for target `pcbnew/pcbnew.py'
pcbnew/CMakeFiles/_pcbnew.dir/build.make:89: warning: ignoring old
commands for target `pcbnew/pcbnew.py'

warnings during build on osx i have been trying to work out what is
causing this issue and found that we have duplicated

COMMAND ${PYTHON_EXECUTABLE}
${CMAKE_SOURCE_DIR}/scripting/build_tools/fix_swig_imports.py
${CMAKE_CURRENT_BINARY_DIR}/pcbnew.py

once on line 412 and again on line 745 in pcbnew/CMakeLists.txt

one of these is in KICAD_SCRIPTING conditional and the other is in
KICAD_SCRIPTING_MODULES conditional, however as you can't have MODULES
without SCRIPTING they seem redundant however i don't understand
enough about the swig system to just delete it and provide a patch.

Are there any swigheads who understand enough to say whether removing

add_custom_target( FixSwigImportsModuleScripting ALL
COMMAND ${PYTHON_EXECUTABLE}
${CMAKE_SOURCE_DIR}/scripting/build_tools/fix_swig_imports.py
${CMAKE_CURRENT_BINARY_DIR}/pcbnew.py
DEPENDS _pcbnew
COMMENT "Fixing swig_import_helper in Kicad scripting modules"
)

is a bad idea?

thanks

Simon

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

Re: [Kicad-developers] Current state of ActionPlugin

[Simon Wells]

slightly off-topic (again?) but it just came to mind.

currently if option X requires Y then Y is forced on if not already
on. is there a way to differentiate between an explicit OFF and an
implicit OFF that we could use to force on if implicit but error if
explicitly off.

This might be useful if a user/packager/compiler is not aware that X
requires Y but he can't/doesn't want Y for whatever reason.

i am not sure how much sense i am making so an example maybe

USER decides to build themselves, he doesn't want or have python but
the action menu sounds interesting.
USER does cmake -DKICAD_PYTHON_SCRIPTING=NO -DKICAD_ACTION_MENU=ON.
kicad build fails due to lack of python. USER gets mad (this ones not
too bad as he can see in build log it was forced on)

if USER had python (but still didn't want it built in to kicad)
3months down the line USER has an issue, uses copy version info and
wonders why PYTHON_SCRIPTING=ON when USER said no.

or from a packagers perspective
PACKAGER likes to add all new features but has a set of packages which
don't require python
PACKAGER does does cmake -DKICAD_PYTHON_SCRIPTING=NO -DKICAD_ACTION_MENU=ON.
PACKAGER doesn't read log as its really long and requires effort
PACKAGER distributes packages saying "No python required, includes action menus"
USER downloads PACKAGERs package and doesn't have python and complains
because it doesn't run

Both of these would make it hard to glimpse at the cmake log unless
the packager makes it available in the latter case to see that it was
forced on (or dig into the source to find out why)

Simon

On Wed, Jan 18, 2017 at 7:46 AM, Jean-Samuel Reynaud
 wrote:
>> yes i was trying to subtly imply that :)
> ok, find attached the patch with the about box updated ;)
>
> Regards,

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

Re: [Kicad-developers] Current state of ActionPlugin

[Simon Wells]

yes i was trying to subtly imply that :)

On Wed, Jan 18, 2017 at 1:39 AM, Jean-Samuel Reynaud
<js.reyn...@gmail.com> wrote:
> Did you want I add it to the patch?
>
> Regards.
>
>
>
> Le 16 janv. 2017 20:35, "Wayne Stambaugh" <stambau...@gmail.com> a écrit :
>>
>> Yes.  This is a useful piece of information in case we suddenly get a
>> rash of python scripting bug reports.
>>
>> On 1/16/2017 2:15 PM, Simon Wells wrote:
>> > Should this option be added to the about box->copy version info for
>> > completeness?
>> >
>> > On Tue, Jan 17, 2017 at 8:08 AM, Jean-Samuel Reynaud
>> > <js.reyn...@gmail.com> wrote:
>> >> Hi all,
>> >>
>> >> Please find attached the patch for the action plugin menu.
>> >>
>> >> There is a build option to enable/disable this feature:
>> >> KICAD_SCRIPTING_ACTION_MENU
>> >> => It's disabled by default
>> >>
>> >> Now there is a refresh button. It took new plugins, update existing ...
>> >> like in footprint wizard dialog.
>> >>
>> >> I had remove the example from the patch as asked.
>> >>
>> >> Regards,
>> >> Le 11/01/2017 à 18:58, jp charras a écrit :
>> >>> Le 11/01/2017 à 17:36, Jean-Samuel Reynaud a écrit :
>> >>>>>> Pay a particular attention to the fact plugins can be *now* updated
>> >>>>>> (when the source file has
>> >>>>>> changed), and therefore menus can also be updated.
>> >>>>>> the "PCB_EDIT_FRAME::createActionPluginMenus()" method calls
>> >>>>>> Connect, but Disconnect is never called
>> >>>>>> by destructors.
>> >>>>>> It can create issues when updating scripts, because it could be
>> >>>>>> called more than once.
>> >>>>>
>> >>>>> If you need to update the menus when a script file changes, you
>> >>>>> would
>> >>>>> have to connect a wxFileWatcherEvent to the appropriate wxMainFrame
>> >>>>> object to monitor the loaded script file and update the menus
>> >>>>> accordingly.  It can be done but I would proceed with caution here.
>> >>>>>
>> >>>> Is it really necessary to add a file watcher ? Once python plugins
>> >>>> are
>> >>>> loaded, python subsystem run the plugin as it was at start time (As I
>> >>>> understand).
>> >>>> I had perform a little test for that. If you modify a plugin while
>> >>>> pcbnew is running, this is always the "old" version that is running.
>> >>>> Not
>> >>>> sure that is true for all OS...
>> >>>
>> >>> I am thinking you are talking only about tests on footprint wizards.
>> >>>
>> >>> On Windows, the newer is reloaded (as long as you run
>> >>> onUpdatePythonModulesClick).
>> >>> This is easy to see if the description string in the footprint plugin
>> >>> is modified.
>> >>>
>> >>>> So menu are not supposed to change even if file change.
>> >>>> An other point: if I implement that file watching, I should also
>> >>>> implement a "directory watcher". In case a new plugins is installed
>> >>>> during pcbnew is running ;)
>> >>>> Perhaps an "update button": like onUpdatePythonModulesClick for
>> >>>> footprint plugins ?
>> >>>
>> >>> From my experience when debugging a footprint wizard module:
>> >>> An "update button" is certainly enough: it is mainly for python script
>> >>> developers when they are
>> >>> writing and debugging a python script, not for an user who just uses a
>> >>> script.
>> >>> An automatic update is not useful, and perhaps not good.
>> >>>
>> >>> The update button was asked since a long time, and I perfectly
>> >>> understand this wish.
>> >>> (The old way was: closing and rerun kicad)
>> >>> It is intended to reload python modules during their development.
>> >>>
>> >>> Remark: onUpdatePythonModulesClick updates all loaded python modules.
>> >>> Of course only python modules which are newer than the currently
>> >>&

Re: [Kicad-developers] Current state of ActionPlugin

[Simon Wells]

Should this option be added to the about box->copy version info for
completeness?

On Tue, Jan 17, 2017 at 8:08 AM, Jean-Samuel Reynaud
 wrote:
> Hi all,
>
> Please find attached the patch for the action plugin menu.
>
> There is a build option to enable/disable this feature:
> KICAD_SCRIPTING_ACTION_MENU
> => It's disabled by default
>
> Now there is a refresh button. It took new plugins, update existing ...
> like in footprint wizard dialog.
>
> I had remove the example from the patch as asked.
>
> Regards,
> Le 11/01/2017 à 18:58, jp charras a écrit :
>> Le 11/01/2017 à 17:36, Jean-Samuel Reynaud a écrit :
> Pay a particular attention to the fact plugins can be *now* updated (when 
> the source file has
> changed), and therefore menus can also be updated.
> the "PCB_EDIT_FRAME::createActionPluginMenus()" method calls Connect, but 
> Disconnect is never called
> by destructors.
> It can create issues when updating scripts, because it could be called 
> more than once.

 If you need to update the menus when a script file changes, you would
 have to connect a wxFileWatcherEvent to the appropriate wxMainFrame
 object to monitor the loaded script file and update the menus
 accordingly.  It can be done but I would proceed with caution here.

>>> Is it really necessary to add a file watcher ? Once python plugins are
>>> loaded, python subsystem run the plugin as it was at start time (As I
>>> understand).
>>> I had perform a little test for that. If you modify a plugin while
>>> pcbnew is running, this is always the "old" version that is running. Not
>>> sure that is true for all OS...
>>
>> I am thinking you are talking only about tests on footprint wizards.
>>
>> On Windows, the newer is reloaded (as long as you run 
>> onUpdatePythonModulesClick).
>> This is easy to see if the description string in the footprint plugin is 
>> modified.
>>
>>> So menu are not supposed to change even if file change.
>>> An other point: if I implement that file watching, I should also
>>> implement a "directory watcher". In case a new plugins is installed
>>> during pcbnew is running ;)
>>> Perhaps an "update button": like onUpdatePythonModulesClick for
>>> footprint plugins ?
>>
>> From my experience when debugging a footprint wizard module:
>> An "update button" is certainly enough: it is mainly for python script 
>> developers when they are
>> writing and debugging a python script, not for an user who just uses a 
>> script.
>> An automatic update is not useful, and perhaps not good.
>>
>> The update button was asked since a long time, and I perfectly understand 
>> this wish.
>> (The old way was: closing and rerun kicad)
>> It is intended to reload python modules during their development.
>>
>> Remark: onUpdatePythonModulesClick updates all loaded python modules.
>> Of course only python modules which are newer than the currently loaded are 
>> reloaded.
>> Therefore onUpdatePythonModulesClick will also update the action plugins.
>>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~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] Footprint Wizards Update

[Simon Wells]

Hi Oliver,

Just a friendly reminder that if you are removing variable definitions
followed by ugly platform specific ifdefs to either check it still
builds on each platform or just double check that the variable is not
used on any platform

nice patches though

thanks

Simon

On Thu, Jan 5, 2017 at 9:11 AM, Oliver Walters
 wrote:
> Thanks JP, sorry I didn't see any of these messages, blame timezones!
>
> One addition I'd like to see is an import error message if a particular
> script is bad.
>
> Previously if there was an error in any footprint script, KiCad would halt
> the import process and no subsequent scripts would be imported.
>
> I changed this with a simple try/except clause and any bad scripts are
> silently dropped. I could not work out how to pass an error message back to
> the UI from the import script.
>
> Cheers,
> Oliver
>
> On 5 Jan 2017 04:00, "Wayne Stambaugh"  wrote:
>
> On 1/4/2017 10:54 AM, jp charras wrote:
>> Le 03/01/2017 à 16:30, Wayne Stambaugh a écrit :
>>> On 1/3/2017 10:08 AM, jp charras wrote:
 Le 03/01/2017 à 15:30, jp charras a écrit :
> Le 03/01/2017 à 14:03, Miguel Angel Ajo Pelayo a écrit :
>> Sorry, I just found the email. Sorry for my delayed answer.
>>
>> The code looks good to me, I believe it's a good change, it's not
>> backwards compatible with the
>> older footprint wizards, but the changes to make them compatible seem
>> simple enough, and well
>> documented.
>>
>>
>> If I had comments to make, it'd be why are we using uInteger, uEtc for
>> parameter types.
>>
>> Could we use the python convention to have constants in upcase, and
>> may be se
>>
>> INTEGER_PARAM,  ETC_PARAM on the python side ?
>>
>> this is more nitpicking than anything.
>>
>>
>> Nice work.
>
> I agree, and I am willing to commit this change (the API is better),
> but because it breaks the
> compatibility (yes, the changes to make old wizards compatible is
> simple and documented) I need the
> Wayne's opinion before committing the changes.
>
> Attached a patch against the lastest kicad version (the initial patch
> is not applicable to the
> current kicad version).
>

 My previous patch is perhaps missing some changes. Here is the full
 patch.
>>>
>>> It looks fine to me except for some coding policy issues ( missing
>>> spaces between ( and ) and some trailing white space).  The only issue I
>>> see is anyone using the python code in custom scripts may not be very
>>> happy about the changes.  It would be nice to hear from the original
>>> author about the changes.  If no one has any serious objections, then
>>> feel free to commit the patch.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>
>> I just committed the Footprint Wizards Update patch, with some fixes
>> (including coding style fixes)
>>
>
> Thanks JP!
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

Re: [Kicad-developers] [PATCH 0/4] Performance counter rework

[Simon Wells]

Hi JP,

see latest code that chris pushed

On Sat, Jan 7, 2017 at 7:43 AM, jp charras <jp.char...@wanadoo.fr> wrote:
> Le 06/01/2017 à 14:35, Simon Richter a écrit :
>> Hi,
>>
>> On 06.01.2017 03:19, Simon Wells wrote:
>>
>>> converting the std::chrono::system_clock::now() to
>>> high_resolution_clock breaks builds on osx, i can't see if there is an
>>> explicit conversion function. is there any reason we aren't just
>>> using std::chrono::high_resolution_clock::now()? as this builds fine
>>> on osx and i don't really want to have to ifdef it
>>
>> Yes, that is actually correct.
>>
>> Another case of gcc accepting incorrect code. :/
>>
>>Simon
>>
>
> Hi Simon,
>
> I don't really understand your answer.
> What code is correct and what code is incorrect?
> gcc has nothing to do with this issue.
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [PATCH 0/4] Performance counter rework

[Simon Wells]

converting the std::chrono::system_clock::now() to
high_resolution_clock breaks builds on osx, i can't see if there is an
explicit conversion function. is there any reason we aren't just
using std::chrono::high_resolution_clock::now()? as this builds fine
on osx and i don't really want to have to ifdef it

On Thu, Dec 29, 2016 at 4:05 PM, Simon Richter  wrote:
> Hi,
>
> this cleans up the performance counters, using only a single interface, and
> switches that implementation to use std::chrono with a high resolution
> timer.
>
>Simon
>
> Simon Richter (4):
>   PROF_COUNTER: initialize in initializer list
>   Use std::chrono and std::cerr in PROF_COUNTER
>   Switch profiled code to uppercase PROF_COUNTER
>   Remove old profile counter implementation
>
>  common/gal/opengl/cached_container.cpp | 15 +++---
>  common/gal/opengl/gpu_manager.cpp  | 10 ++--
>  common/gal/opengl/opengl_gal.cpp   | 10 ++--
>  common/view/view.cpp   |  5 +-
>  include/profile.h  | 92 
> --
>  5 files changed, 38 insertions(+), 94 deletions(-)
>
> --
> 2.11.0
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

___
Mailing list: https://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] Symbol library table.

[Simon Wells]

would it not be better keeping SYS for system and then in the future
if there is an equivalent user dir the user dir could  skip USER so
that its shorter to remember for those who set it which is more likely
than setting the system dir

On Tue, Dec 13, 2016 at 2:22 AM, Wayne Stambaugh  wrote:
> On 12/11/2016 4:14 PM, Nick Østergaard wrote:
>> Also, if we are to use the "verbose" version, can't we just drop the
>> _SYS part?  I don't see that as adding any information to the string.
>
> I'm OK with this.  I'll fix this in my next batch of Eeschema changes.
>
>>
>> 2016-12-11 22:13 GMT+01:00 Nick Østergaard :
>>> Would it be bad to support both?
>
> We would have to be careful in the case of conflicting paths.  Other
> than that, I don't see an issue with supporting both other than the
> additional code which I'm not terribly thrilled about maintaining.
>
>>>
>>> 2016-12-11 22:07 GMT+01:00 Wayne Stambaugh :
 Hey Nick,

 KICAD_SYS_SYMBOL_DIR is much more readable than KISYSSYM.  I was
 actually thinking about changing KISYSMOD to KICAD_SYS_FOOTPRINT_DIR for
 the sake of consistency in spite of the obvious grumbling it will cause.
  I just haven't gotten around to getting other user's opinions yet.  At
 some point before the stable 5 release, I will change one of the two
 variable names so they are consistent.

 Cheers,

 Wayne

 On 12/11/2016 3:27 PM, Nick Østergaard wrote:
> Hi Wayne
>
> I just noticed, https://github.com/KiCad/kicad-library/pull/805
>
> I see that you expect KICAD_SYS_SYMBOL_DIR instead of KISYSSYM. I
> think the latter is better for the sake of consistency.
>
> 2016-12-10 16:39 GMT+01:00 Wayne Stambaugh :
>> I just pushed the commit for loading the symbol library table.  The
>> first time you run Eeschema with the changes, you will be prompted about
>> loading the default symbol library table.  This is the same mechanism
>> that is implemented in the footprint library table code so it will be
>> familiar.  Unless you have a fairly recent copy of the kicad library
>> repo from github, an empty symbol library table will be created in your
>> kicad config folder.  You will need to copy the full version of
>> sym-lib-table from the kicad library repo to your kicad config folder if
>> this is the case.  Please note that the symbol library table is not
>> being used yet.  This is just loads the the table.  If all goes well,
>> the symbol library table will be fully implemented before the holiday 
>> break.
>>
>> Cheers,
>>
>> Wayne
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp

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

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

Re: [Kicad-developers] Cairo boost

[Simon Wells]

I just tried this out on osx and find that in cairo pinch-zoom no
longer works. It still works fine in openGL and legacy canvai (don't
know what the plural for canvas is) any idea why its broke?

On Tue, Dec 13, 2016 at 11:57 AM, Maciej Sumiński
 wrote:
> I am glad the world still has not exploded;)
>
> On 12/12/2016 11:16 PM, Nick Østergaard wrote:
>> Come on! I waited almost eight minutes for you to rebase and push that
>> bunch of patches :D
>>
>> 2016-12-12 22:15 GMT+01:00 Maciej Sumiński :
>>> Hi Nick,
>>>
>>> You were right, at the moment of writing the changes were not pushed,
>>> but they should be already there. Thank you for noting.
>>>
>>> Regards,
>>> Orson
>>>
>>> On 12/12/2016 05:16 PM, Nick Østergaard wrote:
 Are you sure you pushed the changes? The latest commit is from two
 days ago on master.

 2016-12-12 17:08 GMT+01:00 Maciej Sumiński :
> I have just fixed the two mentioned problems (screen refresh after flip,
> inverted cursor control using arrow keys) and merged the changes to the
> master branch.
>
> Regards,
> Orson
>
> On 12/09/2016 05:32 PM, Maciej Sumiński wrote:
>> Hi,
>>
>> Tom has just finished working on cairo backend optimizations [1]. We
>> still have a few tricks up our sleeves, so if the current performance is
>> still not high enough to make cairo the offical SW renderer, we can
>> continue optimizations.
>>
>> It is not merged yet, as the most time consuming part is now implemented
>> using pixman, which is one od cairo dependencies.
>> Wayne, are you ok with making pixman an explicit KiCad dependency? I do
>> not think it should be a problem, but I prefer to be safe than sorry.
>>
>> Tom's branch also contains refactoring of VIEW/VIEW_ITEM classes
>> (decoupling EDA_ITEM from VIEW) and a small bonus feature called
>> "flipped view".
>>
>> Regards,
>> Orson
>>
>> 1. https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+ref/cairo_boost
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

[Kicad-developers] OSX bundle utilities/get prerequisites issues with boost

[Simon Wells]

As a couple of OSX devs have run into this issue i am going to
document it here so that future people are able to find it...

The issue occurs during the "make install" phase of kicad on osx
(hence this only affects devs not users) and will mention something
about not being able to find

@loader_path/libboost_.dylib
i have commonly seen this with libboost_chrono-mt.dylib

This is due to how FindBoost.cmake is configured in that every new
version of boost requires manual intervention to make it work again
due to

function(_Boost_COMPONENT_DEPENDENCIES component _ret)

elseif(NOT Boost_VERSION VERSION_LESS 106100 AND Boost_VERSION
VERSION_LESS 106200)
elseif(NOT Boost_VERSION VERSION_LESS 106200 AND Boost_VERSION
VERSION_LESS 106300)
etc.

The most recent version also has the AND and so it will not work for
any future versions without an updated FindBoost.cmake script. As the
release cycles for boost and cmake are not synced this typically
leaves at least a month between boost release and the next cmake
release fixing the FindBoost.cmake file

As such there are a couple of ways to solve this issue.

1. Downgrade boost to a version that is older than the cmake release
you are running (on brew this is a case of using $ brew switch boost
)
2. Check cmake git master to see if the file has been updated and copy
the changes into your system FindBoost.cmake (on brew
/usr/local/opt/cmake/share/cmake/Modules/FindBoost.cmake)
3. Remove the AND in the FINAL elseif statement (not really
recommended as may not be correct for the new version of boost)
4. install and use cmake HEAD in boost (there may still be a couple of
day delay in the updated script but not nearly as bad as it is now)

I have sent this updated information to the cmake mailing list (as i
was unable to figure out the cause when i last experienced the issue
back in jan so hopefully we may see some changes in getprereqs/bundle
utilities in the future which may reduce the dependency on this issue)
However that will be unlikely until at least cmake 3.8 so don't expect
it to be the required cmake version any time soon.

Simon

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

Re: [Kicad-developers] Gerber Plot last options.[INFO]

[Simon Wells]

I realise this is sorta off track but as its sort of related is there
any particular reason that plot gerbers doesn't just do the drill file
as well? as it can be a rather easy thing to miss clicking the
generate drill file

On Mon, Oct 24, 2016 at 7:28 AM, jp charras  wrote:
> Le 19/09/2016 à 13:58, jp charras a écrit :
>> Hi All,
>>
>> I just pushed in 2016-09-19 revision 6edee2a an option in Plot Gerber dialog 
>> to include advanced
>> aperture and net attributes.
>> This option is not yet activated by default, because net attributes are not 
>> yet fully fixed by
>> Ucamco, in Gerber file format specifications.
>> To activate it, see dialog_plot.cpp, line 43, and uncomment line 44.
>>
>> When activated, you can see a new option in Gerber plot dialog to include 
>> advanced X2 netlist
>> attributes.
>>
>> If activated, the Gerber files contains some metadata, related to netlist 
>> info and aperture attributes.
>> When available, Gerbview can highlight a full net or a full set of items 
>> related to a gived
>> footprint or a given aperture attribute.
>> (Use right click on a Gerber item (line or flashed item) to access the 
>> context menu)
>>
>
> Hi All,
>
> In 2016-10-22 revision 1840c3c I activated the advanced aperture and net 
> attributes option in Gerber
> files.
> (This is an option, and this metadata will be included only on request)
>
> These advanced options are now finalized,
> (To understand them, see
> https://www.ucamco.com/files/downloads/file/189/gerber_component_and_netlist_-_final.pdf?3d90d5ac39ab13049f543f41d0ecec38)
> and Ucamco has already validated my test files.
>
> Of course this metadata will be fully useful in some time, when the board 
> houses are able to use it,
> but *now* it is already useful in Kicad for guys who want to verify the 
> Gerber files before sending
> them to the board maker.
>
> Please, send me yours remarks about this feature.
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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