Re: [Kicad-developers] V6 documentation

[Martijn Kuipers]

If separate, you could update it more frequently. Just take care it is
understandable for which lkicad version it applies.

Local docs is where I look first.

Just my 2cents.
Martijn

A quarta, 19/01/2022, 05:44, Ajith Narayanan  escreveu:

> Greetings!
>
> KiCad's documentation is in a standard source format (asciidoc) from which
> HTML/CSS are generated. Currently 'KiCad Help' just kicks off a browser
> pointing it to the local file(s) (e.g.
> /usr/share/doc/kicad/help/en/kicad.html). This is quite clean.
>
> In other words, KiCad already has a (version controllable) single source
> documentation that can generate both the locally installable documentation,
> as well output suitable to be published online on the web.  (Their styles
> could be different, say by applying different CSS -- many possibilities in
> the pipeline).
>
> A single source along with a capable rendering workflow with multiple
> targets (local documentation, web, epub, PDF via a LaTeX pipeline) etc are
> all enabled by this approach.
>
> I don't think there is anything to be gained by discontinuing local
> documentation. The disk usage is very small, tiny by today's standards, and
> the pipeline / workflow  is pretty much the same, it already exists.
>
> If at all somebody wants to be free of local documentation, then:  this
> need can be served by making kicad-doc-XXX a separately installable
> package, with optional dependency indicated. When not installed, KiCad Help
> would send the browser to the online documentation site (taking care to
> match the KiCad version to the URL to the correct documentation version). I
> feel, on that help page, we should advise the user to install the package
> locally if she would like to have local access.
>
> That's just my input.
>
> --Ajith
>
>
> On Wed, 19 Jan 2022 at 02:13, Jon Evans  wrote:
>
>> We have decided to update the online documentation in a rolling fashion,
>> meaning that new changes go "live" pretty quickly after being approved and
>> merged.
>>
>> The version that is bundled with the application is a snapshot in time
>> (at the point that software release was made).
>>
>> I think moving to an online-only help system is actually a good idea and
>> I've talked about this before some -- it would also make it easier to
>> improve the formatting of the documentation, since we would have only one
>> output format (HTML/CSS) to deal with.
>>
>> The main reason to include offline documentation (other than "because
>> that's how it's always been done with KiCad") is to provide documentation
>> that is accessible if the user's computer doesn't have an internet
>> connection.  I'm not sure that this is a very important feature in today's
>> world.
>>
>> -Jon
>>
>> On Tue, Jan 18, 2022 at 1:05 PM Tom A.  wrote:
>>
>>> I don't have view at all, not really a software engineer so may take a
>>> bit of spamming with some questions that may be quite obvious to others.
>>>
>>> My first question is why in the software Help section is so dated and
>>> online version much more up to date? It seems you can access online version
>>> from the software, so why to include old (probably no more relevant)
>>> documentation?
>>>
>>> Regards,
>>> Tomas
>>>
>>> On Tue, 18 Jan 2022, 17:17 Jon Evans,  wrote:
>>>
 I don't personally see the point of spamming the list with back and
 forth about setting up Git/Gitlab, installing dependencies, etc.

 But, I am not opposed to it if others don't care.

 -Jon

 On Tue, Jan 18, 2022 at 12:02 PM Marco Ciampa 
 wrote:

> On Tue, Jan 18, 2022 at 09:10:22AM -0500, Jon Evans wrote:
> > Hi Tomas,
> >
> > I've been loosely coordinating documentation updates for V6.  There
> are not
> > very many other people working on it.  We'd be happy to have your
> help.
> > If you contact me off-list I can help you get set up to make changes
> and we
> > can figure out where you'd like to start.
>
> I don't want to be rude but I do not understand. This list is almost
> silent. For sure some docs dev set-up instructions will not hurt
> anybody
> and perhaps there is something to learn (I bet I'll learn something
> anyway ...). So please do not discuss that elsewhere. This list was
> meant
> also for this.
>
> --
>
> Saluton,
> Marco Ciampa
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
 ___
 Mailing list: https://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] Symbol library file format

[Martijn Kuipers]

> On 3 Jan 2019, at 04:17, Andrew Lutsenko  wrote:
> 
> Wayne,
> 
> > There are some interesting and practical concepts with protobuf but it's
> functionally a binary storage method which I am opposed to. 
> 
> That is a somewhat common misconception because protobufs are frequently used 
> for efficient storage/transfer in binary format. But it's not tied to that 
> format at all, at it's core protobufs are just a way of defining well 
> structured data, nothing more. It comes with bells and whistles like ability 
> to serialize it in various ways, binary being one of them.
> 
> > Encoding and decoding to a text format would be an acceptable solution. 
> Perfect, here is example of built in proto text encoder, it resembles JSON in 
> that it uses curly braces to encase submessages but doesn't abuse punctuation 
> marks unnecessarily.
> 
> user_collection {
>   description = "my default users"
>   users {
> key: "user_1234"
> value {
>   handle: "winniepoo"
>   paid_membership: true
> }
>   }
>   users {
> key: "user_9b27"
> value {
>   handle: "smokeybear"
> }
>   }
> }
> > There is also the issue of learning curve and another build dependency.
> Yes, that is inevitable but benefits I outlined in my earlier email are too 
> significant to overlook in my opinion.
> 
> > S-expr is not at all like XML at least not in terms of readability.
> It actually is a lot like XML, just less pointy brackets. Same arbitrary 
> distinctions between attributes (which are not even named in S-expr, which 
> adds to confusion when glancing at the file) and subfields.
> 
> Here is real example:
> (fp_text value 330K (at 0 -1.75) (layer B.Fab)
>   (effects (font (size 1 1) (thickness 0.15)) (justify mirror))
> )
> or
> (pad 2 smd rect (at 0.95 0 180) (size 0.7 1.3) (layers B.Cu B.Paste 
> B.Mask)
>   (net 95 "Net-(R17-Pad2)"))
> 
> Without reading file format docs and/or source code I have no idea why some 
> data is in subfields and some data is in some special fixed order on the same 
> level as it's container.
> It's also very easy to confuse "330K" being related to "value" when in fact 
> "value" is field name and "330K" is the value. In proto that would look like 
> this:
> 
> fp_text {
>   name: "value"
>   value: "330K"
>   at {
> x: 0
> y: -1.75
>   }
>   layer: "B.Fab"
>   effects {
> ...
>   }
> }
> 
> But I do agree on the point that all markup formats have their downsides. For 
> example json/yaml or proto text format would be less dense per line, however 
> that may be an upside when looked at it from version control and diff-ing 
> perspective.
> 
> > To me self documenting means that the file format doesn't even require a
> > document to explain it's contents.  It should be self evident from the
> > contents of the file. 
> What I meant by self documenting was that the document describing the format 
> and document implementing the format (actual source code) was the same.
> But even as evident from example above, proto text format yields file 
> contents that are pretty well self documented too.
> 
> > Changing file formats would be a
> > benefit but why would we need to do that?  If we have a human readable
> > file format that can be parsed easily and quickly by a computer, what
> > other criteria do we need in a file format?
> 
> See benefit #3 from my first message. By using something standard we make it 
> so much easier to expand on KiCad ecosystem in other languages. I already 
> made an example as a web viewer, here is another: someone may write a plugin 
> for java autorouter software that will read kicad files directly. 
> S-expressions was likely a good choice when it was made but today it's far 
> from widespread and is pretty much unsupported in most languages so the 
> burden is wholly on the developers. Argument can be made that while 
> S-expressions are both human and computer readable it excels at neither since 
> humans still need supporting documentation or source and computers need 
> custom written libraries.
> 
> Regards,
> Andrew
> 
> and Happy New Year :)
> 
> On Wed, Jan 2, 2019 at 8:01 AM Wayne Stambaugh  > wrote:
> On 1/2/2019 5:24 AM, kristoffer Ödmark wrote:
> > I like the idea of using something as Protobuf and I agree fully with
> > the benefits, especially since one can add/remove fields with minimal
> > impact.
> 
> There are some interesting and practical concepts with protobuf but it's
> functionally a binary storage method which I am opposed to.  Encoding
> and decoding to a text format would be an acceptable solution.  There is
> also the issue of learning curve and another build dependency.
> 
> > 
> > Basically the S-expression system used now is looking very much like a
> > reinvented XML to me anyway, and storing protobuf-defined stuff as XML
> > or similar seems actually nice.
> 
> S-expr is not at all like XML at least not in terms of readability.
> Obviously there are 

Re: [Kicad-developers] A reminder on Git commit comments

[Martijn Kuipers]

FWIW, there are a few software packages out there that can help with git and 
are free to use with open source projects, such as, Gitkraken and Smartgit.

I am not affiliated with any of them, but I have used them both. They are 
pretty much similar for the most common use cases and both provide a 
(hopefully) clearer view into the tree

/Martijn
P.S. This is not to start a flamewar. I apologise for the noise to the 
git-masters around.

> On 3 May 2018, at 07:31, Carsten Schoenert  wrote:
> 
> Hello Rene,
> 
> Am 02.05.2018 um 14:57 schrieb Rene Pöschl:
>> Most of our contributors have no previous experience with git. So we 
>> really can not expect them to understand anything beyond the github 
>> workflow. (They are experts in electronics. Not IT) I also don't believe 
>> we should burden the contributors with too much with this.
> 
> that's unfortunately true for most of contributors or contributions no
> matter what kind of software or project and that's a social challenge we
> all need to deal with.
> 
>> This is even true for the maintainers. They are selected because they 
>> understand how to make good symbols and footprints. (Understanding of 
>> industry standards, limitations of manufacturing processes and the 
>> limitations of kicad)
> 
> Reading this thread and following from time to time some library issue
> on GitHub (only by reading) I see this point in another light. It's up
> to the maintainers to get fulfilled the requirements of the project if
> he is accepting a pull request.
> 
> I see long lists of pull request on GitHub for the libraries which, and
> this list seems even to increase more over the last months which is a
> good sign I think, which waiting a review from one of the people which
> are allowed to do merge requests. OTOH I see also commit messages as
> Reece has pointed out. So for me it looks like there are two problems
> which interacting together.
> 
> 1. The maintainers (you mean above I assume), which are needed to make
> QS on new or modified parts based on the library standards, are also
> "only" volunteering by there free time and this brings long waiting
> queues even for simply contributions. This shows a lack of available
> human resources with a deep understanding what the given standards are
> mean on technical work.
> 
> 2. There are also some library maintaining people needed which know how
> to do the technical git work right. And this means mostly you sometimes
> have to leave the world of platforms like GitHub, GitLab etc if needed.
> If you know what a git merge really is and how a GitHub PR is
> technically working under the hood you are able to solve quickly
> contributions which otherwise need to wait until someone with a better
> technical understanding will provide something useful in the issue
> tracker on GitHub. Over the time this can become a serious problem for a
> project as people can get quickly frustrated and wont contributing in
> future times.
> 
>> For a lot of our casual contributors the current way of contributing is 
>> already too complex. I have seen a lot of them simply give up as soon as 
>> git did something they did not expect. This is especially common on the 
>> symbol lib side as it is likely that the contributor needs to do a 
>> manual merge because somebody else touched the same lib.
> 
> Also this problem isn't new and is related to git can't handle big
> rather complex text files well if two persons have changed such a file.
> git was developed for source code not for handling large text based
> files. In the end you will come to the conclusion that git isn't the
> best tool here but it's also the best we have.
> For me than the workflow heavily based direct on plain git isn't the
> correct one.
> 
> Thinking in long term where more KiCad users will hopefully come the
> current model of library modifications will not work well enough and
> better forms of possibilities for contributions need to prepared. The
> GitHub platform is only one part to get all things together.
> 
>> These casual contributions can in most cases be summarized as a single 
>> "added symbol for component x" message. The enduser might not be 
>> concerned on the detailed mistakes made by the contributor. (And if they 
>> are, the pull request is always linked to the contribution anyways.)
>> As we don't want users to hide their history from us maintainers (we 
>> want to see what they changed after feedback from us) we really do not 
>> want them to squash their commits (by using amend).
> 
> This information is quite useless in the end and confusing due blowing
> of commits and meta information by this. You need this information only
> to decide if further changes are needed before merging or committing.
> For me later all these changes are pointless. So please no merge commits
> in pull requests and no further modification commits.
> 
> For classical pull requests on mailing list this information is handled
> in the 

Re: [Kicad-developers] Mac packaging update

[Martijn Kuipers]

Thanks Adam and others for trying so hard to make kicad play nice on OSX.

Happy hacking,
Martijn

On Fri, 27 Apr 2018, 16:46 Adam Wolf,  wrote:

> Identified the issue.  The applications, when launched from KiCad.app,
> use the embedded Python, but when launched standalone, use the system
> Python.  I'll fix it.
>
> On Fri, Apr 27, 2018 at 7:24 AM, Adam Wolf
>  wrote:
> > You definitely cannot launch it from
> > build/kicad/src/kicad-build/kicad/kicad.app.  There are a few things
> > that have to happen to those files to make them work.
> >
> > I'll take a look at the second problem, but it won't be until tomorrow
> > at the earliest.
> >
> > Thanks for helping test.
> >
> > Adam
> >
> > On Thu, Apr 26, 2018 at 10:49 PM, Shivpratap Chauhan 
> wrote:
> >> Oh I got it. It crashes if I launch it from
> >> build/kicad/src/kicad-build/kicad/kicad.app
> >>
> >> It does not crash if launch from build/kicad-dest/kicad.app
> >>
> >> I have been facing another issue from long time, pcbnew.app failed to
> >> initialize python scripting.
> >>
> >> kicad's  error dialog pop up says:
> >>
> >> 09:08:34: * Error importing the wxPython API! *
> >> 09:08:34: pcbnewInitPythonScripting() failed.
> >>
> >> There seems to be issue with bundled python module search path, above
> >> problem goes away if I
> >> rename wx-3.0-osx_cocoa under
> >> kicad.app/Contents/Frameworks/python/site-packages to
> wx-3.0-osx_cocoa.old
> >>
> >>
> >> I found this same issue with
> >>
> http://downloads.kicad-pcb.org/osx/testing/kicad-nightly-20180426-040756-3f5f591.dmg
> >> this also.
> >>
> >> Any thought on this?
> >>
> >>
> >> On Fri, Apr 27, 2018 at 8:34 AM, Adam Wolf <
> adamw...@feelslikeburning.com>
> >> wrote:
> >>>
> >>> Does pcbnew launch from KiCad.app?
> >>>
> >>> I don't get this on my builds, and I haven't seen it on the ones from
> >>> the KiCad build machine either.  Please try
> >>>
> >>>
> http://downloads.kicad-pcb.org/osx/testing/kicad-nightly-20180426-040756-3f5f591.dmg
> >>> on your machine.
> >>>
> >>> Adam
> >>>
> >>> On Thu, Apr 26, 2018 at 10:00 PM, Shivpratap Chauhan <
> shivm...@gmail.com>
> >>> wrote:
> >>> > Hi Adam,
> >>> >
> >>> > I built kicad on Mac OSX by using
> >>> > https://github.com/wayneandlayne/kicad-mac-builder, build was
> success
> >>> > but
> >>> > pcbnew is crashing on every launch with
> >>> > following stack trace at crash:
> >>> >
> >>> > (lldb) bt
> >>> > * thread #1, queue = 'com.apple.main-thread', stop reason =
> >>> > EXC_BAD_ACCESS
> >>> > (code=1, address=0x118)
> >>> >   * frame #0: 0x7fff7d27eeb7
> >>> > libc++.1.dylib`std::__1::basic_string >>> > std::__1::char_traits, std::__1::allocator
> >>> >>::basic_string(std::__1::basic_string std::__1::char_traits,
> >>> > std::__1::allocator > const&) + 27
> >>> > frame #1: 0x00010fd6ad4d
> >>> > libwx_baseu-3.0.0.4.0.dylib`wxAppConsoleBase::GetAppName() const + 29
> >>> > frame #2: 0x00010fe167d2
> >>> >
> libwx_baseu-3.0.0.4.0.dylib`wxStandardPathsBase::AppendAppInfo(wxString
> >>> > const&) const + 178
> >>> > frame #3: 0x00010fea0847
> >>> > libwx_baseu-3.0.0.4.0.dylib`wxStandardPaths::GetUserDataDir() const
> + 71
> >>> > frame #4: 0x00010e882111
> _pcbnew.kiface`GetOSXKicadUserDataDir()
> >>> > +
> >>> > 33
> >>> > frame #5: 0x00010e8e2b77
> >>> > _pcbnew.kiface`SystemDirsAppend(SEARCH_STACK*) + 167
> >>> > frame #6: 0x00010e8ce0a7
> >>> > _pcbnew.kiface`KIFACE_I::start_common(int)
> >>> > + 103
> >>> > frame #7: 0x00010e0719cb
> >>> > _pcbnew.kiface`PCB::IFACE::OnKifaceStart(PGM_BASE*, int) + 27
> >>> > frame #8: 0x000100089835 kicad`KIWAY::KiFACE(KIWAY::FACE_T,
> >>> > bool) +
> >>> > 437
> >>> > frame #9: 0x00010008a452 kicad`KIWAY::Player(FRAME_T, bool,
> >>> > wxTopLevelWindow*) + 322
> >>> > frame #10: 0x00010001b530
> >>> > kicad`KICAD_MANAGER_FRAME::RunPcbNew(wxString const&) + 48
> >>> > frame #11: 0x00010001bc64
> >>> > kicad`KICAD_MANAGER_FRAME::OnRunPcbNew(wxCommandEvent&) + 228
> >>> > frame #12: 0x00010fec1d70
> >>> > libwx_baseu-3.0.0.4.0.dylib`wxEventHashTable::HandleEvent(wxEvent&,
> >>> > wxEvtHandler*) + 240
> >>> > frame #13: 0x00010fec341d
> >>> >
> libwx_baseu-3.0.0.4.0.dylib`wxEvtHandler::ProcessEventLocally(wxEvent&)
> >>> > + 93
> >>> > frame #14: 0x00010fec32a4
> >>> > libwx_baseu-3.0.0.4.0.dylib`wxEvtHandler::ProcessEvent(wxEvent&) +
> 100
> >>> > frame #15: 0x0001000776a5
> >>> > kicad`EDA_BASE_FRAME::ProcessEvent(wxEvent&) + 85
> >>> > frame #16: 0x00010fec2e5e
> >>> > libwx_baseu-3.0.0.4.0.dylib`wxEvtHandler::ProcessPendingEvents() +
> 478
> >>> > frame #17: 0x00010fd6c437
> >>> > libwx_baseu-3.0.0.4.0.dylib`wxAppConsoleBase::ProcessPendingEvents()
> +
> >>> > 215
> >>> > frame #18: 0x00010fe8e792
> >>> >
> >>> >
> 

[Kicad-developers] KiCad at EuroCircuits

[Martijn Kuipers]

Dear Developers,

I am in no way affiliated with EuroCircuits, but I just received an invitation 
to a KiCad seminar.
http://www.eurocircuits.com/blog/kicad-seminar/ 


I see this as a huge compliment for the state and rate of improvements of KiCad.

Thanks for all your effort! It is not fair, but events like this make it much 
easier to convince colleagues/students to try out KiCad instead of ehh, other 
popular tools.

Keep coding (please),
Martijn___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad patch?

[Martijn Kuipers]

> On 5 Jan 2017, at 21:42, Wayne Stambaugh  wrote:
> 
> I just stumbled across this:
> 
> https://www.adafruit.com/product/720
> 
> They claim "Badge created with permission by the KiCad team."  Does
> anyone know who gave them this permission?  I don't ever remember anyone
> asking us about this since I've been with the project.  Not that I
> wouldn't have given my permission.  Any publicity is good for KiCad.

Wayne, there was a thread about it in 2012 (exactly 5 years ago to date):
http://develissimo.com/forum/topic/83934/ 



Happy NewYear to you all,
Martijn


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

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

Re: [Kicad-developers] OpenSSL license

[Martijn Kuipers]

Hi,
> On 12 Jan 2016, at 19:49, Javier Serrano  
> wrote:
> 
> Hi, the thread about libcurl made me think about a recent discussion I
> read about OpenSSL licensing. The OpenSSL license seems to be
> incompatible with GPL [1]. They do have plans to migrate to Apache 2
> [2], which is compatible with GPL, but they're not there yet.
> 

If it is just for libcurl, use libcurl-gnutls instead. 

/Martijn


> Cheers,
> 
> Javier
> 
> [1] http://www.gnu.org/licenses/license-list.html#OpenSSL
> [2] https://www.openssl.org/blog/blog/2015/08/01/cla/
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


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

[Martijn Kuipers]

> On 12 Jan 2016, at 23:48, Wayne Stambaugh <stambau...@gmail.com> wrote:
> 
> On 1/12/2016 4:01 PM, Martijn Kuipers wrote:
>> Hi,
>>> On 12 Jan 2016, at 19:49, Javier Serrano <javier.serrano.par...@gmail.com> 
>>> wrote:
>>> 
>>> Hi, the thread about libcurl made me think about a recent discussion I
>>> read about OpenSSL licensing. The OpenSSL license seems to be
>>> incompatible with GPL [1]. They do have plans to migrate to Apache 2
>>> [2], which is compatible with GPL, but they're not there yet.
>>> 
>> 
>> If it is just for libcurl, use libcurl-gnutls instead. 
> 
> Good luck with that on windows.  The MSYS2 project provides libcurl
> built against openssl.  I looked at the PKGBUILD file and there are
> variants defined for builds against gnutls and ntls but they are not the
> default and I have no idea if they will build or not or the gnutls
> and/or ntls will build.

You are right. Did not think of Windows or MSYS2. Never had any use for it, but 
KiCad should support it.

Sorry for the noise.

/Martijn

> 
>> 
>> /Martijn
>> 
>> 
>>> Cheers,
>>> 
>>> Javier
>>> 
>>> [1] http://www.gnu.org/licenses/license-list.html#OpenSSL
>>> [2] https://www.openssl.org/blog/blog/2015/08/01/cla/
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://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] Caching/storimg datasheets in KiCad for offline use?

[Martijn Kuipers]

Good morning (it is here),

I use partkeepr for my datasheets and “inventory”. It takes a bit of pain to 
put all your components in, but then the information is easy to get to, 
searchable and all. It can even take a photo of you component via webcam, which 
is great for housings.


It is open source, but I am not advocating to add this to KiCad. Let’s focus on 
the development of the best affordable electronic CAD software. I think it is 
quickly taking the number one spot, 
and has for me already surpassed Eagle. Eagle is great also, but I had to make 
one larger PCB so had the options to either shelve out some more money of use 
KiCad. Guess what was my choice.

Anyway, to make a long story short: here is a link to an excellent open source 
electronic component database with a lot of bells and whistles: 
http://www.partkeepr.org 
Note, the stable release is a bit old, but it is actively being developed and 
the author has been very helpful with some minor issues I have had in the past.

Thanks KiCad devs, KiCad rocks, you rock!
/Martijn



> On 23 Sep 2015, at 02:08, Chris Pavlina  wrote:
> 
> Hmm? No, just store it by part number. You can always use a different means 
> (searching through the KiCad lib?) to find a number first.
> 
> On Sep 22, 2015 7:29 PM, "Andy Peters"  > wrote:
> 
> > On Sep 22, 2015, at 2:14 PM, Chris Pavlina  > > wrote:
> >
> > Good lord. You know you can just store datasheets in a directory on your 
> > file system, right? The same way people have stored things on computers for 
> > decades. Your computer /already has this functionality/.
> 
> Yeah, like who _doesn’t_ have a big directory tree starting with “datasheets” 
> and then a long long list of vendors and within each vendor maybe a bunch of 
> categories …
> 
> Why does the tool need to do EVERYTHING?
> 
> -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

___
Mailing list: https://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] Caching/storimg datasheets in KiCad for offline use?

[Martijn Kuipers]

Hi Lorenzo (and list, as this might interest some of you),

> On 23 Sep 2015, at 08:01, Lorenzo Marcantonio <l.marcanto...@logossrl.com> 
> wrote:
> 
> On Wed, Sep 23, 2015 at 07:57:50AM +0100, Martijn Kuipers wrote:
>> I use partkeepr for my datasheets and “inventory”. It takes a bit of pain to 
>> put all your components in, but then the information is easy to get to, 
>> searchable and all. It can even take a photo of you component via webcam, 
>> which is great for housings.
> 
> Oooh fun product, never heard of it. Too bad it runs on mysql, we are a 
> postgres shop :D
> Maybe it could be coerced, however…


Well f the wiki is accurate: https://wiki.partkeepr.org/wiki/Installer

This step prompts you for the database connection details.

Enter your database parameters. The database must exist prior installation.

Please note that we currently only support MySQL and PostgreSQL via this 
installer. If you need support for other database platforms, like Oracle or 
MSSQL, you need to create the configuration file and use the CLI setup to setup 
the database.


Um abraço,
Martijn

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


___
Mailing list: https://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] Crazyflie 2.0 quadcopter: 3D screenshots

[Martijn Kuipers]

Unbelievable! 

This looks really nice.

Congratulations,
Martijn


> On 23 Sep 2015, at 21:26, easyw  wrote:
> 
> Hi,
> 
> when I saw Crazyflie 2.0 quadcopter I said: that's really awsome! ... but it 
> was missing the 3D :)
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://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] thoughts on dependency on SISL library

[Martijn Kuipers]

Viva Miguel,

We should be fine, from 
https://www.gnu.org/licenses/gpl-faq.html#v3Notwithstanding: 
https://www.gnu.org/licenses/gpl-faq.html#v3Notwithstanding:

In AGPLv3, what counts as “interacting with [the software] remotely through a 
computer network?”

 If the program is expressly designed to accept user requests and send 
responses over a network, then it meets these criteria. Common examples of 
programs that would fall into this category include web and mail servers, 
interactive web-based applications, and servers for games that are played 
online.

If a program is not expressly designed to interact with a user through a 
network, but is being run in an environment where it happens to do so, then it 
does not fall into this category. For example, an application is not required 
to provide source merely because the user is running it over SSH, or a remote X 
session.


BTW, I think it was an extremely generous parting gift from Dick Hollenbeck to 
allow the project-lead (or Jean Pierre) to relicense the code he provided under 
GPLv3.

Regards,
Martijn



 On 26 Mar 2015, at 09:48, Miguel Ángel Ajo majop...@redhat.com wrote:
 
 Not being able to use it for cloud services because of AGPL3+ (I haven’t 
 looked
 at the license, I say it per your comments, cirilo) means that people could 
 not 
 use Kicad scripting for automating the processing for manufacturing of Kicad 
 files 
 (as an example) without publishing their scripts (I guess).  And that’s not 
 necessarily
 a good thing.
 
 
 
 Miguel Ángel Ajo
 
 On Thursday, 26 de March de 2015 at 9:17, Javier Serrano wrote:
 
 On Thu, Mar 26, 2015 at 4:36 AM, Cirilo Bernardo
 cirilo.berna...@gmail.com mailto:cirilo.berna...@gmail.com wrote:
 [ snip ]
 The only really tricky part comes from the 'v3' bit - according to the FSF
 the AGPLv3 is not compatible with GPL2, and not even compatible with
 GPLv3 but OK to mix with GPLv3 (whatever that means - I can already
 hear some lawyers laughing).
 
 [ IANAL, please take the following as the opinion of a non-expert. ]
 
 This is why the '+' (i.e. the or-later) in GPL2+ is really
 important. The KiCad sources are, to the best of my knowledge, GPL2+
 (most) and GPL3+ (the PS router). That means that the mix is
 effectively GPL3+. SISL seems to be AGPL3+. I see no incompatibility
 (see section 13 of both licenses), but mixing in AGPL3+ code is a step
 in the stronger copyleft direction. This is a strategic decision to
 be taken, IMHO by the project leader.
 
 Any thoughts on eventually having SISL as a dependency? What's the
 current status of licensing of KiCad source modules? I can remove
 the SISL dependency but this will cripple the IGES code by removing
 the ability to check the validity of some structures within an input file.
 
 There is still the misleading COPYRIGHT.txt in the root of the KiCad
 sources, which I think should just be removed. This is important, and
 I hope it can be done before the stable release.
 
 Cheers,
 
 Javier
 
 ___
 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

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

Re: [Kicad-developers] OSX Nightlies Update

[Martijn Kuipers]

 On 18 Feb 2015, at 22:01, Adam Wolf adamw...@feelslikeburning.com wrote:
 
 Also, they ones I posted are not ancient--they're from last week. :)
 

With the pace that KiCad is going, that’s ancient.
That was too easy, sorry.

Seriously. Thanks Adam, great effort get OSX KiCad up to snuff. And thanks to 
KiCad devs for that pace I was talking about.

/Martijn



 Adam Wolf
 
 On Wed, Feb 18, 2015 at 3:58 PM, Adam Wolf adamw...@feelslikeburning.com 
 mailto:adamw...@feelslikeburning.com wrote:
 Whoops, sent from wrong address.
 
 -- Forwarded message --
 From: Adam Wolf adamww...@gmail.com mailto:adamww...@gmail.com
 Date: Feb 18, 2015 3:57 PM
 Subject: Re: [Kicad-developers] OSX Nightlies Update
 To: Bob Gustafson bob...@rcn.com mailto:bob...@rcn.com
 Cc: kicad-developers@lists.launchpad.net 
 mailto:kicad-developers@lists.launchpad.net
 
 The nightlies will be built nightly.  I was able to confirm that I fixed the 
 issue Bob reported with the library table, so now I'm waiting for the build 
 server to make a new dmg and I'll quick test that and put it up on kicad 
 pcb.org http://pcb.org/.
 
 I'm off to swimming lessons with my son, hopefully everything looks good when 
 I get back, otherwise I will continue work on this tomorrow morning.
 
 After this, it'll be automatic, out of the build server to the site, so the 
 pokey humans are out of the loop.
 
 Adam Wolf
 
 On Feb 18, 2015 3:36 PM, Bob Gustafson bob...@rcn.com 
 mailto:bob...@rcn.com wrote:
 Hi Adam
 
 Are you going to use a more up-to-date version? The version of the current 
 Nightly seems to be many nights in the past.
 
 I'm watching kicad-pcb.org http://kicad-pcb.org/ for the next Nightly.
 
 Thanks much
 
 Bob G
 
 On 02/18/2015 12:45 PM, Adam Wolf wrote:
 Sure.  The plan was to upload these to the kicad-pcb.org 
 http://kicad-pcb.org/ location as soon as I verified they worked well.  
 Bob found a small issue with the library table in the extras dmg, and I 
 fixed it and am regenerating a build now.  I think that everyone seems to be 
 OK with the packages as they are, so once I test that the library table 
 works well in the new build, I'll upload them to kicad-pcb.org 
 http://kicad-pcb.org/ and we can tell non-devs about them!
 
 Should be today, I think!
 
 Adam Wolf
 
 On Wed, Feb 18, 2015 at 12:22 PM, Andy Peters de...@latke.net 
 mailto:de...@latke.net wrote:
 
  On Feb 18, 2015, at 10:35 AM, Wayne Stambaugh stambau...@gmail.com 
  mailto:stambau...@gmail.com wrote:
 
  Adam,
 
  I think you made the prudent design decision to make the pretty
  footprints available locally as an option.  Nice job with the readme.
  This should get new users up and running quickly.
 
  Thanks,
 
  Wayne
 
 Can the location of these nightlies be publicized?
 
 There are people on the eevblog forum bitching and moaning about how Kicad 
 sucks because blah blah blah and if they could actually use the current 
 stuff I think they'd change their tune.
 
 -a
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers 
 https://launchpad.net/%7Ekicad-developers
 Post to : kicad-developers@lists.launchpad.net 
 mailto:kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers 
 https://launchpad.net/%7Ekicad-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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] OSX Nightlies Update

[Martijn Kuipers]

Hi Adam,


I just quickly opened some of my boards and all work as expected.

KiCad has become huge….600MB for “just” KiCad and 860MB for the footprints 
(offline usage).

It works great though, thanks.

/Martijn


 On 17 Feb 2015, at 19:26, Wayne Stambaugh stambau...@gmail.com wrote:
 
 Great work Adam!  All you OSX users out there, please help Adam out by
 testing the bundles so we can get regular nightly builds for OSX.
 
 
 On 2/17/2015 12:50 PM, Adam Wolf wrote:
 Hi folks,
 
 I have an updated set of OS X nightlies.  I had about 20 users test it
 out last week, and one user had a horrible problem and pcbnew wouldn't
 start, and it looked like a classic bundle paths issue that we've had
 and solved about 10 times, but the other 19 seemed to have everything
 work fine.
 
 If you can take a moment to try them out, that'd be great!  If it looks
 ok, I'll turn on pushing to kicad-pcb.org http://kicad-pcb.org/ 
 http://kicad-pcb.org http://kicad-pcb.org/, and
 then work towards Python in the nightlies.
 
 https://www.dropbox.com/s/9l3d3m8xbvlrq91/kicad-r5404.20150502-102027.dmg?dl=0
 
 https://www.dropbox.com/s/gulwm6afhflfc5c/kicad-extras.20150502-102112.dmg?dl=0
 
 The extras dmg has the offline footprints.
 
 Adam Wolf
 Cofounder and Engineer
 WL
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : 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


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Martijn Kuipers]

 On 14 Jan 2015, at 21:07, Cirilo Bernardo cirilo.berna...@gmail.com wrote:
 
 
 
 On Thu, Jan 15, 2015 at 3:27 AM, Tomasz Wlostowski tomasz.wlostow...@cern.ch 
 mailto:tomasz.wlostow...@cern.ch wrote:
 On 13.01.2015 20:11, Wayne Stambaugh wrote:
  This is a tricky issue that has been discussed before.  The general
  consensus in the past has been not to support forward compatibility.  It
  increases maintenance and complexity of the file parser for a minimal
  net gain to the user.  My preference is to force users that want to
  bleed on the edge to use nightly builds rather than try to maintain any
  forward file compatibility.
 [snip]
 OK, how about this:
 - No extra version tokens (fits point A)
 - Warning instead of error on unrecognized tokens (point C - no big
 changes needed in the parser)
 - If the opened file is produced by a newer version of Kicad, issue a
 big warning when the user attempts to save it, that certain features
 will be lost (points B and D - if somebody complains we can always tell
 him he was warned). AFAIK this is what most commercial software does.
 
 Cheers,
 Tom
 
 Except for Acrobat Reader, all the other software I use simply tells me it
 cannot load the new file. In a corporate environment and especially on
 large projects no one wants to take the risk that someone obliterated some
 data. Let's say Person A sends Person B a file with data missing - what
 can Person B possibly do with that now? Person B was never aware of the
 warning that Person A ignored and the software is not psychic so it cannot
 say hey, the last time you worked on this file it was Version X.Z, not X.Y.
 The problem gets worse and more difficult to detect as the project gets
 more complex. People need to understand the limitations of their tools and
 work with that.  As I said before people can negotiate what version they
 need and if necessary build/install to support a specific project. Otherwise
 why use file versions at all if we're essentially only using it to tell if 
 there
 are newer features and essentially ignore it and write corrupted data anyway?
 


I would be very happy with backward compatibility, especially if it would allow 
us to safe the file in the older format.
This way, not everybody in the team needs to have the same version to be able 
to work.

Of course, if someone saves it in the new format, then I would not expect an 
older kicad to be able to read it.
Wayne could even decide that every format-change implies a version number 
increment, so we can tell the user to install kicad newer than version x.y

I also think, this is not something that will happen every day, so we should 
not overdesign this. Forward compatibility for a EDA tool is not something I 
would advice, as there are just to many things that can go wrong.

If it makes things simples, an external file-format converter would also be 
fine.

Just my 2 cents,
Martijn


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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Mailing list: https://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] OS X Packaging Update

[Martijn Kuipers]

Hi Adam, and others,

I myself several years ago tried a OS X package and know the pain it gives. I 
think the Drag  Drop you have is fine.

If you want to do more interesting things, then I would like to suggest a 
program called Packages (http://s.sudre.free.fr/Software/Packages/about.html 
http://s.sudre.free.fr/Software/Packages/about.html).
It should even allow to add multiple bundles and have the user choose what to 
install.

Although I am not sure how to incorporate that into a cake-build, but I guess 
we have some of the most knowledgeable cmake-builders (people) on board.

Adam, please do not take this as a complaint. I think the work you have done 
for OS X users is excellent. I just happen to stumble upon this and think it 
might be of help, alleviating some of your pains ;-)

Anyway, to you and the entire KiCad list: A Merry Christmas and thanks for 
KiCad.

/Martijn


 On 23 Dec 2014, at 21:27, Adam Wolf adamw...@feelslikeburning.com wrote:
 
 Thanks!  Great eye!
 
 Adam Wolf
 Cofounder and Engineer,
 WL
 
 On Tue, Dec 23, 2014 at 3:21 PM, Nick Østergaard oe.n...@gmail.com 
 mailto:oe.n...@gmail.com wrote:
 2014-12-23 22:03 GMT+01:00 Adam Wolf adamw...@feelslikeburning.com 
 mailto:adamw...@feelslikeburning.com:
  I think Lorenzo made that image.  I am not sure if it is the logo we want to
  go with, but I found the SVG inside of bitmaps_png/source or something and
  dragged it into Inkscape.
 
 Aha! I did not notive that. But the reason the logo you have looks odd
 is becuase you don't have the original font, which is Tiresias
 LPfont. I can be found on http://www.tiresias.org/fonts/lpfont.zip 
 http://www.tiresias.org/fonts/lpfont.zip if
 it is of interest. Seems to be a GPL font, I did not really read the
 copying note. Also note that curl and wget fails on that URL,
 downloading with a browser works fine.
 
  I definitely think we need to change the arrowheads, both in size and not
  being pure black--they are very harsh.  I also think that we might want to
  investigate what a nice subtle texture background looks like too.
 
  http://subtlepatterns.com/ http://subtlepatterns.com/
 
  I will take a stab at a better set of backgrounds in soon, and also I will
  make my script use an svg from the source, I think, so that anyone with
  commit access can update the svg and it'll show up in the next day's
  package.
 
  Adam Wolf
  Cofounder and Engineer
  WL
 
  On Tue, Dec 23, 2014 at 2:25 PM, Nick Østergaard oe.n...@gmail.com 
  mailto:oe.n...@gmail.com wrote:
 
  2014-12-23 21:08 GMT+01:00 Adam Wolf adamw...@feelslikeburning.com 
  mailto:adamw...@feelslikeburning.com:
   I do not think I ever got connected with Miguel enough to get a working
   login to the server.  If you have access, I can give you an ssh public
   key
   that you can add to a user.
 
  I don't have login access to the machine itself, just the Jenkins
  interface.
 
   Also, sneak peek.  (I am not a graphics guy, but I whipped this up as a
   barebones example.)
 
  Looks great to me, although I think those arrowheads are massive
  comared to the arrow line part. And the KiCad logo looks odd to me,
  compared to:
 
  http://www.kicad-pcb.org/download/attachments/589828/kicad_logo.png?version=1modificationDate=1334481453000api=v2
   
  http://www.kicad-pcb.org/download/attachments/589828/kicad_logo.png?version=1modificationDate=1334481453000api=v2
 
  But I am not really sure where the original vectorized version is, I
  think it was Lorenzo that made it, is that right?
 
   Adam Wolf
   Cofounder and Engineer
   WL
  
   On Tue, Dec 23, 2014 at 1:37 PM, Nick Østergaard oe.n...@gmail.com 
   mailto:oe.n...@gmail.com
   wrote:
  
   2014-12-23 19:14 GMT+01:00 Adam Wolf adamw...@feelslikeburning.com 
   mailto:adamw...@feelslikeburning.com:
Hi Nick,
   
I have a jenkins system here--I can upload my build artifacts to the
Kicad
Jenkins though. I would prefer not to make my system be a direct
build
slave
for security reasons.
  
   Ok, this is fair enough.
  
   But did Miguel ever get around to give you the access to get the
   automated uploads working?
  
I was out sick all last week with a 102F fever, but this weekend I
updated
my script to build a good Kicad footprints dmg.  I think the last
thing
left
before the next status update is setting KIGITHUB.  I tested it and
it
works
well, but I need to do it automatically.
  
   Ok, get well soon. Good to hear you are still progressing.
  
Adam Wolf
Cofounder and Engineer
WL
   
On Tue, Dec 23, 2014 at 12:01 PM, Nick Østergaard oe.n...@gmail.com 
mailto:oe.n...@gmail.com
wrote:
   
Hello Adam
   
I see that your builds is not added to the Jenkins running on
ci.kicad-pcb.org http://ci.kicad-pcb.org/. I want to see that 
happen, and Miguel gave me
rights
on Jenkins some time ago.
   
So if you are ready to set this up, it should be straight forward to
add a 

Re: [Kicad-developers] Incremental build speeds.

[Martijn Kuipers]

Tim,
On 22 Oct 2014, at 17:45, Tim Hutt tdh...@gmail.com wrote:

 Oh yeah I forgot to mention I have an SSD, and -j4 did not make a huge 
 difference (can't remember exact time).
 
 I like the DLL solution though! I'm planning to (maybe) do a bit of work on 
 the 3d viewer as it is not much code and quite self-contained. Seems to be a 
 static library at the moment so I will maybe have a go at changing it to a 
 dynamic one.
 
 I might also try porting to QBS (Qt's new build system) which is much faster 
 than make in my experience.

You can try, but my guess is that you should not expect a warm welcome for 
patches doing so. CMake may be slower, but it has shown to be able to deal with 
a whole lot of weird things on all platforms. The main devs and Dick (I am not) 
have spent so much time on this, that I doubt they´ll be very receptive. Also, 
kicad used Wx, why use a QT build-system?

I am not trying to start a flamefest, but perhaps it convinces you to spend 
that time on other KiCad improvements.

Kind regards,
Martijn

 
 Cheers,
 
 Tim
 
 On 22 October 2014 14:40, Tomasz Wlostowski tomasz.wlostow...@cern.ch wrote:
 On 22.10.2014 15:01, Tim Hutt wrote:
 Hi,
 
 
 However, if I perform a null-rebuild (i.e. I don't change anything and
 just run `make` again), it takes about 70 seconds to run.
 
 Hi Tim,
 
 I found it very annoying while developing the PS, where I needed to very 
 frequently rebuild and re-link a small part of pcbnew. My solution was to:
 - exclude the PS sources from CMakeLists.txt
 - build the PS using a standard makefile (using same compiler options as 
 CMake)
 - link it as a DLL with _pcbnew.kiface
 
 By doing this, I only had to rebuild the PS DLL (taking few seconds) instead 
 of waiting ~2 minutes for the CMake to solve dependencies and GCC linker to 
 produce new .kiface image.
 
 It's just a dumb and ugly hack, but may help in some cases.
 
 Cheers,
 Tom
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Config file relocation (new patch)

[Martijn Kuipers]

On 03 Sep 2014, at 22:05, Moses McKnight mo...@texband.net wrote:

 Hi Wayne,
 
 I'm not sure now if that is where they should go.  I looked a little through 
 past emails here and apparently things such as libraries, modules, etc are in 
 subdirectories in ~/Library/Application Support/kicad

Just a minor detail, shouldn’t that be ?
~/Library/Application Support/KiCad

OSX uses the name of the application, which is KiCad (with the capitals).

/Martijn

 
 Another thing I noticed is that the function I found to make it easy to put 
 the config files there was not in wx2.8, so I don't know if we want to use 
 it.  The function is wxStandardPaths::UseAppInfo( 
 wxStandardPaths::AppInfo_None );  and that allows me to use 
 wxStandardPaths::GetUserDataDir() without wx putting the program name at the 
 end of that path.
 
 See the message I just sent to the list with an updated patch.
 
 I'll see what I can do with the Cmake files.  I don't know cmake and don't do 
 much shell scripting, so I'm not sure how to add the .config/kicad directory 
 in there right now.
 
 Thanks,
 Moses
 
 On 09/03/2014 03:44 PM, Wayne Stambaugh wrote:
 Hey Moses,
 
 If the OSX config files should go in ~/Library/Application Support/kicad
 would you please update the patch accordingly.  Also, could you create a
 patch to send to the library developers to update the fp-lib-table
 install script so it gets installed to ~/.config/kicad?
 
 As soon as the OSX testing is confirmed and the install script patch is
 ready, I will commit the changes.
 
 Thanks,
 
 Wayne
 
 On 9/3/2014 1:17 PM, Moses McKnight wrote:
 Hi Wayne,
 
 One person on IRC is compiling with the patch to test on OSX.  Currently
 the files on OSX should go in ~/Library/Preferences/kicad, but from what
 he said and also from these links, it looks like that might should be
 changed to ~/Library/Application Support/kicad.  I did figure out an
 easy way to make the change if it is decided that is better.
 
 http://stackoverflow.com/questions/15677388/default-location-for-configuration-files-macos
 
 https://developer.apple.com/library/mac/documentation/General/Conceptual/MOSXAppProgrammingGuide/AppRuntime/AppRuntime.html
 
 
 The install__fp-lib-table cmake stuff is in the kicad library
 repository, looks like under the template directory.
 
 Moses
 
 On 09/03/2014 09:02 AM, Wayne Stambaugh wrote:
 snip
 Can someone please test this on OSX to make sure it doesn't cause any
 issues before we commit it.  Also, kicad-install.sh calls `make
 install_github_fp-lib-table` to install the global fp-lib-table.  I
 cannot find the definition of install_github_fp-lib-table in any of the
 kicad CMake files.  Where ever this is defined, it will need to be
 changed to copy the global fp-lib-table to ~/.config/kicad.
 
 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


___
Mailing list: https://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] Config file relocation (new patch)

[Martijn Kuipers]

On 03 Sep 2014, at 22:18, Moses McKnight mo...@texband.net wrote:

 According to Marco Serantoni here:
 https://lists.launchpad.net/kicad-developers/msg13245.html
 
 it is lowercase kicad.

I see. I remember there was a decision to call the program KiCad, but if Marco 
wants to use kicad it is fine with me.
Sorry for the noise.

 
 I don't even have a Mac available to look at, so I'm just going by what I'm 
 told or can find!
Thanks for doing that :-)

/Martijn


 
 Moses
 
 
 On 09/03/2014 04:10 PM, Martijn Kuipers wrote:
 
 On 03 Sep 2014, at 22:05, Moses McKnight mo...@texband.net wrote:
 
 Hi Wayne,
 
 I'm not sure now if that is where they should go.  I looked a little 
 through past emails here and apparently things such as libraries, modules, 
 etc are in subdirectories in ~/Library/Application Support/kicad
 
 Just a minor detail, shouldn’t that be ?
 ~/Library/Application Support/KiCad
 
 OSX uses the name of the application, which is KiCad (with the capitals).
 
 /Martijn
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp


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

[Martijn Kuipers]

On 01 Sep 2014, at 19:54, jp charras jp.char...@wanadoo.fr wrote:

 Le 01/09/2014 11:44, Brian Sidebotham a écrit :
 On 1 September 2014 10:17, Javier Serrano
 javier.serrano.par...@gmail.com wrote:
 On Sat, Aug 30, 2014 at 8:47 PM, Wayne Stambaugh stambau...@verizon.net 
 wrote:
 [snip]
 I am proposing that we move to a model more like the
 Linux kernel where there is a merge window for new features followed by
 a stabilization period.
 [snip]
 
 This looks like a very good plan to me. You can count on our help.
 
 3) Documentation
 [snip]
 There has been a suggestion of moving our documentation to a text base
 layout format to make it more version control and translation friendly.
 I'm all for that.
 
 How is the current documentation effort being handled? Is there a
 separate mailing list for it? I don't recall seeing much documentation
 discussion here. What do the main people involved think about changing
 to a markup text-based format?
 
 Cheers,
 
 Javier
 
 Oh, that quickly reminds me - I had started looking at this here:
 https://github.com/BrianSidebotham/KiCAD-Docs-mmd
 
 I think the problem we need to get around if Markdown is chosen as the
 markup because of it's simplicity that formatting the size of images
 is not really present, and this is why it's hard to get a formatted
 PDF document out correctly. However, we all have browsers these days,
 perhaps the documentation in html rather than PDF makes more sense
 anyway.
 
 For HTML of course, we can use CSS to style the output - there's no
 CSS in the above html output.
 
 Best Regards,
 
 Brian.
 
 After a lot of try (using Markdown, LibreOffice .fodt files and trying
 to use some other formats), I agree with Brian:
 
 Using html format for *current Kicad documentation* is the best way:
 * Current doc is very easy to convert to html format (LibreOffice, at
 least the latest version 4.3.1, works fine when switching to html file
 format) from the current .odt format ( we have more than 1000 pages of
 currently actively maintained doc, therefore this is a very important
 thing).
 * No need to still generate the .pdf files, html files are enough.
 * Using html files instead of .odf files, and do not use anymore pdf
 files fixes our major issue: binary files are not easily handled by
 launchpad versioning system).
 * Kicad doc file can be converted to html files with very few changes in
 code (FYI, in early times of Kicad, the html format was used)

I find it much easier to move pdf-files around then html-files. Why not use a 
solution such as latex, or perhaps less academic, sphinx ?
The cakePHP book is done with sphinx, which is basically restructured text (so 
you can keep it in a CVS), but can output a myriad of formats, such as html, 
pdf (via latex), ePub,

There is a tool to convert from odf, but I have not tried it.

For those interested, more info on sphinx can be found here: 
http://sphinx-doc.org/intro.html

Warm regards,
Martijn

 
 -- 
 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] Project proposal

[Martijn Kuipers]

On 01 Sep 2014, at 21:54, Brian Sidebotham brian.sidebot...@gmail.com wrote:

 On 1 September 2014 20:17, Martijn Kuipers martijn.kuip...@gmail.com wrote:
 
 On 01 Sep 2014, at 19:54, jp charras jp.char...@wanadoo.fr wrote:
 
 Le 01/09/2014 11:44, Brian Sidebotham a écrit :
 
 On 1 September 2014 10:17, Javier Serrano
 javier.serrano.par...@gmail.com wrote:
 
 On Sat, Aug 30, 2014 at 8:47 PM, Wayne Stambaugh stambau...@verizon.net
 wrote:
 [snip]
 
 I am proposing that we move to a model more like the
 Linux kernel where there is a merge window for new features followed by
 a stabilization period.
 
 [snip]
 
 This looks like a very good plan to me. You can count on our help.
 
 3) Documentation
 
 [snip]
 
 There has been a suggestion of moving our documentation to a text base
 layout format to make it more version control and translation friendly.
 I'm all for that.
 
 
 How is the current documentation effort being handled? Is there a
 separate mailing list for it? I don't recall seeing much documentation
 discussion here. What do the main people involved think about changing
 to a markup text-based format?
 
 Cheers,
 
 Javier
 
 
 Oh, that quickly reminds me - I had started looking at this here:
 https://github.com/BrianSidebotham/KiCAD-Docs-mmd
 
 I think the problem we need to get around if Markdown is chosen as the
 markup because of it's simplicity that formatting the size of images
 is not really present, and this is why it's hard to get a formatted
 PDF document out correctly. However, we all have browsers these days,
 perhaps the documentation in html rather than PDF makes more sense
 anyway.
 
 For HTML of course, we can use CSS to style the output - there's no
 CSS in the above html output.
 
 Best Regards,
 
 Brian.
 
 
 After a lot of try (using Markdown, LibreOffice .fodt files and trying
 to use some other formats), I agree with Brian:
 
 Using html format for *current Kicad documentation* is the best way:
 * Current doc is very easy to convert to html format (LibreOffice, at
 least the latest version 4.3.1, works fine when switching to html file
 format) from the current .odt format ( we have more than 1000 pages of
 currently actively maintained doc, therefore this is a very important
 thing).
 * No need to still generate the .pdf files, html files are enough.
 * Using html files instead of .odf files, and do not use anymore pdf
 files fixes our major issue: binary files are not easily handled by
 launchpad versioning system).
 * Kicad doc file can be converted to html files with very few changes in
 code (FYI, in early times of Kicad, the html format was used)
 
 
 I find it much easier to move pdf-files around then html-files. Why not use
 a solution such as latex, or perhaps less academic, sphinx ?
 The cakePHP book is done with sphinx, which is basically restructured text
 (so you can keep it in a CVS), but can output a myriad of formats, such as
 html, pdf (via latex), ePub,
 
 There is a tool to convert from odf, but I have not tried it.
 
 For those interested, more info on sphinx can be found here:
 http://sphinx-doc.org/intro.html
 
 Warm regards,
 Martijn
 
 I'm unsure why the files need moving around?

It’s easy to have a pdf and put it in my folder with documentation. Even today, 
I do not always have internet access and it is not so easy to organise docs on 
a localhost (in my opinion).


 Almost the entire weight of this decision should be in the hands of
 the people who write the documentation. Latex I'm sure is definitely
 out - it's hard to see the content for the formatting, so it's not
 easy to work with. We want to create a situation where documentation
 writers can use text diffs to update their language's documentation.
 
 So something like restructured text may work well because it has some
 image formatting capabilities.

I concur. If it was some kind of (re)structured text, then it would be easy to 
send patches and might get more people involved.

 
 Plain HTML can actually do the job too, although most people use a
 language that compiles to html to make the formatting even cleaner.

Exactly, the example I gave (sphinx) does exactly that and allows to create the 
handy pdf as well.
 
 Markdown has books written in it too.

So does Latex, still we can some kind of agree that it is not very friendly to 
the eyes. In my field there is no real alternative, that handles equations as 
well as latex does,.

 
 Best Regards,
 
 Brian.

Warm regards,
Martijn


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

Re: [Kicad-developers] 3D-Viewer new rendering and contributions.

[Martijn Kuipers]

VIva Mário,

They look awesome. Thanks!

One thing I just noticed immediately, and perhaps it was already so in the 
previous 3d viewer, is that the silkscreen extends beyond the board.
In your “Gruvin  Co v1.2” board, the silkscreen of the RP-SMA and slide-switch 
extends beyond the board material.

Um abraço,
Martijn


On 29 Jul 2014, at 07:46, Mário Luzeiro mrluze...@ua.pt wrote:

 But where are the attached files?
 
 And now the screenshots.
 
 Mario 
 LuzeirokiCAD_3dViewer_newRender_Freakduino.jpgkiCAD_3dViewer_newRender_kicaduino.jpg___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://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] KIPRJMOD appears to be broken.

[Martijn Kuipers]

Happy birthday!

I hope you get some raspberry pie :-)

/Martijn

On 15 Apr 2014, at 15:23, Dick Hollenbeck d...@softplc.com wrote:

 
 
 
 Sorry for the inconvenience.
 
 Dick
 
 
 I want to say thanks to everyone for their patience on the Kiway work.  I 
 know its been
 somewhat disruptive.  To be candid, its a miracle that 20,000 lines of 
 changes did not
 break more than it did.  Again, I appreciate those that are willing to be 
 testers, and
 encourage anyone else to use the pre-kiway tagged version if they want 
 stability.
 
 Today is my 58th birthday, and it has become very clear to me recently that I 
 am really
 tired of looking at poorly written KiCad source code.  I am not long for this 
 project.
 
 To get through milestones B) and C) will mean even more changes.  So if you 
 are a
 developer and think you understand how something used to work, maybe even 
 because you
 wrote it for the old architecture, and it does not meet the needs of the new 
 architecture,
 then I doubly thank you for your patience as it morphs into something that 
 meets the needs
 of the new architecture, morphing possibly more than once along the way.
 
 The difficult part for me typically is understanding what the intentions were 
 of the old
 code, because the code does not clearly indicate intentions in the way it 
 should.  To be
 honest, I find a lot of it repulsive.  (Some of that is my age, and the 
 natural tendency
 of folks to get more intolerant as they age.)
 
 This is a tenuous situation, so I ask for your understanding, and patience, 
 and give
 thanks in advance for such as we approach milestones B) and C).
 
 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp


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

[Martijn Kuipers]

Hi,


On Mar 3, 2014, at 2:35 PM, Fabrizio Tappero fabrizio.tapp...@gmail.com wrote:

 Hello,
 This might be  message that pops out 20 or 30 times on a fresh ubuntu install:
 
 LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that doesn't believe 
 we're it's parent
 
 
 I think the English is not really correct.

You are right. It's should be its, but that does not resolve the warning. You 
can find some info here, which indicates it is a Ubuntu-thing.

http://trac.wxwidgets.org/ticket/14292

Hope that helps,
Martijn




 
 Regards
 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

Re: [Kicad-developers] CvPCB - Error

[Martijn Kuipers]

Well from Portugal behind a decent ASDL connection I get the following:

wget https://codeload.github.com/KiCad/Capacitors_Tantalum_SMD.pretty/zip/master
--2014-03-03 17:57:07--  
https://codeload.github.com/KiCad/Capacitors_Tantalum_SMD.pretty/zip/master
Resolving codeload.github.com... 192.30.252.147
Connecting to codeload.github.com|192.30.252.147|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10035 (9.8K) [application/zip]
Saving to: ‘master’

100%[==] 10,035  --.-K/s   in 0.006s  

2014-03-03 17:57:08 (1.71 MB/s) - ‘master’ saved [10035/10035]

Thanks,
Martijn



On Mar 3, 2014, at 5:39 PM, Dick Hollenbeck d...@softplc.com wrote:

 I should mention that this timing test was with this line in my /etc/hosts 
 file:
 
 
  192.30.252.147  codeload.github.com
 
 
 That cuts out a net based DNS transaction.
 
 
 
 
 On 03.03.2014 10:52, Dick Hollenbeck wrote:
 $ wget 
 https://codeload.github.com/KiCad/Capacitors_Tantalum_SMD.pretty/zip/master
 --2014-03-03 10:49:54--
 https://codeload.github.com/KiCad/Capacitors_Tantalum_SMD.pretty/zip/master
 Resolving codeload.github.com (codeload.github.com)... 192.30.252.147
 Connecting to codeload.github.com 
 (codeload.github.com)|192.30.252.147|:443... connected.
 HTTP request sent, awaiting response... 200 OK
 Length: 10035 (9,8K) [application/zip]
 Saving to: `master.1'
 
 100%[===]
 10.035  --.-K/s   in 0.05s
 
 2014-03-03 10:49:54 (178 KB/s) - `master.1' saved [10035/10035]
 
 ===
 
 This is without the redirect.  Its possible github.com has caught on to what 
 we are doing
 and is actually trying to help.  Everytime we hit the site they have a 
 record of our
 visit, since we advertise the web client in the GET header.
 
 Maybe I'm just being optimistic, but 0.05 seconds to fetch a zip file is 
 pretty
 exceptional.  Its possible they've made special provisions for us (read 
 caching).
 
 
 
 
 Dick
 
 
 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp


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

[Martijn Kuipers]

On Mar 3, 2014, at 9:36 PM, Dick Hollenbeck d...@softplc.com wrote:

 On 03.03.2014 11:58, Martijn Kuipers wrote:
 Well from Portugal behind a decent ASDL connection I get the following:
 
 wget 
 https://codeload.github.com/KiCad/Capacitors_Tantalum_SMD.pretty/zip/master
 --2014-03-03 17:57:07--  
 https://codeload.github.com/KiCad/Capacitors_Tantalum_SMD.pretty/zip/master
 Resolving codeload.github.com... 192.30.252.147
 Connecting to codeload.github.com|192.30.252.147|:443... connected.
 HTTP request sent, awaiting response... 200 OK
 Length: 10035 (9.8K) [application/zip]
 Saving to: ‘master’
 
 100%[==] 10,035  --.-K/s   in 
 0.006s  
 
 2014-03-03 17:57:08 (1.71 MB/s) - ‘master’ saved [10035/10035]
 
 Thanks,
 Martijn
 
 
 Wow, I would move to Portugal, but then I'd have to learn Brazilian.
 
 
RIght, I am fond of minority languages such as Dutch, Portuguese and British so 
that was a plus for me ;-)


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

[Martijn Kuipers]

On Nov 29, 2013, at 9:29 AM, Maciej Sumiński maciej.sumin...@cern.ch wrote:

 On 11/28/2013 01:10 PM, Martijn Kuipers wrote:
 
 On Nov 28, 2013, at 12:07 PM, Lorenzo Marcantonio 
 l.marcanto...@logossrl.com wrote:
 
 On Thu, Nov 28, 2013 at 10:56:42AM +0100, Maciej Sumiński wrote:
 
 I am particularly interested in the main developers' view about points:
 - Cut/copy/paste
 
 Never felt a need for copy/paste on a board... YMMV of course (perhaps
 for modular I/O stages or such?)
 
 I can see it be fun to be able to Cut  Paste from one board to another.
 For instance, copy the switching power supply part as a whole.
 
 Just my 2 cents.
 
 /Martijn
 
 Both could be good use cases, but now when I think about it, this is not as 
 easy as it seemed to be in the beginning.
 As far as I know currently there is no back annotation (you cannot update 
 schematics basing on a PCB file), so modules that were copied may introduce 
 some disorder. They need nets to be connected to (this could be cloned, but I 
 am not sure if that is the right way, especially in case of pasting parts 
 from another board), value and reference (value could be copied too and 
 reference could be just the next free number). The things may get more 
 complicated when you reload .net/.cmp file - I think those parts can just 
 disappear, as they are not in the list.

I agree. Following the example of the power supply, it indeed would be nice if 
we could, instead off copying the module, create a part that is the module and 
insert that into the schematics and board.

 I need to reconsider the feature again, maybe there are some good solutions 
 to that.

I also see this as a feature and not a requirement. 

Thanks for thinking of these features!

/Martijn

 
 Regards,
 Orson


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

Re: [Kicad-developers] Next steps

[Martijn Kuipers]

On Nov 28, 2013, at 12:07 PM, Lorenzo Marcantonio l.marcanto...@logossrl.com 
wrote:

 On Thu, Nov 28, 2013 at 10:56:42AM +0100, Maciej Sumiński wrote:
 
 I am particularly interested in the main developers' view about points:
 - Cut/copy/paste
 
 Never felt a need for copy/paste on a board... YMMV of course (perhaps
 for modular I/O stages or such?)

I can see it be fun to be able to Cut  Paste from one board to another.
For instance, copy the switching power supply part as a whole.

Just my 2 cents.

/Martijn


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


___
Mailing list: https://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] A tribute to KiCad quality

[Martijn Kuipers]

Dear devs,

I am in no way affiliated to this site, but it shows that KiCad is used to 
change the way things work.

This site is an excellent example of the quality of KiCad and I sincerely hope 
they reach the funding to build their system:
http://mobilecg.hu/

Keep up the great work (both the KiCad team as well as the Mobile ECG team),
Martijn


___
Mailing list: https://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] A tribute to KiCad quality

[Martijn Kuipers]

Perhaps a wall-of-fame on kicad-pcb.org would be a nice idea.

These kind of product show that more people than just the debs believe in the 
quality of your work.

/Martijn

On Nov 18, 2013, at 10:20 AM, Maciej Sumiński maciej.sumin...@cern.ch wrote:

 I like this one even more:
 http://www.kickstarter.com/projects/mossmann/hackrf-an-open-source-sdr-platform
 
 And I bet that people contributing to KiCad have some more good examples.
 
 Regards,
 Orson
 
 On 11/18/2013 10:48 AM, Martijn Kuipers wrote:
 Dear devs,
 
 I am in no way affiliated to this site, but it shows that KiCad is used to 
 change the way things work.
 
 This site is an excellent example of the quality of KiCad and I sincerely 
 hope they reach the funding to build their system:
 http://mobilecg.hu/
 
 Keep up the great work (both the KiCad team as well as the Mobile ECG team),
 Martijn
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
 
 


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

Re: [Kicad-developers] Kicad distribution method for users - some updates

[Martijn Kuipers]

Adam,

I am using your PPA and I find it very valuable.It's a great way to get a 
recent version.
I think the PPA solves the problem for most Ubuntu/Debian users and seems to be 
widely accepted. I don't see the need for inclusion in Ubuntu repos, but the 
choice is yours.

Anyway, many thanks for the PPA.


/Martijn

On Oct 18, 2013, at 3:05 PM, Dick Hollenbeck d...@softplc.com wrote:

 On 10/18/2013 08:41 AM, Adam Wolf wrote:
 Dick,
 
 Do you see any value in me trying to get a decent package put into the 
 Ubuntu and Debian
 release or should I abandon that project?
 
 Adam Wolf
 WL
 
 
 I do see value in it.  Only you can say if that value makes it worth your 
 time.  Folks
 encountering KiCad for the first time often will install from the repo.  Only 
 later will
 they yearn for the new goodies, which can be obtained only by building from 
 recent source.
 
 A daily PPA like system is therefore more valuable, since it has potential to 
 address the
 needs of both the new user as well as the seasoned one.
 
 
 
 
 
 
 
 
 
 On Oct 18, 2013 8:33 AM, Dick Hollenbeck d...@softplc.com 
 mailto:d...@softplc.com wrote:
 
On 10/18/2013 03:11 AM, Fabrizio Tappero wrote:
 Hello,
 I updated the script according to Dick's suggestion and added some
 modifications in it for yum people so that we are now a bigger
 family. I also uploaded it to the web:
 http://www.kicad-pcb.org/display/KICAD/Download
 
 just a question, Dick, why don't we like sudo apt-get build-dep
 kicad? you removed it. Shouldn't be better to have it there? just in
 case in the future we add some libs, some apt-get guy detect it but we
 do not update this script accordingly.
 
build-dep relies on the person maintaining the package for the distro.  
 His/her choices
and ours are different.  For one thing, we've decided that he/she is way 
 too slow.  For
another, we've decided to build and *patch* boost ourselves.  Getting our 
 dependencies
from his choices made a year ago do not make sense to me.  No one knows 
 more about how to
compile KiCad on Ubuntu than the core developers.  For example, the 
 boost-dev distro
package is not a prerequisite to build KiCad using CMake, but that would 
 erroneously come
in using build-dep.
 
 
I have employees and contractors using this script now, it will have to 
 work for me at all
times, this makes me a watchdog and a maintainer of the script.
 
 
 
 Dick, thanks for the make package thing. I think it is great !
 
The *.deb is not great.  CMake is great.  The *.deb that is built does 
 not proclaim any
prerequisites at run-time nor at build-time.  So that *.deb is only 
 suitable for the
machine on which it was built.  Or a distro exactly at that same version, 
 which also has
all the run-time dependencies installed.  Neither our script, nor the 
 *.deb says anything
about the run-time dependencies.  Run-time dependencies are a subset of 
 build-time
dependencies.
 
For a person familiar with what checkinstall does, using a *.deb 
 generated this way will
give a person a record in the local package management system as to the 
 files that were
installed.  It is not much more than that.
 
Note that
 
   $ sudo make uninstall
 
seems to work fairly well also, as well as
 
   $ sudo dpkg -r kicad
 
would work after installing the lean *.deb file.
 
 
 
 I
 have done some googleing and noticed that for instance slackware Linux
 does maintain a recent version (03/2013) of KiCad:
 http://slackbuilds.org/result/?search=kicadsv=14.0
 
 
I have generic-ized the script to support different notions of the 
 install_prerequisites
step.  In theory more distros could be added for those folks wanting to 
 build from source.
 
 
 
 
 Debian people do it too but it is 1.5 years old. I contacted the
 maintainer but mail bounced back.
 
 There is also and unofficial Debian/Ubuntu apt-get repo that looks
 very official and that we could use:
 http://www.apt-get.org/
 
 The question is kind of philosophical, who should maintain packages
 and distribute open-source software? the developers of the software or
 the guys doing Linux distros?
 
 Well guys, I think lots of progress on this subject has been made
 since two weeks ago, I think cmake is the way to make .deb. I think
 the script on the web is great for the people who want to compile. We
 just need an additional step adding Adam's server in the equation?
 
 Adam, I'll have a look at Karl's stuff and contribute to the cmake but
 first I'd like to fix all this .desktop files and especially this
 icons issue. It seems to me that there is a little bit of a mess
 there.
 
 Regards
 Fabrizio
 
 
 
 
 
 
 
 
 
 On Thu, Oct 17, 2013 at 9:13 PM, Adam Wolf
 adamw...@feelslikeburning.com mailto:adamw...@feelslikeburning.com 
 wrote:
 There have been some discussion in Debian land about changing how they
 package Python-y stuff, that will make a world of difference for me.  It
 

Re: [Kicad-developers] Python scripting documentation

[Martijn Kuipers]

On Sep 21, 2013, at 9:39 AM, Miguel Angel miguelan...@ajo.es wrote:

 Thoughts on this:
 
 * The pythonland libraries need a serious refactor, at this moment all 
 functions and 
 classes are brought together by swig into pcbnew.py: helper functions 
 (LoadBoard, SaveBoard...) 
 unit conversion macros, scripting plugin definitions...
 
 From the documentation perspective, it's a mess...
 
 I think of refactoring into submodules:
 
 pcbnew   (with all the pcbnew objects)
 pcbnew.units (with the unit helpers) 

 http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/view/head:/pcbnew/scripting/units.i
 pcbnew.helpers

 http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/view/head:/pcbnew/scripting/module.i#L58

 http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/view/head:/pcbnew/scripting/pcbnew_scripting_helpers.cpp#L59
   (backport this to python.)
 
 pcbnew.plugins (pcb footprint wizard plugins, etc..)
 
 
* There are many swig artifacts that get documented: _object, 
 SwigPyIterator. We must find a way to get rid of the
 classes that get accidentally documented.

Knowing very little about python, but this should work (it does for C): 
EXCLUDE_SYMBOLS
More info here: http://www.doxygen.nl/config.html#cfg_exclude_symbols

/Martijn


 

  
 
 Miguel Angel Ajo Pelayo
 http://www.nbee.es
 +34 636 52 25 69
 skype: ajoajoajo
 
 
 2013/9/20 Miguel Angel miguelan...@ajo.es
 Yet it's not as perfect as it can be, but it's a good start point,
 
 http://dev.kicad-pcb.org/doxygen-python/annotated.html
 
 http://dev.kicad-pcb.org/kicad-pcbnew-python-refman.pdf
 
 
 
 http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/revision/4327
 
 To build the documentation, you only need doxygen, python, and swig,
 
 mkdir build-doc
 cd build-doc
 cmake ../kicad.bzr  -DKICAD_SCRIPTING=ON
 cd pcbnew
 make doxygen-python
 
 
 I must learn about how to create a mainpage from python into doxygen...
 
 Miguel Angel Ajo Pelayo
 http://www.nbee.es
 +34 636 52 25 69
 skype: ajoajoajo
 
 
 2013/9/8 Miguel Angel miguelan...@ajo.es
 I'm also thinking about giving a try to sphinx, which is the software used to 
 build the python documentation at the python site.
 
 I will drop a link here later if it looks good.
 
 Miguel Angel Ajo Pelayo
 http://www.nbee.es
 +34 636 52 25 69
 skype: ajoajoajo
 
 
 2013/9/8 Miguel Angel miguelan...@ajo.es
 I forgot about the most important part of my previous message, the link :)
 
 http://dev.kicad-pcb.org/doxygen-python-test/classpcbnew_1_1BOARD.html
 
 
 
 Miguel Angel Ajo Pelayo
 http://www.nbee.es
 +34 636 52 25 69
 skype: ajoajoajo
 
 
 2013/9/8 Miguel Angel miguelan...@ajo.es
 
 It's a first try, only BOARD class extended descriptions are
 imported from the C++ doxygen.
 
 It's not perfect, but can be automated and much better than nothing.
 
 We do:
 
  C++ -doxygen- XML  - python_script- .i
 
 then 
 
  *.i's -swig- pcbnew.py
 
 and finally
 
 pcbnew.py - doxygen - html
 
 
 The link came out from a test on command line, now I must spend some more 
 days to get this workflow into cmake 
 
 
 Miguel Angel Ajo Pelayo
 http://www.nbee.es
 +34 636 52 25 69
 skype: ajoajoajo
 
 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://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] Push and shove router

[Martijn Kuipers]

Awesome work!

On Sep 18, 2013, at 8:50 PM, Tomasz Wlostowski tomasz.wlostow...@cern.ch 
wrote:

 On 09/18/2013 09:48 PM, Miguel Angel wrote:
 I can only say *awesome*.
 
 Thanks :)
 
 I supposed that you were kidding with the VB /
 Comic Sans... but you left me suffering for a moment...
 
 Just one question, what's the license for GAL/geometry/tool framework?.
 GPL V2. Only the router (pcbnew/router/*) is V3.

Kicad has the following license (copyright.txt)
 Also note that the only valid version of the GPL as far as KiCad
 is concerned is _this_ particular version of the license (ie v2, not
 v2.2 or v3.x or whatever), unless explicitly otherwise stated.
Unfortunately GPLv3+ code is not compatible with GPLv2 code (not to mix with 
GPLv2+, which it is compatible with).
At least that is my understanding from: 
https://www.gnu.org/licenses/quick-guide-gplv3.html
(Interesting text is just below the diagram).

Now, I am no license freak, but as this popped up, I thought I'd mention it.

Please let this not distract you from your KiCad work :-)

/Martijn

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

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

Re: [Kicad-developers] Push and shove router

[Martijn Kuipers]

No worries.
I'm happy it was just a misunderstanding.

Can't wait to test it for my next board, which is soon.

/Martijn
On Sep 18, 2013, at 9:36 PM, Tomasz Wlostowski tomasz.wlostow...@cern.ch 
wrote:

 On 09/18/2013 10:14 PM, Javier Serrano wrote:
 On Wed, Sep 18, 2013 at 10:00 PM, Martijn Kuipers
 martijn.kuip...@gmail.com mailto:martijn.kuip...@gmail.com wrote:
 
Awesome work!
 
On Sep 18, 2013, at 8:50 PM, Tomasz Wlostowski
tomasz.wlostow...@cern.ch mailto:tomasz.wlostow...@cern.ch wrote:
 
On 09/18/2013 09:48 PM, Miguel Angel wrote:
 
Just one question, what's the license for GAL/geometry/tool
framework?.
GPL V2. Only the router (pcbnew/router/*) is V3.
 
 
 No Tom, it's GPLv2+ as the rest of KiCad. And the router is GPLv3+, not V3.
 Oops, my fault.
 
 Missing + in C++ code usually drops a parse error, pity it doesn't work for 
 license versions :)
 
 Cheers,
 Tom


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

Re: [Kicad-developers] Oscad an EDA tool

[Martijn Kuipers]

Thanks.
This will certainly clear a lot of confusion.

Regards,
Martijn
On Jul 2, 2013, at 1:26 PM, Oscad Team oscad.t...@gmail.com wrote:

 
 Hi
 
 Could you have a look at our homepage oscad.in ? We have added links to KiCad 
 and elaborated on the features.
 Let us know your feedback.
 
 Regards
 Oscad Team
 
 
 On Tue, Jul 2, 2013 at 1:53 AM, Martijn Kuipers martijn.kuip...@gmail.com 
 wrote:
 Hi,
 
 On Jul 1, 2013, at 7:25 PM, Oscad Team oscad.t...@gmail.com wrote:
 
 Hello Dick, Martijn, Edwin
 
 We have not modified/bug-fixed/enhanced the KiCad source code. We have only 
 used the binary version (installable through Ubuntu package manager for 
 Ubuntu and the .exe file for Windows available on the KiCad webpg). We are 
 using KiCad as the schematic editor and layout editor tool in Oscad. We 
 mention that in our documents as well. In fact, in our tutorial series, we 
 have made 4 tutorials on KiCad. We refer to them in our Oscad tutorial for 
 the users to know more about schematic creation and PCB design. We have 3 
 tutorials on Oscad. All these tutorials are available on our webpage 
 oscad.in .
  We only call eeschema, pcbnew and cvpcb using a script and launch them. All 
 our scripts are available on the webpage. Requesting you to kindly check the 
 same.
 
 Kindly let us know of any issues/concerns/feedback.
 
 Thanks for the clarification. Like I said in my email, it was not clear to me 
 and I couldn't find it on your website. Please forgive me for not looking at 
 all the tutorials. I did not even find a weblink to the KiCad site.
 
 Perhaps you could better explain this on your site ? Anyway, if you ever hunt 
 down some bugs, please send them back to KiCad-dev list.
 
 Sincerely yours,
 Martijn
 
 
 Thanks and regards
 Rakhi
 Oscad Team
 
 
 On Mon, Jul 1, 2013 at 8:31 PM, Dick Hollenbeck d...@softplc.com wrote:
 On 07/01/2013 07:31 AM, Edwin van den Oetelaar wrote:
  On Mon, Jul 1, 2013 at 10:00 AM, Martijn Kuipers martijn.kuip...@gmail.com
  mailto:martijn.kuip...@gmail.com wrote:
 
  Just wondering if you (the OSCAD team) made any changes to KiCAD. I 
  went to your site,
  but was unable to find any source code to do a comparison.
 
  So, my question is: did you do any enhancement/bug-fixing/changed to 
  KiCAD code ?
 
  Were any of our main debs aware of OSCAD launching? It seemed to me 
  to come out of
  the blue...
 
  Kind regards,
  Martijn
 
 
  I have never heard of this.
  Furthermore, no source code, not even a link to the KiCAD sources on the 
  website.
  Looks like somebody made a closed binary installer/distribution and forgot 
  who is doing
  most of the work.
  I think this is a bad development, not the way to help the project or the 
  users of KiCAD.
  Greetings,
  Edwin van den Oetelaar
 
 
 Thanks Edwin, let's all keep an eye on this relative to the GPLv2 licensing 
 requirements.
 
 if( distribute_code )
 {
 
 // read the damn license, do what it says
 }
 
 Their stated intentions seem to comply, while their actions are not in 
 obvious compliance.
 Help monitoring this is appreciated.
 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
 
 

___
Mailing list: https://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] Oscad an EDA tool

[Martijn Kuipers]

Just wondering if you (the OSCAD team) made any changes to KiCAD. I went to 
your site, but was unable to find any source code to do a comparison.

So, my question is: did you do any enhancement/bug-fixing/changed to KiCAD code 
? 

Were any of our main debs aware of OSCAD launching? It seemed to me to come 
out of the blue...

Kind regards,
Martijn

On Jul 1, 2013, at 7:16 AM, Oscad Team oscad.t...@gmail.com wrote:

 Hi 
 
 This is Oscad team! form IIT Mumbai, India, introducing a new EDA tool Oscad
 
 Oscad: An open source EDA tool for circuit design, simulation, analysis and 
 PCB design
 
 Using open source software software, such as KiCad, Ngspice and Scilab, we 
 have built an integrated open source EDA tool, Oscad. One may draw a circuit 
 using KiCad, create a netlist and simulate using Ngspice.  One may also do 
 PCB design and generate Gerber files.  One may add models and subcircuits.  
 One may also generate differential equations of analog circuits and solve 
 them through Scilab.  Oscad runs on Linux and a few flavours of Windows (XP 
 and 7, at present).
 
 We have written a book that explains the use of Oscad.  The book, Oscad 
 source code and Spoken Tutorials that explain the use of Oscad are all 
 available for free download from http://oscad.in.
 
 TahnkYou
 Oscad team
 IIT Mumbai, India
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://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] Oscad an EDA tool

[Martijn Kuipers]

Hi,

On Jul 1, 2013, at 7:25 PM, Oscad Team oscad.t...@gmail.com wrote:

 Hello Dick, Martijn, Edwin
 
 We have not modified/bug-fixed/enhanced the KiCad source code. We have only 
 used the binary version (installable through Ubuntu package manager for 
 Ubuntu and the .exe file for Windows available on the KiCad webpg). We are 
 using KiCad as the schematic editor and layout editor tool in Oscad. We 
 mention that in our documents as well. In fact, in our tutorial series, we 
 have made 4 tutorials on KiCad. We refer to them in our Oscad tutorial for 
 the users to know more about schematic creation and PCB design. We have 3 
 tutorials on Oscad. All these tutorials are available on our webpage oscad.in 
 .
  We only call eeschema, pcbnew and cvpcb using a script and launch them. All 
 our scripts are available on the webpage. Requesting you to kindly check the 
 same.
 
 Kindly let us know of any issues/concerns/feedback.
Thanks for the clarification. Like I said in my email, it was not clear to me 
and I couldn't find it on your website. Please forgive me for not looking at 
all the tutorials. I did not even find a weblink to the KiCad site.

Perhaps you could better explain this on your site ? Anyway, if you ever hunt 
down some bugs, please send them back to KiCad-dev list.

Sincerely yours,
Martijn

 
 Thanks and regards
 Rakhi
 Oscad Team
 
 
 On Mon, Jul 1, 2013 at 8:31 PM, Dick Hollenbeck d...@softplc.com wrote:
 On 07/01/2013 07:31 AM, Edwin van den Oetelaar wrote:
  On Mon, Jul 1, 2013 at 10:00 AM, Martijn Kuipers martijn.kuip...@gmail.com
  mailto:martijn.kuip...@gmail.com wrote:
 
  Just wondering if you (the OSCAD team) made any changes to KiCAD. I 
  went to your site,
  but was unable to find any source code to do a comparison.
 
  So, my question is: did you do any enhancement/bug-fixing/changed to 
  KiCAD code ?
 
  Were any of our main debs aware of OSCAD launching? It seemed to me 
  to come out of
  the blue...
 
  Kind regards,
  Martijn
 
 
  I have never heard of this.
  Furthermore, no source code, not even a link to the KiCAD sources on the 
  website.
  Looks like somebody made a closed binary installer/distribution and forgot 
  who is doing
  most of the work.
  I think this is a bad development, not the way to help the project or the 
  users of KiCAD.
  Greetings,
  Edwin van den Oetelaar
 
 
 Thanks Edwin, let's all keep an eye on this relative to the GPLv2 licensing 
 requirements.
 
 if( distribute_code )
 {
 
 // read the damn license, do what it says
 }
 
 Their stated intentions seem to comply, while their actions are not in 
 obvious compliance.
 Help monitoring this is appreciated.
 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://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] About MCAD integration

[Martijn Kuipers]

On the verge of asking a stupid question: 

Why isn't VRML sufficient? Most packages support it and there is even a free 
library (Coin3d is now GPL).

/Martijn

On May 6, 2013, at 9:16 AM, Miguel Angel Ajo miguelan...@nbee.es wrote:

 Well, the full models can be done later,
 
 What I find more important is the full PCB detail (holes, countour, etc..) 
 which it's really used
 for MCAD integration :-)
 
 If you do it for IGES (which I think it's a good Idea), please consider to do 
 it like a plugin (3D exporter)
 because, this way somebody could come later and do something yet fancier that 
 we thought
 about .. :)
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On Monday, 6 de May de 2013 at 10:13, Lorenzo Marcantonio wrote:
 
 On Mon, May 06, 2013 at 10:06:18AM +0200, Miguel Angel Ajo wrote:
 anyway I find more useful a full model output (with all shapes) than 
 bounding boxes :)
 
 Then you *really* have a lot of memory and processor time to handle you
 designs :D (alternatively you don't need complex designs). Boundary models
 are also used for airflow calculation models, BTW. Really there is
 usually (if not ever) no advantage in having a pin-by-pin model of a QFP
 or something (except eye candy, maybe)
 
 IGES is not 'easy' (it's a little easier maybe, in respect to STEP) but
 at least is a) stable (STEP is not actually finished yet) and b) fully
 and freely documented. The fact that c) is AFAIK still required for some
 goverment work should ensure that it won't go away in a short time...
 
 --
 Lorenzo Marcantonio
 Logos Srl
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help : https://help.launchpad.net/ListHelp
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://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] I am not dyslexic but need help

[Martijn Kuipers]

You're welcome. I hope it solved it for you.

Thanks for your work on KiCad as it is getting easier and easier to work with 
and to teach to beginners.

/Martijn

On Apr 11, 2013, at 6:54 PM, Dick Hollenbeck d...@softplc.com wrote:

 Thank you Martin.
 
 Sorry to involve the list with this, but it did concern the list in as
 much as my postings will now be more intelligible, thanks to Martin.
 
 Dick
 


___
Mailing list: https://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 OSX build, with scripting, codename wife

[Martijn Kuipers]

Hi Miguel,

Downloading as we speak. On the github page you call it a universal OSX binary, 
but that would mean it supports both PowerPC and Intel based MACS, whereas is 
this email announcement you call it i386 +x64 build.

I'm looking forward in compiling it myself, just to see if your solution is 
portable. 

Thanks also to your wife ;-)

/Martijn


On Mar 10, 2013, at 2:19 AM, Miguel Angel Ajo Pelayo miguelan...@nbee.es 
wrote:

 
 
 Hi, 
 
 I've been working on the release of Kicad with scripting for MacOSX, also 
 tried to package it all together with 
 all kicad libs, and the templates.
 
 It's supposed to be a i386 + x64 binary build, with scripting support.
 
 kicad-scripting-osx-latest.zip
 
 
 It has all the new kicad templates system and libraries inside kicad.app, and 
 it's supposed to be accessible from all the other apps.
 
 I'm not sure if it will only work in 10.8, or may be 10.5-10.8, (it has a 
 dependency to system's python2.7).
 
 If there is any adventurous out there, please try, and tell me how does it 
 work (or doesn't).
 
 
 PS:
 
The codename for the release is wife, as my wife has been taking care 
 all saturday of our little Margarita, so she's a time donor to kicad now 
 too ;)
 
 My build  packaging script is temporarily here, for just in case anyone 
 wants to compile himself.. 
 https://github.com/mangelajo/KicadOSXBuilder
 
 Cheers!! ;)
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://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 OSX build, with scripting, codename wife

[Martijn Kuipers]

On Mar 11, 2013, at 12:35 AM, Miguel Angel Ajo Pelayo miguelan...@nbee.es 
wrote:

 Awesome!!, thanks for testing Martijn, :-)
 
 I think I used cmake from homebrew: 
 
 MacBook-Air-de-Miguel:src ajo$ which cmake
 /Users/ajo/.rvm/bin/cmake
 MacBook-Air-de-Miguel:src ajo$ ls -la `which cmake`
 lrwxr-xr-x  1 ajo  staff  47  2 mar 00:24 /Users/ajo/.rvm/bin/cmake - 
 ../../.homebrew/Cellar/cmake/2.8.10.2/bin/cmake

At my machine using cmake from home-brew threw an error (sorry, did not catch 
it).

 
  So we should document how to install brew, and cmake + wget + bzr + swig
 
- XCode (from app store) and Command Line Tools for Xcode from 
(http://connect.apple.com)
- Homebrew (http://mxcl.github.com/homebrew/)
- wget, bzr and swig via homebrew: brew install wget bzr swig
- cmake (http://www.cmake.org/cmake/resources/software.html)

Easy as 1-2-3 ...

 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 11/03/2013, at 01:29, Martijn Kuipers martijn.kuip...@gmail.com wrote:
 
 Congratulations Miguel!
 
 I just completed a build on a pristine Macbook Air.
 
 Some (minor) comments:
 You need wget, bzr and swig. I installed all of these with homebrew 
 without any problems. And you need cmake (not from homebrew, but cmake has 
 native OSX version).
 
 Other prerequisites:
 XCode and Xcode command line tools (obviously), which you can get from Apple.
 
 Then be patient and just watch the screens scroll by, but the result is 
 really nice :-)
 The entire directory needs about 2.5GB, The zipped Kicad is almost 100 MB, 
 which is around 350MB unpacked.
 
 Um abraço,
 Martijn
 
 
 On Mar 10, 2013, at 6:56 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es 
 wrote:
 
 I was always hoping to see the libraries (DLLs) to go into 
 /Library/Kicad, so we can keep the memory footprint down of the separate 
 Kicad components. But it is not a trivial task, so it seems.
 I am not following what you want to do. Is it like:
 /Applications/kicad/kicad.app - the app with the libs
 /Applications/kicad/libraries - footprints, components, etc.
 /Applications/kicad/scripts - python user scripts
 /Applications/kicad/doc - documentation and demos
 ?
 
 
 Look to the patches/loader.sh on github, at this moment, all the libraries 
 *.dylib and files go inside kicad.app/Frameworks/ and the other apps use 
 them from there (../../../kicad.app/Frameworks) , wx and python-site 
 mainly. 
 
 Also there are the demos+modules+etc in kicad.app/Resources/ or something 
 like that  that's what I was planning to pull out of kicad.app again and 
 yet leave it findable for all the apps.
 
 
 
 https://github.com/mangelajo/KicadOSXBuilder/commit/c41f116620182d56c07aee75cd751fe1ba922f7f
 This is the change, I also re-uploaded 
 kicad-scripting-osx-3992.zip
 
 :-)
 I think it's better like this, people can go into the data directory and 
 change/fetch whatever they like :)
 
 
 
 
 Kind regards,
 Martijn
 
 
 
 
 
 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 10/03/2013, at 11:18, Martijn Kuipers martijn.kuip...@gmail.com 
 wrote:
 
 Hi Miguel,
 
 Downloading as we speak. On the github page you call it a universal OSX 
 binary, but that would mean it supports both PowerPC and Intel based 
 MACS, whereas is this email announcement you call it i386 +x64 build.
 
 I'm looking forward in compiling it myself, just to see if your 
 solution is portable. 
 
 Thanks also to your wife ;-)
 
 /Martijn
 
 
 On Mar 10, 2013, at 2:19 AM, Miguel Angel Ajo Pelayo 
 miguelan...@nbee.es wrote:
 
 
 
 Hi, 
 
 I've been working on the release of Kicad with scripting for MacOSX, 
 also tried to package it all together with 
 all kicad libs, and the templates.
 
 It's supposed to be a i386 + x64 binary build, with scripting support.
 
 kicad-scripting-osx-latest.zip
 
 
 It has all the new kicad templates system and libraries inside 
 kicad.app, and it's supposed to be accessible from all the other apps.
 
 I'm not sure if it will only work in 10.8, or may be 10.5-10.8, (it 
 has a dependency to system's python2.7).
 
 If there is any adventurous out there, please try, and tell me how 
 does it work (or doesn't).
 
 
 PS:
 
The codename for the release is wife, as my wife has been taking 
 care all saturday of our little Margarita, so she's a time donor to 
 kicad now too ;)
 
 My build  packaging script is temporarily here, for just in case 
 anyone wants to compile himself.. 
 https://github.com/mangelajo/KicadOSXBuilder
 
 Cheers!! ;)
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Mac OSX build, with scripting, codename wife

[Martijn Kuipers]

I just build a pure x64 binary for OSX. 
Packed: 82MB
Unpacked: 300MB

Honoustly, I expected the difference with a 386/x64 build to be bigger
Packed: 82 vs 100MB
Unpacked: 300 vs 350MB

/Martijn

On Mar 11, 2013, at 12:35 AM, Miguel Angel Ajo Pelayo miguelan...@nbee.es 
wrote:

 Awesome!!, thanks for testing Martijn, :-)
 
 I think I used cmake from homebrew: 
 
 MacBook-Air-de-Miguel:src ajo$ which cmake
 /Users/ajo/.rvm/bin/cmake
 MacBook-Air-de-Miguel:src ajo$ ls -la `which cmake`
 lrwxr-xr-x  1 ajo  staff  47  2 mar 00:24 /Users/ajo/.rvm/bin/cmake - 
 ../../.homebrew/Cellar/cmake/2.8.10.2/bin/cmake
 
  So we should document how to install brew, and cmake + wget + bzr + swig
 
 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 11/03/2013, at 01:29, Martijn Kuipers martijn.kuip...@gmail.com wrote:
 
 Congratulations Miguel!
 
 I just completed a build on a pristine Macbook Air.
 
 Some (minor) comments:
 You need wget, bzr and swig. I installed all of these with homebrew 
 without any problems. And you need cmake (not from homebrew, but cmake has 
 native OSX version).
 
 Other prerequisites:
 XCode and Xcode command line tools (obviously), which you can get from Apple.
 
 Then be patient and just watch the screens scroll by, but the result is 
 really nice :-)
 The entire directory needs about 2.5GB, The zipped Kicad is almost 100 MB, 
 which is around 350MB unpacked.
 
 Um abraço,
 Martijn
 
 
 On Mar 10, 2013, at 6:56 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es 
 wrote:
 
 I was always hoping to see the libraries (DLLs) to go into 
 /Library/Kicad, so we can keep the memory footprint down of the separate 
 Kicad components. But it is not a trivial task, so it seems.
 I am not following what you want to do. Is it like:
 /Applications/kicad/kicad.app - the app with the libs
 /Applications/kicad/libraries - footprints, components, etc.
 /Applications/kicad/scripts - python user scripts
 /Applications/kicad/doc - documentation and demos
 ?
 
 
 Look to the patches/loader.sh on github, at this moment, all the libraries 
 *.dylib and files go inside kicad.app/Frameworks/ and the other apps use 
 them from there (../../../kicad.app/Frameworks) , wx and python-site 
 mainly. 
 
 Also there are the demos+modules+etc in kicad.app/Resources/ or something 
 like that  that's what I was planning to pull out of kicad.app again and 
 yet leave it findable for all the apps.
 
 
 
 https://github.com/mangelajo/KicadOSXBuilder/commit/c41f116620182d56c07aee75cd751fe1ba922f7f
 This is the change, I also re-uploaded 
 kicad-scripting-osx-3992.zip
 
 :-)
 I think it's better like this, people can go into the data directory and 
 change/fetch whatever they like :)
 
 
 
 
 Kind regards,
 Martijn
 
 
 
 
 
 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 10/03/2013, at 11:18, Martijn Kuipers martijn.kuip...@gmail.com 
 wrote:
 
 Hi Miguel,
 
 Downloading as we speak. On the github page you call it a universal OSX 
 binary, but that would mean it supports both PowerPC and Intel based 
 MACS, whereas is this email announcement you call it i386 +x64 build.
 
 I'm looking forward in compiling it myself, just to see if your 
 solution is portable. 
 
 Thanks also to your wife ;-)
 
 /Martijn
 
 
 On Mar 10, 2013, at 2:19 AM, Miguel Angel Ajo Pelayo 
 miguelan...@nbee.es wrote:
 
 
 
 Hi, 
 
 I've been working on the release of Kicad with scripting for MacOSX, 
 also tried to package it all together with 
 all kicad libs, and the templates.
 
 It's supposed to be a i386 + x64 binary build, with scripting support.
 
 kicad-scripting-osx-latest.zip
 
 
 It has all the new kicad templates system and libraries inside 
 kicad.app, and it's supposed to be accessible from all the other apps.
 
 I'm not sure if it will only work in 10.8, or may be 10.5-10.8, (it 
 has a dependency to system's python2.7).
 
 If there is any adventurous out there, please try, and tell me how 
 does it work (or doesn't).
 
 
 PS:
 
The codename for the release is wife, as my wife has been taking 
 care all saturday of our little Margarita, so she's a time donor to 
 kicad now too ;)
 
 My build  packaging script is temporarily here, for just in case 
 anyone wants to compile himself.. 
 https://github.com/mangelajo/KicadOSXBuilder
 
 Cheers!! ;)
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
 
 
 
 
 
 
 

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

Re: [Kicad-developers] Parallel build errors on Windows using mingw32-make

[Martijn Kuipers (Private)]

Hi,

I had a similar problem some years ago with CMake.
The solutions then was to add add_dependencies to the targets. From cmake.org
quote
 add_dependencies: Add a dependency between top-level targets.

  add_dependencies(target-name depend-target1
   depend-target2 ...)

Make a top-level target depend on other top-level targets. A top-level target 
is one created by ADD_EXECUTABLE, ADD_LIBRARY, or ADD_CUSTOM_TARGET. Adding 
dependencies with this command can be used to make sure one target is built 
before another target. See the DEPENDS option of ADD_CUSTOM_TARGET and 
ADD_CUSTOM_COMMAND for adding file-level dependencies in custom rules. See the 
OBJECT_DEPENDS option in SET_SOURCE_FILES_PROPERTIES to add file-level 
dependencies to object files. 
/quote

I don't have a kicad build environment ready. If nobody gets to it first I can 
see if I can make some time. (It would be on Linux though, as my MBP is too 
slow).

/Martijn

On Jan 24, 2013, at 8:32 AM, Brian Sidebotham brian.sidebot...@gmail.com 
wrote:

 Thanks for your feedback Dick. I'll try and have a look into it to see what's 
 going on.
 
 Best Regards, Brian.
 
 
 On 23 January 2013 19:54, Dick Hollenbeck d...@softplc.com wrote:
 On 01/23/2013 12:43 PM, Brian Sidebotham wrote:
  I used to think these problems were solely down to mingw32-make, however 
  from the other
  cmake problem, perhaps some of them are not.
 
  I've not seen this problem before, this is the first time I've come across 
  it, but it is
  repeatable.
 
 
 It is repeatable until you change something.  This is a race condition I 
 think, so don't
 be fooled into thinking it is a new bug, or that if it goes away it has been 
 necessarily
 fixed.
 
 So in other words, it is repeatable only for the moment.
 
 And while it is you may want to try and nail it.
 
 
 If you want instead to sweep it under the rug, and simply hope it does not 
 reappear, you
 could run with
 
 -j3
 
 
 That might get you by, until somebody has time to look at it in greater 
 detail.
 
 Some things I would suggest:
 
 compare the output of cmake (i.e. makefiles) on between linux and windows.
 
 especially wrt to this make target.
 
 Base on those results:
 
 Try a newer mingw32-make.  Try a newer cmake.
 
 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

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

[Martijn Kuipers]

Hi Léo,

Thank you for your interest in KiCad. I agree, it is already very
powerful.

I think your email already gave you a hint of what could be done
quote
 I know KiCad leader is french but I've don't
 see any french kicad book… 
/quote

Now I am not suggesting you to start and write a book, but perhaps you
could write a Tutorial (in French if you like). If you get a lot of
feedback from the readers, then  it might be worth to start thinking of
writing a book.

At the moment internationalization of the website/tutorials is not the
highest priority, because it would take time away improving the
existing documentation. But, it's open source, and nobody will stop you
from writing a French tutorial. It might be that you don't receive so
much feedback, since not everybody might be able to easily read in
French (I haven't spoken much French in the last 20 years or so).

Thanks,
Martijn


On Mon, 17 Dec 2012 21:01:44 +0100
OpenSourceWay opensource...@laposte.net wrote:

  
 
 Hi, 
 
 I'm not so good at C++, I've never write code in C++, only C.
 But I think I can do what I need, but, I think big features is very
 important, but kicad is already powerfuul, I think its just need a
 good comunication, public image. I think a beautiful and simple
 website is important, I know KiCad leader is french but I've don't
 see any french kicad book… 
 
 I think I can be more gainful other than writting line
 of code… 
 
 Léo 
 
 Le 2012-12-17 19:48, Miguel Angel Ajo Pelayo a écrit :
 
 
  Hi Léo, 
  
  We recently moved to a Confluence instance for the
 main site at http://www.kicad-pcb.org [4]. It works quite well, 
  may
 be what it needs now it's more content. I think main developers are
 happy with bzr and launchpad as it works. (I prefer 
  other solutions
 also, but bzr works reasonably well, and right now it lets developers
 put all their effort in the KiCad software 
  itself.) 
  
  How good
 are you at C++ ? , may be you could try contributing to the software
 itself. Find a feature you'd like to see on KiCad, 
  ask as you need,
 start a branch, follow the guidelines, and then ask for merge on
 testing branch. 
  
  We're also plenty of ideas and a couple of bugs in the bug
 tracker. 
  
  I started with a little one, and I liked it, code quality
 in KiCad is getting better and better on every commit. 
  
  Greetings,
 
  Mike. 
  
  Miguel Angel Ajo 
  http://www.nbee.es [5] 
 
 +34911407752 
  skype: ajoajoajo 
  
  On 17/12/2012, at 18:45,
 OpenSourceWay opensource...@laposte.net wrote: 
  
  Hello ! 
  
 
 I'm new here, and I'll introduce myself. I'm french, and I've created
 a lot of free projects like OpenSourceSoft -
 http://opensourcesoft.fr.nf [1] - and other, mainly listed in my
 personal website. 
  
  As 2013
 will be a new year, I'll try to stop creating open source project
 alone but I want to participate in usefull big projects, like Kicad.
 I'm also an electronics student and I want to create some fun PCB
 over my Linux Laptop but Cadence PSD isn't free and doesn't work. 
  
  So, I'll try
 you to create this really big project, wich is already powerfull. I
 don't know if you need that but I think the website can be
 reorganised, without using a lot of external tools as launchpad,
 libs, chat… CodingTeam is a good soft wich include wiki, source
 repository, xmpp server, bug tracking tool, localisation tool, forum… 
  
  Thanks for
 all, and sorry for my bad english. 
  
  Léo 
  
  -- 
 
 OpenSourceWay
  opensource...@laposte.net
  opensourceway.fr.nf
 
 ___
  Mailing list:
 https://launchpad.net/~kicad-developers [2]
  Post to :
 kicad-developers@lists.launchpad.net
  Unsubscribe :
 https://launchpad.net/~kicad-developers [2]
  More help :
 https://help.launchpad.net/ListHelp [3]
 


___
Mailing list: https://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] PLUGIN::Footprint*() from python

[Martijn Kuipers (Private)]

Hi list,

I have never designed more than double sided PCBs with KiCad, so I have never 
run into this. What happens to the layers of a footprint if I place a component 
on the bottom-side ? Are all the layers reversed, i.e., fronts means back and 
vice versa? 

/Martijn


On Nov 14, 2012, at 1:57 PM, Dick Hollenbeck d...@softplc.com wrote:

 On 11/14/2012 12:10 AM, Chris Giorgi wrote:
 
 
 On Tue, Nov 13, 2012 at 7:57 PM, Dick Hollenbeck d...@softplc.com
 mailto:d...@softplc.com wrote:
 
On 11/13/2012 05:33 PM, Chris Giorgi wrote:
 Good afternoon,
 
 I've been glancing at this thread onoff for a while and have and have an 
 observation
 and suggestion.
 
 A board has a distinct set of lamination layers:
Front
Inner 1
   :
Inner n
Back
 
 Each lamination may have one or more physical materials or operations:
Substrate, Copper, Adhesive, Solder Paste, Solder Mask, Silk Screen, 
 Drill, Place
 Parts, Probe, etc...
 
A real board does, yes.  But in the software each of the above is a 
 layer, so the
paradigm you are proposing does not match, nor does it help in the 
 reduction of dope
associated with pads, measured in total text length.
 
In this thread, mostly we are trimming pad descriptions down with this, 
 since we do not
have padstack support.This *.kicad_pcb and *.kicad_mod effort now is 
 merely a file
format conversion, to improved readability.  There is no change being 
 made at this
time to
internal BOARD data structures as a result of this current work.
 
 
 Dick,
  I was suggesting only a consistent naming scheme for the (logical) layers 
 based on the
 physical layering and materials. Internal representations would not need to 
 change at
 all, and the resultant names are similar, if not identical to those 
 suggested by Wayne
 in most cases. For conciseness and clarity, I would suggest types labeled 
 Cu, Adh,
 Paste, Silk, Mask, Draw, Cmnt, and Edge. Symbolic layer 
 positions include
 F or Front for the first defined (0), B or Back for the last defined 
 (N), I or
 Inner followed by a number for 1 - (N-1), and G or Global for items 
 not residing
 on a specific physical layer.
 
 Front - 0.Cu= F.Cu= Front.Cu 
 Inner1- 1.Cu= I1.Cu   = Inner1.Cu
 Inner{n}  - {n}.Cu  = I{n}.Cu = Inner{n}.Cu
 Inner14  - 14.Cu  = I14.Cu = Inner14.Cu
 Back - 15.Cu  = B.Cu   = Back.Cu
 Adhes_Back - B.Adh
 Adhes_Front - F.Adh
 SoldP_Back - B.Paste
 SoldP_Front - F.Paste
 SilkS_Back  - B.Silk
 SilkS_Front  - F.Silk
 Mask_Back  - B.Mask
 Mask_Front  - F.Mask
 Drawings - G.Draw
 Comments - G.Cmnt
 Eco1 - G.Eco1
 Eco2 - G.Eco2
 PCB_Edges G.Edge
 
 Parsing would be very straightforward and the format I proposed would allow 
 for very
 concise representations of more complex pad structures, such as a thermal 
 via connected
 to the front, back, and 2nd and 4th inner copper ground layers in an 8 layer 
 board --
 eg. 0+I2+Inner4+Back.Cu .
 
 Parsing (wild stab):
  - Split at . as L, T ( L=0+I2+Inner4+Back, T=Cu)
  - Handle wildcards in L, T. (* - Array containing all defined values, 
 skip tokenizer)
  - Tokenize L by replacing symbolic names with numeric identifiers ( 
 L'=0+2+4+7 )
 (First letter and number is unique)
  - If we have ranges, replace with included values (i.e. 0-2+4 - 
 0+1+2+4).
  - Dump into an array L'' = [0,1,2,4]
  - Treat T similarly (T' = Cu) (i.e. Eco1-3 - Eco1+Eco2+Eco3, 
 Mask1+2+Paste -
 Mask1+Mask2+Paste).
  - Lookup indices for T and dump into an array T'' = [5]
  - Iterate L'' and T'', marking each layer as a bit in a field, or however 
 it's
 represented internally.
 (pseudocode: for (l in L'') { for (t in T'') { layers.setbit(layer[l][t]]) } 
 )
 
 In my opinion, the results would be concise, while remaining readable and 
 possibly
 allowing for forward compatibility. Looking back at the above, I wonder if 
 it might make
 more sense to reverse the order -- {Type}({Idx.})(.{LayerPosition}) -- 
 giving us Cu.F,
 Adh.B, Silk.Front, Cu.3, Eco1, Cu.In2, and Draw, which I find 
 slightly more
 readable.
 
 
 I finished my implementation last night.
 
 Really, the main win was simply *.Cu in through hole pads.
 
 The rest is just noise mostly, and what is not in the noise category is in 
 the arm waving
 category.
 
 Submit a patch if you want it considered.  I am back onto the layer manager 
 now.
 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp


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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Martijn Kuipers]

On Wed, 14 Nov 2012 08:25:04 -0600
Dick Hollenbeck d...@softplc.com wrote:

 
  1) Footprints inside a BOARD.
 
  2) Footprints inside a library.
 
  3) Footprints exported.
 
 
 
 
  1)- they can be on F.Cu or B.Cu layers either.
 
 
  2)- Should always be represented in a normalized form.  a) no
  rotation, b) (at 0 0), c)
 
 oops,
 always on F.Cu for 2)
 
 
 
  3)- Only the source code knows for sure, but it would be nice to
  have this one equal 2) so you could simply copy the file into an
  s-expression (i.e. KICAD PLUGIN) library path.
 
 
 
 

Dick, thanks for the clarification and your efforts on KiCad.

/Martijn

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

Re: [Kicad-developers] Python binding of enums

[Martijn Kuipers]

Hi All involved in scripting :-)

I am a scripting-sceptic, but must say amazing progress is being made. Perhaps 
I will become a script-kiddy at my age :-)

Thanks! 
/Martijn
On Aug 10, 2012, at 7:15 AM, Lorenzo Marcantonio wrote:

 On Fri, Aug 10, 2012 at 07:33:24AM +0200, Miguel Angel Ajo Pelayo wrote:
 I keep reading and thinking.
 
 And one idea comes to my mind:
 
 Why don't we do those checks on the python side, but, with one
 restriction (to cut out the maintenance drawback): have the MAX_VALUE
 / MIN_VALUE for every enum in C++, example:
 
 I see no problem with that, many of them already behave this way...
 Often there is the -1 as unspecified/invalid marker. Other enums
 starts at 0 (since it's the default behaviour for enums and there is no
 reason to choose otherwise).
 
 For example: UNDEFINED_LAYER = -1, LAYER_COUNT = 32
 for color we have UNSPECIFIED = -1 and LAST_COLOR (last time I looked
 was 24...)
 
 Bitmasked enum are not a problem (since these are inherently used at the
 bit level), other critical stuff will be handled in a case-by-case
 fashion (I didn't see much funky stuff in there)
 
 This would be plan 3b (facade but only for strange stuff XD)
 
 -- 
 Lorenzo Marcantonio
 Logos Srl
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp


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

Re: [Kicad-developers] Python binding of enums

[Martijn Kuipers]

Lorenzo,

I got it ;-)




On Aug 10, 2012, at 10:37 AM, Lorenzo Marcantonio wrote:

 On Fri, Aug 10, 2012 at 10:50:02AM +0200, Miguel Angel Ajo Pelayo wrote:
 In fact, Martjin is right, the scripting is progressing faster than I
 expected
 even if things can be refined later :-) (like the enums and unneeded
 exports)
 
 (I was joking if it wasn't clear!)
 
 Something to work on in the meantime is good to have, but I think we
 should decide these
 things ASAP
 
 -- 
 Lorenzo Marcantonio
 Logos Srl
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp


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

[Martijn Kuipers]

Good luck.

But from what we have seen from your work, they're lucky to have you.

/Martijn


On Apr 16, 2012, at 10:54 PM, Wayne Stambaugh wrote:

 I just want to let my fellow KiCad developers know that I will be
 starting a new job Wednesday.  I'm not sure how this will impact the
 amount of time that I can commit to KiCad but I'm guessing that
 initially I will have less time as I get settled into the daily routine.
 If you don't hear from me, please be patient.  It just means that I
 have other things on my plate.  Thanks for your understanding.
 
 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] Hello, I want to help with you project

[Martijn Kuipers]

Hello Edwin,

You had the first step right. Joining this mailing-list is the right place to 
start helping KiCad.
We have a few very core contributors (I am not one of them), who are improving 
KiCad in a rapid pace.

As a matter of fact, the improvements through the last year of KiCad have been 
amazing thanks to them.

Just for the interest, what would be your platform of choice you use KiCad on? 
Windows/Linux/Mac/Other?

Eeschema has undergone a major change in the format of its libraries, based on 
s-expressions, which I think is one of 
the best changes that happened, even though it does not directly improve the 
user-experience. So if you are thinking of 
things related to schema-import from other programs (Eagle v6 for example), you 
best look at the new format.

Other than that, I would suggest to work on some of the things you want to see 
improved: That gives you the best motivation.

Like other open source, you will need a sponsor for committing things. Let me 
advise you on some things to take care of:
- read and follow coding-style; 
- explain what you want to achieve and how to achieve it. The list is pretty 
responsive
- Make piece-wise patches, don't expect a large patch to be applied, as it is 
difficult to check.

KiCad is a very large code, so the core-devs are very keen on keeping the code 
maintainable.

Met vriendelijke groeten/Warm regards,
Martijn 



On Mar 27, 2012, at 10:56 AM, Edwin van den Oetelaar wrote:

 Hello everyone,
 My name is Edwin, I have some motivation and skill to help with your project.
 Although I am not very old yet, I do have some deep knowledge of
 PCB's, data-formats, workflow and related software.
 (I have been working in this field for more than 15 years)
 
 I can program in almost anything, and have some visions on how to make
 this project even better.
 
 Just throw me a bone (a few bugs to get my teeth into) so I can chew
 on it, and help you.
 I am a bit confused about how this is coordinated, I see so many
 websites (sourceforge/lauchpad/yahoo, some French stuff)
 Just point me in the right direction.
 
 Keep it going, and have a happy day,
 
 Edwin
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://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] Hello, I want to help with you project

[Martijn Kuipers]

On Mar 27, 2012, at 12:22 PM, Edwin van den Oetelaar wrote:

 First: Thanks for the warm welcome everyone.
 
 For now I just want to get to know the project by fixing some bugs
 that nobody got time for. (or some feature you think most important)
 
 As a vision I see more of the project rewritten in a
 python/WxPython/Cython (not SWIG, sorry folks)

Note: I don't know anything about Cython but a quick google.

I think not many devs on the list share your vision. There is some scripting 
work being done, 
but that  is scripting inside KiCad and not KiCad inside scripting.

I also think a major rewrite of KiCad to Python/C#/QT4/Whatever, is not 
something that will benefit the project (my opinion).

There are still many things that could be done in Python/wxPython/Cython, but I 
foresee those as small addon programs to 
KiCad and not the other way around. Things like importer/exporter/gcode 
creator/etc.


/Martijn

 This will make the whole system very flexible (while running) without
 need of re-compiles. Many things (including GUI and import/export) can
 benefit from a high-level approach with code-development in advanced
 editors/interactive shells (like Pycharm, DreamPie) The introspection
 (also of code written in Cython) will bring new levels of productivity
 and performance (and development speed) never seen before. (not in
 Eagle, not in any of the commercial software I worked with and (got)
 payed for)
 The reason that this will work with KiCAD and not with the other
 projects is that KiCAD is open and the rest of the world is not,
 everyone is 'protecting their investment' by keeping things closed and
 charging insane amounts of money for minor updates (which are released
 as new major versions, so get your wallet ready).
 In about 2 years KiCAD will have taken over in number of features,
 means of workflow-management and integration with other software.
 Some things that will make an impact : integration/import of
 mechanical drawings/footprints from others. Editing/routing with
 'inference engine' in a sketch-up way. (showing alternatives in
 real-time, smart align and snapping)
 
 What do you dream about?
 
 Have a good day,
 Edwin
 
 
 
 On Tue, Mar 27, 2012 at 12:21 PM, Fabrizio Tappero
 fabrizio.tapp...@gmail.com wrote:
 Welcome Edwin,
 
 great to hear that you want to help. You will have plenty of chances
 to do so. What is that interests you?
 
 cheers
 fabrizio
 
 
 On Tue, Mar 27, 2012 at 12:12 PM, Martijn Kuipers
 martijn.kuip...@gmail.com wrote:
 Hello Edwin,
 
 You had the first step right. Joining this mailing-list is the right place 
 to start helping KiCad.
 We have a few very core contributors (I am not one of them), who are 
 improving KiCad in a rapid pace.
 
 As a matter of fact, the improvements through the last year of KiCad have 
 been amazing thanks to them.
 
 Just for the interest, what would be your platform of choice you use KiCad 
 on? Windows/Linux/Mac/Other?
 
 Eeschema has undergone a major change in the format of its libraries, based 
 on s-expressions, which I think is one of
 the best changes that happened, even though it does not directly improve 
 the user-experience. So if you are thinking of
 things related to schema-import from other programs (Eagle v6 for example), 
 you best look at the new format.
 
 Other than that, I would suggest to work on some of the things you want to 
 see improved: That gives you the best motivation.
 
 Like other open source, you will need a sponsor for committing things. Let 
 me advise you on some things to take care of:
 - read and follow coding-style;
 - explain what you want to achieve and how to achieve it. The list is 
 pretty responsive
 - Make piece-wise patches, don't expect a large patch to be applied, as it 
 is difficult to check.
 
 KiCad is a very large code, so the core-devs are very keen on keeping the 
 code maintainable.
 
 Met vriendelijke groeten/Warm regards,
 Martijn
 
 
 
 On Mar 27, 2012, at 10:56 AM, Edwin van den Oetelaar wrote:
 
 Hello everyone,
 My name is Edwin, I have some motivation and skill to help with your 
 project.
 Although I am not very old yet, I do have some deep knowledge of
 PCB's, data-formats, workflow and related software.
 (I have been working in this field for more than 15 years)
 
 I can program in almost anything, and have some visions on how to make
 this project even better.
 
 Just throw me a bone (a few bugs to get my teeth into) so I can chew
 on it, and help you.
 I am a bit confused about how this is coordinated, I see so many
 websites (sourceforge/lauchpad/yahoo, some French stuff)
 Just point me in the right direction.
 
 Keep it going, and have a happy day,
 
 Edwin
 
 ___
 Mailing list: https://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] Hello, I want to help with you project

[Martijn Kuipers]

Edwin,

On Mar 27, 2012, at 12:43 PM, Edwin van den Oetelaar wrote:

 Sorry for top-posting but..
 
 I expressed a vision, which could be a direction. (like the moon 50
 years ago in 1962)

Sure, and I gave you my opinion. 

 The future will tell if it is something of value.

Off the record, I have been wrong before :-)

 I am just one person with limited time.
 Let me start on something small, you mention import/output/gcode..
 Just point me to something concrete and I will cooperate and try to be 
 helpful.

The best I can direct you is the link Brian gave you 
quote
For speed, here's a direct link to the bug tracker for KiCad hosted on
Launchpad: https://bugs.launchpad.net/kicad
/quote

When I checked it said: 558 open bugs, so there is plenty to do.

I wasn't trying to make you feel unwelcome, if I did I apologize. All help is 
welcome.

/Martijn

 
 Have a good day,
 Edwin
 
 On Tue, Mar 27, 2012 at 1:30 PM, Martijn Kuipers
 martijn.kuip...@gmail.com wrote:
 
 On Mar 27, 2012, at 12:22 PM, Edwin van den Oetelaar wrote:
 
 First: Thanks for the warm welcome everyone.
 
 For now I just want to get to know the project by fixing some bugs
 that nobody got time for. (or some feature you think most important)
 
 As a vision I see more of the project rewritten in a
 python/WxPython/Cython (not SWIG, sorry folks)
 
 Note: I don't know anything about Cython but a quick google.
 
 I think not many devs on the list share your vision. There is some scripting 
 work being done,
 but that  is scripting inside KiCad and not KiCad inside scripting.
 
 I also think a major rewrite of KiCad to Python/C#/QT4/Whatever, is not 
 something that will benefit the project (my opinion).
 
 There are still many things that could be done in Python/wxPython/Cython, 
 but I foresee those as small addon programs to
 KiCad and not the other way around. Things like importer/exporter/gcode 
 creator/etc.
 
 
 /Martijn
 
 This will make the whole system very flexible (while running) without
 need of re-compiles. Many things (including GUI and import/export) can
 benefit from a high-level approach with code-development in advanced
 editors/interactive shells (like Pycharm, DreamPie) The introspection
 (also of code written in Cython) will bring new levels of productivity
 and performance (and development speed) never seen before. (not in
 Eagle, not in any of the commercial software I worked with and (got)
 payed for)
 The reason that this will work with KiCAD and not with the other
 projects is that KiCAD is open and the rest of the world is not,
 everyone is 'protecting their investment' by keeping things closed and
 charging insane amounts of money for minor updates (which are released
 as new major versions, so get your wallet ready).
 In about 2 years KiCAD will have taken over in number of features,
 means of workflow-management and integration with other software.
 Some things that will make an impact : integration/import of
 mechanical drawings/footprints from others. Editing/routing with
 'inference engine' in a sketch-up way. (showing alternatives in
 real-time, smart align and snapping)
 
 What do you dream about?
 
 Have a good day,
 Edwin
 
 
 
 On Tue, Mar 27, 2012 at 12:21 PM, Fabrizio Tappero
 fabrizio.tapp...@gmail.com wrote:
 Welcome Edwin,
 
 great to hear that you want to help. You will have plenty of chances
 to do so. What is that interests you?
 
 cheers
 fabrizio
 
 
 On Tue, Mar 27, 2012 at 12:12 PM, Martijn Kuipers
 martijn.kuip...@gmail.com wrote:
 Hello Edwin,
 
 You had the first step right. Joining this mailing-list is the right 
 place to start helping KiCad.
 We have a few very core contributors (I am not one of them), who are 
 improving KiCad in a rapid pace.
 
 As a matter of fact, the improvements through the last year of KiCad have 
 been amazing thanks to them.
 
 Just for the interest, what would be your platform of choice you use 
 KiCad on? Windows/Linux/Mac/Other?
 
 Eeschema has undergone a major change in the format of its libraries, 
 based on s-expressions, which I think is one of
 the best changes that happened, even though it does not directly improve 
 the user-experience. So if you are thinking of
 things related to schema-import from other programs (Eagle v6 for 
 example), you best look at the new format.
 
 Other than that, I would suggest to work on some of the things you want 
 to see improved: That gives you the best motivation.
 
 Like other open source, you will need a sponsor for committing things. 
 Let me advise you on some things to take care of:
 - read and follow coding-style;
 - explain what you want to achieve and how to achieve it. The list is 
 pretty responsive
 - Make piece-wise patches, don't expect a large patch to be applied, as 
 it is difficult to check.
 
 KiCad is a very large code, so the core-devs are very keen on keeping the 
 code maintainable.
 
 Met vriendelijke groeten/Warm regards,
 Martijn
 
 
 
 On Mar 27, 2012, at 10:56 AM, Edwin van den Oetelaar

Re: [Kicad-developers] Library License

[Martijn Kuipers]

On Mar 22, 2012, at 3:30 PM, Dick Hollenbeck wrote:

 On 03/22/2012 06:38 AM, Opendous Support wrote:
 Footprints are not subject to copyright either.
 They are not creative: ... they are simple data
 gathered from JEDEC, IPC and manufacturer sources.
  Copyright is designed to protect the original expression of ideas,
 and not the ideas themselves.  For example, if you take a photograph
 of the insides of your computer you are automatically the Copyright
 owner of the photograph.  Your original expression is the overexposed
 and blurry image.  In the same way that JEDEC/IPC/manufacturers own
 the Copyrights on the datasheets/specifications they produce, you own
 the specification (schematic and layout files) you produce of your
 design.
 http://en.wikipedia.org/wiki/Copyright#Idea-expression_dichotomy_and_the_merger_doctrine
 
  Everything but the actual circuit connection ideas can be
 Copyrighted since copy[right] covers only the expression of the
 definition, not the circuit itself.  In other words, someone can redo
 your work and create something nearly identical and they will be the
 Copyright owners of that work.
 http://features.linuxtoday.com/news_story.php3?ltsn=1999-06-22-005-05-NW-LF
 http://www.armisteadtechnologies.com/copy-pcb.shtml
 http://freedomdefined.org/OSHW
 
 I can be wrong, but, anything that's been designed
 by an author, has authorship, and it makes it have copyright.
  That is the most sensible attitude.
 
 It's not worth worrying about: really.
  Why risk it.  Anything that can lead to FUD from others and dissuade
 use of KiCad should be avoided.  I would be willing to donate all my
 library work into the Public Domain under, for example, the Creative
 Commons Public Domain Dedication:
 http://creativecommons.org/publicdomain/zero/1.0/
 
  If the original authors of library elements cannot be contacted
 simply ask users of the KiCad mailing list to recreate schematic
 symbols and module footprints.  I'm sure many users would be willing
 to help out and contribute.  As noted earlier, it is the expression of
 an idea that is Copyrightable so it is mostly a simple matter of
 redoing the work.
 
 -Matt
 
 
 Great posting Matt.
 
 We do have pending opportunities to formulate a strategy.  So I think a 
 plodding dialog is
 harmless and good.   For example, we will be moving to s-expressions for 
 schematic and
 board stuff (parts, footprints, schematics and boards).
 
 Some interesting questions that I hope will stimulate some thinking, and 
 eventually some
 responses:
 
 
 1) What are we to conclude when a conversion program changes the expression 
 of an idea
 (to s-expressions)?   Sounds not to be a copyright violation during the 
 conversion, but an
 opportunity to re-establish a specific license or posture on the converted 
 work.
Normally translation (language-wise) are covered under copyright. So I think 
that means that GPL remains GPL, if the GPL can be asserted on symbol/footprint 
libraries.
From reading the opinions in this thread it seems it can be licensed with the 
GPL. Whether or not a schema using a symbol then has to be GPL-ed is something 
which is unclear to me, and I wonder if the answer will be the same for each 
country where KiCad is used.


 2) Do we want the work invested in KiCad project schematic parts and 
 footprints to add
 value to KiCad expressly, and not be available for *easy* use in other 
 software packages? 
 How important is this on a scale of 1-10?
0. I think we should allow other programs to import/convert KiCad libraries. I 
have already seen people switching to Eagle because they feel it has the most 
complete library, even though they could import them.
In my opinion, having a neutral license for parts and footprints is adding 
value to KiCad.


 3) What are the incentives for anyone to share their work in parts and 
 footprints?  Are
 they sufficient?
I think a upload part/footprint to KiCad button or the ability to share your 
libraries with (something like git/bzr) would be an incentive.
This would allow a reseller (adafruit, rs, farnell, etc) to publish the 
parts/footprint in their libraries and you would add their repo as a library 
resource (or clone it).

I think what is stopping people (guilty) from sharing parts and footprints is 
in the ease of submission. 

/Martijn
___
Mailing list: https://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] Reverse engineering on KiCad

[Martijn Kuipers]

On Mar 14, 2012, at 2:37 PM, Solonen Vesa wrote:

 Some forgotten details:
 
 Original thread [1] and some more [2]. Regarding linking problems mentioned 
 on [2] they are solved by taking WxWidgets cmake modules from the current 
 branch. Namely 'UsewxWidgets.cmake' and 'FindwxWidgets.cmake'. By these 
 changes everything builds and links nicely on a modern multilib (64b) Linux. 
 And runs too it seems.
 
 Do any of the main developers have any objections for implementing backgroung 
 image support for Pcbnew along the lines of Clive's design? I may take a look 
 for a task of porting that functionality to the current branch, but would 
 like to make it a import menu function.
 
 Best regards,
 -Vesa
 
 [1] 
 http://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg01645.html
 [2] 
 http://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg01696.html

Upfront: regular user who uses recent KiCad versions, not one of the main 
developers.

I think this would be a great item to have. In the past I have had some broken 
gadgets to fix, for which I obviously did not have a schematic. Although it 
can be done by hand (which is what I do), this feature would greatly reduce the 
time needed to create a schematic (and get an idea where to start looking for 
broken parts). 

/Martijn



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

Re: [Kicad-developers] [PATCH] - PCBNEW - implement PS plotting width correction.

[Martijn Kuipers]

I didn't know it either and Brians' explanation did not explain it to me fully 
(sorry Brian), so I decided I wanted to know.

I found this page (http://www.standardpc.com/engineering.htm) where they say:
**Etch factor is a reduction of line width due to the etching process.  The 
sides of the copper trace are exposed to the etching solution as the unwanted 
copper is removed from the surface.  The amount of reduction is dependant on 
the thickness of the base copper cladding.  For example: A 10 mil trace may be 
reduced 0.5 mils when etching 1oz copper clad or 1.0 mil when etching 2oz base 
copper.  Staying within 20% of nominal trace width as specified by IPC is not a 
problem with standard copper weights.  If heavier copper weights are used then 
compensating the line width may be required to maintain the 20% tolerance.  For 
a 12 mil line utilizing a 4oz copper base, it would be advisable to compensate 
the designed line width by 2 mils to allow for etch factor.

A similar situation exists with RF designs where line width tolerances are 
critical to the function of the board.  Typically we will compensate line 
widths as necessary to achieve the designed line width (as taken from the 
gerber files) after etching.  If you would prefer to compensate the line widths 
yourself, please notify us so we do not over compensate.


Happy NewYear,
Martijn

On Dec 30, 2011, at 9:05 PM, Brian F. G. Bidulock wrote:

 Dick,
 
 On Fri, 30 Dec 2011, Dick Hollenbeck wrote:
 
 Hi Alexander,
 
 It would have been nice to explain your strategy and why you chose this over 
 possible
 other alternatives.
 
 Can you pllease explain:
 
 What is width correction?
 
 Why do you need it?  That is, what is wrong with the original width that it 
 needs
 correction?
 
 Why is the original width wrong?
 
 Thank you very much,
 
 Dick
 
 The correction is for etch factor.  PS is the final plotting
 stage in toner transfer method.   The PS image will be tranfered
 to the board directly as an etch resist.  Widths of tracks and
 vias must, therefore, be corrected for etch factor.
 
 --brian
 
 -- 
 Brian F. G. Bidulockœ The reasonable man adapts himself to the œ
 bidul...@openss7.orgœ world; the unreasonable one persists in  œ
 http://www.openss7.org/ œ trying  to adapt the  world  to himself. œ
œ Therefore  all  progress  depends on the œ
œ unreasonable man. -- George Bernard Shaw œ
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] OSX and new Icons

[Martijn Kuipers]

Hi,
On Dec 9, 2011, at 8:51 PM, Marco Serantoni wrote:

 Hi folks,
 I'm as usual doing my semestral build of Kicad, one is for Xmas.
 I've noticed that icons were changed i wish to compliment with the author for 
 the enhancement, i appreciated the KDE style but i'm afraid that could be 
 confusing for operations like New, Open and Save that are usually coded in a 
 different way under Windows and OSX.
 
 Now passing to the problem, i've noticed that also the icons for the 
 applications are changed, to make them appear correctly under OSX i need to a 
 bitmap of different square sizes: 16,32,128,256,512 needed for a icns file 
 (icon).
 Are those avaiable ? otherwise i had to still use the old icons and create a 
 new one for PCB Calculator.

the svg-sources for the icons should be in bitmaps_png/sources. There is 
already some cmake support for them (the quote below seems to indicate this was 
done by Dick):

Important cmake config options:

1) USE_PNG_BITMAPS is defaulting to ON, change it to OFF if you don't like the
PNGs and want to use XPM for size reasons, or what not.   I think eventually xpm
support goes away.

2) MAINTAIN_PNG defaults to OFF.  Set to ON only if you have all the tools
installed that are described in bitmaps_png/CMakeLists.txt.  If you are not a
PNG maintainer, the *.cpp files are part of the source tree, and you do not have
to build them.  Note to builders, be careful you don't churn the *.cpp files as
PNG bitmaps are built, so that you do not create unnecessary bzr deltas in the
source code tree.



Hope that helps,
Martijn

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


___
Mailing list: https://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] Concerns about clearing disagreements before committing.

[Martijn Kuipers]

Dick and Vladimir,
Thanks for trying to solve this together!

I agree with your assessment. I think I read that board-files will be saved in 
a defined unit (engineering unit). I think this is great especially if the 
board-file also has the information on which unit is used (mm, mil, nm, 
whatever).
Ok, probably not whatever, but one really small imperial unit, one really small 
metric unit and perhaps a really small mil-based unit (centi-mill?).

I am also in favour in rolling-back the commits as for the moment it does not 
compile for me (needs the fabs-patch, floating abs, which is trivial, but not 
necessary). 

I will do my best to do OSX-testing of your results. (we actually use KiCAD on 
all 3 platforms).

Break a leg ;-)
Martijn



On Nov 24, 2011, at 5:30 AM, Dick Hollenbeck wrote:

 
 Vladimir,
 
 Tonight : definitions and some questions
 Tomorrow: a proposal to share/split the work and how to do it
 
 If you can look over the questions and clear any confusion on my part that 
 would
 be appreciated.  Thanks very much.
 
 
 Definitions:
 
 *) Board Internal Units (BIU). This is a pseudonym for the engineering units
 used by a BOARD when it is in RAM, and only when it is in RAM.  BIU is
 perhaps nanometers in the future, and deci-mils currently.
 A BIU refers typically to a measurement or a position on an XY grid, and this 
 is
 because this grid is dimensioned in BIUs along both its X and Y axes. Both X 
 and
 Y can be either positive or negative on this grid. In the case of measurements
 or scalars, there can be a radius, a diameter, a distance (length), and all of
 these can and should be expressed in BIUs, when we are in RAM and when we are
 talking about the objects within the class BOARD instance. One special
 feature of XY points within the BIU coordinate system is that they will always
 be integers. In contrast, distances and other forms of measurements are not
 subject to the same limitation by the very nature of physics. Coordinates are
 always integers because we use signed whole numbers to represent these BIU
 coordinates.
 
 *) Snap grid. A snap grid is a subset of the full set of possible XY 
 coordinates
 in the BIU coordinate system. Points falling on the snap grid are evenly 
 spaced
 in X and Y directions and are some integer multiple apart in this 2D space,
 usually greater than one BIU apart.
 
 *) Metric Board. This is a pcb board that has a great number of coordinates 
 and
 distances that happen to be some multiple of the BIU that is also a multiple 
 of
 a metric engineering unit such as micrometers.
 
 *) Imperial Board.  This is a pcb board that has a great number of 
 coordinates and
 distances that happen to be some multiple of the BIU that is also a multiple 
 of
 an imperial engineering unit such as mils or inches.
 
 
 Assumptions:
 
 a) It is OK to modify the board file format in order to handle the BIU change.
 
 b) Boards saved on disk in the new format will not be readable using old 
 software.
 
 c) Since we have no backwards compatibility obligation, we can make 
 significant
 changes to the file format while we have this disruption opportunity.
 
 
 Questions:
 
 1) Is it not possible that the board could be saved on disk using engineering
 units other than the BIUs?
 
 2) Once the BOARD is in RAM, is it not possible that all objects within the
 BOARD* object use BIUs as their spatial coordinates and BIUs as units of
 measured distances?
 
 3) Is it not true that the main difference between the user interface in play
 while working on a metric board vs. an imperial board, is the grid snap 
 distance
 (and various computer screen fields and menus) ?
 
 4) If sufficient resolution is preserved, is there not some advantage in
 disconnecting the chosen engineering units in a saved BOARD file from the BIU?
 (On the theory that if the BIU needs to be changed again in the future, that 
 you
 do not also have to change the BOARD file format, a situation we currently 
 find
 ourselves in?)
 
 5) Is is not simply a matter of scaling other engineering units like 
 millimeters
 when loading a BOARD file into the RAM resident form where BIUs pertain? In
 reverse direction for disk saves?
 
 6) Is it not simply a matter of scaling to other engineering units like
 millimeters or mils when exporting a RAM resident BOARD (of course using BIUs)
 to other formats such as gerbers?
 
 7) Which items among 1) through 6) are new?
 
 Dick
 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp


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

Re: [Kicad-developers] Kicad future documentation - first draft

[Martijn Kuipers]

Hi Dick,

This is not my fight. I almost was typing in a reply, but I think it is in 
KiCads' best interest to not begin a quarrel.
I just wanted to note a few things:
- I agree, we disagree on almost all points and as my comments did not convince 
you otherwise, neither did yours.
- I agree when you are right saying you are a major shareholder and as I told 
you I do appreciate the efforts put into KiCad by you and everyone else.

So it seems we can reach some form of agreement. A dutch saying goes like this: 
Hoge bomen vangen veel wind. Since I doubt google will give an accurate 
translating, and I am unaware (at least at the moment) of the English 
equivalent, you can roughly translate this to: Those who step forward and put 
in a lot of effort are most likely to receive criticism.  It does not state 
whether that is fair or not.

Sincerely yours,
Martijn


On Sep 28, 2011, at 1:08 AM, Dick Hollenbeck wrote:

 On 09/27/2011 03:33 AM, Martijn Kuipers wrote:
 On Sep 27, 2011, at 12:33 AM, Brian Sidebotham wrote:
 
 On 27 September 2011 00:22, Dick Hollenbeck d...@softplc.com wrote:
 On 09/26/2011 05:04 PM, Fred Cooke wrote:
 Yes it absolutely is constructive criticism, it points out weaknesses, 
 explains why they
 are weaknesses, and explains how to do it better. Sounds EXACTLY like 
 constructive
 criticism to me, Dick. Your name could not be more fitting.
 I agree the last sentence should not be posted in public space. 
 
 I do not agree that it is not constructive criticism, i.e., I think it is 
 constructive. Let's not forget the original poster to whom Dick replied 
 might not be a native English speaker.
 
 I have de-activated Fred Cooke from this mailing list.
 
 Judge, Jury and Executioner. This is not very democratic.  
 
 Wrong metaphor.  Think owner, and major shareholder.  More below.  If you 
 like, bouncer
 at a shareholder's meeting.
 
 
 In open source (s)he-who-does-the-work-decides is fine with me with respect 
 to general directions, coding decisions, vcs, etc, but this is not a 
 code-problem.
 
 I'm very glad! His posts have only ever been derogatory and of no
 substance. Sorry you've had to deal with it.
 This I also don't agree with. Maybe he has not done as much as you (Brian), 
 Dick or Jean-Pierre, he has been trying to be helpful. 
 
 
 Martijn,
 
 
 Since you are a shareholder, I will try and respect your opinion, even as I 
 disagree with
 most all of it.
 
 First, the least controversial:  what is constructive criticism? 
 
 1) It does not end with I do not like it.
 2) It respects the feelings of the performer.
 3) It uses language like if you were to do this ..., then here would be the 
 benefit for
 all of us...
 
 
 I do agree this is more difficult in a foreign language.
 
 
 
 Fred has been trying to gain respect through the wrong means, not through 
 contributions
 and by being respectful.  I grepped through the commit logs and don't see his 
 name once.
 
 On this list, and in general, *being respectful* earns you good will.  Good 
 will then
 eventually earns you respect. 
 
 Around here we don't kick the *hens* that lay the golden eggs.  All are not 
 equal here. 
 
 When decency and respect break down, as has apparently happened here, we 
 would have to
 fall back to understanding of ownership.  Think of this mailing list as a 
 shareholder's
 meeting, one in which they let customer's attend so long as they behave.
 
 The KiCad project has owners, and users. Some are owners.  Some own more than 
 others. 
 Ownership can be measured by previous contributions.  Contributions come in 
 many forms:
 ideas, team building, leadership, coding, website administration, 
 documenting, sifting
 through bug reports, translating, fixing bugs, building 3-d models, editing 
 wikis, etc.
 etc. etc.
 
 
 Here is my most important point:
 those that have succeeded here have all been respectful at the start, this 
 includes
 Jean-Pierre, who has been enormously respectful of the other hens.  Wayne, 
 who has been
 enormously respectful of the other hens.
 
 Brian, who has been enormously respectful of the hens.  Name after name it's 
 the same
 way.  And I cherish every one of them, too many of which will go unnamed just 
 here.  Sorry
 Jerry, sorry sorry sorry, as I make my point without listing everyone.
 
 
 Fabrizio has been enormously respectful of the hens *from the start* and 
 continues to be
 so, and is now a hen himself.
 
 
 The respect of the hens is a self identifying personality trait, that 
 predisposes a person
 to succeed here, or to fail if you do not have it.  This does not mean that a 
 person has
 to agree with everything.  I am respecting you now, even as I explain my 
 disagreement.
 
 
 When I tried to protect a hen, Fabrizio, I got *personally* attacked in a 
 malicious,
 non-ambiguous, destructive way.  This is not a misunderstanding.   I said 
 that Fred had
 already also attacked me through my facebook account.  Putting this to a vote 
 is
 non-sensical

Re: [Kicad-developers] Kicad future documentation - first draft

[Martijn Kuipers]

On Sep 27, 2011, at 12:33 AM, Brian Sidebotham wrote:

 On 27 September 2011 00:22, Dick Hollenbeck d...@softplc.com wrote:
 On 09/26/2011 05:04 PM, Fred Cooke wrote:
 Yes it absolutely is constructive criticism, it points out weaknesses, 
 explains why they
 are weaknesses, and explains how to do it better. Sounds EXACTLY like 
 constructive
 criticism to me, Dick. Your name could not be more fitting.

I agree the last sentence should not be posted in public space. 

I do not agree that it is not constructive criticism, i.e., I think it is 
constructive. Let's not forget the original poster to whom Dick replied might 
not be a native English speaker.

 
 I have de-activated Fred Cooke from this mailing list.
 

Judge, Jury and Executioner. This is not very democratic.  In open source 
(s)he-who-does-the-work-decides is fine with me with respect to general 
directions, coding decisions, vcs, etc, but this is not a code-problem.

 I'm very glad! His posts have only ever been derogatory and of no
 substance. Sorry you've had to deal with it.

This I also don't agree with. Maybe he has not done as much as you (Brian), 
Dick or Jean-Pierre, he has been trying to be helpful. 

Cheers,
Martijn

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


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

Re: [Kicad-developers] Kicad Library Concept Ideas

[Martijn Kuipers]

On Feb 3, 2011, at 19:13 PM, Dick Hollenbeck wrote:

 On 02/03/2011 12:37 AM, Dick Hollenbeck wrote:
 Start by conceptually, i.e. algorithmically walking through:
  PART* LIB_TABLE::LookupPart( const LPID aLPID, LIB* aLocalLib )
 
 and conceptually step through that until you end up in
 
  DIR_LIB_SOURCE::ReadPart()
 
 
 This path is basically a matter of resolving the four elements of the LPID.
 
 
 LookupPart does work already, and there are some lazy operations that happen
 only once and only when needed.
 
 When I have more time I will make a main test program for the DSO/DLL.
 
 
 Man I love CMake and Linux.  It took only about 5 minutes to park a test
 program on top of libsweet.so.  So now you can single step through the code
 if you are on Linux.  Windows/Mingw might need some additional work but
 nothing significant.
 
 The test data are generated with a script called
 make-dir-lib-source-test-data.sh, invoked first.
 Then the test program is run from the same directory simply with
 $ ./test_sch_lib_table
 
 The reported error is correct, since value has not yet been taught to the
 parser, and the parser is that last thing that had run:
 
 
 (part tigers/ears (value 22)(footprint SM0805))
   ^
 
 ===captured output==
 dick@dick-intel:/svn/kicad/work/new$ ./make-dir-lib-source-test-data.sh
 
 dick@dick-intel:/svn/kicad/work/new$ md build
 dick@dick-intel:/svn/kicad/work/new$ cd build
 
 dick@dick-intel:/svn/kicad/work/new/build$ cmake -DCMAKE_BUILD_TYPE=Debug ../
 -- The C compiler identification is GNU
 -- The CXX compiler identification is GNU
 -- Check for working C compiler: /usr/bin/gcc
 -- Check for working C compiler: /usr/bin/gcc -- works
 -- Detecting C compiler ABI info
 -- Detecting C compiler ABI info - done
 -- Check for working CXX compiler: /usr/bin/c++
 -- Check for working CXX compiler: /usr/bin/c++ -- works
 -- Detecting CXX compiler ABI info
 -- Detecting CXX compiler ABI info - done
 -- Found Doxygen: /usr/bin/doxygen
 -- Check for installed wxWidgets -- found
 -- Found PythonLibs: /usr/lib/libpython2.6.so
 -- Configuring done
 -- Generating done
 -- Build files have been written to: /svn/kicad/work/new/build
 
 
 dick@dick-intel:/svn/kicad/work/new/build$ make
 Scanning dependencies of target sweet
 [  7%] Building CXX object CMakeFiles/sweet.dir/sch_lib_table.cpp.o
 [ 14%] Building CXX object CMakeFiles/sweet.dir/sch_lib_table_keywords.cpp.o
 [ 21%] Building CXX object CMakeFiles/sweet.dir/sch_lib.cpp.o
 [ 28%] Building CXX object CMakeFiles/sweet.dir/sch_lpid.cpp.o
 [ 35%] Building CXX object CMakeFiles/sweet.dir/sch_dir_lib_source.cpp.o
 [ 42%] Building CXX object CMakeFiles/sweet.dir/sch_part.cpp.o
 [ 50%] Building CXX object CMakeFiles/sweet.dir/sweet_keywords.cpp.o
 [ 57%] Building CXX object
 CMakeFiles/sweet.dir/svn/kicad/work/common/richio.cpp.o
 [ 64%] Building CXX object
 CMakeFiles/sweet.dir/svn/kicad/work/common/dsnlexer.cpp.o
 Linking CXX shared library libsweet.so
 [ 78%] Built target sweet
 [ 85%] Swig source
 /svn/kicad/work/new/sch_lib_table.h:202: Warning(312): Nested class not
 currently supported (ignored).
 Scanning dependencies of target _sweet
 [ 92%] Building CXX object CMakeFiles/_sweet.dir/sweetPYTHON_wrap.cxx.o
 Linking CXX shared module _sweet.so
 [ 92%] Built target _sweet
 Scanning dependencies of target test_sch_lib_table
 [100%] Building CXX object
 CMakeFiles/test_sch_lib_table.dir/test_sch_lib_table.cpp.o
 Linking CXX executable test_sch_lib_table
 [100%] Built target test_sch_lib_table
 
 
 
 dick@dick-intel:/svn/kicad/work/new/build$ ./test_sch_lib_table
 test 'Parse() - Format()' round tripping:
 (lib_table
  (lib (logical meparts)(type dir)(full_uri /tmp/eeschema-lib)(options
 useVersioning))
  (lib (logical old-project)(type schematic)(full_uri
 /tmp/old-schematic.sch)(options ))
  (lib (logical www)(type http)(full_uri http://kicad.org/libs)(options ))
 )
 
 test a lookup of 'www':
  (lib (logical www)(type http)(full_uri http://kicad.org/libs)(options ))
 
 list of logical libraries:
 logicalName: meparts
 logicalName: old-project
 logicalName: www
 lookupPart:kitties/ears
 lookupPart:kitties/eyes
 lookupPart:kitties/feet
 lookupPart:lions/ears
 lookupPart:lions/eyes
 lookupPart:lions/feet
 lookupPart:tigers/ears
 lookupPart:tigers/eyes
 lookupPart:tigers/feet
 lookupPartRev:rev10
 lookupPartRev:rev5
 lookupPartRev:rev1
 PART::PART(tigers/ears/rev10)
 lookupPartLatestRev:tigers/ears/rev10
 PARSE_ERROR: Expecting 'anchor|value|footprint|model|keywords|alternates
 |property
  |property_del
 |pin
  |pin_merge|pin_swap|pin_renum|pin_rename|route_pin_swap
 |polyline|line|rectangle|circle|arc|bezier|text' in input/source
 meparts:tigers/ears, line 1, offset 20
 from /svn/kicad/work/common/dsnlexer.cpp : Expecting : 291
 (part tigers/ears (value 22)(footprint SM0805))
   ^
 dick@dick-intel:/svn/kicad/work/new/build$
 
 

Re: [Kicad-developers] New part file format document.

[Martijn Kuipers]

On Dec 20, 2010, at 20:29 PM, Wayne Stambaugh wrote:

 On 12/20/2010 1:42 PM, Dick Hollenbeck wrote:
 On 12/14/2010 04:49 PM, Wayne Stambaugh wrote:
 I made some ,inor changes to clarify inherited vs base part and changed
 LPID names reflect local naming convention as suggested by Dick.
 
 Wayne
 
 
 Wayne and others,
 
 
 I coded the initial major portion of DIR_LIB_SOURCE this weekend.  I believe 
 the design is still
 holding water, so far.
 
 
 The only thing that has come up is this age old issue of content in 
 container, and names.
 
 Let me generalize, so you can see it is not specific to this design.
 
 Assume you have a C++ file, and you decide to put the name of the file INTO 
 the file as a string.
 
 You load that C++ text file, and save it by another name.
 
 The file now lives in two *containers*. 
 
 
 
 1) The text editor is a container, and it assigns a name to the text file in 
 memory.
 
 
 2) The filesystem is a container, and it assigns a name to the text file on 
 disk.
 
 
 Each container has its own understanding of the name of the content (i.e. 
 text file).  A
 disagreement has happened.  And it is not about the name in the editor and 
 the name on disk.
 
 It is about the name IN THE FILE, and the name in the editor and on disk.
 
 
 
 
 Either of the two examples of content (text file) within container would 
 suffice to make my point:
 
 
as long as you put the name of the file in the file, there is always
the potential for a disagreement between what the file's container
thinks the content is named, and what the contained name says.
 
 
 Therefore, we might want to re-think our Sweet token that we referred to as 
 NAME
 
 (part NAME [extends LPID]
 ..
 )
 
 and either drop it, since the Sweet string will always be in some kind of 
 container, or realize that
 this is not *really* the name of the part, the container will always chose 
 that.
 
 I actually considered this when I wrote the specification.  I don't remember
 why I chose to include NAME in the part syntax.  I think it's a great idea.
 Using the file name as the part name makes sense to me.

It has both advantages and disadvantages. The advantage would be that you do 
not need to scan/read the file to know the component, but (in my opinion) the 
cons outweigh the advantage. The disadvantage I see has to do with the 
different filesystems, case-sensitivity and illegal characters. Now the 
filename could hint the part, but the only requirement for a filename is that 
it is unique within the directory.

Kind regards,
Martijn

 
 
 
 A useful comprimize is to conceptually or actually change NAME to 
 SHORT_DESCRIPTION, but if you have
 a description elsewhere, a short description may not be needed at all.
 
 A description (short or otherwise) seems like a good candidate for a property.
 I'm not sure if it should be a reserved property or a user definable property.
 
 
 Think about it.  The only time when the container will not name the content, 
 may be on the clipboard.
 
 Would you even need the name in the clipboard?  If you are pasting into 
 another
 part file, it will take the name of the new part file.  You may need to name
 them when they become components in a schematic but that would be part of the
 schematic file format.
 
 
 A fast answer is probably a wrong answer.  I've been thinking about it for a 
 day and still need more
 time to state the best solution.
 
 Let me know so I can update the specification.  I have already made the 
 changes
 for providing pin and gate swapping flags to be passed to external tools.  I
 want to keep the specification synced with the code as much as possible to
 avoid confusion.
 
 Wayne
 
 
 I just know that the problem will exist as we now have things, and as 
 stated, it is not a problem
 unique to this design.
 
 The container's name will always really dominate, since that is the 
 mechanism used to find units of
 content.
 
 Dick
 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://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 part file format units discussion.

[Martijn Kuipers]

On Dec 16, 2010, at 1:16 AM, Brian Sidebotham wrote:

 On 15 December 2010 20:07, Wayne Stambaugh wstamba...@dilon.com wrote:
 Dick and I have been discussing his ideas on making schematics and therefore
 parts dimensionless.  The more I think about it, the more I like it.  Please
 look over the discussion below and feel free to comment.  I have also 
 attached
 the revised part specification with Brian's part renaming suggestion.
 
 Wayne
 
  Original Message 
 Subject: Re: Patch for kicad gal
 Date: Wed, 15 Dec 2010 13:07:23 -0600
 From: Dick Hollenbeck d...@softplc.com
 To: Wayne Stambaugh wstamba...@dilon.com
 
 On 12/15/2010 12:23 PM, Wayne Stambaugh wrote:
 On 12/15/2010 12:15 PM, Dick Hollenbeck wrote:
 On 12/15/2010 10:55 AM, Dick Hollenbeck wrote:
 On 12/15/2010 10:18 AM, Wayne Stambaugh wrote:
 On 12/14/2010 5:44 PM, Dick Hollenbeck wrote:
 On 12/14/2010 03:38 PM, Wayne Stambaugh wrote:
 On 12/14/2010 1:54 PM, Dick Hollenbeck wrote:
 
  snipped 
 
 
 As I was reading your spec.  I began to wonder if it would be helpful 
 for *human
 writability* if:
 
 The units of the coordinate system were grid oriented.  In other 
 words, if we could
 superimpose an additional cartesian coordinate system that was at a 
 lesser resolution
 onto the normal coordinate system.
 
 In this mode, pins might be 1 unit apart, vertically or horizontally.
 
 Don't know if we can do the same for text or pin names.  But maybe.  
 Maybe this makes
 writing Sweet with a text editor easier?
 
 
 (gxy X Y)   grid coordinate  (maybe it implies a division of X and Y 
 by 50 or so.)
 
 (xy X Y)units coordinate
 I'm not 100% sure if I follow you.  If the xy coordinates where in 
 terms of
 grid (gxy), wouldn't that mean a conversion in order to figure out 
 where a item
 is located relative to the grid?
 Again, I am not over selling, but I want you to understand my original 
 thinking, at
 least enough to tell me it's foolish or not worth it:
 
 First I start by assuming dimensions in the schematic are not even 
 important unless I
 go to print.  Dimensions, i.e. *scaling*, could be added at the 
 eleventh hour just
 before printing.  EESCHEMA only.
 
 
 What is important is that the grid let me connect wires to pins.  So if 
 the pins are
 on grid points, the wires are on grid points, then what is not on a 
 grid point?  Text
 can be on a grid point.  What is left is arcs, curves, but very little 
 else.
 
 Therefore, in some cases all we need is a ficticious coordinate system 
 that is based
 entirely on grid points *alone*.
 
 If (xy 100 200) were a valid point before, then (gxy 1 2) becomes the 
 *same* exact
 point expressed in grid coordinates, assuming the grid was 100 x 100 
 original units.
 
 Basically what this does is eliminate some trailing zeros, on the 
 assumption that grid
 points are the only points of interest, and that the grid is a multiple 
 of 10.  If the
 grid is 200 x 200:
 
 then (xy 200 2000)  becomes (gxy 1 20)
 
 And the author of the code in his TEXT EDITOR might find this easier.
 
 It requires that you don't ever need to go off grid.   And admittedly 
 this is not the
 case with curves.  So I don't know if it is easier or harder.
 
 That is one line of thought, two coordinate systems.
 
 An alternative line of thought is to have one coordinate system but 
 have it BE the
 grid system in all cases, and use fractions to go off grid, like (xy 
 1.25 4.5).  So
 pins *by request or by definition* are one X unit or one Y unit apart.  
  Then only at
 time of printing do you assign the scaling factor, and which point you 
 can stretch the
 schematic to any size you want.  Likewise during editing, you can 
 stretch to any size
 you want.  The schematic is essentially dimension-less.
 This concept has a lot going for it.  I like the idea of a dimension-less
 schematics.  You would never have to worry about pins being off grid and 
 not
 connecting properly to a wire or bus no matter where you placed them in 
 the
 schematic.  My main concern is how easy is this going to be for users to
 understand given that the initial part file editor is going be text 
 based.
 Converting off grid part coordinates is going to be confusing.  It will 
 also
 make specifying things like line width and text height and width 
 relative to
 the grid spacing difficult as well.  A graphical editor may be required 
 to draw
 off grid elements properly.  This will definitely have to be determined 
 before
 we start coding.
 Well we can make all the new kids wear uniforms to school, 
 metaphorically.  This means
 we challenge the need for text that does not fit within a grid unit.  
 Maybe all text
 is the same size in EESCHEMA, by default any way.
 
 
 Converting existing symbols over we can simply use fractional numbers if 
 they go off
 grid.  But
 
 
 (pin ..(xy 1 2) ..)
 (pin ..(xy 2 2) ..)
 
 gets pretty easy, it reminds me of using graph paper as a kid.  In fact a 
 person could
 draw his part on graph 

Re: [Kicad-developers] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)

[Martijn Kuipers]

On Dec 14, 2010, at 2:55 AM, Dick Hollenbeck wrote:

 On 12/13/2010 01:48 PM, Dick Hollenbeck wrote:
 Wayne and Torsten,
 
 Here is a patch that allows the GAL to compile and run on Ubuntu Lucid x86_64
 
 with *version wxWidgets 2.8.x*
 
 The key thing is the wxWidgets version.  The repo seems to be dependent on 
 2.9.
 
 
 Moving forward, we're going to need write access to a branch holding this 
 stuff.  I
 think we should keep it a separate branch.  Kicad's Cmake can be told to do 
 a checkout
 later.
 
 If the *community* decision is to move forward with it.  (Seems that could 
 have been a
 point of mis-understanding.)  I am only one voice, but I should get a good 
 look at it
 over the Christmas break.

Great, for me an example (just like you planned) might show me the value of 
Torstens' work. Not saying there isn't any, I am just not seeing it (my fault 
really).

If I understand correctly you (DIck) are proposing to maintain 2 branches for a 
while:
- Kicad as we know it
- Kicad Next Generation

If the next generation is as promising as is foreseen, then one day we 
(Jean-Pierre) will just bless the next generation branch as the stable one. 
Right ?

Thanks for all the effort people are putting into Kicad.

/Martijn 

 
 Thanks again to Torsten for what looks to be:
 
 1) great work,
 2) conforming to the coding standards, and
 3) for patience in the supreme.
 
 
 Regards,
 
 
 Dick
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://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] sourceforge.net svn repo is emptied

[Martijn Kuipers]

Hi Dick,

Great. Why not submit a single text-file saying it is hosted now on lp.?

/Martijn
On Nov 11, 2010, at 23:32 PM, Dick Hollenbeck wrote:

 I was able to erase the content of the SVN repo at sourceforge.net.
 
 After doing that I disabled it for general use.  But as we have learned,
 disabling it does not prevent someone from reading from it.  However,
 now it will come up empty during a checkout.
 
 The package maintainers will now have to dig a little, for
 understanding, and update their build scripts to use bzr against
 launchpad.net.
 
 Dick
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://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] Events inside kicad

[Martijn Kuipers]

On Oct 27, 2010, at 1:27 AM, Wayne Stambaugh wrote:

 On 10/26/2010 2:58 PM, Marco Serantoni wrote:
 
 On 26/ott/2010, at 20.54, Dick Hollenbeck wrote:
 
 On 10/26/2010 01:50 PM, Marco Serantoni wrote:
 In those days i was thinking about to add an internal event generation for 
 some kicad classes.
 Adding internal events at wxAUIManager could be a good start to implement 
 external frames and utilities (plugins) , making possible plug-in new 
 functionalities and probably reorganizing some parts of code
 
 Marco,
 
 Before you commit this, I would like to see an example of how you are
 going to handle these events in some type of plug in framework.  I'm
 just not seeing where you are going with this.  If you are planning on
 handling these events in any of the Kicad application main windows, that
 doesn't make much sense because it was a command event generated by the
 main window that got you to that point in the first place.  What does
 make sense to me it to create some custom command events for handling
 things like zoom and grid selection.  One of the often overlooked
 features of command events is that they can be used to pass objects and
 data pointers along with the event by using the Set/GetClientObject and
 Set/GetClientData.  I'm not rejecting this patch, but I'm concerned that
 this patch will not be fully developed and no plugins that handle these
 events will ever be written which means there is an unnecessary level
 complexity in this code.


Marco could probably explain it better than I can, but from what I understood 
his intention is to make Kicad event-based and using message-passing, pretty 
much like wx itself.

A good explanation of this event-based use (for those that do not already know 
it) can be found here:
http://docs.wxwidgets.org/trunk/overview_events.html

I also misunderstood Marco's email in thinking he was proposing a 
plugin-framework, but that is not the case. However, having this in Kicad would 
make it easier to add a plugin-framework. Eagle seems to have a large amount of 
scripts around, so there must be some use for it. Of course, Kicad is open 
source so the most wanted plugins could be ported inside Kicad. 

This is just what I understood after a small conversation I had with Marco. Of 
course, he can probably explain things a lot better than me, although he 
convinced me it was a good thing, for what it is worth.

/Martijn
 
 
 I've already something ready, if nobody has something against it i wish 
 commit the first tranche of the implementation on pcbnew.
 
 
 If it is as disruptive as you say, can we see a patch and have a short
 chat about it before you commit?
 
 Indeed, 
 Here is the patch, let's chat :)
 
 Your patch has a few issues.  The code formatting is incorrect.  Please
 see the recently released coding guidelines in the Kicad source tree or
 use uncrustify to correct the formatting.  Also, try to avoid the wx
 prefix when naming source code that is not going to be pushed upstream
 to wxWidgets.  I think we should leave that to the wxWidget developers.
 I know there are a few other places in where this is used in the Kicad
 source tree but this is one of those minor things that should be cleaned
 up.  Thank you for your effort.
 
 Wayne
 
 
 --
 Marco
 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp


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

[Martijn Kuipers]

On Oct 15, 2010, at 16:32 PM, Wayne Stambaugh wrote:

 On 10/15/2010 6:37 AM, Brian Sidebotham wrote:
 I already had a suspicion my patch was not complete.
 I was hoping to achieve that cmake does all the dependency checks and then 
 decides if there is enough to build it or to ask for other dependencies, 
 instead of finding out at linking-time.
 
 
 Probably we need to do the wxWidgets check before the expat check, right?
 
 So the patch should to the following (?):
 # only gl and mono can be detected
 find_package(wxWidgets COMPONENTS mono gl REQUIRED)
 
 Why is the wxWidgets monolithic library being used?  I can build separate
 wxWidgets libraries on Windows using both dynamic link and static libraries on
 both Mingw/MSYS and Visual Studio 2005 with no problems.  I usually use static
 because it make my life easier but I have successfully built Kicad both ways.
 If you are going use the monolithic library, use a command line switch as 
 shown
 below.
 
 option(KICAD_USE_WX_MONO Enable/disable building with wxWidgets monolithic
 library (default OFF))
 
 if(KICAD_USE_WX_MONO)
find_package( wxWidgets COMPONENTS mono gl REQUIRED )
 else(KICAD_USE_WX_MONO)
find_package( wxWidgets COMPONENTS gl adv html core net base xml aui 
 REQUIRED )
 endif(KICAD_USE_WX_MONO)
 
You don't need expat here, like
 find_package( wxWidgets COMPONENTS gl adv html core net base xml aui expat 
 REQUIRED )



 Use the -DKICAD_USE_WX_MONO=ON switch when running CMake.
 
 if(NOT WIN32)
   find_package(wxWidgets COMPONENTS gl adv html core net base xml 
 REQUIRED)
 endif(NOT WIN32)
 
 There is no reason to use if(NOT WIN32) here.  I know I've said this before 
 and
 I will say it again.  Build tools should test for features not platforms.
 Whenever you see WIN32, APPLE, POSIX, etc., try to replace it with a feature
 test solution.  See the Recommendations for Writing Autoconf Macros page of
 http://www.lrde.epita.fr/~adl/dl/autotools.pdf for an excellent explanation of
 why to test for features.  Unfortunately the CMake folks accept and create
 these kinds of tests.
I wonder why we changed to cmake if autoconf does things the-right-way, but 
either way is fine with me.


 I know you thinking, how does that solve our expat library problem.  There are
 several ways to approach this problem but fortunately for us, the wxWidgets
 folks have a clue and provided a wxUSE_EXPAT definition when wxWidgets is 
 built
 using its own internal version of expat.  You should be able to use the CMake
 CheckSymbolExists macro to check for wxUSE_EXPAT in the setup.h file for the
 version of wxWidgets that was found.  Now you know which expat library to link
 against.  
Neat, learned something new.

 Assuming that the linker paths are defined correctly, you can link to
 the correct library.  This is actually not the optimal way to do it.  On
 platforms that support wx-config, you should use it instead.  So we end up 
 with
 something as following.
OSX has wx-config, it just does not show expat flags when built as a sys 
library with wxwidgets.
I am willing to send a bug report to the wx-folks, but in the mean time we 
could easily work around it, add a comment and rip it out when it is supported 
upstream. 

 
 find_program( wx-config, HAS_WX_CONFIG )
 
 if( NOT HAS_WX_CONFIG OR CROSS_COMPILING )
CheckSymbolExists( wxUSE_EXPAT path_to_correct_wx_version/setup.h
 USE_WX_EXPAT )
if( USE_WX_EXPAT )
   add_library( name_of_wx_widgets_expat_library )
else( USE_WX_EXPAT )
add_library( expat )
endif( USE_WX_EXPAT )
 endif( NOT HAS_WX_CONFIG OR CROSS_COMPILING )
 
 Assuming your development environment is setup correctly, this should work no
 matter what platform you are building against.
 
Windows has no wx-config? Ouch.

/Martijn

 Wayne
 
 
 but how can we check for (wx)expat and if that fails look for (sys)expat? 
 if wxWidgets cannot find wxexpat it should look for the system one with 
 find_package...and add the linker flag -lexpat
 
 These changes are tricky, since cmake behaves different on linux/win/osx, 
 but with a little help I am sure we can work it out. Also, if building a 
 deb-package you probably do not want the static linked version, but one 
 with dependencies on the other packages, but I have not looked into that 
 yet.
 
 Hi Martijn,
 
 I think the type of check you need is something like: (psuedo code)
 
 check (wxWidgets COMPONENTS expat QUIET)
 if (NOT wxWidgets_FOUND)
check (expat QUIET)
if(expat_FOUND)
add_link_library(expat)
else(expat_FOUND)
print Neither wxWidgets expat, or sys expat found
check_find_package_result(expat)
endif(expat_FOUND)
 endif(NOT wxWidgets_FOUND)
 
 ...
 (carry on with std wxWidgets checks)
 ...
 
 Something along those lines anyway I guess. If you struggle and just
 want a patch made, let me know. I could have a look at it when I get
 home for work tonight.
 
 Best Regards,
 
 Brian.
 
 

Re: [Kicad-developers] [PATCH] expat dependency for cmake

[Martijn Kuipers]

snip
 There are two ways that wxWidgets depends on expat:
 
 1) wxXml class depends on expat.
 
 2) xrc depends on wxXml which depends on expat
 
 
 My current theory is this:
 
 wxWidgets folks have probably gotten their build system fairly robust
 for users of 2), i.e. xrc.
 
 For those that are only using 1), like Kicad, then they still have a
 hole or two.  When we say they,
 
 Perhaps a test should be done to depend on the xrc support, even though
 we don't use it.  That might be another way to consider plugging this hole.
 
 The provider of wxWidgets is definitely a factor also to consider also,
 where does it come from?  If it comes from the distro repo, then there
 is a package maintainer in this picture also, else not.
 
 
 Dick

Thanks Dick and Wayne for your clear explanation.  Though even if it is a wx 
problem, should we not plug the hole while we await a fix from upstream?

/Martijn
___
Mailing list: https://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] expat dependency for cmake

[Martijn Kuipers]

On Oct 15, 2010, at 0:32 AM, Brian Sidebotham wrote:

 Hi again Martijn,
 
 Sorry I didn't see you had made use of check_find_package_result().
 
 This introduces a more fundamental problem, now sys expat is required.
 If I hide expat from my system and configure kicad with that check in,
 the output is:
 
 -- The C compiler identification is GNU
 -- The CXX compiler identification is GNU
 -- Check for working C compiler: C:/dev-env/apps/MinGW/bin/gcc.exe
 -- Check for working C compiler: C:/dev-env/apps/MinGW/bin/gcc.exe -- works
 -- Detecting C compiler ABI info
 -- Detecting C compiler ABI info - done
 -- Check for working CXX compiler: C:/dev-env/apps/MinGW/bin/g++.exe
 -- Check for working CXX compiler: C:/dev-env/apps/MinGW/bin/g++.exe -- works
 -- Detecting CXX compiler ABI info
 -- Detecting CXX compiler ABI info - done
 -- Check for installed OpenGL -- found
 -- Check for installed Expat -- not found
 CMake Error at CMakeModules/CheckFindPackageResult.cmake:6 (message):
  Expat was not found - it is required to build Kicad
 Call Stack (most recent call first):
  CMakeLists.txt:134 (check_find_package_result)
 
 
 CMake Error: The following variables are used in this project, but
 they are set to NOTFOUND.
 Please set them or make sure they are set and tested correctly in the
 CMake files:
 EXPAT_INCLUDE_DIR (ADVANCED)
   used as include directory in directory C:/dev-env/src/kicad/kicad
 
 -- Configuring incomplete, errors occurred!
 
 See my earlier explanation about how QUIET and
 check_find_package_result() work together. Just a bit of rejigging
 required and it'll work how you want it to.
 
 Best Regards,
 
 Brian.
 
 On 15 October 2010 00:17, Brian Sidebotham brian.sidebot...@gmail.com wrote:
 Hi Martijn,
 
 I don't think this patch is correct. You have made the build alter if
 expat is found as a system library. In this case you add the system
 expat library to the linker. The trouble is, although I have a system
 expat, I compile wxWidgets to use its own implementation as I'm sure
 this is the more thoroughly controlled code path (less susceptible to
 bugs).
 
 Instead, you could check for just the component expat for wxWidgets,
 and only if you cannot locate expat shoudl you then do the sys expat
 check and conditionally add the expat library link option, and then
 continue on to check for the full list of other wxWidgets components.
 
 QUIET does not mean not required - it just means do not fail at this
 point, and do not print messages to the screeen. This is important,
 although most checks in the KiCad cmake files are straight forward. A
 patch I put together the other day would require this operation. It
 was along the lines of:
 
 ---
 
 find_package(wxWidgets COMPONENTS gl adv html core net base xml QUIET)
 
 # On a windows console (i.e. not MSYS), a monolithic build cannot
 detect other components,
 # only gl and mono can be detected
 if(WIN32)
if(NOT wxWidgets_FOUND)
find_package(wxWidgets COMPONENTS mono gl QUIET)
endif(NOT wxWidgets_FOUND)
 endif(WIN32)
 
 ---
 
 If REQUIRED was used, it would have failed before doing the
 exceptional check for the win32 monolithic build. KiCad uses this
 method, and then fails through the check_find_package_result() method
 if needed after all possible checks have been run. This is a neat way
 of handling multiple checks. You can find the
 check_find_package_result() cmake macro under the CMakeModules
 directory of the kicad source.
 
 This is only my opinion of course, others might expand on this or
 approve it and tell me to shut up! ;-)
 
 Best Regards,
 
 Brian.
 
 On 14 October 2010 12:10, Martijn Kuipers martijn.kuip...@gmail.com wrote:
 Dear Devs,
 
 Kicad has a dependency on expat. It can either be provided by expat or by 
 wxWidgets. However, cmake does not look for expat and as such if not found, 
 a linker error occurs (which is bad, since it happens near the end of the 
 building process).
 
 This patch adds a non-required dependency on expat (since it can be 
 provided by wxWidgets) and if it finds the library it adds it to the linker 
 flag (-lexpat). If the library is not found, it is added as a component to 
 wxWidgets library.
 
 This patch allows me to build kicad, with the system provided library for 
 expat. I have tested this on OSX, but I think it is needed on all platforms.
 
 
 Note, all dependencies in the CMake files are of type QUIET, which means 
 not required.  It also means, the compiler will try to build kicad, whether 
 it finds the libraries or not. From a quick look it might make sense to 
 make wxWidgets REQUIRED and to make expat REQUIRED if it is not provided by 
 wxWidgets. This is not added to this patch, because I would like to hear 
 your opinion on this first.
 
 /Martijn
 
 
 

Hi Brian,

I already had a suspicion my patch was not complete. 
I was hoping to achieve that cmake does all the dependency checks and then 
decides if there is enough to build it or to ask for other

[Kicad-developers] [PATCH] wxLOCALE_CONV_ENCODING null-pointer exception with debug enabled

[Martijn Kuipers]

Dear Devs,In order to debug Kicad I have enabled DEBUG for both wxWidgets and Kicad. Both compile fine, but when any component from Kicad is executed a warning about wxLOCALE_CONV_ENCODING pops up. You can safely "cancel" this, but then it segfaults on a debug message and only if the default locale cannot be found. As you guessed it, this is the case on my system.Simply changing the messages makes the segfault go away. This patch makes 2 small changes:1. It useswxLOCALE_LOAD_DEFAULTinstead ofwxLOCALE_CONV_ENCODING,which is being deprecated (see http://trac.wxwidgets.org/changeset/65634)2. Change the wxLogDebug message to not include the member 'm_LanguageId'as it can be NULL.Only the first change can have an effect for release-builds, but since it is being deprecated we might as well solve it now./Martijn

wxdebug-locale-exception.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] [PATCH] expat dependency for cmake

[Martijn Kuipers]

Dear Devs,

Kicad has a dependency on expat. It can either be provided by expat or by 
wxWidgets. However, cmake does not look for expat and as such if not found, a 
linker error occurs (which is bad, since it happens near the end of the 
building process). 

This patch adds a non-required dependency on expat (since it can be provided by 
wxWidgets) and if it finds the library it adds it to the linker flag (-lexpat). 
If the library is not found, it is added as a component to wxWidgets library.

This patch allows me to build kicad, with the system provided library for 
expat. I have tested this on OSX, but I think it is needed on all platforms.


Note, all dependencies in the CMake files are of type QUIET, which means not 
required.  It also means, the compiler will try to build kicad, whether it 
finds the libraries or not. From a quick look it might make sense to make 
wxWidgets REQUIRED and to make expat REQUIRED if it is not provided by 
wxWidgets. This is not added to this patch, because I would like to hear your 
opinion on this first.

/Martijn



cmake-expat-dependancy.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] exploiting human readability

[Martijn Kuipers]

On Oct 8, 2010, at 8:00 AM, Dick Hollenbeck wrote:

 
 I got my mind around the parts list tonight.
 
 Conceptual clarifications below:
 
 
 The component is located and rotated [and mirrored] when it is
 instantiated within a part.
 
 
 class PART
 {
COMPONENT* component// points into the parts list
 
POINT pos;
 
wxString  reference;
 
int angle;
 }
 
 
 
 
 The class PART needs to have the (x,y,angle) coordinates for the fields,
 which reside in the parts_list components.  So you can move the fields,
 but not edit them.
 
 You want unique fields? Then make a new parts list entry.
 
 This ensures the BOM falls out clean as a whistle.
 
 
 class FIELD_USAGE
 {
int xoffset;
int yoffset;
int angle;
bool visible
font type ?
color ?
 }
 
 
 Add a std::vectorFIELD_USAGE  to class PART above.  This gives you an
 instantiation specific ability to move the fields, spin them, hide them,
 and change font.  You cannot change the field values in the instance,
 except for the reference, which is technically no longer a field.
 
 
 
 
 Parts List, further clarifications:
 --
 
 A parts list is an internal spread sheet, with columns, and has a
 spreadsheet UI in eeschema.
 
 
 The columns dictate the fields within all the components in the parts list.
 If a user adds a column, all components get that field in the same
 sequence.  All fields are in the same sequence.  All components have the
 same number of fields.
 
 Some columns are mandatory to mimic the current mandatory fields.
 
 We add a new boolean mandatory field called DNS. It only takes true or
 false as a value, say a check box.
 
 The parts list is a spreadsheet, with columns.  It is is a library
 source, but for this particular schematic, it is an instantiation factory.
 
 Nothing can be instantiated in a schematic that is not in the parts list.
 
 All schematic pages/sheets are in one file, along with the parts list.
 
 Fields cannot be inherited as they are dragged from another library
 source into the parts list, they are copied, along with their initial
 values.  So the sweet little language we have been dreaming up cannot
 support (field_delete) or (field_swap) or anything like that with
 respect to fields.
 
 Why?
 
 The only fields that are actually in affect at any point in time are
 those belonging to components in the parts list.  Because you cannot
 instantiate anything else.  You first have to drag your component into
 the parts list.  The origin can be any library or another row in the
 same parts list.  The latter situation arises when you have multiple
 resistor values and want the same resistor symbol but with a different
 value.  Using the spread sheet UI, you can add fields instantaneously to
 all components in the parts list simply by adding another column.
 
 When the parts list is saved as part of the schematic, you see a region
 in the massive, multi-sheet schematic file called a parts_list:
 
 (parts_list
  (columns   # superimposed onto all components contained, as user defined 
 fields
(column Optional1)
(column Optional2)
  )
  (library
(component (stuff true) (field datasheet rj11.pdf) (field value 
 RJ11)..(field Optional1 digikey) (field Optional2 ABC))
(component (stuff true) (field datasheet Yageo.pdf) (field value 33ohm) 
 (field Optional1 mouser) (field Optional2 DEF))
  )
 )
 
 
 The coolest thing about the parts list, other than direct BOM creation,
 is that you will probably use them to house your library source(s).  You
 can create a dummy schematic, maybe use sheets therein to categorize
 visible instances of the components within the parts list.  That dummy
 schematic can then be loaded as a library source while editing a
 functional other schematic file, but the first is a read only library
 source in such a situation.
 
 
 This was the last conceptual hole that I had to fill.  If you can
 already see that I am missing something that will lead to this being
 unworkable, please yell.  I will start on the *.h file soon.  It might
 shine light on other holes, but also make things clearer for some.
 
 
 Dick


My understanding is that a:
- components are those things you find in the catalogues, e.g., 74LS00
- parts are those things you find in your schematic, e.g., IC1 (which could be 
74LS00)

Perhaps we should not talk about parts-list, but use BOM instead.

Perhaps you already mentioned this, but I just did not understand it.
There is a base-component library. These are just files with components, that 
are maintained at kicad-website, but it is ok to have a local copy. Since this 
is a central repository, local copies are read-only or you will loose all 
additional information on an update.

Is there a way to maintain local information with the components that is not 
lost after an update? Is this even possible? I think it is.

I have my preferred footprints with most components, so it would be nice if I 
could add the 

Re: [Kicad-developers] [PATCH] Ortographic mode for 3D viewer and minor cleanup

[Martijn Kuipers]

On Oct 7, 2010, at 15:03 PM, Dick Hollenbeck wrote:

 On 10/07/2010 07:50 AM, Alex G wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 10/07/2010 08:53 AM, Dick Hollenbeck wrote:
 
 Alex,
 
 congrats on your patch getting accepted and applied!
 
 I have just a few comments below that will make your next patch even better.
 
 Thanks,
 
 Dick
 
 
 Dick,
 
 Thanks for the confidence. :)
 I'm looking forward to making more contributions in the future,
 hopefully, of more value. Although my narrow experience makes tasks such
 as working on the new library structure seem daunting, I'm constantly
 looking for something I can improve.
 
 
 We'd like to see you contribute more.
 
 On the enums' commas, I usually leave them in there with the notion that
 you will be adding more and, why waist the time to go back and add that
 comma to extend the list?
 
 The language designers thought the same thing after a point.  This was
 not originally in the language and they it added after somebody asked
 for it.
 
 So now comes the compiler developer, who probably does not have as much
 experience as the language designer, and ties that warning to a
 -pedantic flag.  That is fine, since he also gave you the ability to
 turn off warnings on a case by case basis, which what I would suggest
 you do.  (Whatever way you are controlling the compiler flags.  I just
 let the cmake script do that for me.)
 
 It is part of the language, and many experienced programmers utilize it,
 and any compiler supporting C++ should handle it without voicing an
 opinion on it if asked to be quiet about it.
 
 And I cannot believe I actually spent all the time to write this.
 
 But getting you to contribute more is worth it.  Keep up the good work!
 
 Dick

If you want to silent it use:
-std=c99 -pedantic

without the std option gcc uses the more pedantic c89 specs

/Martijn

 
 
 
 I would like to explain why I made some modifications that are more or
 less debatable. I am not trying trying to prove that I am right, just to
 share some thoughts.
 
 I compile with -pedantic. I made this habit while working on a
 cross-platform HPC project. -pedantic made sure that the code would work
 with other compilers (including MSVC++), but also caught a lot of small
 mistakes that could cause the program to segfault. I find it a very
 useful tool. Although a very anal one, I find its benefits greater than
 the sum of its deficiencies.
 
 When I first built kicad with -pedantic, the number of warnings I got
 made it impossible to catch the meaningful ones. The extra , at end of
 enumerator list was one of the more common ones. While the lack of ,
 is noise for you, its presence is noise for me. I believed that removing
 it would not cause any stir.
 
 
 Looks like you had one to many spaces on these lines, should have been 4.
 
 
 Sorry about that. Careless mistake on my part.
 
 
 Spelling error in ortographic
 
 
 Careless mistake again.
 
 
 Please put a blank line above comments if comments are only thing on
 that line and they are not a comment continuation.
 
 
 needed a blank line here, above the single line comment.
 
 
 Of course.
 
 
 No need for this edit, last enum can have a trailing comma just fine.  I
 write code like that.
 
 ditto, leave the comma in, this edit is noise.
 
 More noise, and more noise many times below that I do not mention again.
 
 Noise.
 
 
 - -pedantic made me do it. I'm innocent :P
 
 
 The space between \n E is not needed, removing the \ before the E was a
 good edit.
 
 - -pedantic pointed me to this :)
 
 
 selection spelling
 
 
 +int   m_Selected_Tool;  // Pour editions: Tool 
 (Dcode) selectionn�
 
 
 Didn't catch that. I had some files that KDevelop was complaining about
 the encoding, and this was one of them. I failed to see why the
 complaint occurred, and as a result, failed to see the horrible monster
 I had created. I apologize about this.
 
 
 comment start is off by one:
 
 
 +FILLED_WITH_BG_BODYCOLOR/* Poly, Square, Circle, Arc = option Fill
   * with background body color, translucent
   * (texts inside this shape can be seen)
   * not filled in BW mode when plotting or
 
 
 Careless mistake.
 
 
 These were my printf()s and I can assure you that nobody else needs them
 except me.  I like printf() as a better IO model than std::out 
 
 
 Some pedantic warnings as well led me here. I thought that std::cout
 might be better because of stronger type-safety. If you use %p, can you
 please cast the pointer to (void *) ? It fixes the -pedantic warning.
 
 
 So please don't do this in the future.  
 
 I don't understand why printf() is preferred over std::cout in C++ code,
 but I will comply.
 
 Alex
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)
 Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
 
 

Re: [Kicad-developers] exploiting human readability

[Martijn Kuipers]

Hi,

On Oct 5, 2010, at 19:26 PM, Brian Sidebotham wrote:

 On 5 October 2010 15:33, Dick Hollenbeck d...@softplc.com wrote:
 
 I get paid to brainstorm, so brace yourself.
 
 Continuing with library brainstorming, the following is put on the table
 for consideration and eventual evaluation. Brace yourself, this is out
 of the box.  Open up your mind before proceeding.
 
 Remember the HTML editors which let you view HTML source and the
 resultant GUI presentation at the same time?  One panel has the html
 source, another shows you its effects.  The following concepts use that
 UI paradigm.  Use the source Luke, use the source.
 
 
 A library is not a library file:
 ---
 
 The concept of a *library file* is gone.  There are none.  The concept
 of a library can still exist but it is a RAM resident concept.  Each
 component that we traditionally think of residing in a *library file* is
 actually in its own file on disk in a directory (or repo or schematic).
 A library is only built in RAM during the loading of a collection of
 components.

I think this would be great. Does this mean we get 3 sorts of files?
symbol, footprint and part-files?
(symbol, e.g., a resistor, 
component, e.g., a 10k 5% resister of .25W with footprint R025W 

Part-files can be project specific or general. Parts can be created 
automatically when needed and in the simples form only has 2 include-lines (and 
perhaps a part-number, e.g., R1). You could add lines if you want gate-swapping.


 
 
 Loading components:
 --
 
 The act of loading components utilizes the notion of inheritance and
 classical file inclusion like the C++ #include.  Let's go back an
 understand inheritance thinking about Java. In a Java virtual machine
 each class definition container has a method table.  That table is
 initially populated with methods from the base class.  As the base class
 is extended some of those methods are overloaded (replaced) with ones
 from the derived class in the internal method table.  Additional fields
 can be introduced in derived classes also, into what is a field table
 for that class.  Now lets move that conceptual model to a component.
 Lets assume we have a pin table, and a graphics table.  We give a
 component the ability to inherit from: 1) a base code fragment,  or 2)
 symbol or 3) component.  In this case you can do pin additions, or pin
 modifications, pin swapping, in the same way you can overload a Java
 class's method table.  Pins can be overloaded or replaced, and graphical
 primitives can be inherited and extended.
Would we really need base-symbols and base-footprints? Meaning, do we want 
symbols that are derived from other symbols? Why not flatten all symbols and 
footprints? I *think* this would be much easier to use and maintain.

A part would be derived from both a symbol and a footprint, and you can 
overload some parts (e.g., which NAND to use in the 74LS00). Symbols could 
already be linked to footprints, such that when you select a symbol you get a 
list of footprints (you should be able to override this).

 
 The magic happens during the loading phase of the S-expressions, so that
 the built up component is fully assembled in RAM by using pieces from
 various places out there, while *loading*.
 
 If desired, the various pieces can be ear-marked with their origins in
 full recognition of the existence of inheritance.  One might do this
 only to facilitate graphical editing of a derived component, although if
 the grammar is sweet enough, textual editing may be enough for all
 editing of derived components.
 
 Re-loading is simply done by clicking a parse or show button.  The
 the parser reloads the source stream and does file inclusions as called
 for.  A portion of that source stream comes from the textual UI panel.
 Inherited portions come from a library (which is now a RAM resident
 concept only).
 
 
 Example
 ---
 
 (component SOMENAME
  # inherit is like C++'s #include
  (inherit SOMEOTHERNAME WHERE)
  (pin 12 ... WHERE...ORIENTATION)
  (pin 13 ... WHERE...ORIENTATION)
  (pin 14 ...)
 )
 
 Pin 12 and 13 are provided here and they are overloads because 12 and 13
 have already been defined in SOMEOTHERNAME.  So this could be the means
 of a *pin swap*.   However pin 14 is new, since SOMEOTHERNAME did not
 have one, so this is an extension. In one example we see both a)
 overloading and b) extension.
 
 This example would be a new SOMENAME component, and its graphics are
 fully inherited from SOMEOTHERNAME, and can be extended here, but not
 overloaded in any way that I can think up.
 
 
 Where do they come from? and component versioning:
 -
 The ability to reference an external component by a GUID (globally
 unique ID) of some kind lets you pull in components from anywhere in the
 world.  A GUID inherently needs to respect versioning.  That is to say,
 if you make an edit to a component that somebody else 

Re: [Kicad-developers] library structure

[Martijn Kuipers]

On Sep 23, 2010, at 1:09 AM, Wayne Stambaugh wrote:
 symbol - The graphical and/or electrical representation of a component.
 Think everything between DRAW/ENDDRAW in the current file format.
 
 field - The default and user defined text values that describe a
 component such as value, reference designator, footprint, etc.
 
 component - The combination of default and user defined fields and a
 symbol that get imported into a schematic.
 
 library - One or more components along with some meta-data to describe
 the library.
 


When drawing a schematic everything is easy when using components, especially 
using user-defined libraries. Does this mean that Kicad will ship with a large 
set of (component-) libraries? Or, will every user need to start creating his 
own, from symbols (is there a symbol-library foreseen?)? 

Will the component-library also have a reference to (default) footprint(s)? 
Related to this, if a component is available with different footprints are they 
different components, or the same component with a reference to multiple 
footprints? If the latter is true, then one could easily choose another 
footprint in newPCB, for instance.

/Martijn
P.S. What is the preferred option regarding the mailing-list. Do I reply to the 
author and CC the list or just reply to the list (if someone is not subscribed 
to should then ask to be CC-ed) ? 





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

[Martijn Kuipers]

On Sep 23, 2010, at 13:29 PM, Wayne Stambaugh wrote:

 On 9/23/2010 4:12 AM, Martijn Kuipers wrote:
 
 On Sep 23, 2010, at 1:09 AM, Wayne Stambaugh wrote:
 symbol - The graphical and/or electrical representation of a component.
 Think everything between DRAW/ENDDRAW in the current file format.
 
 field - The default and user defined text values that describe a
 component such as value, reference designator, footprint, etc.
 
 component - The combination of default and user defined fields and a
 symbol that get imported into a schematic.
 
 library - One or more components along with some meta-data to describe
 the library.
 
 
 
 When drawing a schematic everything is easy when using components, 
 especially using user-defined libraries. Does this mean that Kicad will ship 
 with a large set of (component-) libraries? Or, will every user need to 
 start creating his own, from symbols (is there a symbol-library foreseen?)? 
 
 I doubt Kicad will ever ship with a large set of manufacturer specific
 component libraries.  I think the main goal is to provide a quality set of
 generic libraries and hope that as users create more complete component
 libraries that they make them freely available for others use and/or modify.
 Once these libraries mature, they could be added to the list of libraries
 included with Kicad.
That was what I was hoping for.


  As for symbol only libraries, I'm not sure we will need
 them if we provide copy/paste into the component library editor.
Sounds good.

 
 
 Will the component-library also have a reference to (default) footprint(s)? 
 Related to this, if a component is available with different footprints are 
 they different components, or the same component with a reference to 
 multiple footprints? If the latter is true, then one could easily choose 
 another footprint in newPCB, for instance.
 
 I don't see any reason why the footprint field could not used to define wild
 cards for pattern matching or multiple footprints when creating generic
 components such as 7400 or RESISTOR similar to what we have already.  You 
 could
 just as easily create manufacture specific component using the full part 
 number
 as the value field which would be tied to a specific footprint.
Ok.

 
 
 /Martijn
 P.S. What is the preferred option regarding the mailing-list. Do I reply to 
 the author and CC the list or just reply to the list (if someone is not 
 subscribed to should then ask to be CC-ed) ? 
 
 Generally speaking you should reply to the list.  I only email someone 
 directly
 regarding a matter that does not require input from all the Kicad developers.
Done!

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

Re: [Kicad-developers] OSX Installer debate

[Martijn Kuipers]

On Sep 14, 2010, at 10:17 AM, Vesa Solonen wrote:

 On Mon, 13 Sep 2010, Martijn Kuipers wrote:
 
 On Sep 13, 2010, at 18:42 PM, Jerry Jacobs wrote:
 
 Also there are still some odd things when using Kicad on OSX for example
 the viewport is damn slow of PCBnew. But it is usable and functional.
 
 This is probably due to the fact that the cocoa-port of wxWidgets is not yet 
 complete. Will try to look into it, time permitting.
 
 Before barking at the wxWidgets, it may be of value to look at KiCad drawing 
 code.
I did not want to bark at all. Whenever I need some wxWidgets for OSX I am told 
by the wxWidgets-lists that the OSX (cocoa) is not complete and not optimal. 
Sorry if it sounded like I am blaming wxWidgets only, not my intention at all.


 The drawing is damn slow on every platform that does compositing and 
 buffering properly - OSX and Win upwards Vista. On linux it depends on 
 everything, but proper buffering is not ususally done and the flicker is very 
 annoying. Some performance improvements are on the way from Brian F. Biduloc 
 and kicad-gal from Thorsten. I have no experience or skills to implement 
 these, but from the tests it's evident there is some fondamental mismatch 
 between KiCad drawing code and current graphics technologies. With new vector 
 font the drawing problems begin to show even on schematics with lots of text 
 (vertices).

Thanks for the explanation.


 
 My main platform is Linux, so there may be some pessimism regarding graphics 
 ;) For example Freeroute on IcedTea runs really fine as long as the window is 
 minimized, but saturates X as soon as something needs to be drawn. Sun Java 
 works _very_ much better, even though it probably does all drawing on the cpu.
 
 If you find something that makes KiCad on OSX work well, it probably helps on 
 every platform.
I thought it was just an OSX problem, guess not.


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

Re: [Kicad-developers] OSX Installer debate

[Martijn Kuipers]

Please use reply-all to keep the messages on the list

On Sep 14, 2010, at 19:49 PM, Karl Schmidt wrote:

 
 On Sep 14, 2010, at 10:17 AM, Vesa Solonen wrote:
 The drawing is damn slow on every platform that does compositing and 
 buffering properly - OSX
 and Win upwards Vista. 
 
 Just don't have any problem with flicker  -- OTH I played  OSX on a tablet - 
 other than multi touch I'm not at all impressed -- there are lots of graphics 
 compromises that most people are not even aware of.
 
 I would hope that OSX support does not become a distraction to the other work.


I play OSX every day on my MacBook and it is by far the best laptop I have 
ever had. Why I use Kicad, even though there are more mature tools out there, 
is that I work in a mixed OS environment. I myself use OSX and Linux, but have 
coworkers with Windows and we all need to work together. Kicad allows this just 
fine.

I doubt OSX support will become a distraction. I started this thread to see how 
to best package Kicad for OSX. In time I hope to be able to improve other 
parts, but  I don't have much need for many features.

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

Re: [Kicad-developers] OSX Installer debate

[Martijn Kuipers]

On Sep 13, 2010, at 16:13 PM, Dick Hollenbeck wrote:

 On 09/13/2010 10:01 AM, Martijn Kuipers wrote:
 On Sep 13, 2010, at 15:20 PM, Dick Hollenbeck wrote:
 
 
 On 09/13/2010 08:53 AM, Martijn Kuipers wrote:
 
 How do we want the OSX packages to look like (installer) ?
 At the moment we have a DMG-generated from scripts and one generated with 
 CPack (I patched my CMakeList.txt with the patch from Jerry floating 
 around on the list).
 
 Neither are satisfactory, in my opinion.
 
 Let me explain:
 If we add docs and libraries to the DMG file, then it is no longer 
 DragDrop. 
 Normally you drag the application (on our case the Kicad folder with all 
 applications) to the Applications link, which are both shown by the 
 installer in the finder. However, if we also include libraries in the DMG, 
 then these need to be installed in /Library/Application Support/kicad or 
 in $HOME/Library/Application Support/kicad (according to Marco). We don't 
 want the user to drag them into the applications.
 
 I see 2 posible solutions:
 1. Use packagemanager, which allows more complex installs. Disadvantage is 
 that you have no clue what is installed where and since there is no 
 uninstall I think it's rather messy.
 2. Split the libraries and applications in separate DMGs. I personally 
 like this option, since it allows you to easily update either Kicad or the 
 Libraries. Not sure what to do with docs. Can we put them in a sub-folder 
 in the Kicad folder under applications? Same with scripts ?
 
 I would love to hear your opinions on this. 
 
 /Martijn
 
 
 There are two classes of users:
 
 1) those that install from a pre-built package.
 2) those that install by building the source themselves.
 
 In the linux world there is a package manager person for each distro,
 and he is responsible for users in class 1) on his distro.
 So I actually think you should be talking to those people for that
 category of user.
 
 Sure. For Kicad who is the OSX package manager? I hope (s)he is reading this 
 list. As for Linux, I think Kicad ought to provide a static-version (should 
 fit most distros). Of course, if someone wants to add deb, rpm, etc., then 
 that is fine with me, it is just more work because of the version 
 dependancies between the different components. Wrapping a static-package 
 inside deb or rpm is not a good solution (my personal opinion).
 
 
 
 For category 2) users, I see no reason why cmake and/or one of its
 sibling programs cannot be used.  This makes it easier for those of use
 that do not use OSx to stay in the conversation.
 
 I don't object to cmake at all. I think the DMG is not as nice as it could 
 be, but I have not spend much time looking at all the options CPack gives 
 you.
 
 If there is an area where Win/Linux/OSX can be different, it is in the 
 installers. And my questions were solely related to the OSX installer, where 
 I don't think the split I mentioned is so different from what we have now.  
 I don't think there are libraries included in the kicad source, they are in 
 kicad-lib-committers/kicad/library. 
 
 My suggestion would be to create 2 installers;
 - Kicad application
 - Libraries (with Libraries I mean eeschema components, footprints, 
 packages3d and modules). The name is confusing, but I did not mean things 
 like wxWidgets, Boost, etc.
 
 I am a User 1 type, if I can find a recent enough version, otherwise I am 
 User 2. But even as User 2 I prefer to create packages and then install 
 those. 
 
 /Martijn
 
 
 Sorry, I still don't understand what problem you are trying to solve. 
 Maybe one problem at a time would be best in your communications.
Sorry, I'll try to be more clear. It is one problem only, really.
 
 Have you looked at the debian package maintainer strategy?  I think you
 can download the debian package builder scripts.  It was Richard Burton
 who was maintaining that package and we had heard he wanted out because
 of medical school demands.
 
 He splits up the entire project into a number of packages like you
 suggest.  But he uses some shell scripts and cmake scripts to do it.
You are right, this is very similar to what I suggested. 


 I think if you clarify and shrink down the specif problem you are trying
 to solve, then maybe you will get more helpful feedback from others.
Perhaps you are not familiar with the OSX installation process. It is extremely 
simple. You drag the application into the Applications folder and you are done. 
Uninstalling is simply done by deleting the application. OSX does not have the 
wonderful install/uninstall/upgrade/solve dependencies of Debian (I am huge fan 
of Debian and it is my only OS next to OSX). 
However, its simplicity only works for single programs, where everything is in 
one place. Not something like Kicad, where the libraries (components, 
footprints, etc) are shared among the programs.  Why? Because you would need to 
move the different parts to different locations manually. The new 
package-system solves

[Kicad-developers] OSX: Where to store the libraries and modules

[Martijn Kuipers]

I managed to create the DMG-files for kicad on OSX. Next I wanted to add the 
libraries, but where should they be stored?

Are
 /Users/Share/Kicad/Libraries
and
 /Users/Share/Kicad/Modules

the right place?

The script to build the DMG files creates a name based on the current bzr 
revision id. Probably need to add a flag for release-builds, but that should be 
easy. It also automatically add the COPYRIGHT.txt notice, which pops-up when 
the DMG gets mounted.

I was thinking of using the same dragdrop principle, so you would get 
something like

Kicad  - /Applications

Inside this DMG I would add a Library DMG, which does more or less the same 
thing

LibsMods - /Users/Share/

If it gets decided to use CPack, then I will just think of this as nice 
exercise. I just think/feel that these scripts are more flexible.

Comments are welcome.

/Martijn
___
Mailing list: https://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] Compiling fails on XML class on Apple OS X with wxWidgets 2.9-svn - Part 2

[Martijn Kuipers]

On Sep 7, 2010, at 18:13 PM, Martijn Kuipers wrote:

 
 On Sep 7, 2010, at 17:48 PM, Martijn Kuipers wrote:
 
 
 On Sep 7, 2010, at 17:13 PM, Dick Hollenbeck wrote:
 
 On 09/07/2010 04:41 AM, Martijn Kuipers wrote:
 Dear list,
 
 I just encountered the same problem as Jerry compiling Kicad on OSX with 
 wxWidget SVN (around 2.9.1), see here:
 https://lists.launchpad.net/kicad-developers/msg05158.html
 
 It is exactly the same error, which is not weird as I followed his 
 instructions to the letter.
 
 Jerry, anyone: Did you figure out how to solve this? 
 
 Cheers,
 Martijn
 
 
 I think there could be a bug in the wxWidgets build and install script
 and/or package for your OS (and possibly linux).
 
 If you do a
 
 $ cd /svn/wxWidgets
 
 $ find . -name '*expat*'
 
 
 you see that wxWidgets is nesting a SVN checkout of expat into their tree.
 
 Yet who installs this library?   I think the problem is basically that
 expat is not being installed, simple as that.
 
 IMO the problem in is in the wxWidgets *package* for your OS (and
 linux), which should probably have a dependency in it for expat.
 
 Dick
 
 
 Thanks, that sounds plausible. But then we can use xml builtin. So I just 
 compiled wxWidget from SVN with the following line:
 
 ./configure --enable-unicode=yes --enable-shared=no --enable-monolithic 
 --with-opengl   --enable-aui --enable-debug --with-expat=builtin 
 --with-osx_cocoa   --with-macosx-sdk=/Developer/SDKs/MacOSX10.6.sdk/ 
 --prefix=/opt/wxwidgets-svn
 
 I then did a clean checkout of kicad-svn and only had to add the ASSERT line
 
 CMAKE_CXX_FLAGS:STRING=-D__ASSERTMACROS__
 
 And it compiles fine. I only see 2 warnings:
 1. ld: warning: in 
 /System/Library/Frameworks//QuickTime.framework/QuickTime, missing required 
 architecture x86_64 in file. 
  But that's apple's fault for not providing the x86_64 stuff.
 
 2. ld: warning: option -s is obsolete and being ignored
  This is harmless
 
 Perhaps someone can confirm this works for them and then Jerry can update 
 his osx-compiling page.
 
 /Martijn
 
 And here is where I am wrong. 
 I then did a clean checkout of kicad-svn and only had to add the ASSERT line
 
 Kicad in svn from sf is from April. Not what I wanted. Sorry for the noise, 
 continuing now with the correct source :-(
 
 /Martijn

Sorry for so many emails, but I just got the src from bizar and it still works 
:-)
I am running 2010-09-07 BZR 2479

Same strategy used as for the svn-mistake.

/Martijn



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