The separate program issue is just an implementation detail. The main thing
that Kicad is headed for is the refactoring slated for the 6.0 dev cycle.
The cleaner data structure foundation and subsequent decoupling of the
logic from the UI classes will allow all sorts of automation that are
currently very hard or impossible. The vision that was set since over 5
years ago was for Kicad to present a library-like interface to the outside
world. It kind of does now on PCBnew only, but things are slowly improving
as things get refactored and legacy code gets phased out.
I honestly think the last thing Kicad needs right now is a chance of
direction, I speak as a user that has been using Kicad professionally for
just over 2 years now, working on dozens of PCB projects over that time.
The developments in the past few years have been nothing but awesome for a
project with Kicad's resources. We just need to be patient, or try to help
out in a constructive manner.
Over the past couple years I have been using the dev version in production
to take advantage of the new features (dealing with versions/instability
was a small price to pay for me), I also helped a little bit (as time
allowed) with the occasional patch or grumpy bug report. I'd like to thank
everyone that has worked on the project so far; It basically has made it
possible for me to make a living doing what I enjoy, and I really hope the
project can retain the momentum it has built up in the past few months, it
just keeps getting better!
On Wed, Mar 7, 2018 at 8:21 PM, Ouabache Designworks <z3qmt...@gmail.com>
> On Wed, Mar 7, 2018 at 3:08 PM, Tomasz Wlostowski <
> tomasz.wlostow...@cern.ch> wrote:
>> Which features you think should go to separate programs?
> Export netlist for one. It is a simple addition as long as your design
> fits completely
> on the sheet that you are editing but what happens if you have a
> multisheet design?
> Now you have to locate and read all those other sheets from files. What
> used to
> be a graphics editor now has to deal with a lot of other problems that
> have nothing
> to do with placing and displaying graphics.
> What happens if you edit a schematic, export the netlist and are
> interrupted before
> you can save the schematic? That might only happen one time out of a
> but you now have a corrupt database where the schematic file doesn't match
> netlist. Kicad is getting enough users to make that a real problem. We
> need to
> go through and prevent that from every occurring in the first place. You
> do that by placing the netlister in a separate program that only operates
> the outputed files.
> DRC has the same problem in that it depends on data that has to be located
> read in from other files.
>> Bear in mind that most PCB designers don't like the 'unix-style'
>> workflow, if by that you mean writing makefiles, shell scripts or other
>> programming just to stitch different 'independent programs that do their
>> particular jobs well' together.
> The user doesn't do the stitching. The tool smith does. EEschema will call
> netlist or DRC program to operate on the schematic files rather than on the
> design image in memory.
>> > Create a Pad Mux tool that lets you codesign the IC package and pinout
>> > as part of the IC design team. That is the ultimate in pin swapping
>> > capability.
>> Kicad is a PCB design tool. We don't aim to become an IC design tool.
> I used to be a PCB design engineer until I switched over to design IC's.
> My tools
> did not change, all I did was change libraries. It was great. My
> deliverable to the
> board designer was the symbol that they used for my chip. It was easy to
> together have them try out different pinouts before we had to release.
> That was back in the 90's. 10 years later our tools had diverged enough
> that on my
> latest chips the tool that we used to collaborate between the IC and PCB
> teams was
> a spreadsheet. The system architects that used to use schematic capture to
> their block diagrams had switched over to using microsoft visio. We can do
> a lot better.
> EEschema would make a great engineering tool for a lot of engineers if it
> only had two
> additional features. The first is true hierarchy and the second is
> heterogeneous buses.
> I understand that Jon Evans has the bussing working and we could deal with
> the hierarchy
> by writing out the data and processing it in separate programs.
> John Eaton
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : firstname.lastname@example.org
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
Mailing list: https://launchpad.net/~kicad-developers
Post to : email@example.com
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp