kicad-developers team mailing list archive

[Collin Anderson <metacollin@xxxxxxxxxxxx>]

I'm in agreement as well. 

Windows treats the user like a child.  It assumes you don't know what you're doing, and just about all of the design decisions in Windows  can ultimately be traced back to the premise that the user is probably stupid.  Well, not stupid, but largely ignorant/inexperienced in regard to computers.  

This is not a bad thing - most people use Windows, and most people are not particularly computer savvy, so this makes a lot of sense.

The downside of this is that Windows is incredibly frustrating, inflexible, and relatively powerless in the hands of a power user.  This begins with installation. Have any of you ever tried to Install Windows to a drive that wasn't enumerated as the first/zeroth drive?  

You can't.  Surely the user made a mistake. Or because the user won't know how to boot from a second drive.

To install Windows on a second drive, you have to physically disconnect all other drives from the SATA bus (lol if you have several PCIE SSDs, then it's an extra pain in the ass).  

So the question we need to ask is who is KiCad meant for? 

Is it indented for makers who are learning and do this as a hobby, that are helpless without an Arduino? Is KiCad intended to be for people who came from using Fritzing? 

If so, then KiCad should treat the user like a child and assume they didn't mean to do something.  Assume it was a mistake.  KiCad can be the Microsoft Word of EDA.  It will just change your shit because it knows what you wanted to do better than you.  We can even have a talking 1/4W through hole resistor character named Ohmer, who is poorly animated with CGI from 1995, randomly pop up to try to help people with their arduino shield.  

Or is KiCad intended to be a professional tool used by real engineers who actually know how to design electronics? Is KiCad intended to be powerful? 

If so, then KiCad should treat the user like an adult. It should expect the user to be responsible for their actions, and certainly warn them about things that might be mistakes or accidents.  This is the entire point of DRC.  But, maybe I know what I'm doing and maybe KiCad should assume that and let me proceed.  

Right now, I have a bunch of footprints that I use to "fake" vias for via stitching.  ghetto_vias.pretty.  I have to copy and paste them manually, and manually set the net, and if I ever make any changes that involves removing components, I'm screwed.  I can either have all my ghetto_vias get wiped out along with footprints I wanted removed, or I can manually delete the extra footprints which gets dicey on a large board and maybe the changes I did were significant.  

Now, since they're footprints, I also lose push and shove ability.  

Stront's patch is perfect and should not only be included, but the default behavior.  But I'll settle for included but needs to be turned on in the preferences. 



> On Oct 9, 2016, at 11:35 PM, Chris Pavlina <pavlina.chris@xxxxxxxxx> wrote:
> 
> ...yes. All of this.
> 
> 
>> On Oct 10, 2016 01:25, "Strontium" <strntydog@xxxxxxxxx> wrote:
>>> On 09/10/16 23:11, Wayne Stambaugh wrote:
>>> On 10/8/2016 1:20 PM, Nox wrote:
>>> 
>>> There is nothing here that has not been discussed before.  The reason
>>> that freely assigning nets to vias has not been implemented is that
>>> every implementation is a compromise.  If we allow random net naming of
>>> vias, all manner of bad things can happen that are completely out of the
>>> control of kicad.  Instead of your wtf moment being some tracks and vias
>>> with no associated net being ripped up when you import a new netlist,
>>> your wtf moment is a stack useless pcbs that you just spend money on.  I
>> Wayne, respectfully this is where I believe you have missed the point.  If a designer assigns a net to a via, then THEY are responsible for the WTF moment.  IF Kicad rips up the nets the designer assigned to vias then KICAD is responsible for the WTF moment.  In one case the designer screwed up and in the other Kicad screwed the designer over.
>> 
>> Its as simple as that.
>> 
>> My original patch, posted many moons ago, fixed this problem neatly.  It did not allow a user to assign arbitrary nets, but if you plonked a via on a GND fill, it had a GND net, and that via would ALWAYS have a GND net until you did something explicitly to change it.  What is wrong with that, HOW is that Kicads fault if the user should have plonked it on the VCC plane.  Its not.  Kicad shouldn't go along behind you ripping up your design for the hell of it.  I, in fact, laid boards out, which i believe would be impractical, if not impossible to lay out without this patch, and i have to keep a version of that kicad around simply because kicad isn’t up to the task of following my instructions without later destroying my design intent.
>> 
>> It is not obvious and NOT a DRC violation to have a via go from being assigned to GND and suddenly being assigned to UNASSIGNED. Boards could be made like that without the designer knowing they are being messed with by the DRC pass.  Now the result is the plane it was supposed to stich is no longer stitched, AND the design intent has been destroyed by Kicad.
>> 
>> MY opinion, and I know it doesnt count for much, is DRC should NEVER reassign an net unless it can UNAMBIGUOUSLY PROVE the nets connectivity.  IF it cant prove the nets connectivity it should leave the damn net assignment alone.  Throw a DRC Error FINE, but dont change my design. And it should NOT ASSUME IT KNOWS BETTER THAN THE PERSON WHO LAID IT.  To be completely fair, the whole "Reassign the nets pass" of Kicad should be able to be disabled, it should generate DRC violations for net conflicts, but a designer should be able to tell Kicad, HEY DONT CHANGE MY DESIGN JUST DO WHAT YOU ARE TOLD.
>> 
>> If a user wants to manually assign a net, problem belong them, but i think its worse for Kicad to insist it knows better than the designer and that is precisely the situation we have now.
>> 
>> Show a case where leaving the via on the net the user assigned when it was placed causes a design fault VS reassigning to UNASSIGNED (and that fault is kicads and not the stupidity of the designer) and i will change my position, but no one has ever been able to show that except for "Beware monsters" type replies.
>> 
>> AND if one wanted to proceed "Cautiously" just have a global option "Preserve nets on DRC" which selectively enables my proposed patch, then users who dont use via stitching can "proceed cautiously" and other who actually want to get a design out the door can do some work, and not have to lay tons of superfluous, difficult to manage, and easily screwed up stitching tracks.
>> 
>> Stront
>> 
>> 
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp