Re: [Kicad-developers] Some schematics library structure ideas
2015-01-15 20:14 GMT+03:00 Andy Peters de...@latke.net: On Jan 14, 2015, at 7:46 PM, Fat-Zer fatz...@gmail.com wrote: yep, but for user can be able to easily chose it, kicad library should provide them out of the box... And I propouse a way to store them in library more straightforward IMO. I guess I don't see the point. How many components have different symbols? Perhaps passives, where resistors can either be a rectangle or the v^v^v^v we all know and love? Not a lot if we count all the components on the library, but not so few if we will start count them on fingers: Resistors, Polarised capacitors, Fuses, Inductors, logical gates, also it would be nice to have some small warients of some items... yep, but it's a suggestion in case of open hardware environment. It may be usefull in case you are reusing somebody's else workarounds. but it's not a first goal, just a suggestion for a bit more distant future... By the word, I'm not really experienced in that and may be totally wrong. If you are reusing someone else's work, the simplest path is to just use whatever symbol that person chose. Why complicate matters, to little, if any, benefit? May be... as I said I'm not very experienced, so may be it's just my mad fantasy...and it's not a primary goal. Yep... From your words the getting rid of cvpcb sounds great... if you can handle such a work (taking in mind that schematic and footprint library are nearly two different pices of data for now) I, personally, will appreciate it... and I believe it will be appreciated by a lot of other members of the community... I won't have enough time and (honestly speaking) skills to do that on my own... That the symbol libraries and footprint libraries are separate doesn't bother me at all. In fact, I think that it makes perfect sense. How many parts use an SOIC-8 footprint? A zillion. So why carry the footprint around with each of these zillion parts, when each part can just point to a library and a footprint? Off course no... Talking in Chris Giorgi's terminology, but than device and schematic libraries are two different pieces there is no way to create a strong connection between them so we don't have any part library now and I see no way to create it from. In other words now you can nail a footprint to the schematics but it's hard to track changes in the schematic/footprints libraries about the link... I honestly don't see how setting up library _COMPONENTS_ (defined as a marriage between a symbol, a footprint, and something that points to, or is, an orderable part number) just once is more difficult that drawing a schematic with generic symbols and then using an intermediate tool to marry a symbol with a footprint _for each symbol_ and _for each new design_. Sure, the _component_ is represented by a symbol in the schematic library, but in most designs the schematic is the master (the source code, if you will). More difficult for whom? For the user the first variant is definitely much more easy. But for the devs and library team it means to rewrite and _redesign_ the current library structure from scratch. It's a damn great work... Yes, that is... IMO the main audience of the kicad will be hobiest and some more experienced people from openhardware world for the nearest future. So the idea to support there needs doesn't sounds so crazy, isn't it? )) I'm not sure the main audience for Kicad is hobbyists. I can't be the only do it for a living EE who needs a quality EDA package and would like to buy Altium but can't afford it and just simply hates EAGLE. Oh... It seems I've really misestimated the number of such people... ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Boomerang with locale dependent entries in .kicad_pcb
Le 16/01/2015 03:19, LordBlick a écrit : In response to a message written on 16.01.2015, 01:38, from LordBlick: I just discovered that for some reason Pcbnew does not display complete zones in just designed project. Looking into project file: (layers - (0 Gorna jumper) - (31 Dolna signal) (32 B.Adhes user) (33 F.Adhes user) (34 B.Paste user) (35 F.Paste user) (36 B.SilkS user) (37 F.SilkS user) (38 B.Mask user) (39 F.Mask user) (40 Dwgs.User user) (41 Cmts.User user) (44 Edge.Cuts user) ) And then in pycrust: pcbnew.BOARD_GetStandardLayerName(0) u'F.Cu' pcbnew.BOARD_GetStandardLayerName(31) u'B.Cu' What can I do with this mess in file ? Same name are in Areas/Zone, which is IMHO incorrectly. translations are good in user interface, not in project files… Never mind, just test attachment. BTW. I've found, that in GAL mode additional intermediate points between area and subareas are displayed, which seems to be incorrect. See attached image. The pcb file has no issue, no mess. The Layers section is perfectly valid Copper layers can be renamed by the user. Your board is broken: Some zones are connected to nothing. For instance, the main zone has a net name = /GND, and many pads have a net name = GND which is not the same net. -- 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
Re: [Kicad-developers] [PATCH] two minor fixes
Le 16/01/2015 08:14, Mark Roszko a écrit : First patch fixes the Save library file as dialog which had the library extension instead of library extension wildcard used. Second patch fixes a null termination in eeschema/cross-probing.cpp. The char array line is in block scope and is never preinitialized to all 0s. There's also no guarantee for strncpy to actually copy null if size of bytes to read == buffer size passed. We need to set the last byte of line to NULL after strncpy as insurance. Committed. Thanks. -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] The library tables wizard
Ok, I see you have fixed it in rev 5371. But I still see two semicolons in github/github_getliblist.cpp I don't see why there are two. 2015-01-15 22:57 GMT+01:00 Nick Østergaard oe.n...@gmail.com: Ahh, I just found the place. I have attached a patch that removed the extra slash and the extra semicolon. This interface looks much nicer to choose from instead of the browser window. :) Also, on the same dialog/form as the Github Libs List the button called Add FP Library entry does nothing. 2015-01-15 22:50 GMT+01:00 Nick Østergaard oe.n...@gmail.com: Hi Jean-Pierre To me it seems like you have a double semicolor on pcbnew/github/github_getliblist.cpp 104wxString urlPrefix = wxT( https://; ) + repo.GetServer() + wxT( / );; Aslo I geth the following error when trying to fetch. The problem is the two slashes before repos. I could not figure out where those two slashes come from, therefore I have not attached a patch. https GET command failed Cannot get/download json data from: 'https://api.github.com/orgs/KiCad//repos?per_page=99page=1' Reason: 'Not found' 2015-01-15 21:26 GMT+01:00 Miguel Ángel Ajo majop...@redhat.com: As I said on the other email, awesome :-) I’m glad my advice made any sense. And I like your idea of being able to make a local copy via the KiCad plugin, that’s very nice. Miguel Ángel Ajo On Thursday, 15 de January de 2015 at 21:10, jp charras wrote: Le 07/01/2015 23:38, Miguel Ángel Ajo a écrit : Hi Jean Pierre, just an idea for your wizard work: https://api.github.com/orgs/KiCad/repos You could save the need to work with the HTML viewer and pagination problems using the above API endpoint, all the KiCad project repositories are listed into it in json format. Best regards, Miguel Ángel Ajo Your advices are always golden. I added some enhancements to the fp lib table wizard: a button to import and display the full list of these .pretty libs on github (using this URL). * if the current select plugin is the github plugin, one can select some of these libraries and add them to the current table. * if the current select plugin is the kicad plugin, one can select some of these libraries and download them to make a local copy (which is the usual way of work) in corresponding .pretty folders. They can added later to the table after they are downloaded. Testers are welcome -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] more pythonic scripting API for pcbnew
On 15 January 2015 at 10:20, Miguel Ángel Ajo majop...@redhat.com wrote: Yesterday I wrote a proposal for discussion here: http://pads.kicad-pcb.org/p/kicad-scripting-layer (please write your name for your color using the top right icon, so what you write can be identified to you). I tried not to look too much into the original Piers proposal, to do a true top-down design (“how do I like to interact with kicad objects?”) In the end, it looks quite much like Piers proposal, just with the difference of Point/Size objects receiving the unit. I was trying to be as pythonic as possible avoiding set_/get_ methods, and instead rely on attributes and implicit setters/getters. The listed options are not exclusive, just different ways of doing the same. Please feel free to write about other use cases, or copy, paste, then modify my blocks to provide different possible interactions. Best, Miguel Ángel. Miguel Ángel Ajo Hi Miguel, I thought I'd add my thoughts here instead of changing what others have done. I see that someone doesn't like the Point( 10, 10, unit=MM ) paradime for creating a 2D vector. Personally, I prefer that construct compared to the proposed point_mm( 10, 10 ) by quite a long way. But, it's of course a pain to always use unit=MM. Generally we know the units we're going to work with when we start with pcbnew scripting so it would be good to be able to do something like pcbnew.default_units = MM somewhere near the start of the script and then all 2D vectors can be created without the unit=MM additional argument, such as: Point( 10, 10 ) instead. That would make a nicer interface in my opinion. I only had a chance to have a quick look at it. Thanks for getting something together for people to look at. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] more pythonic scripting API for pcbnew
Hi Brian, I see your point, but the problem with that is interoperability, for example if we mix up modules which work with pcbnew, they could change units, and mix them all up. I have proposed on the ether pad to do something like: Point.mm(10, 10), which would, under the hood do: class Point: def __init__(x, y, unit): … @staticmethod def mm(x,y): return Point(x, y, unit=MM) how does it sound? I’m also trying to think if there is any way to handle it within a context, with Units(MM): point = Point(10,10) But I haven’t found how to push the context and make it available to Point.. Miguel Ángel Ajo On Friday, 16 de January de 2015 at 11:03, Brian Sidebotham wrote: On 15 January 2015 at 10:20, Miguel Ángel Ajo majop...@redhat.com (mailto:majop...@redhat.com) wrote: Yesterday I wrote a proposal for discussion here: http://pads.kicad-pcb.org/p/kicad-scripting-layer (please write your name for your color using the top right icon, so what you write can be identified to you). I tried not to look too much into the original Piers proposal, to do a true top-down design (“how do I like to interact with kicad objects?”) In the end, it looks quite much like Piers proposal, just with the difference of Point/Size objects receiving the unit. I was trying to be as pythonic as possible avoiding set_/get_ methods, and instead rely on attributes and implicit setters/getters. The listed options are not exclusive, just different ways of doing the same. Please feel free to write about other use cases, or copy, paste, then modify my blocks to provide different possible interactions. Best, Miguel Ángel. Miguel Ángel Ajo Hi Miguel, I thought I'd add my thoughts here instead of changing what others have done. I see that someone doesn't like the Point( 10, 10, unit=MM ) paradime for creating a 2D vector. Personally, I prefer that construct compared to the proposed point_mm( 10, 10 ) by quite a long way. But, it's of course a pain to always use unit=MM. Generally we know the units we're going to work with when we start with pcbnew scripting so it would be good to be able to do something like pcbnew.default_units = MM somewhere near the start of the script and then all 2D vectors can be created without the unit=MM additional argument, such as: Point( 10, 10 ) instead. That would make a nicer interface in my opinion. I only had a chance to have a quick look at it. Thanks for getting something together for people to look at. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] more pythonic scripting API for pcbnew
In response to a message written on 16.01.2015, 13:09, from Miguel Ángel Ajo: I’m also trying to think if there is any way to handle it within a context, with Units(MM): point = Point(10,10) I think that any similar constructions debate are waste of time. If somebody wants to create some sensible script, then she/he will made own way to ensure using correct units… There is not only right way, there are a number of possible solutions. -- Best Regards, LordBlick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] more pythonic scripting API for pcbnew
In my opinion it’s not a waste of time. A decent API will lead to more standardized scripts, and the people ability to share and look at other’s work. Cheers, Miguel Ángel. Miguel Ángel Ajo On Friday, 16 de January de 2015 at 13:24, LordBlick wrote: In response to a message written on 16.01.2015, 13:09, from Miguel Ángel Ajo: I’m also trying to think if there is any way to handle it within a context, with Units(MM): point = Point(10,10) I think that any similar constructions debate are waste of time. If somebody wants to create some sensible script, then she/he will made own way to ensure using correct units… There is not only right way, there are a number of possible solutions. -- Best Regards, LordBlick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Netnames convention. Was: Boomerang[...]
In response to a message written on 16.01.2015, 09:38, from jp charras: The pcb file has no issue, no mess. The Layers section is perfectly valid Copper layers can be renamed by the user. OK, I'm also wondering about how is possible to achieve and modify list of used layers in python interface. Your board is broken: Some zones are connected to nothing. For instance, the main zone has a net name = /GND, and many pads have a net name = GND which is not the same net. OK, thanks for the tip, I'm tired recently and I am surprised that this had not noticed before. Usually I'm not using cvpcb, so everything of eeschema→→pcbnew goes by netlist. IMHO there's some mess in eeschema: Netnames generated from netlabels(usually yellow) are preceding with additional „/”, although generated ones from Global Labels(usually red in frame with right/left in/out endings, similar to angle bracket) hasn't that preceed… Is here someone, who can explain usability of this ? I like to have netnames exactly, as I name it… I'm checking on that list Checkbox(I don't like any extra, not ordered „/” in net name.) :] -- Best Regards, LordBlick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Netnames convention. Was: Boomerang[...]
Le 16/01/2015 13:38, Daniel Dawid Majewski a écrit : In response to a message written on 16.01.2015, 09:38, from jp charras: The pcb file has no issue, no mess. The Layers section is perfectly valid Copper layers can be renamed by the user. OK, I'm also wondering about how is possible to achieve and modify list of used layers in python interface. Your board is broken: Some zones are connected to nothing. For instance, the main zone has a net name = /GND, and many pads have a net name = GND which is not the same net. OK, thanks for the tip, I'm tired recently and I am surprised that this had not noticed before. Usually I'm not using cvpcb, so everything of eeschema→→pcbnew goes by netlist. IMHO there's some mess in eeschema: Netnames generated from netlabels(usually yellow) are preceding with additional „/”, although generated ones from Global Labels(usually red in frame with right/left in/out endings, similar to angle bracket) hasn't that preceed… Is here someone, who can explain usability of this ? I like to have netnames exactly, as I name it… I'm checking on that list Checkbox(I don't like any extra, not ordered „/” in net name.) :] Like C/C++ variables, there are local or global netnames. Local netnames are prefixed by the name of the sheet path. global netnames are not prefixed All EDA tools I know do that, or something like. And this is not a mess, this is just mandatory. I like to have netnames exactly, as I name it Perhaps you like, but you cannot. At least as long you are using a schematic tool which knows what is a hierarchy and complex hierarchies, and therefore local and global netnames. -- 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
Re: [Kicad-developers] more pythonic scripting API for pcbnew
In response to a message written on 16.01.2015, 13:26, from Miguel Ángel Ajo: In my opinion it’s not a waste of time. A decent API will lead to more standardized scripts, and the people ability to share and look at other’s work. All right, IMHO this could itself be provided at that condition if is not used, there will not be silently consume system resources. Only lest it was made out of such API layer of additional layer of additional layer… Yo dawg! If we want to brag about own scripts, it is possible to create any forum or page to share scripts, no need for this fancy API. Personally, I cured myself from thinking that my script should be attached to the giant, which becomes the KiCad repository. Usually, any amendment affects a small portion of the software, and you have to rebuild the whole, to get the current package. -- Best Regards, LordBlick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] more pythonic scripting API for pcbnew
On 16.01.2015 14:06, LordBlick wrote: In response to a message written on 16.01.2015, 13:26, from Miguel Ángel Ajo: In my opinion it’s not a waste of time. A decent API will lead to more standardized scripts, and the people ability to share and look at other’s work. All right, IMHO this could itself be provided at that condition if is not used, there will not be silently consume system resources. Only lest it was made out of such API layer of additional layer of additional layer… Yo dawg! If we want to brag about own scripts, it is possible to create any forum or page to share scripts, no need for this fancy API. Personally, I cured myself from thinking that my script should be attached to the giant, which becomes the KiCad repository. Dear LordBlick, I'm of quite opposite opinion - all scripts of decent quality should be available in some official repository (whether it will be separate from the main Kicad repo is a different discussion) and possibly packaged with the releases of Kicad. A stable and simple API for scripting, that is independent of the pcbnew's internal storage model is a big step in that direction. To me the discussion if: Point(10, 10, Units=MM) is better than Point.mm(10, 10) or point_mm(10, 10) is a waste of time, because I don't see any of these forms making script development significantly more difficult. Cheers, Tom @Miguel: PS - What do you think about adding a GAL canvas object to the scripting API? It could be useful for footprint/import wizards or other PCB feature generators as a preview window, embedded in a GUI form. I've had in mind a Pythonish SVG graphic importer (see attachment), adding a simple OSHW logo to a Kicad PCB project is quite painful 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
Re: [Kicad-developers] more pythonic scripting API for pcbnew
Why don't we start with a Python repo on Launchpad or GitHub. I'll leave that decision to the Python developers. This way the Python developers can share ideas and contribute their Python expertise. Once a script reaches some level of usefulness and maturity, the script can then be submitted for inclusion in the KiCad source. What do you think? Is there anyone out there who would like to volunteer to lead such an effort? On 01/16/2015 08:35 AM, Tomasz Wlostowski wrote: On 16.01.2015 14:06, LordBlick wrote: In response to a message written on 16.01.2015, 13:26, from Miguel Ángel Ajo: In my opinion it’s not a waste of time. A decent API will lead to more standardized scripts, and the people ability to share and look at other’s work. All right, IMHO this could itself be provided at that condition if is not used, there will not be silently consume system resources. Only lest it was made out of such API layer of additional layer of additional layer… Yo dawg! If we want to brag about own scripts, it is possible to create any forum or page to share scripts, no need for this fancy API. Personally, I cured myself from thinking that my script should be attached to the giant, which becomes the KiCad repository. Dear LordBlick, I'm of quite opposite opinion - all scripts of decent quality should be available in some official repository (whether it will be separate from the main Kicad repo is a different discussion) and possibly packaged with the releases of Kicad. A stable and simple API for scripting, that is independent of the pcbnew's internal storage model is a big step in that direction. To me the discussion if: Point(10, 10, Units=MM) is better than Point.mm(10, 10) or point_mm(10, 10) is a waste of time, because I don't see any of these forms making script development significantly more difficult. Cheers, Tom @Miguel: PS - What do you think about adding a GAL canvas object to the scripting API? It could be useful for footprint/import wizards or other PCB feature generators as a preview window, embedded in a GUI form. I've had in mind a Pythonish SVG graphic importer (see attachment), adding a simple OSHW logo to a Kicad PCB project is quite painful 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] Netnames convention. Was: Boomerang[...]
In response to a message written on 16.01.2015, 14:02, from jp charras: I'm checking on that list Checkbox(I don't like any extra, not ordered „/” in net name.) :] Like C/C++ variables, there are local or global netnames. Local netnames are prefixed by the name of the sheet path. global netnames are not prefixed All EDA tools I know do that, or something like. And this is not a mess, this is just mandatory. I like to have netnames exactly, as I name it Perhaps you like, but you cannot. At least as long you are using a schematic tool which knows what is a hierarchy and complex hierarchies, and therefore local and global netnames. Netlist generator could be merciful to me, when it would not have found hierarchical information sheets. Alternatively in netlist dialog might be included same or similar checkbox as I mention above… ;) Temporary I use some external tools. Why that ? Because local labels takes less place(no additional wire), so with my very small library symbols I can design without hierarchical sheets… ;- -- Best Regards, LordBlick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] more pythonic scripting API for pcbnew
First of all, let me first clarify, we’re discussing two things at the same time: [people scripts (2, 2.1, 2.2)] — [kicad-python-api(1)i] — [C++ swigged-API] 1) Building an API to access the kicad objects in a way that is not tightly coupled to the KiCad internals, and that it’s for consumption from python scripts. This API is to be written in python. I believe this API should live in the kicad repository, even if we iterate first on a separate one. This way, when breaking changes happen in the C++ implementation (interface change, object change, etc..) the API layer can be updated to work with the new C++ interface. 2) Having scripts people build on python to provide specific functions. This could live on a separate repo without risk, since the API contract should not change (unless somehow deprecated). If something becomes really useful for the wide community, of course, it can always be packaged together with KiCad. 2.1) At some point, we could even make a repository available via github, the same way we do for footprints. 2.2) I also find interesting another kind of special functions, not to run standalone from kicad, but to run inside kicad: a) Contextual menu hooks: scripts that can hook certain contextual menus, to provide functions, so users can plug those special functions into kicad. b) Tool bar hooks: To install functions in the toolbar. c) I/O plugins: To write I/O plugins in plain python. I’m replying between lines too- On Friday, 16 de January de 2015 at 15:25, LordBlick wrote: In response to a message written on 16.01.2015, 14:35, from Tomasz Wlostowski: On 16.01.2015 14:06, LordBlick wrote: Dear LordBlick, I'm of quite opposite opinion - all scripts of decent quality should be available in some official repository (whether it will be separate from the main Kicad repo is a different discussion) and possibly packaged with the releases of Kicad. Separate repository seems more sensible. My OS packaging environment (RPM) spends 23 minutes to build every release (without docs and libs) and that amount of time still grows. Every element, which can stand alone, should have separate repo as was done with docs and libs. Build time is painful, but I believe it's something which shouldn’t stop us from adding new functionalities, otherwise we should stop development now ;-) A stable and simple API for scripting, that is independent of the pcbnew's internal storage model is a big step in that direction. To me the discussion if: Point(10, 10, Units=MM) is better than Point.mm(10, 10) or point_mm(10, 10) is a waste of time, because I don't see any of these forms making script development significantly more difficult. That's my appointment too, but possibly haven't found proprietary words… Some of ways comes from Python language specific forms. Ok, let’s not spend more time on that part. :) @Miguel: PS - What do you think about adding a GAL canvas object to the scripting API? It could be useful for footprint/import wizards or other PCB feature generators as a preview window, embedded in a GUI form. It will be great to control fast drawing area from external script. Today I use cairo/gtk to my scribbles. Yes, I totally missed that when using scripting, if you could give me an example of how to instantiate the GAL canvas from a standalone simple wxpython application, that should give me an idea on what do we need to provide from the C++ API layer. I've had in mind a Pythonish SVG graphic importer (see attachment), adding a simple OSHW logo to a Kicad PCB project is quite painful now... Curiously, I'm doing svg import work in python with additional ability to simple edit points position. Screenshot contains yet unfinished UI editor. I have some ideas, eg. a choice to import (DrawPolygon footprint or other draws - arcs, circles segments, zone on board or draw elements on board etc ...) Nice! -- Best Regards, LordBlick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Boomerang with locale dependent entries in .kicad_pcb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 [snip] BTW. I've found, that in GAL mode additional intermediate points between area and subareas are displayed, which seems to be incorrect. See attached image. Hi LordBlick, Thanks for the notification, should be fixed in 5374. Regards, Orson -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJUuUQcAAoJEBRwGu1hpbJ1geAH/RoeKg9sNCj4BWzzWdwwzycx +ugtVeKx75JEV5C3ilRgW6+gecqF+MBfmSWUJ+HWKEAG8KyEOrxzqeVQxZSIhcCv oQShr+1odSHsZkFCXVwwJVBnj7bD2O5P3vWE+jc07ebvF2nkDh42dwT3zeNOslXi soynkApFUvkchuMjguk4BIPVtdOJBdi+lawVglKbtforvnRHQNYfqYZO0nTJG8Y0 oYD9B/tKBxACJPNQhbgizln//0Uo2unXNO/W8ArsPmS0/LvYUUwWMVa2nnMJtlO8 3BPqx31uCMG2b+6/2TRpsHgc93qMKLZX0IUOPQEtJMeQ+MJ5W9xwn2WwqDnkwmU= =LAdP -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] more pythonic scripting API for pcbnew
About units: For me it was a big benefit to be able to just use any 2
element tuple like object for coordinates and sizes, and direct numbers for
other values, and not having to use a conversion to internal units all the
time. I do a lot of my calculations with numpy, so it makes things a lot
easier if numpy arrays can be used directly.
To me it makes most sense to use mm as default unit for the python API, and
convert from inches to mm using a simple inch2mm function.
Furthermore I put my script in a github repository, like Wayne suggested, I
hope this leads to more organized experimenting, please clone and improve.
It can be found at https://github.com/pierstitus/kicad-python
LordBlick, thanks for another improvement to the layer conversion, it is
much better to use the names that are used in the GUI ('F.Cu' instead of
'F_Cu'). It's committed to the github repo above.
Piers
On Fri, Jan 16, 2015 at 5:14 PM, Miguel Ángel Ajo majop...@redhat.com
wrote:
First of all, let me first clarify, we’re discussing two things at the
same time:
[people scripts (2, 2.1, 2.2)] — [kicad-python-api(1)i] — [C++
swigged-API]
1) Building an API to access the kicad objects in a way that is not
tightly coupled to the KiCad internals, and that it’s for consumption from
python scripts. This API is to be written in python.
I believe this API should live in the kicad repository, even if we
iterate
first on a separate one. This way, when breaking changes happen in the C++
implementation (interface change, object change, etc..) the API layer
can be updated to work with the new C++ interface.
2) Having scripts people build on python to provide specific functions.
This could live on a separate repo without risk, since the API contract
should not change (unless somehow deprecated). If something becomes
really useful for the wide community, of course, it can always be packaged
together with KiCad.
2.1) At some point, we could even make a repository available via github,
the same way we do for footprints.
2.2) I also find interesting another kind of special functions, not to run
standalone
from kicad, but to run inside kicad:
a) Contextual menu hooks: scripts that can hook certain contextual
menus,
to provide functions, so users can plug those special functions
into kicad.
b) Tool bar hooks: To install functions in the toolbar.
c) I/O plugins: To write I/O plugins in plain python.
I’m replying between lines too-
On Friday, 16 de January de 2015 at 15:25, LordBlick wrote:
In response to a message written on 16.01.2015, 14:35, from Tomasz
Wlostowski:
On 16.01.2015 14:06, LordBlick wrote: Dear LordBlick,
I'm of quite opposite opinion - all scripts of decent quality should be
available in some official repository (whether it will be separate from the
main Kicad repo is a different discussion) and possibly packaged with the
releases of Kicad.
Separate repository seems more sensible. My OS packaging environment (RPM)
spends 23 minutes to build every release (without docs and libs) and that
amount
of time still grows. Every element, which can stand alone, should have
separate
repo as was done with docs and libs.
Build time is painful, but I believe it's something which shouldn’t stop
us from
adding new functionalities, otherwise we should stop development now ;-)
A stable and simple API for scripting, that is independent of the pcbnew's
internal storage model is a big step in that direction. To me the
discussion
if: Point(10, 10, Units=MM) is better than Point.mm(10, 10) or point_mm(10,
10) is a waste of time, because I don't see any of these forms making
script
development significantly more difficult.
That's my appointment too, but possibly haven't found proprietary words…
Some of ways comes from Python language specific forms.
Ok, let’s not spend more time on that part. :)
@Miguel: PS - What do you think about adding a GAL canvas object to the
scripting API? It could be useful for footprint/import wizards or other PCB
feature generators as a preview window, embedded in a GUI form.
It will be great to control fast drawing area from external script. Today
I use
cairo/gtk to my scribbles.
Yes, I totally missed that when using scripting, if you could give me an
example
of how to instantiate the GAL canvas from a standalone simple wxpython
application, that should give me an idea on what do we need to provide
from the C++ API layer.
I've had in mind a Pythonish SVG graphic importer (see attachment), adding
a
simple OSHW logo to a Kicad PCB project is quite painful now...
Curiously, I'm doing svg import work in python with additional ability to
simple
edit points position.
Screenshot contains yet unfinished UI editor. I have some ideas, eg. a
choice to
import (DrawPolygon footprint or other draws - arcs, circles segments,
zone on
board or draw elements on board etc ...)
Nice!
--
Best Regards,
LordBlick
Re: [Kicad-developers] more pythonic scripting API for pcbnew
In response to a message written on 16.01.2015, 18:10, from Piers Titus van der
Torren:
About units: For me it was a big benefit to be able to just use any 2 element
tuple like object for coordinates and sizes, and direct numbers for other
values, and not having to use a conversion to internal units all the time. I do
a lot of my calculations with numpy, so it makes things a lot easier if numpy
arrays can be used directly.
To me it makes most sense to use mm as default unit for the python API, and
convert from inches to mm using a simple inch2mm function.
Why not use KiCAD internal units ? Any necessary geometric calculation can be
implemented in compiled _pcbnew.so
Also we can look onto Cython…
Furthermore I put my script in a github repository, like Wayne suggested, I hope
this leads to more organized experimenting, please clone and improve. It can be
found at https://github.com/pierstitus/kicad-python
LordBlick, thanks for another improvement to the layer conversion, it is much
better to use the names that are used in the GUI ('F.Cu' instead of 'F_Cu').
As Jean-Pierre Charras wrote in thread nearly, board names for cooper layers may
vary:
brd = pcbnew
pcb = brd.GetBoard()
pcb.SetLayerName(0, 'Top')
True
pcb.SetLayerName(31, 'Bottom')
True
pcb.SetLayerName(32, 'BottomGlue')
False
It's committed to the github repo above.
Thank you for cooperate… :)
--
Best Regards,
LordBlick
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] more pythonic scripting API for pcbnew
Miguel Ángel Ajo
On Friday, 16 de January de 2015 at 20:01, LordBlick wrote:
In response to a message written on 16.01.2015, 18:43, from Miguel Ángel Ajo:
About using mm as the default unit, other people may disagree, we should
provide
facilities to let people specify their unit.
wxPoint and wxSize can be subclassed to allow any arithmetical operation and
unit conversion with propietary methods.
As Jean-Pierre Charras wrote in thread nearly, board names for cooper
layers may
vary:
brd = pcbnew
pcb = brd.GetBoard()
pcb.SetLayerName(0, 'Top')
True
pcb.SetLayerName(31, 'Bottom')
True
pcb.SetLayerName(32, 'BottomGlue')
False
Hmm, that’s an important point for not referencing layers by names
dynamically,
(I was proposing that too)
may be we should be defining a set of 32 constants for the layers we can
reference
and keep up to date with any ID changes at the C++ side. Although I suppose
ID’s
are not
going to change for compatibility reasons.
Seems to be unessary creating independent data. Simply:
lsLayers = tuple([(idl, brd.BOARD_GetStandardLayerName(idl)) for idl in
range(brd.LAYER_ID_COUNT)])
lsCuLayers = tuple(filter(lambda idl, layerName: layerName.endswith('.Cu'),
lsLayers))
Yes, you already told me, but wasn’t the point against using provided names
that they could eventualy change?.
This is why I was suggesting constants. It’s not an awful work ;) but I
understand you may
not want to do it ;)
--
Best Regards,
LordBlick
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
(mailto:kicad-developers@lists.launchpad.net)
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://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] Mirrored printing broken on wxWidgets 3.0.2
I recently discovered that the mirrored printing in Pcbnew is broken on windows. At first I thought it was a 32 bit versus 64 bit issue but I discovered that it is due to the wxWidgets version. When I use wxWidgets 3.0.0, the mirrored printing works fine (at least on 32 bit MinGW builds). Using wxWidgets 3.0.2 breaks the mirrored printing on both 32 and 64 bit builds. Has anybody else noticed this on any other platforms? ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Boomerang with locale dependent entries in .kicad_pcb
In response to a message written on 16.01.2015, 18:02, from Maciej Sumiński: Thanks for the notification, should be fixed in 5374. Seems to be OK, Thank you -- Best Regards, LordBlick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Mirrored printing broken on wxWidgets 3.0.2
Le 16/01/2015 22:03, Wayne Stambaugh a écrit : I recently discovered that the mirrored printing in Pcbnew is broken on windows. At first I thought it was a 32 bit versus 64 bit issue but I discovered that it is due to the wxWidgets version. When I use wxWidgets 3.0.0, the mirrored printing works fine (at least on 32 bit MinGW builds). Using wxWidgets 3.0.2 breaks the mirrored printing on both 32 and 64 bit builds. Has anybody else noticed this on any other platforms? After test on W7, 32 bits, I did not noticed an issue when printing in mirrored mode. This is a bit strange, because the mirroring is made by our printing routines, not by the wxDC. But what is the actual issue? On Windows, the only one issue I am aware of is with Postscripts printers, (and only ps drivers, whith include the pdf virtual printers) is the fact lines (like tracks) have a very small width, near 0. -- 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
