EEVblog Electronics Community Forum
Electronics => PCB/EDA/CAD => KiCad => Topic started by: PlainName on August 28, 2020, 05:14:32 pm
-
There's a lot of things I like about Kicad, but using it isn't one of them. Have none of the devs used Windows in their life? Modeless consistency is the way to go: having to select a mode, do something, unselect the mode, select another mode, etc, is so DOS-era. And right click to do something with an object but left drag to select is... well, I was going to say perverse, but it isn't compared to dragging to select and then attaching to the mouse pointer regardless of mouse button! Every time I make a selection like that I end up moving whatever I've selected.
So, is there an alternative interface that does things in a more Windows-like way? OK, a more pre-W10-like way?
-
At this moment no, it has been an issue for a while know.
If you have enough programming skills (and time), I guess you can basically port the whole project and work on your own 8)
-
Thanks. Good to know my view isn't too perverse!
Maybe I'll let them have another go at it before jumping in to show 'em how it's done :)
-
Thanks. Good to know my view isn't too perverse!
Maybe I'll let them have another go at it before jumping in to show 'em how it's done :)
Depends who you're asking I guess, some seem to enjoy it.. :-//
-
There's a lot of things I like about Kicad, but using it isn't one of them.
:-DD
I'll frame that and put it up on the wall over my bench.
Thank you for a good laugh!
-
There's a lot of things I like about Kicad, but using it isn't one of them. Have none of the devs used Windows in their life? Modeless consistency is the way to go: having to select a mode, do something, unselect the mode, select another mode, etc, is so DOS-era. And right click to do something with an object but left drag to select is... well, I was going to say perverse, but it isn't compared to dragging to select and then attaching to the mouse pointer regardless of mouse button! Every time I make a selection like that I end up moving whatever I've selected.
So, is there an alternative interface that does things in a more Windows-like way? OK, a more pre-W10-like way?
Windows dev here who tries and fix Windows problems.
I am confused by your issue. You are upset because KiCad has a concept of tools that you must select? This is similar to EAGLE and other CAD programs work, you have to enter modes for everything. How do you expect it to know you want to draw a line instead of a via otherwise? We don't exactly have neural interfaces...
The expectation is you learn the hotkeys and everything becomes instant which is true for most CAD programs. Heck, all the online CADs also do the same.
Left click to drag select is how literally drag select works in any program on Windows????
It's also impossible to drag select and move components by accident. You have to activate the move tool _after_ the selection is made by either pressing M or right click move. Even double click on a selection does nothing other than open the properties window.
-
Thanks. Good to know my view isn't too perverse!
No you're not. Exactly the same issues drive me to distraction too.
-
Depends who you're asking I guess, some seem to enjoy it.. :-//
Well, there are people who pay good money to be tied up and abused too. Takes all sorts... ^-^
-
You are upset because KiCad has a concept of tools that you must select?
No, I am disappointed with being in a mode. What tends to happen is you go to some mode (say, placing a track) and click, click, oh just check the incoming email/reference pdf/EEVblog so send your mouse to a different window and it doesn't go because it's locked into track placement mode inside that window. And you've just panned 20 feet away from what you were placing because the window pans when you hit the edge. Etc.
This is similar to EAGLE and other CAD programs work
Ah, right. It should be shit because other things are shit? OK.
The expectation is you learn the hotkeys and everything becomes instant
Arse about face error. The stuff is allegedly there to help me and pander to my whims (aka make things easier), not have me make contortions to fit its foibles. Progress is not made by accepting problems will never be solved and going out of your way to perpetuate them.
[digression]
Speaking of which, the browser address bar is a classic (at least in Firefox and derivatives): start typing a previously-used address and you get URL completion with the suggested part highlit. Sometimes you type the wrong key - say, "eevbr" - and some unwanted auto-completion is offered. No problem, just backspace your bad key and type the right one. Except that backspace deletes the suggest and you need two backspaces to delete your original mistake. Bad, right? But it gets worse because if there was no auto-suggestion you only need one backspace. So you can't sensibly edit a URL in the address bar without looking at what is being typed there. Has no dev ever thoguht to themselves, "Er, this could be a bit confusing"? Hasn't anyone figured that the delete key should delete the actual real keystroke and not a virtual string? This is an example of us being forced to pander to technology (OK, someone's stupid coding/design) rather than having technology work for the user.
[/digression]
Left click to drag select is how literally drag select works in any program on Windows?
Indeed it is, and you might note that it's not that which I am whining about. It is the instant attaching of the selection to the mouse (despite releasing the left mouse button) so moving the mouse moves whatever is selected. Thus you cannot select something you really don't want to move without a large amount of trepidation, which doesn't encourage one to do the thing!
You have to activate the move tool _after_ the selection is made by either pressing M or right click move.
That's not how it happens for me. Maybe there is some setting to switch between the two, but I know not where or what it is.
-
Ah, right. It should be shit because other things are shit? OK.
It is the entire industry, this is 20+ years of UX considerations. Nobody else is complaining. We don't have brain interfaces yet for a computer to magically know what we want it to do on a click.
oh just check the incoming email/reference pdf/EEVblog so send your mouse to a different window and it doesn't go because it's locked into track placement mode inside that window.
This is not possible. KiCad does not attempt to block your mouse from leaving the window and I just retested on 5.1 and had no issue switching windows with a tool activated.
Indeed it is, and you might note that it's not that which I am whining about. It is the instant attaching of the selection to the mouse (despite releasing the left mouse button) so moving the mouse moves whatever is selected. Thus you cannot select something you really don't want to move without a large amount of trepidation, which doesn't encourage one to do the thing!
Ah I see. This is a schematic editor specific issue in 5.1. This is fixed in the nightlies/master with other significant changes.
Progress is not made by accepting problems will never be solved and going out of your way to perpetuate them.
Progress is also not made by complaining about problems but not proposing an actual solution.
Also submitting a detailed report to the issue tracker helps, we want to know about issues users are facing. But we need them in one place and not forums. We need to know your version, your operating system, the tool being used, the steps taken, etc. That is how progress is made.
-
This is fixed in the nightlies/master with other significant changes
OK :-+
Progress is also not made by complaining about problems but not proposing an actual solution.
To point. It's possible to know that something is wrong (catching a novel infection, say) without knowing how to fix it. However, in this case one only has to look at Windows pre-10 to see how it can be done nicely.
Also submitting a detailed report to the issue tracker helps
Yes, and were I a consistent user I would no doubt do that. A drive-by report without chance of a follow-up might actually do more damage than it fixed.
-
Ah, right. It should be shit because other things are shit? OK.
It is the entire industry, this is 20+ years of UX considerations. Nobody else is complaining. We don't have brain interfaces yet for a computer to magically know what we want it to do on a click.
Oh, I've heard plenty of people complaining, about KiCad and other CAD tools having crappy UIs. The reason that you don't hear about it is that folks who have found CAD UIs less than stellar have given up talking to people who trot out the same tired defences rather than going "OK, what's wrong?". Tired defences like "nobody else is complaining" when quite clearly they are.
-
Ah, right. It should be shit because other things are shit? OK.
It is the entire industry, this is 20+ years of UX considerations. Nobody else is complaining. We don't have brain interfaces yet for a computer to magically know what we want it to do on a click.
Oh, I've heard plenty of people complaining, about KiCad and other CAD tools having crappy UIs. The reason that you don't hear about it is that folks who have found CAD UIs less than stellar have given up talking to people who trot out the same tired defences rather than going "OK, what's wrong?". Tired defences like "nobody else is complaining" when quite clearly they are.
Ok, but there's still the second part. It's one thing to say "this is terrible". It's another to say "This is terrible, this is my suggested alternative solution that'll work like XYZ which has benefits ABC over the existing solution" that is far more conducive to getting changes made. Like I'm being serious about the neural interface bit, I personally do not know of any other way to make program determine the intended action selection otherwise. If someone were to describe an alternative or even find something else that is readily accessible like a video or other tool as an example of an alternative, that helps far more.
KiCad in particular does have UX quirks here and there. There has been work in improving a bit of things in the next major version. I've made it my own goal to fix Windows specific UX issues and harass other devs with a stick to fix UX/workflow issues as well. But unless people report clear issues with what is wrong, why is it wrong and what is better, it's really hard to realize things are wrong. We programmers end up stuck in mental sandboxes just like any other engineer may get "arrogant" with his designs until shown the light.
-
Hi,
I find the way KiCad works much more intuitive than i.e. Eagle. There are some shortcomings, of course, but they are not within the UI of the basic functions. It is rather some strange issues I had with library management not recognising my user defined paths, which where resolved magically after some twiddeling.
Regards, Bernd
-
It's one thing to say "this is terrible". It's another to say "This is terrible, this is my suggested alternative solution
The click-drag-release is terrible. My suggestion is to copy any Microsoft Windows app: click-drag to select, leave selected but free the mouse. Only if the left button is pressed inside the selection should the selection be dragged or moved.
Bearing in mind your earlier comment I just tried this again now. You can click on something to select and then choose M or whatever to move. Why? Why not just let the thing be dragged with a left mouse button drag? Anyway, I then did a drag select (left mouse button, drag the cursor across the objects to select - this is a 'block select') and then released the mouse button. Moving the mouse dragged the selected objects.
So:
1. Only drag/move when the left mouse button is being pressed
2. When the left mouse button is being pressed, drag/move whatever is under it if it's selected.
-
To point. It's possible to know that something is wrong (catching a novel infection, say) without knowing how to fix it. However, in this case one only has to look at Windows pre-10 to see how it can be done nicely.
Keep in mind that KiCAD is not Windows software, it is a cross-platform software, working also on a Mac and Linux. So an "only has to look at Windows pre-10" sort of reference is not very helpful because I am pretty sure that "fixing" one UI niggle in this manner will bring a torrent of enraged Mac or Linux users who are used to different UI conventions.
Also submitting a detailed report to the issue tracker helps
Yes, and were I a consistent user I would no doubt do that. A drive-by report without chance of a follow-up might actually do more damage than it fixed.
That's fine but then how do you expect the issue to be actually fixed? Or do you expect the developers to be reading 20 random forums, Stack Overflow, Youtube comments and what not to check whether someone didn't write a complaint about their software there today? I hope that we can agree that this would be unmanageable, especially for a project that doesn't have a paid bug triage team and PR/marketing department full of people with nothing better to do.
Bug trackers exist for a reason and it isn't to keep people from reporting problems. The tracker will typically send you an e-mail if there are additional questions or something happens with your report (e.g. it gets resolved), so you don't need to be actively following it.
-
If kiCad want to fix the interface, then they just need to fire up a copy of DipTrace to see how it should be done.
I've tried a few times to give kiCad a go, but the UI and controls just drive me mad every time, it's like you get a new keyboard and the keys are out of your muscle memory, but worse, like all the keys are in completely random order like no other keyboard made.
-
Oh, I've heard plenty of people complaining, about KiCad and other CAD tools having crappy UIs. The reason that you don't hear about it is that folks who have found CAD UIs less than stellar have given up talking to people who trot out the same tired defences rather than going "OK, what's wrong?". Tired defences like "nobody else is complaining" when quite clearly they are.
You have a point there but the problem with UIs is that pretty much everyone hates them - and everyone wants them to work in *their* way. Good luck trying to reconcile this.
This sort of "KiCAD/Eagle/X UI sucks because it doesn't work the same as software Y" thread is an evergreen and most developers will ignore it because rarely anything constructive comes out of it.
Case in point - personally I like both the KiCAD and Blender UIs because I am a heavy keyboard user - left hand hitting shortcuts activating modes, right hand on a mouse, which makes it very efficient.
Other people hate these UIs because since they don't have everything on a button or a menu entry, it is not discoverable and hard to use for mouse-centric users. E.g. in the case of Blender this type of complaint came often from people switching from 3DS Max/3D Studio where you are totally screwed without a mouse because most things don't really have shortcuts. So people got "trained" to use a mouse for everything and Blender with its different UI philosophy was alien and unusable to them (even though the "two handed" concept with keys/mouse is/was clearly described in the manual).
Then you have programs like MicroCap, that has a horrible UI mess, with buttons everywhere because the authors have obviously tried to expose everything as a button to cater to mouse users.
User interfaces are an entire engineering and design discipline by themselves. Unfortunately a lot of people think they know how it should be done without really knowing much about the subject. Both users and developers.
If kiCad want to fix the interface, then they just need to fire up a copy of DipTrace to see how it should be done.
I've tried a few times to give kiCad a go, but the UI and controls just drive me mad every time, it's like you get a new keyboard and the keys are out of your muscle memory, but worse, like all the keys are in completely random order like no other keyboard made.
You know that you can redefine pretty much all the shortcuts, right? And re "fire up a copy of DipTrace to see how it should be done." - see above.
-
Oh, I've heard plenty of people complaining, about KiCad and other CAD tools having crappy UIs. The reason that you don't hear about it is that folks who have found CAD UIs less than stellar have given up talking to people who trot out the same tired defences rather than going "OK, what's wrong?". Tired defences like "nobody else is complaining" when quite clearly they are.
You have a point there but the problem with UIs is that pretty much everyone hates them - and everyone wants them to work in *their* way. Good luck trying to reconcile this.
No what people want is for UIs to be consistent with conventions for the platform they are on. This is why the drag/select of KiCad is jarring - it doesn't fit the conventions that every other application under the sun uses.
In terms of self-consistency application UIs on different platforms are: terrible on Unix/Linux, OK on Windows, and good on MacOS and I can't help thinking that the Unix/Linux origins of many CAD programs haven't helped here. Word processing applications, both on and across platforms, tend to be surprisingly consistent - I can drive just about any modern word processor on any platform without learning anything before I try using them. Whereas every, and I mean, every schematic entry editor I have ever used on any CAD application is different, wildly different and requires prior study to us, even if you have used every other comparable CAD application beforehand
Why have CAD application designers failed to create a common UI grammar in the way other application designers have in areas like word processing, graphics, spreadsheets and so on? And why do they so often make choices that are inconsistent with the behaviour of other applications in general?
My final complaint with CAD software in general, and most definitely with KiCad in particular, is that every lesson about UI usability learned over the past 35 years since we started using GUIs seems to get ignored. Lessons about modality, non-modality, presenting information consistently, making common operations easy and so on, real basic stuff. It is as difficult to place a resistor in KiCad, something you will do dozens of times in a schematic, as it is to place an obscure seldom used component, it ought to be easy to do the common things quickly, not at exactly the same level of complexity as it is to do an uncommon thing.
-
Keep in mind that KiCAD is not Windows software, it is a cross-platform software
Yes, but Microsoft invested a lot in usability studies and got it pretty much spot on while Apple/Linux were learning from mistakes. It is not being partisan to say "Do it like the one that works" :)
User interfaces are an entire engineering and design discipline by themselves.
Indeed. And ideally should be treated that way. Would you let a web developer program your IoT hardware (probably with node.js or something)?
-
Yes, but Microsoft invested a lot in usability studies and got it pretty much spot on while Apple/Linux were learning from mistakes.
BRACE! BRACE! BRACE!
::)
-
It's one thing to say "this is terrible". It's another to say "This is terrible, this is my suggested alternative solution
The click-drag-release is terrible. My suggestion is to copy any Microsoft Windows app: click-drag to select, leave selected but free the mouse. Only if the left button is pressed inside the selection should the selection be dragged or moved.
Bearing in mind your earlier comment I just tried this again now. You can click on something to select and then choose M or whatever to move. Why? Why not just let the thing be dragged with a left mouse button drag? Anyway, I then did a drag select (left mouse button, drag the cursor across the objects to select - this is a 'block select') and then released the mouse button. Moving the mouse dragged the selected objects.
So:
1. Only drag/move when the left mouse button is being pressed
2. When the left mouse button is being pressed, drag/move whatever is under it if it's selected.
Like I said, the behavior was changed altogether in the nightlies to be identical between schematic and pcb editor, along with substanial changes to event processing.
You can obtain a nightly from here (scroll to the bottom for latest)
https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/nightly/
But be warned that this is the development version and it should not be used for new designs yet.
> Why? Why not just let the thing be dragged with a left mouse button drag?
Ok.
So I'm trying to understand your description which I can now read better because claiming this is "Windows behavior" made no sense at all.
Are you saying you want to click on items and while still holding the mouse button be able to immediately drag it?
-
> Why? Why not just let the thing be dragged with a left mouse button drag?
Ok.
So I'm trying to understand your description which I can now read better because claiming this is "Windows behavior" made no sense at all.
Are you saying you want to click on items and while still holding the mouse button be able to immediately drag it?
dunkemhigh's earlier description seems very clear to me. It's how things work in any standard Windows application, and as far as I am aware also on MacOS and (most?) Linux GUIs:
My suggestion is to copy any Microsoft Windows app: click-drag to select, leave selected but free the mouse. Only if the left button is pressed inside the selection should the selection be dragged or moved.
-
Are you saying you want to click on items and while still holding the mouse button be able to immediately drag i
Yes.
-
@dunkemhigh
If you are just looking for a more intuitive package, just download DipTrace, yeah it's not open source, but the free download version is quite sufficient for hobbiests, it's not tied to the cloud so nobody can take it away from you, and if you need more then it's not that expensive to buy - especially the pricing for non profit hobbiests (https://diptrace.com/buy/non-profit/)
It works mostly like you expect it should work.
Here is a screen capture I made spending less than 5 minutes to do a very crude demo for you (https://youtu.be/Gj8m5xLXX_w). I used the keyboard twice, once to enter "10k" and once to CTRL-R rotate the led, everything else just mouse exactly like you expect, want to place a component pick it from the side pane and drop it where you want, want to move a thing, click and drag, want to draw a wire, click and click, want to cancel drawing a wire, right click, want to move stuff without breaking connections, just click drag, want to move a bunch of stuff click-drag to select all the stuff you want to select, and then click-drag to move the selected stuff, mouse wheel to zoom in/out, middle button to pan. The components I used are from my own custom library, which is another bonus of DipTrace the component (and footprint for pcb) editor is just as intuitive making it very easy to make your own library how you want it.
-
> Why? Why not just let the thing be dragged with a left mouse button drag?
Ok.
So I'm trying to understand your description which I can now read better because claiming this is "Windows behavior" made no sense at all.
Are you saying you want to click on items and while still holding the mouse button be able to immediately drag it?
dunkemhigh's earlier description seems very clear to me. It's how things work in any standard Windows application, and as far as I am aware also on MacOS and (most?) Linux GUIs:
My suggestion is to copy any Microsoft Windows app: click-drag to select, leave selected but free the mouse. Only if the left button is pressed inside the selection should the selection be dragged or moved.
I've used Windows since Windows 95. I've never considered this a "Windows thing".
I am somewhat interested in implementing it behind a setting flag, but there's only a week left until feature freeze for V6 so it might not happen in time :/
-
Thanks for the suggestion of DipTrace. However, I am not looking for a free or 'hobbiest' product per se - I would expect to use it for professional work as well as personal designs, and I don't object to paying for a good tool. I am also not short of PCB software already.
My reason for looking at KiCAD was because I am interested in what's around and what features they have that might benefit (or just interest) me. It gets mostly good reviews and looks like I might need it as a skill in a professional capacity at some point, so I thought it worth spending a little time using it to knock off an actual design (the best way to get into a product, I find).
-
Some 6 or 7 years ago I was in need for a new PCB suite, as Windows tried to force a "Blue tiles of Death" screen upon me on every boot, and that was the final straw that made me switch to Linux. So I tried a few programs. Eagle had a completely horrible user interface. I could not even type in a value, and the first schematic I made in it had a 0.2Ohm resistor, that value was not in the drop down list.
Also tried Geda. It was usable, sort of, but the schematic and PCB part were completely separate programs with different sort of interfaces.
When I tried KiCad, together with the "Getting started in KiCad" guide (which is obsolete now unfortunately) I got a pretty good idea of how the user interface worked and it worked quite well. Back then there were still a handful of serious bugs in KiCad. Bugs on the level of: you can edit a library component, but then you can't save your edited component.
Then in the last 5 or so years I've seen KiCad grow. All serious bugs got smashed, new functionality added, GUI improvements, tremendous libraries. Side projects to automate boring tasks, a friendly forum...
The click-drag-select-move you mentioned is currently only present in Eeschema. In Pcbnew the selection is already separate from the operation, and it has been so for quite some time. Eeschema is getting a mayor update with KiCad V6 (Expected within a year probably) and the idea is to get it more in line with Pcbnew.
For the still limited amount of developers and budget for the KiCad project they've done an amazing job in these last years.
Maybe I'll let them have another go at it before jumping in to show 'em how it's done
Go on, jump in. Show them how to code a better GUI.
-
No, I am disappointed with being in a mode. What tends to happen is you go to some mode (say, placing a track) and click, click, oh just check the incoming email/reference pdf/EEVblog so send your mouse to a different window and it doesn't go because it's locked into track placement mode inside that window. And you've just panned 20 feet away from what you were placing because the window pans when you hit the edge. Etc.
If you want some productivity, then get rid of those distractions. Quit your mail program, close internet, find some focus to work on a project.
I also do not like the panning, and turned it off long ago. Setting is:
**Pcbnew / Preferences / Preferences / Common / Pan while moving object**
I do have the "Center and warp cursor on zoom" checkbox on (default). This is a feature lots of users bitch about, (you probably too), but if you give yourself some time to get used to it, then you start wondering why other programs do not work in that way.
-
The click-drag-select-move you mentioned is currently only present in Eeschema
Is Eeschema a different product to Kicad? Come to that, is PCBNew? (And what does PCBOld do?) When I download and install Kicad, what am I actually installing if not those?
Maybe I'll let them have another go at it before jumping in to show 'em how it's done
Go on, jump in. Show them how to code a better GUI.
Hmmm. Maybe I shouldn't try to inject humour into things. Clearly, even adding a smiley emoticon doesn't show intent nowadays.
If you want some productivity, then get rid of those distractions.
Those were generic examples anyone could identify with. But real-life ones might be browsing to a file, opening a datasheet, running a calculator, checking JLCPCB for limitations, looking up footprint dimensions, ... Do you really need me to list a ton of stuff to which you can try your best to imply the user is at fault for not devoting 100% of their - and their machine's - time and focus to this single app? It is the app that is failing to follow accepted user interface guidelines, remember, not the user.
-
When you install KiCad, it's made up of about 10+ different programs probably:
* KiCad project manager (normally started for each project)
* Eeschema, this is the program for the schematics.
* Pcbnew, For drawing the PCB.
* Symbol Editor.
* Footprint Editor.
* Footprint Library manager.
* CvPcb for assinging footprints to schematic components (called differently now-a-day's)
* Gerbview for viewing gerber files.
* Various utilites, such as "Bitmap to Component", the "Page Layout Editor" and more.
* Footprint scripts (in Python!) BOM scripts ...
And all of these work reasonably together to form the KiCad EDA Suite.
KiCad is pretty much "Modeless" Drawing a long track in KiCad is comparable with drawing a polyline in almost any CAD program. Having to go through a 3 layer deep menu structure for each line segment would probably not be a GUI improvement. So what's left is the panning off screen, which is easy to turn off.
-
Regarding the drag mode. In most cad software, you usually don't just want to drag something somewhere, but specify exactly the drag. You may want to select the reference for dragging. In a cad tool you can select a bunch of objects, then say move, then say you wan't to move the centerpoint of a circular part to the intersection of two lines. This is much harder to do by just clicking and dragging, but easy to do with drag mode. You may want to be in a completly different zoom setting and part of the drawing when selecting the objects, selecting the reference and when dragging.
This is why the majority of cad tools work this way.
-
When you install KiCad, it's made up of about 10+ different programs probably:
Yes, I realise that. My question was rhetorical ("asked in order to produce an effect or to make a statement rather than to elicit information" - ODE). To expande, if you (the generic 'you', not necessarily you personally) complain that the forum doesn't embed images properly, the implication is that it's a forum problem. If you're a techy and privy to what runs the forum, you might be a pedant and say it's SMF. It's kind of stretching things to say it's such-and-such plugin problem, or even that it's a foible of php. To the user, it's EEVBlog. It's a coherent whole (or should be).
-
In most cad software...
Oh boy! That's a messy can of worms to tip over :)
I like the way Altium implements drag selection: drag down and to the right selects anything completely enclosed, while dragging up and to the left selects anything with a part enclosed. But for other stuff they are very poor. Usually, one would select a bunch of things and then do something with them. With Altium you first say what you're going to do to them, then you select what you want to do it to. The result is that it's a bit longer to do anything (and if you're from a Windows world, which you will be, it's counter-intuitive).
This is why the majority of cad tools work this way.
But some seem to manage just fine. TurboCAD, for instance, doesn't seem to have a selection or dragging problem. At least, I can't recall being annoyed by it in those respects. In fact, now I think about it, it does pretty well: select stuff then do something to 'em, OR select what you want to do and then do it to things individually. But click'n'drag works just like you'd expect it to do. Well, like I'd expect it to!
If that app - a CAD tool no less! - can manage it, why can't others? The answer is probably because they have a long history and retain certain ways of doing things because that's how they were done. And, of course, they're all different because they all come from a time when there weren't any standards, or they we too difficult to implement. Or, again quite probably, because they are just a massive bunch of addons and fixes and enhancements to the first quite simple, and not really designed as such, utility.
Proteus is a good example, having its roots in DOS and dragging that user interface into Windows with it, but over time (25 years or so) they changed to a more Windows-centric interface. Still not quite correct, but a lot better than it used to be.
-
In most cad software...
Oh boy! That's a messy can of worms to tip over :)
It sure is, but for some things you have to find a compromise somewhere.
I like the way Altium implements drag selection: drag down and to the right selects anything completely enclosed, while dragging up and to the left selects anything with a part enclosed.
Same in KiCad. In Pcbnew (that is the PCB part of KiCad :) ) it already works this way for quite some time. Eeschema (The schematic part of KiCad :) ) is likely to follow with the next mayor update.
Small difference: KiCad only distinguishes with dragging left to right, or right to left. It don't care about up and down, that is up to you.
Proteus is a good example, having its roots in DOS and dragging that user interface into Windows with it, but over time (25 years or so) they changed to a more Windows-centric interface. Still not quite correct, but a lot better than it used to be.
KiCad ain't even 25 year old! It started as a hobby project from a university professor, and it's only really taking off in the last handful of years. Before that it was pretty buggy and development was much slower then now. KiCad is picking up development speed each year. Give KiCad a few more years (it won't need 25) and then see in what state it is. (The Proteus website claims it's over 30 years old).
What sort of comparison would you make between programs such as Proteus and Altium versus KiCad?
They're quite different beasts. At least I think so. I'm simply in no situation to afford a EUR 5000 Proteus license or Altium, which price I don't even dare look up. And when comparing prices, don't start with crippled 200 pin software or 80 sqare cm 2 layer boards. KiCad is no slouch. Some people are asking for updates on the 32 copper layer limit in KiCad. They were using 26 copper layers and were starting to worry about this limit. Others were complaining that KiCad was getting a bit slow on their i9 with a 10.000 footprint PCB. (Or was it hundredthousand?) The story is somewhere in the bug tracker on github. Maybe also migrated to Gitlab when KiCad switched.
-
KiCad ain't even 25 year old! It started as a hobby project from a university professor, and it's only really taking off in the last handful of years. Before that it was pretty buggy and development was much slower then now. KiCad is picking up development speed each year.
Yep, we are really picking up speed. The GitLab migration has done absolute wonders. FUCK LAUNCHPAD. What a shitty service that honestly hinders and stunts growth for any project dumb enough to use it. It continues to exist and do untold damage to open source projects.
Same in KiCad. In Pcbnew (that is the PCB part of KiCad :) ) it already works this way for quite some time. Eeschema (The schematic part of KiCad :) ) is likely to follow with the next mayor update.
Yep, this behavior is implemented in eeschema in the next major update. You can try it in a nightly.
There was a legacy/history of how eeschema and pcbnew were implemented back in the day. 5.1 was actually an emergency update to convert eeschema partially to the newer rendering framework because the old one got horribly broken on macOS I believe. The next major cleans up a bunch of the remaining inconsistencies.
-
It started as a hobby project from a university professor
Well that's a good way to get perverse design decisions embedded in it at the start ;)
But most things probably start like that. Sometimes some higher-up decides that restarting afresh, but this time implementing all the things learned from jury-rigging the original, is a Good Idea. I think the majority of those restarts end up worse, or dead, or just taking forever to get anywhere. Such is life...
What sort of comparison would you make between programs such as Proteus and Altium versus KiCad?
I'm not quite sure what you're asking, there. I suspect any answer would be quite complicated since the position of a product in the marketplace will have an effect. It may be rubbish, but if it's the #1 product then you need to use it if you're going to be part of things. Even if you restrict to purely personal jobs that will never be seen by anyone else, if your PCB house, for instance, understands quite a few native formats but not the product you use, that could be a bit of a kink in the road for you. The likelihood of getting support from somewhere like EEVBlog can be important too :)
-
I had my daily dose of comedy again in this topic.
It's just such a thing, that most open source developers don't seem to understand one very important rule.
Even if you software is free and open source, you are still competing against commercial products.
Or in other words, you have to understand the market you're in and how your customers think, need and like.
Most developers (incl KiCad) don't even get so far, but if they do, they always seem step in the same huge mistake.
"We asked our community and therefor..... (fill in)"
Let me tell you one basic thing about marketing, the biggest mistake you can make, is ask your current userbase if they're happy.
Especially for a product/company that still needs to prove himself and want to gain popularity, you should be focused in almost everything except your current userbase.
Be VERY involved why other people are not using your program yet and try to understand why.
Take every bit of critique and feedback dead serious.
Otherwise, especially in the commercial world, you won't even last at all.
The last word I heard almost directly from the KiCad team, was that keeping it multi platform/OS stable is their main focus. :palm: |O
I still have an headache from facepalming my head.
I lost my faith in KiCad, they just don't seem to be open minded to any feedback and (no offence), their usebase (fans) seem to be even worse.
Someone called Diptrace earlier in this topic, although it still has some major flaws, they actually do take feedback pretty serious and I have seen them making a lot more progress with a team that is a lot smaller.
The fact that it's free and open source is just a extremely poor excuse, there are plenty of examples of free and open source programs that make tons of more progress in even just a month.
-
I lost my faith in KiCad, they just don't seem to be open minded to any feedback and (no offence)
We are. We prefer it in the issue tracker with _details_. The feedback that "THIS IS BAD", but never any explanation, or suggestion of a solution or reference doesn't help. The more concrete descriptions, the better.
The wishlist is constantly growing and also being implemented these days https://bit.ly/3091xtv
(https://bit.ly/3091xtv)
I personally have watched Dave's eevblog videos with kicad and used that to knock off issues just by watching someone actually trying to use it which is something other videos such as tutorials don't really show you gripes.
And the mention of DipTrace has shown me yes, there actually is another control scheme that is possible, seriously, I have never seen it before and I bet other devs haven't either. Most people will have a legacy of one CAD tool lineage or another and thats it.
But this is what I mean by a description or reference.
The last word I heard almost directly from the KiCad team, was that keeping it multi platform/OS stable is their main focus. :palm: |O
I still have an headache from facepalming my head.
When both CERN and The Linux Foundation are both major funders of the project....what choice is there? CERN is going full removal of Microsoft internally.
And honestly, the cross platformness isn't too problematic. It really is macOS that struggles but it's usually given it's own hacks for macOS instead of breaking things for Linux and Windows.
Honestly, my biggest headache is all the pre Windows 10 users I would love to kick off. But those Windows 7 diehards just resist progress.
-
I lost my faith in KiCad, they just don't seem to be open minded to any feedback and (no offence)
We are. We prefer it in the issue tracker with _details_.
:-DD :-DD :-DD :-DD :-DD
I forgot to add some other point, now I know which one.
Sorry, rule two with marketing, don't expect that your customers will exactly tell you what to do in exactly the format you like.
Otherwise I could also just fix my plumbing issue myself, instead of calling for a plumber to fix it, right?
That's the same idea.
You, as a "company" or team have to subtract the main issues from people who are complaining.
Just thinking that they are just there to bash you, is just plain naive and maybe even a little arrogant.
Unfortunately, a lot of coders seem to be only able to think in ticking of buck tracking lists, aka; computer says no. :palm:
Anything else in an other format and they seem totally lost and helpless.
I am very sorry, but if you call KiCad's interface en user experience on par, you VERY clearly have never ever worked with professional EDA's
Maybe that sounds to blunt for some people, but I rather look the reality in the eye.
I am also more than happy to be proven wrong.
-
I am very sorry, but if you call KiCad's interface en user experience on par, you VERY clearly have never ever worked with professional EDA's
Maybe that sounds to blunt for some people, but I rather look the reality in the eye.
I am also more than happy to be proven wrong.
I have never said it was on par with anything in terms of quality.
But hey, at the end of the day you can't satisfy all "customers". It is why multiple commerical EDAs exist. Each one meets different needs and in different ways.
-
I am very sorry, but if you call KiCad's interface en user experience on par, you VERY clearly have never ever worked with professional EDA's
Maybe that sounds to blunt for some people, but I rather look the reality in the eye.
I am also more than happy to be proven wrong.
I have never said it was on par with anything in terms of quality.
But hey, at the end of the day you can't satisfy all "customers". It is why multiple commerical EDAs exist.
Obviously that wasn't directly meant to you, but just a general statement.
-
In most cad software...
Oh boy! That's a messy can of worms to tip over :)
It sure is, but for some things you have to find a compromise somewhere.
I like the way Altium implements drag selection: drag down and to the right selects anything completely enclosed, while dragging up and to the left selects anything with a part enclosed.
Same in KiCad. In Pcbnew (that is the PCB part of KiCad :) ) it already works this way for quite some time. Eeschema (The schematic part of KiCad :) ) is likely to follow with the next mayor update.
Small difference: KiCad only distinguishes with dragging left to right, or right to left. It don't care about up and down, that is up to you.
Proteus is a good example, having its roots in DOS and dragging that user interface into Windows with it, but over time (25 years or so) they changed to a more Windows-centric interface. Still not quite correct, but a lot better than it used to be.
KiCad ain't even 25 year old! It started as a hobby project from a university professor, and it's only really taking off in the last handful of years. Before that it was pretty buggy and development was much slower then now. KiCad is picking up development speed each year. Give KiCad a few more years (it won't need 25) and then see in what state it is. (The Proteus website claims it's over 30 years old).
What sort of comparison would you make between programs such as Proteus and Altium versus KiCad?
They're quite different beasts. At least I think so. I'm simply in no situation to afford a EUR 5000 Proteus license or Altium, which price I don't even dare look up. And when comparing prices, don't start with crippled 200 pin software or 80 sqare cm 2 layer boards. KiCad is no slouch. Some people are asking for updates on the 32 copper layer limit in KiCad. They were using 26 copper layers and were starting to worry about this limit. Others were complaining that KiCad was getting a bit slow on their i9 with a 10.000 footprint PCB. (Or was it hundredthousand?) The story is somewhere in the bug tracker on github. Maybe also migrated to Gitlab when KiCad switched.
Sorry, but isn't this obvious?
The whole issue is just all about priorities.
Get the basics done, make it that most people can use it, than work your *ss of to get a proper user interface that even my grandma understands.
Instead of wasting time in auto routers as well as schematic simulators and some multi platform/OS thing that is absolutely not important to anyone except an handful.
the first one is totally useless, the second one you're competing against LTSPice which has an ENORMOUS userbase, or Microcap which is also free nowadays and has been around for many years, the last one can be temporarily fixed with just WINE.
-
... the last one can be temporarily fixed with just WINE.
Sorry, while you're right (IMHO) about much, you're way off base there. That 'temporary' fix would be an almost perfect way of accumulating technical debt. If your aim is to be multiplatform (and that's a perfectly legitimate aim, one that everybody but the poor benighted souls who are stuck with a choice of Windows, Windows or Windows are grateful for) then targetting one platform and using a band-aid to let it run on others is a sure fire recipe for disaster. A lot of things will run under WINE, but won't run very smoothly and tend to have lots of UI glitches and more. You end up patching your code to make it work better with the band-aid, piling ugliness on ugliness, creating tech debt like it's going out of fashion.
I've done my fair share of ports (of commercial software) from Windows to other platforms and it's not pretty, not pretty at all. Designing for multiplatform from the get-go really is the only way to do it without storing up trouble for yourself in the future.
-
I tried every EDA I could get my hands on about 10 years ago. Decided they all suck, all of them have UIs that are terrible in one way or another. At this point though I know how to use KiCAD so I'd probably just be annoyed if they changed it. Also as someone else said, it isn't Windows software, it just happens to support Windows among other operating systems. I would not expect it to behave exactly like Windows, if it did then it would be inconsistent on other platforms.
-
The last word I heard almost directly from the KiCad team, was that keeping it multi platform/OS stable is their main focus. :palm: |O
I still have an headache from facepalming my head.
Who in his right mind is against cross-platform software? It's more work, but its the only sensible development model to be independent from commercial software vendors without sacrificing most of the userbase.
-
I would not expect it to behave exactly like Windows, if it did then it would be inconsistent on other platforms.
Doesn't have to be exactly like Windows, and it's going to be consistent on one or more platforms - that's a fact of multi-platform ability and the platforms be far apart. The point I was raising was that Windows had it about right, so having a great user interface just happens to be like Windows used to be.
By contrast, the way things currently seem to work is to make it not consistent to any platform. Does Linux or Mac have the drag-select-move thing I've been banging on about in here?
And while it is great and useful to be multi-platform, the overriding platform right now is and has been Windows. Linux on the desktop may have its day, but it's not yet (though Microsoft seem determined to push us there). Mac is still an also-ran. So if you have a choice and can't decide which way to fall, surely the way to go is where your largest potential user-base is?
-
Will you please stop banging on the drag-select-move thing.
You've been told, and confirmed by others that it already works this way for quite some time in Pcbnew, and is already implemented in the nightlies for Eeschema.
What do you mean with:
, so having a great user interface just happens to be like Windows used to be.
Windows ain't so great for you anymore?
So if you have a choice and can't decide which way to fall, surely the way to go is where your largest potential user-base is?
I am very happy that I'm able to not use windows.
-
You've been told, and confirmed by others that it already works this way for quite some time in Pcbnew, and is already implemented in the nightlies for Eeschema.
1. It may not be in PCBNew but, as mentioned before, we are talking Kicad.
2. I accept it is fixed in the nightlies.
3. I use it because it's an example. Doesn't matter if it was fixed 20 years ago, if one is looking for something to use as an example that we can all relate to, that's what an example is! Give me another example if you're too sensitive for this one.
Windows ain't so great for you anymore?
Are you kidding? Undiscoverable, hidden buttons, invisible window edges... The philosophy is just as bad: a universal interface for phones, tablets and desktops.
-
The last word I heard almost directly from the KiCad team, was that keeping it multi platform/OS stable is their main focus. :palm: |O
I still have an headache from facepalming my head.
Who in his right mind is against cross-platform software? It's more work, but its the only sensible development model to be independent from commercial software vendors without sacrificing most of the userbase.
Who said I am against it?
I am just thinking from a practical stand point of view.
If you look at the market, the amount of EE engineers that use anything else than Windows professionally is probably less than 5% maybe 10% at most.
One thing is certain, that market is NOT gonna change any time soon, even if you had the best possible software ever.
So making something cross-platform is very noble an probably more a (50-60s style) ideology, it's just not practical.
And it won't be practical anytime soon.
First gain enough momentum, as soon as you have enough of it, you can change things.
That's exactly the same strategy most successful companies use.
I repeat it once again, even if your software is free, you're still competing against paid software.
-
So making something cross-platform is very noble an probably more a (50-60s style) ideology, it's just not practical.
:-DD :-DD
In the 50s and 60s cross-platform wasn't even an idea, if you got a new computer, often even from the same manufacturer, you expected to have to re-write all your software. The idea of backward/upward compatibility within the same manufacturer's range didn't exist until the mid 60s, cross platform compatibility wasn't even on the cards.
And of course cross-platform is completely practical, if you know what you're doing. I used to look after four of the ports of an expert systems tool that ran on DOS, Windows, Vax VMS, SunOS, AIX, Apollo Domain and CTOS, so obviously I haven't a clue what I'm talking about. We managed to do that in the days (late 80s) when there weren't cross-platform toolkits to make the job easier (as there clearly are now) and working on a codebase that was originally written in FORTRAN with no regard to portability beyond DOS that used all sorts of hardware/OS 'tricks' that had to be re-engineered. If we (a small software house with two full-time developers) could practically manage to do it then, and get multiple platform products out of the door and working, then nowadays it ought to be a doddle in comparison.
Excuses for not doing cross-platform software development start with inexperience, and passes through a lot of other in- words like indifference, and in the worst cases ship up at incompetence. If I (not a superhuman coder) have managed to do it, others can.
-
So making something cross-platform is very noble an probably more a (50-60s style) ideology, it's just not practical.
In the 50s and 60s cross-platform wasn't even an idea,
:palm:
I was referring to the (pre) cold war and such, but I guess some people still live in the fairy tail of ideologies.
My apologies.
Obviously cross-platform wasn't a thing back than.
But yes, I do agree that something can only work if people know what they are doing
But at this moment I am a little confused, because it isn't a good EDA, nor a nice interface to work with.
So maybe they just wanted to make a cross-platform program, and we are all fooled believing it was a EDA? :-DD
-
Thats not how it would work with KiCad. >50% of main devs are Linux users to my knowledge, thus if one OS would be dropped, it would be Windows.
While KiCad is competing against propertiary software, its main focus is as with many OSS projects not to extend the userbase as far as possible (there is no revenue to increase), but serve their existing userbase (many OSS and OSH people, also mainly running Linux, who also make many of the contributions).
What is helping KiCad are people and companies who contribute to its development. From what I see, KiCad now comes into the range where there is momentum from companies starting to invest into its development, to serve their usecases better. This in turn improves the software for everyone and makes it interesting for more users and companies to help with its development.
While KiCad competes with other EDA vendors, the huge difference is that KiCad is a tool which can be used and improved by everyone, and not a product which is sold for an anual fee. Like with Blender or Linux, companies can cooporate in tool development while competing with their products. This reduces costs in the long term and increases quality, because you are not dependent on some nice company response. I think, this principle can create a momentum. Focusing on Windows would on the other hand reduce it drastically because the projects would loose developers (for example, I would not contribute to it if it would be Windows only).
-
This reduces costs in the long term and increases quality,
Ehm no that is not how it works.
It reduces "maybe" some costs short term.
A free program doesn't mean reducing costs.
Reducing costs would be making a program that is so easy to work with, without any bugs and a rock solid customer support to help you immediately when heaving issues with it.
And leaving a potential project just because it's not 100% your favorite flavor, sorry, I find that very silly and very unprofessional.
Than you're also only looking at short term goals.
-
And leaving a potential project just because it's not 100% your favorite flavor, sorry, I find that very silly and very unprofessional.
Than you're also only looking at short term goals.
That literally doesn't make any sense. One cannot leave something that is only a potential project. Unprofessional implies professional, which implies getting paid and we're talking about a largely volunteer effort. The last sentence makes no sense in its context, or possibly because of its context, even after correcting the typo.
I'm not making a rhetorical cry of "Nonsense!", I'm talking about literal nonsense as I, at least, can't work out what you're actually trying to say (based on a working assumption that what you're trying to say makes sense, even if people might disagree with it).
-
so obviously I haven't a clue what I'm talking about. We managed to do that in the days (late 80s) when there weren't cross-platform toolkits to make the job easier
I would hazard a guess that your ports used native paradigms? For instance, had Windows been around then you would have used the OS-supplied open/save dialogs rather than a roll-your-own that was ported to all supported platforms?
A bit of both - native where we could, a common look-and-feel for end user applications developed in the expert systems shell. It was possible to write interactive applications inside the expert systems shell - we opted to keep these looking the same on different platforms, so that customer applications would look familiar to them whether they were running them on DOS for broadly distributed applications or an expensive workstation for applications with truly heavy inference engine loads.
Code wise, it was mostly a thin adaption layer to native methods for things like open/save dialogues and windows for the 'programmer's UI' which was mostly a set of built in text and form editors for inference rules, frames (a paradigm for some expert/AI systems at the time) and a limited procedural language mostly associated with scripting user interaction. A surprisingly big library to deal with OS basics including read and writing files, and our own graphics library for the 'application UI'. That lot all got retargetted at the different back-ends but kept us making the same internal calls so that the core product was (in theory) code identical on all platforms. There was a lot of back-and-forth manual version control between the 'non-DOS' code and the 'DOS' code that got better over time as we back-ported the 'non-DOS' interfaces to the DOS code and the VMS code (which in modern version control terms had its own branch).
Windows 2.0 was around, and it was this we targetted for the initial Windows port, even selling a few copies, knowing that Windows 3.0 was on its way and (correctly) predicting that it would be a "big thing" (we had early access to Windows 3.0 and it was generally released near the end of my sojourn there). We had an unreleased part working OS/2 port too.
It was difficult. messy, but educational.
-
OK, thanks :)
-
This reduces costs in the long term and increases quality,
Ehm no that is not how it works.
It reduces "maybe" some costs short term.
You clearly misread this comment. Let's say an Altium licence costs 5.000$, and you have 10 seats. To replace your Altium seats with KiCad you need feature X, Y, Z,... (better routing tools, length-matching, etc.) which in turn requires, lets say, 2 man years in development time. This costs you for some time significantly more than Altium, but after that time you can, for example, go down to 5.000$ donations to KiCad each year to support development, instead of 50.000$ towards Altium. If there is a second company with similar requirements/goals, you can split the costs, and this scales quite well with enough interest from commercial side. Exemplary, Blender employs 20 developer out of regular donations.
And leaving a potential project just because it's not 100% your favorite flavor, sorry, I find that very silly and very unprofessional.
Than you're also only looking at short term goals.
That literally doesn't make any sense. One cannot leave something that is only a potential project. Unprofessional implies professional, which implies getting paid and we're talking about a largely volunteer effort. The last sentence makes no sense in its context, or possibly because of its context, even after correcting the typo.
Cerebus is right. I'm 100% Linux users, and I would have never started using a Windows only tool therefore, even less contributing to one. I would instead work on pcb_rnd, LibrePCB or Horizon now if KiCad was not there.
-
You clearly misread this comment.
Or maybe you miswrote it. ;)
-
And leaving a potential project just because it's not 100% your favorite flavor, sorry, I find that very silly and very unprofessional.
Than you're also only looking at short term goals.
That literally doesn't make any sense. One cannot leave something that is only a potential project. Unprofessional implies professional, which implies getting paid and we're talking about a largely volunteer effort. The last sentence makes no sense in its context, or possibly because of its context, even after correcting the typo.
I'm not making a rhetorical cry of "Nonsense!", I'm talking about literal nonsense as I, at least, can't work out what you're actually trying to say (based on a working assumption that what you're trying to say makes sense, even if people might disagree with it).
Professional also means "of high quality".
You can still act and work on an unpaid project, as if it's actually a professional product, even if that is based on a volunteer effort.
The size of KiCad is obviously a little bit more than taking care of goats at your local animal shelter, so I think you can also expect such professionalism.
-
Your context would seem to imply 'professional' in the sense of 'professional ethics' but the whole thing is so confused I can't be sure of that. You then confound that by talking about 'professional quality'. I'm simply asking you to put your ideas down in cogent form, not a mishmash, so that we can get what you're trying to say. Then we'll have some opportunity to either agree with you or dispute you.
-
You clearly misread this comment.
Or maybe you miswrote it. ;)
Indeed, it certainly wasn't clear to me that he was talking about the commercially supported mode/model that he clearly is talking about. I like to think that my English Comprehension skills are quite good (used to get top marks for that at school) but I'm having great difficulty trying to follow the arguments of some of the people in this thread.
-
This reduces costs in the long term and increases quality,
Ehm no that is not how it works.
It reduces "maybe" some costs short term.
You clearly misread this comment. Let's say an Altium licence costs 5.000$, and you have 10 seats. To replace your Altium seats with KiCad you need feature X, Y, Z,... (better routing tools, length-matching, etc.) which in turn requires, lets say, 2 man years in development time. This costs you for some time significantly more than Altium, but after that time you can, for example, go down to 5.000$ donations to KiCad each year to support development, instead of 50.000$ towards Altium. If there is a second company with similar requirements/goals, you can split the costs, and this scales quite well with enough interest from commercial side. Exemplary, Blender employs 20 developer out of regular donations.
And leaving a potential project just because it's not 100% your favorite flavor, sorry, I find that very silly and very unprofessional.
Than you're also only looking at short term goals.
That literally doesn't make any sense. One cannot leave something that is only a potential project. Unprofessional implies professional, which implies getting paid and we're talking about a largely volunteer effort. The last sentence makes no sense in its context, or possibly because of its context, even after correcting the typo.
Cerebus is right. I'm 100% Linux users, and I would have never started using a Windows only tool therefore, even less contributing to one. I would instead work on pcb_rnd, LibrePCB or Horizon now if KiCad was not there.
yes, and now take the same look at the wages and hourly rate, because these engineers don't work for free.
10 engineers will cost you at least 700k to 1 million a year (that's on the low side).
That $50000 is not even a significant amount, especially not being spread over multiple years.
For one year that is around 8% compared to the wages (and that is assuming you have ONLY engineers working)
Also even deductible from taxes etc. that will go down to maybe 2-3% of the total costs.
Other technical costs like equipment and prototyping not included.
Not even considering the lack of trust in a specific piece of software, and all financial damages or worse (failing products).
Even with all the bugs involved, Altium has a proven record, if I call them today they will sort things out with me.
On top of that those engineers have many many years of experience in the software they are using.
To get them up to the same level (assuming we can convince them easily, which is not going to be an easy case), that would also take at least half a year to a year.
Assuming the alternative (KiCad in this case) has all the same qualities (which currently is very far from it).
So that will cost me another 200k-400k, time being put in teaching those engineers.
That's quit some years of paid licenses without running all the other risks.
The only use case I see for KiCad is for small companies, if they change the GUI at least.
With maybe just one or two engineers, producing 2-5 new designs or iterations a year of (very) simple designs (full board and old design conversions don't work on KiCad, tried many times)
But my experience is that these people also need a GUI that is much more usable.
They don't have the time to just make any mistake because it's all on them, so they naturally select something they are familiar with or at least feels familiar.
That's either Eagle, Altium, or something that feels similar like Protel 99
At these companies there is no or very little budget for taking courses, or spending a lot of time (with all the risks involved) to swap to a totally new program.
For this reason, I see a lot more in something like Diptrace, because it feels and looks very familiar.
-
Your context would seem to imply 'professional' in the sense of 'professional ethics' but the whole thing is so confused I can't be sure of that. You then confound that by talking about 'professional quality'. I'm simply asking you to put your ideas down in cogent form, not a mishmash, so that we can get what you're trying to say. Then we'll have some opportunity to either agree with you or dispute you.
I think my context is very clear if you look for people who have knowledge and skills to perform a task a make a good working product.
A good skilled professional engineer would be capable to put his own opinions aside and still finish his task.
Even if he doesn't agree fully with everything.
Like I said cross-platform is nothing more than a noble ideology (which I am even big fan of btw!!), just not reality and especially shouldn't be high on a list of priorities if you want to make a good working product.
I have absolutely no idea why I have to explain that over and over again and people being silly of the choosing of words.
-
yes, and now take the same look at the wages and hourly rate, because these engineers don't work for free.
10 engineers will cost you at least 700k to 1 million a year (that's on the low side).
That $50000 is not even a significant amount, especially not being spread over multiple years.
For one year that is around 8% compared to the wages (and that is assuming you have ONLY engineers working)
Also even deductible from taxes etc. that will go down to maybe 2-3% of the total costs.
Other technical costs like equipment and prototyping not included.
Not even considering the lack of trust in a specific piece of software, and all financial damages or worse (failing products).
Even with all the bugs involved, Altium has a proven record, if I call them today they will sort things out with me.
On top of that those engineers have many many years of experience in the software they are using.
To get them up to the same level (assuming we can convince them easily, which is not going to be an easy case), that would also take at least half a year to a year.
Assuming the alternative (KiCad in this case) has all the same qualities (which currently is very far from it).
So that will cost me another 200k-400k, time being put in teaching those engineers.
That's quit some years of paid licenses without running all the other risks.
The only use case I see for KiCad is for small companies, if they change the GUI at least.
With maybe just one or two engineers, producing 2-5 new designs or iterations a year of (very) simple designs (full board and old design conversions don't work on KiCad, tried many times)
But my experience is that these people also need a GUI that is much more usable.
They don't have the time to just make any mistake because it's all on them, so they naturally select something they are familiar with or at least feels familiar.
That's either Eagle, Altium, or something that feels similar like Protel 99
At these companies there is no or very little budget for taking courses, or spending a lot of time (with all the risks involved) to swap to a totally new program.
For this reason, I see a lot more in something like Diptrace, because it feels and looks very familiar.
So your argument seems to be that KiCad is an irrelevance and that people should just use Eagle/Altium/Protel/Diptrace 'because economics and first mover advantages'. Why then are you even debating in a thread that, in essence, is "the KiCad UI needs improving"?
-
A good skilled professional engineer would be capable to put his own opinions aside and still finish his task.
No, a paid engineer can just "shut up, do your job and take the money", a volunteer is only going to volunteer for things he feels worthwhile and agrees with. :palm:
-
yes, and now take the same look at the wages and hourly rate, because these engineers don't work for free.
10 engineers will cost you at least 700k to 1 million a year (that's on the low side).
That $50000 is not even a significant amount, especially not being spread over multiple years.
For one year that is around 8% compared to the wages (and that is assuming you have ONLY engineers working)
Also even deductible from taxes etc. that will go down to maybe 2-3% of the total costs.
Other technical costs like equipment and prototyping not included.
Not even considering the lack of trust in a specific piece of software, and all financial damages or worse (failing products).
Even with all the bugs involved, Altium has a proven record, if I call them today they will sort things out with me.
On top of that those engineers have many many years of experience in the software they are using.
To get them up to the same level (assuming we can convince them easily, which is not going to be an easy case), that would also take at least half a year to a year.
Assuming the alternative (KiCad in this case) has all the same qualities (which currently is very far from it).
So that will cost me another 200k-400k, time being put in teaching those engineers.
That's quit some years of paid licenses without running all the other risks.
The only use case I see for KiCad is for small companies, if they change the GUI at least.
With maybe just one or two engineers, producing 2-5 new designs or iterations a year of (very) simple designs (full board and old design conversions don't work on KiCad, tried many times)
But my experience is that these people also need a GUI that is much more usable.
They don't have the time to just make any mistake because it's all on them, so they naturally select something they are familiar with or at least feels familiar.
That's either Eagle, Altium, or something that feels similar like Protel 99
At these companies there is no or very little budget for taking courses, or spending a lot of time (with all the risks involved) to swap to a totally new program.
For this reason, I see a lot more in something like Diptrace, because it feels and looks very familiar.
So your argument seems to be that KiCad is an irrelevance and that people should just use Eagle/Altium/Protel/Diptrace 'because economics and first mover advantages'. Why then are you even debating in a thread that, in essence, is "the KiCad UI needs improving"?
No that is clearly not my argument.
My argument is that if you want to at least people to use it, you should make the transition of what they now use as smooth as possible.
A proper graphical user interface is a very important step in that process.
It doesn't have to be fancy and pretty, as long as it's similar and familiar with what people use.
Once you have people on board, THAN you can move to these other things and add or change features.
That's is just simply a matter of priorities.
-
A good skilled professional engineer would be capable to put his own opinions aside and still finish his task.
No, a paid engineer can just "shut up, do your job and take the money", a volunteer is only going to volunteer for things he feels worthwhile and agrees with. :palm:
And people expect that they are going to agree on everything?
Good luck with finding volunteering jobs.
Like I said, I don't see a size project like KiCad as taking care of cute little goats on a farm.
So that automatically means you can expect some kind of responsibilities as well as professionalism.
In very similar volunteer projects, the only difference vs a paid job, is the fact that people can just leave whenever they want, have less time and are not being paid.
(although in certain countries paid people can also leave whenever they want)
I have even seen teams who work ten times more professional vs paid.
-
No that is clearly not my argument.
That may not be your argument, but it's not "clearly not [your] argument".
My argument is that if you want to at least people to use it, you should make the transition of what they now use as smooth as possible.
A proper graphical user interface is a very important step in that process.
It doesn't have to be fancy and pretty, as long as it's similar and familiar with what people use.
Once you have people on board, THAN you can move to these other things and add or change features.
That's is just simply a matter of priorities.
Now that is clear. Why not just say that rather than all the circumperambulations around economics etc.?
I would, on that basis, disagree with your:
It doesn't have to be fancy and pretty, as long as it's similar and familiar with what people use.
Most sane people's thesis is that all CAD software has crap user interfaces, KiCad being at least as bad, if not possibly worse, than the others. The argument is "let's make a decent user interface", not "let's copy or largely replicate a familiar (but still crap) user interface".
-
A good skilled professional engineer would be capable to put his own opinions aside and still finish his task.
No, a paid engineer can just "shut up, do your job and take the money", a volunteer is only going to volunteer for things he feels worthwhile and agrees with. :palm:
And people expect that they are going to agree on everything?
Good luck with finding volunteering jobs.
Like I said, I don't see a size project like KiCad as taking care of cute little goats on a farm.
So that automatically means you can expect some kind of responsibilities as well as professionalism.
In very similar volunteer projects, the only difference vs a paid job, is the fact that people can just leave whenever they want, have less time and are not being paid.
(although in certain countries paid people can also leave whenever they want)
I have even seen teams who work ten times more professional vs paid.
What? Do you think that people are running around looking for volunteer jobs like they do paid jobs? One you need to live, the other you do because you agree with the aims and methods of the project your are volunteering for, or you don't volunteer for it.
It's not the bloody army - "I want three volunteers. You, you and you." "Yes Sarge!" "Yes Sarge!" "Yes Sarge!". I'm beginning to suspect that you might be one of life's natural Second Lieutenants. :)
-
No that is clearly not my argument.
That may not be your argument, but it's not "clearly not [your] argument".
My argument is that if you want to at least people to use it, you should make the transition of what they now use as smooth as possible.
A proper graphical user interface is a very important step in that process.
It doesn't have to be fancy and pretty, as long as it's similar and familiar with what people use.
Once you have people on board, THAN you can move to these other things and add or change features.
That's is just simply a matter of priorities.
Now that is clear. Why not just say that rather than all the circumperambulations around economics etc.?
I would, on that basis, disagree with your:
It doesn't have to be fancy and pretty, as long as it's similar and familiar with what people use.
Most sane people's thesis is that all CAD software has crap user interfaces, KiCad being at least as bad, if not possibly worse, than the others. The argument is "let's make a decent user interface", not "let's copy or largely replicate a familiar (but still crap) user interface".
I literally said all these things before.
The economics part is making people understand the why, and mostly the why as in; I am NOT talking about personal preference, but just facts.
I don't even like or agree with these facts, but unfortunately that is just how the world operates.
You as a tiny organisation (KiCad, and yes, relativity speaking it's a speck of dust) is not going to change that any time soon.
People, ESPECIALLY engineers, need to understand that their personal ideas (what I call ideologies) are subordinate to the bigger picture.
That doesn't mean you shouldn't have them, or censor them, it means that if you want to have a successful product, you need to understand who or what you are battling against.
Just dumping something on peoples laps and expect them they are going to like it, doesn't work.
That is even more true with engineers.
About the interface; either be (much) better, or just copy.
Don't be as worse and totally different.
That's a lose-lose situation.
Especially when your only selling point left is that it's free.
My piece of advice, is diving into some books or lectures about peoples behavior, psychology and marketing etc.
And yes that is still applicable to free things. In the end you're s till competing one way or another.
-
It doesn't have to be fancy and pretty, as long as it's similar and familiar with what people use.
Most sane people's thesis is that all CAD software has crap user interfaces, KiCad being at least as bad, if not possibly worse, than the others. The argument is "let's make a decent user interface", not "let's copy or largely replicate a familiar (but still crap) user interface".
What is familiar? Eagle, KiCad, Target 3001!, Altium? Each of them has different UX principles and internal data models. I started with Target 3001! and found it nice to work with, then had to learn Eagle due to school and hated it in the beginning until I were able to make sensible results and quite a few PCB's. After that I went full OSS and had problems with the KiCad UI as well, until it made click and I understood the advantages of their UI design. (I'm no longer able to use Eagle productive, and find the UI of Target 3001! awful and old-school now though).
From what I have seen, there are people hating the UI of KiCad, I know people which prefer it over the one of Eagle and Altium. It's their preference, and those things are highly subjective. My opinion is it works already quite well, when you understood the basic principles it is a powerful UI, and with each major release there are notable improvements.
-
My piece of advice, is diving into some books or lectures about peoples behavior, psychology and marketing etc.
And yes that is still applicable to free things. In the end you're s till competing one way or another.
How delightfully patronising of you. I'd suggest that someone who lectures someone whose background they don't know about "diving into some books or lectures about peoples behavior, psychology and marketing etc" is more in need of instruction in how to handle the psychology of other people than anybody they might be lecturing.
I personally hate an argument from authority or argument from experience, but as I'm essentially being accused of naïvety and/or inexperience I think I'll permit myself to use one for once. I've spent nearly 45 years designing, programming, organizing, marketing and selling software and services (punctuated by a few years as a tech journalist), quite successfully I might add, with plenty of happy customers over the years. I've provided consultancy services to household names, served as a non-exec director on the board of a national trade body and on one of the advisory boards of another. What does your CV look like to put you in the position to lecture so?
Your problem is that you disagree with me, and you don't seem to know how to argue your point without resorting to an ad-hominem attack. Let's put aside the generally accepted principle that switching to ad-hominem means you've already lost your argument. On the balance of probabilities my professional experience, versus your inability to even martial an argument into proper paragraphs or get a verb to agree with the pronoun you're using, would seem to suggest that one of us is better placed to make a judgement than the other.
-
My piece of advice, is diving into some books or lectures about peoples behavior, psychology and marketing etc.
And yes that is still applicable to free things. In the end you're s till competing one way or another.
How delightfully patronising of you. I'd suggest that someone who lectures someone whose background they don't know about "diving into some books or lectures about peoples behavior, psychology and marketing etc" is more in need of instruction in how to handle the psychology of other people than anybody they might be lecturing.
I personally hate an argument from authority or argument from experience, but as I'm essentially being accused of naïvety and/or inexperience I think I'll permit myself to use one for once. I've spent nearly 45 years designing, programming, organizing, marketing and selling software and services (punctuated by a few years as a tech journalist), quite successfully I might add, with plenty of happy customers over the years. I've provided consultancy services to household names, served as a non-exec director on the board of a national trade body and on one of the advisory boards of another. What does your CV look like to put you in the position to lecture so?
Your problem is that you disagree with me, and you don't seem to know how to argue your point without resorting to an ad-hominem attack. Let's put aside the generally accepted principle that switching to ad-hominem means you've already lost your argument. On the balance of probabilities my professional experience, versus your inability to even martial an argument into proper paragraphs or get a verb to agree with the pronoun you're using, would seem to suggest that one of us is better placed to make a judgement than the other.
In some cultures it's actually seen as something positive and constructive instead, I guess not for others.
My bad if you see it so negative as "authority" instead of asking for clarification.
Ever thought of that?
No, my problem is that people mix up their personal believes with factual reality.
In combination with constantly nitpicking details that are totally not important for the discussion.
I have never been "short of arguments", and out of respect and professionality I would also never ever call people that way or use disrespectful words like ad-hominem etc.
Nor would I never say something about how they phrase things, or speak, especially if they aren't native speakers.
Apparently other people do including playing blame games
As an scientist and engineer, I would like to understand the reality to solve problems.
But apparently literature in other scientific fields doesn't count and are just ways to fill paper?
I rather would like to have a constructive conversation, where people try to understand each other points of view, instead of fighting them.
So instead of already thinking that something is BS, wonder why people are unhappy (with an user interface in this very specific example)
But in these kind of subjects that seems to be close to impossible.
Saying with a very similar background and experience.
So it's easy, if it can't be constructive, I will just leave it for what it is.
No offence from my side, people just have different opinions, no reason to be offended for something like this.
-
It doesn't have to be fancy and pretty, as long as it's similar and familiar with what people use.
Most sane people's thesis is that all CAD software has crap user interfaces, KiCad being at least as bad, if not possibly worse, than the others. The argument is "let's make a decent user interface", not "let's copy or largely replicate a familiar (but still crap) user interface".
What is familiar? Eagle, KiCad, Target 3001!, Altium? Each of them has different UX principles and internal data models. I started with Target 3001! and found it nice to work with, then had to learn Eagle due to school and hated it in the beginning until I were able to make sensible results and quite a few PCB's. After that I went full OSS and had problems with the KiCad UI as well, until it made click and I understood the advantages of their UI design. (I'm no longer able to use Eagle productive, and find the UI of Target 3001! awful and old-school now though).
From what I have seen, there are people hating the UI of KiCad, I know people which prefer it over the one of Eagle and Altium. It's their preference, and those things are highly subjective. My opinion is it works already quite well, when you understood the basic principles it is a powerful UI, and with each major release there are notable improvements.
Gah! The old "UIs are highly subjective" argument. No, they are not, not in first instance. UIs are good and bad by objective criteria, in the first instance. There's a whole body of work on UI usability that objectively quantifies how some are better and some are worse in terms of the effort applied by the user to get the UI to effect the results they are trying to achieve. At the next level, sure, which people prefer is subjective, but first and foremost surely must be measurements of effort, both in day-to-day use and in 'effort to learn'.
An example. The decision to put the menus on the Macintosh (and I'm talking 1984 here) at the top of the screen versus the top of the application window (à la Windows and other WIMP interfaces at the time) was driven by empirical research that people moved the mouse to a menu that stayed in the same absolute position on the screen much faster and more accurately than they did to a menu that was in a fixed relative position. At times I've used Macs and Windows side by side and, despite being much more familiar with Windows at the time, found this born out in experience, the Mac UI was faster to use.
Another example. The whole 'place a component' paradigm is wrong in most schematic capture packages. Set yourself a challenge, draw a simple schematic with pencil and paper. Then draw that schematic in both LTSpice and the schematic capture package of your choice, timing yourself. This is obviously only fair if you already know LTSpice as well as your chosen schematic capture package, but I suspect most folks do. My expectation is that you will complete the schematic in LTSpice faster. Why, because it makes the common 'place a resistor', 'place a capacitor' tasks fast and easy, most schematic capture packages make it harder. This is an objectively measurable difference and figure of merit.
-
because it makes the common 'place a resistor', 'place a capacitor' tasks fast and easy
I think the important thing there is how it makes it fast and easy. Consider someone used to, say, Kicad and not LTSpice - they will be placing things almost without thinking (perhaps - it seems to me the interface demands too much consideration, but go with it). You could then say Kicad has made things fast and easy, but without saying how and why it's not very meaningful.
There is also fast and easy for new, middling, and expert users, each being different. The new user will appreciate perhaps a popup list of components to pick from whereas the expert might prefer a magic keystroke. Again, it's not really enough to say that one is faster and/or easier without explaining why it is so.
-
Pictures of common components on the toolbar. LTSpice is so ubiquitous on here I'm surprised I need to point this out; my wrong assumption, but it still surprises me.
(https://external-content.duckduckgo.com/iu/?u=http%3A%2F%2Fwww.jenrathbun.com%2FElectronics%2Fwp-content%2Fuploads%2F2013%2F12%2FLTSpice-Initial-Load.jpg&f=1&nofb=1)
-
LTSpice is so ubiquitous on here I'm surprised I need to point this out;
I think the thrust of my comment was missed, then.
-
No, but if you've used both it's clear which will get the job done faster. If you haven't then sorry, but you need to actually try it. The alternative would be for me to spend a day writing up a usability report on the 'challenge task'. Guess what, that's not happening.
-
Rejoice, the nightly / v6 now has click on component anchors to immediately start drawing wires.
Click-drag on components is also partially there now by default.
-
Well done :-+
-
For what it's worth, I find it funny that people want a Windows experience and hold up LTSpice as an example >:D.
John
-
For what it's worth, I find it funny that people want a Windows experience and hold up LTSpice as an example >:D.
John
Haha, true :D
-
Regarding the "give me a toolbar of common components" suggestion:
Well what is a common component? Spice has it easy. These are just the primitives of it. But what is common for a PCB design tool? I mean a resistor could be, but a resistor is represented by some symbol in some library. You might be satisfied with the symbol in the Device library that comes with kicad but somebody else might have their own symbol defined (for example they have symbols for every possible resistor that they have in stock. Fully filled out with order information and a footprint pre assigned. Somebody else might have a set of partially defined resistors in the lib like for example one for a 0805 imperial; 1% tolerance; 75V and one for 0603 imperial; 1% 50V ... And yet another person has the crazy idea of wanting all libraries local to the project including the symbol for a resistor)
And a similar problem exists for every component out there. What you define as common is not very likely common to somebody else. So if there would be a tool to easily add common components, then this tool must be highly configurable. This increases the implementation complexity quite considerably. And to be honest I am not even convinced that it will really save that much time for most users (in the grand scheme of things). After all drawing the schematic itself is one of the fastest tasks no matter how bad the editor is. The longest task of designing a project (at least for me) is deciding which exact components to use, especially as this in most cases means making decisions about what tradeoffs to make. Anything that would help with this part is therefore much more likely to save time than reducing adding a resistor down from lets say ["ctrl+a"->enter "R" into already highlighted filter field->click on resitor or just press "enter"] to [click on resitor in toolbar]. (and in current nightly you don't even need the ctrl key. Just use "a"->"r"->"enter")
-
Hmm. Someone who doesn't regard a resistor as a universal component, found in every non-trivial circuit design ever. A [different] symbol for every resistor in stock? I think someone doesn't understand the very essence of a schematic diagram. Confounding "symbol" and "complete component specification in the database" is an indication of some very off thinking.
In my mind when I draw a schematic I go "I need a resistor", then once I've got "a resistor", I go on to draw the next component. Only later do I go "that resistor needs to be 10K", and then "1/8W", and then "0802", and "1%". What I don't do is go "I want to draw a 10K 1/8W 1% 0802 resistor from Vishay" in one breathless thought the first time I encounter the need for a resistor there in the circuit. Ditto "NPN transistor" not "2N3055 in a TO-3(P) case from Motorola, high hFE variant, packaged in tubes, in 50s". People should not be made to think in such concrete detailed terms while doing a relatively abstract task. We call it "capturing the schematic", not "filling in every detail but the physical layout and the tracks on the board".
I may know all that detailed stuff in advance, I probably do, but when drawing a schematic I don't want to be bothered with the details of each and every component, just the big picture. I'll do the details once I've got a whole to pin them on. You draw the schematic, then you specialise it as to component values, then as to other characteristics. You don't think about the individual footprints and the minutiae as you draw the whole. Just as when I wrote this screed - I picked the words, and I only went and added the formatting flourishes once there was a whole linguistic picture.
Just to get you thinking. Someone produces a schematic in KiCad. Someone else comes along and says "I need you to convert all the symbols in this schematic into IEC standard ones" (Which by the way is completely realistic. An American would probably use ANSI symbols in first instance, their new European customer might insist on IEC symbols.) How do they do that? Remember, the actual circuit hasn't changed one jot, neither has any component characteristic. All that needs to change is the symbolic representation of the components in visual form.
-
Hmm. Someone who doesn't regard a resistor as a universal component, found in every non-trivial circuit design ever. A [different] symbol for every resistor in stock? I think someone doesn't understand the very essence of a schematic diagram.
Except, go to wikipedia and lookup the article entry for a resistor. You will find there is no universal symbol for a resistor. Instead there are two distinct, and widely accepted symbol representations that are commonly used.
So a choice must be exposed somewhere, otherwise the end-user is unnecessarily constrained. Next you have a decision as to size - should a 5W current sense resistor receive the same visual emphasis in a schematic as a bias/pull-up. What if the resistor is part of a resistor array component. etc.
A workflow that works for me - is to pull my most common representations and choices into my own library. That has two advantages. Firstly I get the representations, designators and choice restrictions I/my org want and use most frequently. And secondly it provides a navigation shortcut for fast selection when populating items on a schematic.
I don't want to be bothered with the details of each and every component, just the big picture.
Following the same approach - Use or create generic symbol representations for popular components - eg. bipolars, fets, generic dual/quad op-amps and comparators, etc.
That way - you can complete a full PCB indicating only the necessary footprints - ie sot-23 versus dpak, soic versus dip etc, but without having to drill down and specify actual manufacturers parts or even values if you want.
I do this all the time. Leave the choice of current limiting resistor until later, when I actually pick a led and color with associated voltage drop. Or delay the op-amp choice until I have test data about performance. In most cases only the footprint matters.
That's a ton of design flexibility, while not particularly increasing gui/workflow complexity.
-
Instead of some of the examples I gave, I should have used your example for a resistor.
The genericity / specificity tradeoffs that you prefer, are quite easy if you are willing to create your own library. And by that, I mean mostly just copy/paste from defaults - while restricting choice to preferred representations, and editing for size, designators etc for common components.
I have a generic resistor that I use everywhere - it gets the minimalistic designator "R" in my library as a default - so it's quick to find, and use.
It has the sawtooth view, because I hate the ugly square box, and small because I almost never want to give a resistor visual emphasis. But stylistically, these are personal preferences. If I hand the project on to someone who wants something else, they can edit, and the changes will propagate across project schematics.
I do complete schematics using only this "R" symbol - without ever specifying actual values - resistance, tolerance, rating, manufacturer. super generic.
I have also done complete pcbs with the only additional criteria being a smd footprint - all other component choices are delayed until I have the physical board in my hands and am ready to solder.
That is a high-abstraction workflow. And it is easily supported.
-
Hmm. Someone who doesn't regard a resistor as a universal component, found in every non-trivial circuit design ever. A [different] symbol for every resistor in stock? I think someone doesn't understand the very essence of a schematic diagram.
Except, go to wikipedia and lookup the article entry for a resistor. You will find there is no universal symbol for a resistor. Instead there are two distinct, and widely accepted symbol representations that are commonly used.
Yes, two, count them, two, but here are not different symbols for each and every possible value and type of resistor. Read things in context, please. Vis:
...but somebody else might have their own symbol defined (for example they have symbols for every possible resistor that they have in stock. Fully filled out with order information and a footprint pre assigned. Somebody else might have a set of partially defined resistors in the lib like for example one for a 0805 imperial; 1% tolerance; 75V and one for 0603 imperial; 1% 50V ...
A sane system is, click on resistor tool, slap down a resistor, default to whatever basic graphic is set globally {ANSI, IEC, Man-From-Mars}, worry about the details later. A non-sane scheme is start placing a component (either clicking on an op-amp symbol or hitting the 'a' key), and be faced with this choice:
(https://www.eevblog.com/forum/kicad/alternatice-ui/?action=dlattach;attach=1090808;image)
and have to dig through 14,854 possible components to get to the humble omni-present resistor. What is quicker, making common components immediately accessible, or requiring this palaver for every component?
So a choice must be exposed somewhere, otherwise the end-user is unnecessarily constrained. Next you have a decision as to size - should a 5W current sense resistor receive the same visual emphasis in a schematic as a bias/pull-up.
Now you're just being silly. What proportion of schematics have you ever seen with that feature?
-
A sane system is, click on resistor tool, slap down a resistor, default to whatever basic graphic is set globally {ANSI, IEC, Man-From-Mars}, worry about the details later.
See my other comment, that I believe addresses exactly this point.
-
A sane system is, click on resistor tool, slap down a resistor, default to whatever basic graphic is set globally {ANSI, IEC, Man-From-Mars}, worry about the details later.
See my other comment, that I believe addresses exactly this point.
No it doesn't. It effectively says "To make this tool usable you must heavily customise it, don't expect it to be easy to use out of the box for the very basic task of drawing a schematic. Please learn it and then fix it for yourself". I'd hate to see the UI you'd come up with for a general purpose drawing tool like Illustrator, CorelDraw or InkScape. Presumably there would be a line tool and a graphic tool, and then if you wanted a simple circle or rectangle tool you'd have to customise the graphic tool (after leaning how to use it) and your excuse for this would be along the lines of "It can draw any graphic, and it isn't for us to look at what people draw and make any judgements about common graphics that they draw".
I despair at any possibility of getting this basic "usability" idea into the collective heads of the KiCad crowd.
-
Hmm. Someone who doesn't regard a resistor as a universal component, found in every non-trivial circuit design ever. A [different] symbol for every resistor in stock? I think someone doesn't understand the very essence of a schematic diagram. Confounding "symbol" and "complete component specification in the database" is an indication of some very off thinking.
I think this is a view of schematic diagrams from 4 decades ago. Modern professional designs detail component specifications to the dot, that information is transfered to design review, quality control, manufacturing and other departments. You don't waste time placing "resistors", instead immediately open a company library that has previously used parts with all that data immediately attached to the symbol.
Just to get you thinking. Someone produces a schematic in KiCad. Someone else comes along and says "I need you to convert all the symbols in this schematic into IEC standard ones" (Which by the way is completely realistic. An American would probably use ANSI symbols in first instance, their new European customer might insist on IEC symbols.) How do they do that? Remember, the actual circuit hasn't changed one jot, neither has any component characteristic. All that needs to change is the symbolic representation of the components in visual form.
I would consider it poor engineering practice to make such a radical visual change to a schematic for simple updates. The symbol standard should have been defined at the start of the job. Changing it afterwards comes with the risk of stupid issues that shouldn't exist arising and requiring full requalification of a design.
-
I despair at any possibility of getting this basic "usability" idea into the collective heads of the KiCad crowd.
Sorry to say that, but you fell into the standard UX pit of: my approach is the right one.
KiCad is not a drawing tool for schematics as you would draw them for a book. Nor is it a tool to draw schematics for simulation, where you do not care if you can order that part. KiCad is there to build pcbs, and its long term goal is professional usage. And thats where database part libraries reside (planned for KiCad v7). Or nowadays, atomic libraries, when you want to have fully specified library symbols in KiCad as required by many business.
Optimizing you usecase makes KiCad behave more like a toy for electronic beginners, but not for people who care about the parts they need to order in the future.
For your use-case: place a resistor once, and duplicate it when you need a second one. Should be fast enough and works for every part, not only the "standard" ones.
-
There is an open issue now discussing the toolbar and the implications of it: https://gitlab.com/kicad/code/kicad/-/issues/6028
-
Hmm. Someone who doesn't regard a resistor as a universal component, found in every non-trivial circuit design ever. A [different] symbol for every resistor in stock? I think someone doesn't understand the very essence of a schematic diagram. Confounding "symbol" and "complete component specification in the database" is an indication of some very off thinking.
I think this is a view of schematic diagrams from 4 decades ago. Modern professional designs detail component specifications to the dot, that information is transfered to design review, quality control, manufacturing and other departments. You don't waste time placing "resistors", instead immediately open a company library that has previously used parts with all that data immediately attached to the symbol.
I am talking about the usability aspects of drawing the schematic, in a tool, not the whole production process. Are you really going to tell me that in drafting a schematic, you always specify each and every possible parameter of a component (unless a tool forces you to , like KiCad)? Are you so 'modern' that you never draw a schematic with a paper and pencil, and when you do, is it logical to draw the schematic as a whole and then annotate it, or completely annotate every component symbol as you draw it?
Just to get you thinking. Someone produces a schematic in KiCad. Someone else comes along and says "I need you to convert all the symbols in this schematic into IEC standard ones" (Which by the way is completely realistic. An American would probably use ANSI symbols in first instance, their new European customer might insist on IEC symbols.) How do they do that? Remember, the actual circuit hasn't changed one jot, neither has any component characteristic. All that needs to change is the symbolic representation of the components in visual form.
I would consider it poor engineering practice to make such a radical visual change to a schematic for simple updates. The symbol standard should have been defined at the start of the job. Changing it afterwards comes with the risk of stupid issues that shouldn't exist arising and requiring full requalification of a design.
Aside from the fact that in real life 'unreasonable' demands like this intervene (you would not turn down a £100 million order from some countries military who insist on a particular symbology because "Our processes don't allow us to change the symbol set on a drawing") this is merely to get the programmer in question thinking about the mechanics of this. This ought to be a drawing level setting of "use symbol set \$x\$" both for usability/functionality reasons and also because (for anyone who realises that the parts are going to end up in a database) it's the sane way to build the data structures. (SELECT symbol_drawing FROM standard_symbols WHERE basic_part_type = "R" AND symbol_set = "ANSI"; ).
Even though the whole 'requalifaction' thing is a red herring, it should not need to be said that a process that insists on a complete requalification of a design for the drawing equivalent of 'using a different font to print this out for customer X' is a broken process.
-
I despair at any possibility of getting this basic "usability" idea into the collective heads of the KiCad crowd.
Sorry to say that, but you fell into the standard UX pit of: my approach is the right one.
No I didn't. It's just convenient for you to say that so that you can continue thinking that your approach is the right one. Yes, it's hard to have your baby criticised, especially when someone says that your whole UI is riddled with usability problems and needs a radical overhaul.
KiCad is not a drawing tool for schematics as you would draw them for a book. Nor is it a tool to draw schematics for simulation, where you do not care if you can order that part. KiCad is there to build pcbs, and its long term goal is professional usage. And thats where database part libraries reside (planned for KiCad v7). Or nowadays, atomic libraries, when you want to have fully specified library symbols in KiCad as required by many business.
Optimizing you usecase makes KiCad behave more like a toy for electronic beginners, but not for people who care about the parts they need to order in the future.
There is no tension between "make the drawing bit easy" and "make it possible to fully specify components". To get the latter it is not necessary to make "drawing" an exercise in "selecting components from a database". You're thinking of the schematic capture tool as a "produce a netlist containing wires and references to a database of components" tool, which it is under the skin, but on that skin you've quite deliberately put a schematic drawing interface. If you're really so wedded to the idea that it's being a "select parts from a database" tool is overridingly important and the drawing bit is an annoying irrelevance, why bother with this drawing at all. Make 'em select all their components from the database and only then let them draw any wires or move components about. That would be ridiculous wouldn't it? Why so resistant to making the drawing easy with good usability? Looks to me that you can't see the wood for the trees.
For your use-case: place a resistor once, and duplicate it when you need a second one. Should be fast enough and works for every part, not only the "standard" ones.
For a start it's not a use-case, it's a UI usability case, inability to tell the two apart is telling; as is dropping into business analyst-ese with phrases like "use case".
Every time, every bloody time, someone says to fanboy contributors of program x "It would be better if the UI did this like that" the fanboys say "Oh, you can do that [the functional equivalent] by <series of moves in existing UI>" thereby completely missing the point. Just because something is functionally possible doesn't mean that it satisfies usability criteria.
I've been a programmer for 45 years, since the bloody punch card era. If I was as resistant to improving usability as you guys seem to be I'd still be insisting that my customers used punch cards. "No, look, you CAN change the customer field. Just pull the 3rd card out of the batch, walk over to the punch/duplicator, hit COPY for the first twenty columns, then type the new customer name, and then keep hitting copy until the end of the card. Then put the card back into the stack. See, no need for fancy mice or screens. Not as easy for you, you say. Well if you want a millennial toy rather then a professional tool I suppose it's alright, but we produce professional tools." Sound familiar?
-
I despair at any possibility of getting this basic "usability" idea into the collective heads of the KiCad crowd.
Sorry to say that, but you fell into the standard UX pit of: my approach is the right one.
No I didn't. It's just convenient for you to say that so that you can continue thinking that your approach is the right one. Yes, it's hard to have your baby criticised, especially when someone says that your whole UI is riddled with usability problems and needs a radical overhaul.
I never said KiCad is perfect, just that your usecase is not the only one.
For your use-case: place a resistor once, and duplicate it when you need a second one. Should be fast enough and works for every part, not only the "standard" ones.
For a start it's not a use-case, it's a UI usability case, inability to tell the two apart is telling; as is dropping into business analyst-ese with phrases like "use case".
Every time, every bloody time, someone says to fanboy contributors of program x "It would be better if the UI did this like that" the fanboys say "Oh, you can do that [the functional equivalent] by <series of moves in existing UI>" thereby completely missing the point. Just because something is functionally possible doesn't mean that it satisfies usability criteria.
I've been a programmer for 45 years, since the bloody punch card era. If I was as resistant to improving usability as you guys seem to be I'd still be insisting that my customers used punch cards. "No, look, you CAN change the customer field. Just pull the 3rd card out of the batch, walk over to the punch/duplicator, hit COPY for the first twenty columns, then type the new customer name, and then keep hitting copy until the end of the card. Then put the card back into the stack. See, no need for fancy mice or screens. Not as easy for you, you say. Well if you want a millennial toy rather then a professional tool I suppose it's alright, but we produce professional tools." Sound familiar?
Yes, this is a workaround. But simply because I don't think what you want will be implemented upstream anytime soon. It starts with the simple problem: what is a Resistor? That thing is inside a library, which is >>OPTIONAL<<. KiCad does not know what a resistor is on the data-format level, and never will. Would you like to hardcode this? Would you like it configurable? If this will ever be implemented, this would likely be a plugin you install.
Let's start at the basics: What are the use-cases/user stories a proper symbol chooser should support:
Your usecase: I want to place Resistor, Capacitor with a single click on a Toolbar Button -- Problem: you already stated the solution of your problem which serves your use-case, but not other ones
Other usecase: I want to place a LM747 --> does not work with your Toolbar
Other usecase: I want to place this fully defined symbol from the database --> does not work with a simple Toolbar
Other usecase: I want to place the same symbol multiple times --> can be seen independent from the symbol chooser
Other usecase: I want to choose the next symbol after placing the current one
Other usecase: I want to filter the library by maximum supply voltage
Other usecase: I want to categorize the symbols
...
So, lets behave like proper programmers, and collect the requirements first. And what do proper requirements do not include: A solution. Finding solutions is a later step when you actually know what you want.
Anyway, what is a "UI usability case"? Google finds outstanding 4 results where this term is used.
-
It starts with the simple problem: what is a Resistor? That thing is inside a library, which is >>OPTIONAL<<.
Ah, I finally get it. I foolishly am discussing a program to do electronics with, where resistors are ten-a-penny and appear on every circuit board I own, every circuit board I've ever designed (except breakout boards for switches and other trivia) and in every schematic I have ever drawn, whereas you are clearly not. If you can't or won't get it into your head that placing the single most used individual component in the whole of electronics should be the 2nd easiest of all tasks (placing wires should obviously be 1st) in a schematic capture program then <throws hands up in despair rather than completing the sentence>. To posit that a schematic capture/PCB layout package should not need to know what a resistor is so wrong there isn't a word for it.
Anyway, what is a "UI usability case"? Google finds outstanding 4 results where this term is used.
English, work it out. That it's not industry jargon like "use case" or "user story" goes a long way to explaining why there's a lot of shitty software out there. It's quite clear that you're at the "being clever/snarky" stage now, rather than the "even remotely looking like someone who might one day actually listen stage".
I tire of this. There's really no point in me carrying on as it's quite clear that you are just dead set to do it one way and one way only and you really, really, don't care what your 'customers' think or are incapable of comprehending that there is a better way. I'm out.
For the avoidance of doubt, I'm marking this topic 'ignore' I really do feel that I'm wasting my time here. I tried...
-
Well, it became clear this will not work out between us.
English, work it out. That it's not industry jargon like "use case" or "user story" goes a long way to explaining why there's a lot of shitty software out there. It's quite clear that you're at the "being clever/snarky" stage now, rather than the "even remotely looking like someone who might one day actually listen stage".
I tire of this. There's really no point in me carrying on as it's quite clear that you are just dead set to do it one way and one way only and you really, really, don't care what your 'customers' think or are incapable of comprehending that there is a better way. I'm out.
For the avoidance of doubt, I'm marking this topic 'ignore' I really do feel that I'm wasting my time here. I tried...
I come from research, and when you invent a term, you need to explain it. Even it looks clear to you, without specification, people will interpret different things into it. And industry jargon like requirements engineering is something everyone should have heard of, as well as some basic terms. Nothing wrong with it.
And even though you will not read this anymore: I can listen and change my opinion. I do that all the time. But it requires good arguments, and I did not see them in yours. Coming with arguments like "I've been a programmer for 45 years" is the opposite of an extraordinary argument. I know quite a few, way more senior engineers than me, which build crappy software from an engineering standpoint, and they don't see this. From my point of view, I only heard: this is the right way and you are wrong. No discussion anywhere to iterate design ideas and incorporating feedback of use-cases, other people might want. And I'm not the only one who stated them to you.
---
Lets start with an idea of me, if this could be a workable symbol chooser (idea was stated in https://gitlab.com/kicad/code/kicad/-/issues/6028). No guarantees given, more like a though how it could be improved.
What about a dock, which can be attached to the window like the layer-chooser in pcbnew:
1. You have a visualization of the current selected symbol/footprint in the dock
2. You see some searchable tree/etc. (what works well), where you can select the symbol
3. You can apply extensive filters on the symbols
4. You can add symbols to a bookmark, which are like a library, and which you can easily open anytime
Advantages:
* always open
* immediate visual feedback what library you are in
* you can (for example) open the devices library and place resistors as often you want, like in a toolbar (but more flexible)
* Works with the KiCad library, but also some future concept like database library
* scales well for bigger libraries
* you can select one library by default (Like Devices) to help beginners
* one solution for everything. Not something specialized.
Disadvantages:
* space could be too small to fit everything in
* bad for small screens
* ???
---
Any input? What good examples of other EDA's (not LTSPICE) can you think of in this regard, where we can steal the good parts?
-
What good examples of other EDA's
Well, now you mention it...
(not LTSPICE)
Oh.
:box:
-
For what it's worth, a library for simulation-only purposes would be a nice addition to KiCad, and could also satisfy those who just want to sketch schematics. Ideally it would consist of all the Spice primitives. It could even be an addon, and maybe there is one already that I haven't found yet (if anyone knows, please let me know!)
For background, I have only just started looking at KiCad, and so far strictly for simulation. Why in the world would I do that? Because I work for a semiconductor company, and therefore can't use LTspice. I also know personally someone who was publically yelled at by the author of LTspice in a seminar because he had been toying with an IC design and dared to ask some questions about it. KiCad and ngspice seem to have the most momentum behind them, and I am looking for a longer term solution.
I also think of KiCad as a good choice because of promising developments for PCBs. Right now I use Altium. I found the user interface hard to learn, but I learned it. The same for Eagle, Orcad, LTspice (which I used to use extensively), etc. So yeah, KiCad has some pretty funky interface choices, but it also does some things I really like. I still was able to go from downloading it to running a simulation in about an hour. It took me a lot longer to get anywhere with Altium.
Interestingly, I learned that Altium 20 also uses ngspice as its simulation engine.
You want a terrible example of a user interface? Try Windows 10 and Office 365. It tricks you into thinking you can be productive, but by the time you realize it's all a terrible lie, you are trapped in sticky secretions and slowly dissolved by MS's digestive enzymes...
John
-
Adding a special UI for simulation purposes makes sense. The current implementation in KiCad is more like, it works, but not, it works well.
One idea of mine would be the addition of some sort of "virtual" simulation objects. Things like voltage sources are only required for simulation, and don't have any use outside (e.g. for the PCB). Perhaps we could add them in such a way to only be visible in a simulation mode, or visually distinct from the normal schematic.
An EDA with a pretty nice simulation engine is Proteus (https://www.labcenter.com/ (https://www.labcenter.com/)). Dunno about library handling, but I really liked it to simulate a circuit in real-time with visual indicators of logic levels on each pin. The integrated support of MCU's is also something I want to see in KiCad at some future time.
A different simulation tool which we could steal ideas of is Qucs (http://qucs.sourceforge.net/ (http://qucs.sourceforge.net/)). The plots embedded into the schematic make it well suited, not only for simulation, but for documentation as well. And you don't have to fiddle with an additional window.
-
KiCad is not a drawing tool for schematics as you would draw them for a book. Nor is it a tool to draw schematics for simulation, where you do not care if you can order that part. KiCad is there to build pcbs, and its long term goal is professional usage. And thats where database part libraries reside (planned for KiCad v7). Or nowadays, atomic libraries, when you want to have fully specified library symbols in KiCad as required by many business.
Optimizing you usecase makes KiCad behave more like a toy for electronic beginners, but not for people who care about the parts they need to order in the future.
But this is not correct as a universal approach. A high-volume manufacturer - may well defer part choices until assembly and the final choice may well depend on the market price their agent can negotiate on any particular day. The specification of an inductor value/ or RC snubber may want to be deferred until product emci testing. The particular op-amp choice will depend on actual received test data, or even final customer product tolerances. Tempco may be region specific, x7r/x5r depends on product enclosure choices etc. None of this necessarily needs to be specified up-front to create a valid pcb design. YAGNI.
In all these cases the only thing that matters is footprint. Consider the process of dropping more than one footprint on a pcb (eg. smd and th) to provide for later flexibility in part choice depending on electrical characteristics, price, and availability. It is a common enough strategy, which reveals valid engineering and business decision-making.
With that said, library support for specific components, is also frequently desirable. Why do I have to create my own symbols, adopt and fix others - combing through manufacturers datasheets and errata? The more well-vetted and community tested libraries for specific parts the better - particularly for high pinout items like mcus and fpgas. Even better if manufacturers could be encouraged and aided to take responsibility for creating these themselves.
So I really think support is needed for both of these workflows. In know in my library I have converged on a mix of super generic parts (to defer engineering risk) and very specific parts (where a design leverages a specific component).
-
So I really think support is needed for both of these workflows. In know in my library I have converged on a mix of super generic parts (to defer engineering risk) and very specific parts (where a design leverages a specific component).
Indeed. There are multiple workflows which should be supported. I would say KiCad already supports this with its library system. (Generic vs Atomic libraries)
-
@delfinom , maybe this video can be useful, (seems) Altium user trying KiCAD for first time, from point of experienced CAD user feedback.
https://www.youtube.com/watch?v=maaBkw7IRUc (https://www.youtube.com/watch?v=maaBkw7IRUc)
-
For what it's worth, a library for simulation-only purposes would be a nice addition to KiCad, and could also satisfy those who just want to sketch schematics. Ideally it would consist of all the Spice primitives. It could even be an addon, and maybe there is one already that I haven't found yet (if anyone knows, please let me know!)
We have added such a library quite some time ago. It is called Simulation_SPICE. It of course does not contain everything yet but it is a start. If you installed KiCad before this lib was added then you likely need to manually add it to your current library table as the installers do not do that (nested library tables with one table per library set would be the solution here, not sure if they got into v6).
The naming scheme is deliberately chosen to be able to add ngspice specific symbols into a Simulation_NgSpice library and possibly specific libraries for other simulation engines.
-
I did see these libraries, thanks. They are not very complete, though.
Please note that I am not complaining. I realize that PSpice is a work in progress, it depends on volunteers, and that simulation is not its main purpose. I am not yet using it for PCB layout, since we have Altium, and we use features of Altium that are not ready in KiCad yet, such as rule-based DRC. But, it sure would be nice to use it for both someday:).
But, it looks like it could be well suited for simulation, and I am looking for an option other than LTSpice. In my case, simulation is a much different process than PCB design, and really only the schematic entry part is similar. KiCad works for this, and there is really a dearth of schematic entry tools for NGSPICE that are clean and open source, so it's a good choice. It also looks like it has a future, unlike some other options that have recently been made free, but not open source.
My personal preference would be to support NGSPICE with a complete set of NGSPICE components in a symbol library. I think it would be good to have it nested, if possible, but that could come later. Some common subckts like generic op-amp models, etc could also go in here.
I would not bother with making large model libraries a core piece of this, since if people like the simulation tool, this will come like it did for LTspice. I'm sure others may vehemently disagree with this, but frankly it is a losing situation to supply spice models of any complexity as a core piece of KiCad.
I haven't said anything about plotting and data analysis, but that's a whole 'nother thing.
Cheers,
John