Re: [Kicad-developers] [RFC] Symbol library file format
With the amount of data that KiCad handles performance of particular parser has minuscule impact. File IO delays would thwart any processing time. What Simon talked about is as he said a separate discussion and is orthogonal to the decision of how to define data model and what file format to use. Also I don't agree that there is a dichotomy of "save full memory state" or "save only bare protocol data". There is lots of room for compromise on what things on top of bare data you want to save to disk to speed up restoring full memory state on load. Spatial indexes, if you choose to save them, would have to be described in terms of another structure in the IDL, it's not generator's responsibility to understand what the index represents. But anyway - that's a separate discussion. I understand that you are cautious to bring in new dependency that most devs are not familiar with. Is there anything I can do to break the ice? I was planning to translate the current schematic file format proposal into proto definitions to show how easy they are to use. I could also try to add a cmake target that would compile those proto definitions in ready to use .h and .cpp files. Will you reconsider if I show these examples? Do you have other concerns about requirements that are potentially not met aside from performance? I can try to answer any questions you have. If perf is the only one I could also possibly write some sort of benchmark comparing parsing performance of KiCad's current s-expr parser and protobufs. But that is not a small commitment so I don't want to do it if I can't change your mind. Regards, Andrew On Sat, Jan 5, 2019 at 5:17 AM Wayne Stambaugh wrote: > On 1/3/19 11:24 PM, Simon Richter wrote: > > Hi, > > > > On 03.01.19 19:06, José Ignacio wrote: > > > >> I > >> think useful comments to the proposed format should see beyond the > >> actual low level representation of the data and talk about the overall > >> model being used to store it. > > > > tl;dr: That's a separate discussion. > > > > There are two schools of thought here, one that treats saved data as a > > protocol between two black box instances, and one that treats it as a > > serialization of the internal state. > > > > Both have advantages and disadvantages. The "protocol" approach allows > > changing internals more easily, and gives better compatibility between > > versions as changes to the file format have to be made deliberately, > > while the "serialization" approach gives us load/save basically for > > free, so we need a lot less code. > > > > The "serialization" model also requires us to generate the internal data > > structures from a more constrained language like IDL, as the marshaller > > needs to know when to follow pointers, and what members of an array are > > actually valid. > > > > I'm not sure there are generators that include support for spatial > > indexes, though, which is pretty much a requirement for fast rendering, > > so this is pretty much impossible at the moment, which places us in > > "hand written load/save code" territory anyway. > > > > We have also ignored diff/merge capability so far, which I believe is a > > good thing because it cannot really be done on a textual level (schemas > > are two-dimensional, PCBs are three-dimensional, so there is no normal > > form with a consistent ordering of elements that will make the files > > diffable). > > > > I fully expect both the internal model and the file format to change > > significantly in the coming years as new features are added. The main > > requirement for the file format is that it always needs to be possible > > to read older files in some way, and to recognize when a file is newer > > than the current parser understands. > > > > It might be a good idea to also have an "extension" mechanism, where we > > don't increase the version number when adding a new feature, but rather > > mark files that actually use the new feature, so files written by newer > > versions that don't use one of the newer functions can be read by older > > versions. This would also be another point for "hand written" load/save. > > > >Simon > > > > I've done some more investigation on this and I'm not convinced that > this is any better than our current implementation due to some of the > issues Simon mentioned above. I've also discovered there is also a > significant performance hit[1] with the JSON reader. This is important > due to the overhead required when loading libraries. I appreciate the > information and protobufs are interesting but I am going to stick with > what we have and know versus what we don't know because I don't think we > have the extra manpower to experiment only to find out it doesn't suite > our requirements. > > Cheers, > > Wayne > > [1]: > > https://groups.google.com/forum/#!searchin/protobuf/JSON|sort:date/protobuf/23Slq4AX7oE/xuwQX_ZXAAAJ > > ___ > Mailing list: https://launchpad.net/~kicad-developers >
[Kicad-developers] [PATCH] Remove unused code from legacy_gal
Hi,
Here is a really silly (since it's in legacy code) small patch for
some unused code I was alerted to by Clang. But might as well get it
off my patch stack!
Cheers,
John
From 3f7aaef50dc0cc51d995450c6c6a7c5fca85f8d1 Mon Sep 17 00:00:00 2001
From: John Beard
Date: Fri, 4 Jan 2019 14:20:47 +
Subject: [PATCH] Remove unused VIRT_MIN/MAX from legacy_gal
---
common/legacy_gal/eda_draw_frame.cpp | 7 ---
1 file changed, 7 deletions(-)
diff --git a/common/legacy_gal/eda_draw_frame.cpp b/common/legacy_gal/eda_draw_frame.cpp
index b9a8eba41..1e22efda0 100644
--- a/common/legacy_gal/eda_draw_frame.cpp
+++ b/common/legacy_gal/eda_draw_frame.cpp
@@ -1018,13 +1018,6 @@ bool EDA_DRAW_FRAME::HandleBlockBegin( wxDC* aDC, EDA_KEY aKey, const wxPoint& a
}
-// I am not seeing a problem with this size yet:
-static const double MAX_AXIS = INT_MAX - 100;
-
-#define VIRT_MIN(-MAX_AXIS/2.0) ///< min X or Y coordinate in virtual space
-#define VIRT_MAX(MAX_AXIS/2.0) ///< max X or Y coordinate in virtual space
-
-
void EDA_DRAW_FRAME::AdjustScrollBars( const wxPoint& aCenterPositionIU )
{
}
--
2.20.1
___
Mailing list: https://launchpad.net/~kicad-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 unit test framework
I just did git am 000* and it worked fine for me, on master. On Sun, 6 Jan 2019 at 01:20, John Beard wrote: > On Sat, Jan 5, 2019 at 4:23 PM Seth Hillbrand wrote: > > > Patch 0002 does not apply cleanly to qa/CMakeLists.txt even after > > applying 0001 > > Hmm, that's odd: I can apply this with "git am 0002". I'm applying > on top of 69fc301bf. Where are you applying it to? Do you still have > the triangulation test code in your tree? IIRC there is a conflict in > that file. > > Cheers, > > John > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Pcbnew unit test framework
On Sat, Jan 5, 2019 at 4:23 PM Seth Hillbrand wrote: > Patch 0002 does not apply cleanly to qa/CMakeLists.txt even after > applying 0001 Hmm, that's odd: I can apply this with "git am 0002". I'm applying on top of 69fc301bf. Where are you applying it to? Do you still have the triangulation test code in your tree? IIRC there is a conflict in that file. Cheers, John ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] 5.1 string freeze
I’m not aware of anything pending. Cheers, Jeff. > On 5 Jan 2019, at 21:21, Wayne Stambaugh wrote: > > Is there any reason not to start the 5.1 string freeze? If so, please > let me know. Otherwise we can officially freeze the strings so our > translators can start work towards the 5.1 stable release. > > Cheers, > > Wayne > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] 5.1 string freeze
Am 2019-01-05 16:21, schrieb Wayne Stambaugh: Is there any reason not to start the 5.1 string freeze? If so, please let me know. Otherwise we can officially freeze the strings so our translators can start work towards the 5.1 stable release. For 5.0, the string freeze was RC2. Are we tagging that here as well? There are no string holds from my perspective atm. -Seth ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] 5.1 string freeze
Is there any reason not to start the 5.1 string freeze? If so, please let me know. Otherwise we can officially freeze the strings so our translators can start work towards the 5.1 stable release. Cheers, Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Pcbnew unit test framework
Hi John- Patch 0002 does not apply cleanly to qa/CMakeLists.txt even after applying 0001 -S Am 2019-01-04 09:36, schrieb John Beard: Hi, I have worked out how to do unit tests of the Pcbnew code. The first example test is a pretty unexciting one about the import plugin manager (which is what I was doing at the time). This is followed by a fix for a minor 5.1 bug with a unit test on the logic (numbered NPTH pads in arrays) Also a small bunch of small Boost helpers which should allow to use some nicer boost test code without causing breakage on older boosts. After these patches, there will be 4 unit test executable run by "make test". Cheers, John ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] grammar.c not found,
I've pushed your patch. Thanks for tracking this down John! Best- Seth Am 2018-12-23 16:32, schrieb John Beard: Hi, It seems "make clean" might be the trigger here. The target for the libeval grammar is done with CMake add_custom_command with an OUTPUT. This means the output file will be cleaned on "make clean", but as the grammar.c is not then regenerated by default, it will be missing until checked out from Git. Here's a patch to use add_custom_target instead. Any CMake wizards are invited to criticise if I have misunderstood. At least from my tests, "make clean" no longer removes grammar.c and the target can still be used to (re)generate it. Here's a bug report so we can tie back with the Fixes: line and find this issue in future: https://bugs.launchpad.net/kicad/+bug/1809610 Cheers, John On Sun, Dec 23, 2018 at 1:27 AM Nick Østergaard wrote: Hi Lachlan, Are you sure that your workspace is clean? I don't see any issues on any platform. Nick On Sat, 22 Dec 2018 at 06:53, Lachlan Audas wrote: > > Hi, just pull the lest-est developer build from git-hub for KiCad > and tried compiling it. But but get this Error, missing file "grammar.c" > >kicad-source-mirror/common/libeval/numeric_evaluator.cpp:36:21: fatal error: grammar.c: No such file or directory > #include "grammar.c" > > the 5.0.2 version has the file, but not the developers version > Any one else seen this ? > > Lachlan > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Hoping to contribute but I have some questions
Wayne My prior approach was to 1) verify that the was/is change list produces no errors on the schematic (since it is derived from the PCB there can be discrepancies). 2) if there were no errors, update the PCB and schematic reference designations 3) update the netlist with the new reference designations. 4) direct the user to re-import the netlist, which rebuilds the associations. Obviously 3) and 4) can be problematic for a variety of reasons. What I would propose is to simply regenerate the netlist from within eeSchema and reimport that into PCBNew. I should point out that what I am proposing is currently done manually. In other words, somebody would manually change all the reference designations in PCBNew and either simultaneously make the change in eeSchema or keep a handwritten was/is list to do it subsequently. The manual approach is not only a huge amount of work, it is fraught with the potential for error. The way to test coherency between the PCB and schematic is to update the netlist, reimport it, and, if possible, run a DRC. Once a schematic's reference designations get out of whack with the PCB it can be really hard to fix. I don't make large boards and these two issues were why I wrote my utility in the first place. Automating the process is not only a huge timesaver but it greatly reduces the odds of an error. In any event, regardless of the approach, netlist coherency can be resolved by re-creating the netlist from the updated schematic in eeSchema and re-importing it into PCBNew. This is what would have to be done if somebody did the reannotation manually. I have been looking at cross-probing.cpp and I see a clear path to the solution by adding a small number of additional message types. This could include directing the eeSchema to generate a netlist, cross-application error reporting, etc.. Does that make sense or am I missing something? Thanks Brian -Original Message- From: Kicad-developers On Behalf Of Wayne Stambaugh Sent: January 5, 2019 8:07 AM To: kicad-developers@lists.launchpad.net Subject: Re: [Kicad-developers] Hoping to contribute but I have some questions On 1/4/19 6:18 PM, Tomasz Wlostowski wrote: > On 04/01/2019 18:51, Brian Piccioni wrote: >> I am still keen to attempt to incorporate geographical component annotation >> into KiCad. In general, it is preferable for component annotation to be done >> relative to the PCB and in some logical order (left/right, top to bottom, >> etc). Thereafter this information is imported to the schematic. I wrote a >> standalone utility (RenumKicadPCB) which does this but ideally, we’d want >> the function built into Kicad. >> >> I understand this would be viewed as a “rogue effort” but lack of >> geographical component annotation is a major missing feature and my hope is >> that if my code works the developers might consider adding it or something >> like it into the project. Otherwise I’ll just maintain my own variant of the >> two affected applications for limited use. >> >> I am not used to working in c++ or working on large projects. Nevertheless, >> I figured I’d give it a try. I have been studying the source for a few weeks >> and have developed a strategy which would be very simple to implement if I >> had more skill/experience. >> >> The first thing I want to do is to add the ability for eeSchema to import a >> “was/is” file to update schematic annotation. Since renumbering the PCB can >> be done manually or with a plugin this seems like a good first step. Since >> an annotation function already exists in eeSchema, all I would have to do it >> provide an option for replacing annotation with a was/is rather than the >> annotation generated by eeSchema’s annotate function. >> >> I see a clear path to doing so however, the scope of Kicad and my limited >> experience with c++ and large projects mean it is not going to be easy for >> me. I am not that adept at navigating Doxygen files so I have a few >> questions regarding the source code (these are limited to eeSchema at the >> moment). >> >> 1) Where are the file IO functions? I have searched for (for example) >> LoadProjectFIle and find the prototype but not the actual function. >> Similarly I find the prototype for SaveEEFile() but not the actual function. >> >> 2) I would like to copy as much of the existing code and dialogs as >> possible (i.e. make new dialog based off another dialog) but when I open, >> for example, dialog_annotate_base.h I see >> >> >> /// >> // C++ code generated with wxFormBuilder (version Jun 5 2018) >> // http://www.wxformbuilder.org/ >> // >> // PLEASE DO *NOT* EDIT THIS FILE! >> >> / >> // >> >> But I can’t find the “source” from which this file is generated. Where is it? >> >> 3) There is a guide
Re: [Kicad-developers] [RFC] Symbol library file format
My ERC Proposal was more like a: we should at least think about it a bit instead of writing the pin type near style and number/name. We can specify ERC hints in a future-proof way without extending the current implementation. Like: (erc_hints (pin_type power_in)) This would allow us to specify new erc hints in the future without splitting them up at different places in KiCad 7. I'm in favor of pin properties. In fact I would like to have the ability to specify properties for all important items. (Pin, Symbol, Net, Sub-schematic, Label,...). Those can be used by users and 3rd-party programs, as well as to quickly prototype new stuff like ERC rules. Regards, Thomas Am 04.01.19 um 19:55 schrieb Wayne Stambaugh: > I'm willing to add properties which are already defined to pins. There > has been talk about adding about adding electrical constraints for > advance ERC testing to symbols but that will not be part of the v6 > implementation of the new file format. It's going to be a lot of work > to implement the features we've added to v6 so this would be outside the > scope of the first version of the new file format. I'm certainly open > to discussing this as part of a later version of kicad. > > On 1/2/19 3:52 PM, mark.vandoesb...@hetnet.nl wrote: >> One thing I would like to have is user defined pin properties, just like >> the part properties. Currently I use the BOM generator to generate a >> software header file from the netlist. I have to use an additional file >> to store the information I need. It would be nice if this information >> can be stored in the symbol. This could be any kind of information, for >> example bank number or clock region for an FPGA. Or driver strenght/speed >> setting for a microcontroller. >> >> regards, >> >> Mark. >> >> Wayne Stambaugh wrote: >> >> I have updated and published the symbol file format[1] for comment. >> Hopefully there isn't too much to change. The only thing to really >> finalize is the internal units. The initial concept was unitless but >> the more I think about it and discuss with other developers, it makes >> more sense to use units for the following reasons: >> >> 1. It's easier to visualize in your head how the symbols on a given page >> size will layout. >> >> 2. Converting from other file formats (Eagle, Altium, etc) will be >> easier since most if not all of them have a defined unit. >> >> I'm thinking 10u (or possibly 100u) will make a good internal units >> value. Once we nail down the units, I will update the file format >> document accordingly. >> >> Please keep in mind that this is the symbol library file format document >> so things like constraints belong in the schematic file format. I will >> be posting the schematic file format as soon as I finish updating it. >> >> Cheers, >> >> Wayne >> >> [1]: >> >> https://docs.google.com/document/d/1lyL_8FWZRouMkwqLiIt84rd2Htg4v1vz8_2MzRKHRkc/edit >> >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > ___ > Mailing list: https://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: OpenPGP digital 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] [RFC] Symbol library file format
Hi Mario, On 1/4/19 10:53 AM, Mário Luzeiro wrote: >> Now if you create a unique part number for every >> resistance value, tolerance, temperature coefficient, manufacturer, etc. >> that would be tens if not hundreds of thousands of unique part numbers. > > I know my intervention may be a bit offtopic, but it may add some other > elements to discussion: > > On such case of the 3D variants, it could be considered a 3D parametric > generation but KiCad would need to support it internally somehow. > Since a 3D file is only need at export time (eg: when user exports the > project to STEP) or for 3D Viewer proposes ( generated on the fly ), there > was no need to storage any 3D data for share a project as it will always be > generated by KiCad. > > Parametric / procedural generation is the easiest part: > https://github.com/KammutierSpule/kicad3Dmodels > > Mario Luzeiro This is an interesting idea but I'm not sure I want kicad to be a parametric 3D model generator. I think this is best left to tools that are specialized for this purpose such as FreeCAD. Although this could be scripted using python since a lot of this work is already done. This is a discussion after v6. Cheers, Wayne > > > From: Kicad-developers > on behalf of > Wayne Stambaugh > Sent: 04 January 2019 14:03 > To: kicad-developers@lists.launchpad.net > Subject: Re: [Kicad-developers] [RFC] Symbol library file format > > On 1/2/2019 2:55 PM, Vesa Solonen wrote: >> kristoffer Ödmark kirjoitti 2.1.2019 klo 12.32: >> >>> I would rather have a new atomic file-format or storage format, so one >>> could actually send a complete part in an easy way, that would include >>> 3D-Files, SPICE data, symbol and footprints, and it would also mean that >>> one could do the mapping to pins in that directory or file instead. > > I can somewhat see the utility in this but it really doesn't make a lot > of sense to me. Lets assume for a second that it would be useful to > create a separate atomic part for every 0603 resistor part number > currently available. Given that the 0603 footprint file is 1.7K, the > step 3D model is 39.6K, the wrl 3D model is 14.4K, and the fully defined > symbol file would be about 1.5K so that's a total of 57.2K per atomic > part number. Now if you create a unique part number for every > resistance value, tolerance, temperature coefficient, manufacturer, etc. > that would be tens if not hundreds of thousands of unique part numbers. > 100K unique atomic part numbers would require 5.72G of storage just for > the 0603 resistors. Add all of the other resistors footprints including > THT and your talking about several 100G. Add all of the other passive > components like capacitors, inductors, etc and you are talking about > several terabytes of storage. Maybe I'm missing something but even with > modern storage systems, this doesn't scale well. > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-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
On 1/3/19 11:24 PM, Simon Richter wrote: > Hi, > > On 03.01.19 19:06, José Ignacio wrote: > >> I >> think useful comments to the proposed format should see beyond the >> actual low level representation of the data and talk about the overall >> model being used to store it. > > tl;dr: That's a separate discussion. > > There are two schools of thought here, one that treats saved data as a > protocol between two black box instances, and one that treats it as a > serialization of the internal state. > > Both have advantages and disadvantages. The "protocol" approach allows > changing internals more easily, and gives better compatibility between > versions as changes to the file format have to be made deliberately, > while the "serialization" approach gives us load/save basically for > free, so we need a lot less code. > > The "serialization" model also requires us to generate the internal data > structures from a more constrained language like IDL, as the marshaller > needs to know when to follow pointers, and what members of an array are > actually valid. > > I'm not sure there are generators that include support for spatial > indexes, though, which is pretty much a requirement for fast rendering, > so this is pretty much impossible at the moment, which places us in > "hand written load/save code" territory anyway. > > We have also ignored diff/merge capability so far, which I believe is a > good thing because it cannot really be done on a textual level (schemas > are two-dimensional, PCBs are three-dimensional, so there is no normal > form with a consistent ordering of elements that will make the files > diffable). > > I fully expect both the internal model and the file format to change > significantly in the coming years as new features are added. The main > requirement for the file format is that it always needs to be possible > to read older files in some way, and to recognize when a file is newer > than the current parser understands. > > It might be a good idea to also have an "extension" mechanism, where we > don't increase the version number when adding a new feature, but rather > mark files that actually use the new feature, so files written by newer > versions that don't use one of the newer functions can be read by older > versions. This would also be another point for "hand written" load/save. > >Simon > I've done some more investigation on this and I'm not convinced that this is any better than our current implementation due to some of the issues Simon mentioned above. I've also discovered there is also a significant performance hit[1] with the JSON reader. This is important due to the overhead required when loading libraries. I appreciate the information and protobufs are interesting but I am going to stick with what we have and know versus what we don't know because I don't think we have the extra manpower to experiment only to find out it doesn't suite our requirements. Cheers, Wayne [1]: https://groups.google.com/forum/#!searchin/protobuf/JSON|sort:date/protobuf/23Slq4AX7oE/xuwQX_ZXAAAJ signature.asc Description: OpenPGP digital 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] Hoping to contribute but I have some questions
On 1/4/19 6:18 PM, Tomasz Wlostowski wrote: > On 04/01/2019 18:51, Brian Piccioni wrote: >> I am still keen to attempt to incorporate geographical component annotation >> into KiCad. In general, it is preferable for component annotation to be done >> relative to the PCB and in some logical order (left/right, top to bottom, >> etc). Thereafter this information is imported to the schematic. I wrote a >> standalone utility (RenumKicadPCB) which does this but ideally, we’d want >> the function built into Kicad. >> >> I understand this would be viewed as a “rogue effort” but lack of >> geographical component annotation is a major missing feature and my hope is >> that if my code works the developers might consider adding it or something >> like it into the project. Otherwise I’ll just maintain my own variant of the >> two affected applications for limited use. >> >> I am not used to working in c++ or working on large projects. Nevertheless, >> I figured I’d give it a try. I have been studying the source for a few weeks >> and have developed a strategy which would be very simple to implement if I >> had more skill/experience. >> >> The first thing I want to do is to add the ability for eeSchema to import a >> “was/is” file to update schematic annotation. Since renumbering the PCB can >> be done manually or with a plugin this seems like a good first step. Since >> an annotation function already exists in eeSchema, all I would have to do it >> provide an option for replacing annotation with a was/is rather than the >> annotation generated by eeSchema’s annotate function. >> >> I see a clear path to doing so however, the scope of Kicad and my limited >> experience with c++ and large projects mean it is not going to be easy for >> me. I am not that adept at navigating Doxygen files so I have a few >> questions regarding the source code (these are limited to eeSchema at the >> moment). >> >> 1) Where are the file IO functions? I have searched for (for example) >> LoadProjectFIle and find the prototype but not the actual function. >> Similarly I find the prototype for SaveEEFile() but not the actual function. >> >> 2) I would like to copy as much of the existing code and dialogs as >> possible (i.e. make new dialog based off another dialog) but when I open, >> for example, dialog_annotate_base.h I see >> >> >> /// >> // C++ code generated with wxFormBuilder (version Jun 5 2018) >> // http://www.wxformbuilder.org/ >> // >> // PLEASE DO *NOT* EDIT THIS FILE! >> >> /// >> >> But I can’t find the “source” from which this file is generated. Where is it? >> >> 3) There is a guide on the Kicad documentation “Tool framework” which >> describes adding a tool to PCBNew. Is there a similar guide to adding a >> tool/function to eeSchema? How do I go about this? >> > > Hi Brian, > > Others have already answered to your questions so here's my offer: I > believe geographical annotation is a very useful feature so I can offer > a bit of my help. Point me to: > - the latest sources of your tool, > - a sketch of the user interface (dialogs), can be a hand-made drawing > - a brief description of how you want all this to work (in terms of user > experience). > > Once I have this information, I'll try making a basic port of your code > to Kicad codebase to the stage where you could take it over and > contribute further features/fixes on your own. > > Tom > There is a lower level piece of the puzzle that is missing and that is back annotation from the board editor to the schematic editor. This is non-trivial because you have create a netlist from the board information and pass it back to the schematic editor. This would be the only solution that I would accept. I want to avoid multiple ad-hoc solutions for back annotation purposes. 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
Re: [Kicad-developers] "Fuzzy" antialiasing in eeschema
Alex Lockwood kirjoitti 4.1.2019 klo 4.14: > I know this is solidly within in realm of minor complaints, but I > wonder, is there anything "easy" that can be done about this? > > https://misc.c4757p.com/fuzzy-wires.png > > A simple answer, I think, is to give eeschema and pcbnew separate > settings for antialiasing (as the sort of things pcbnew renders benefit > much more from it), but... can anybody explain to someone who doesn't > know jack about antialiasing algorithms why this happens? The > corners/junctions "spreading out" so far really strikes me as odd from > how I understand AA normally working. Are we doing anything...weird? There is a pretty rambling thread about it here: https://lists.launchpad.net/kicad-developers/msg38079.html Essentially it boils down to lack of development manpower and compatibility/performance/OpenGL-version (2.1) limitations. -Vesa ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
