Author Topic: CERN's contribution to KiCAD  (Read 75527 times)

0 Members and 1 Guest are viewing this topic.

Offline elgonzo

  • Supporter
  • ****
  • Posts: 690
  • Country: 00
Re: CERN's contribution to KiCAD
« Reply #50 on: May 07, 2013, 02:20:59 am »
Isn't Eclipse built around that plugin type framework?

Yes, Eclipse is kind of a plug-in framework. It has its strength in being a toolkit for designing your own specific IDE environments. Out-of-the-box it might not be the simplest application to work with, because of all the complexity its flexibility brings. However, considering the intended user group (developers), it's not much of an issue.

Kicad is just doing its first steps with its Python scripting. But i can't tell whether it is usable or still rudimentary experimental.

Blender would be nice example for good scripting integration. Not only has a full-featured Python-API, it even allows you to load any binary library compatible with your host OS*) via Python (within Blender) and call their exported function(s) without ever needing to compile or link against Blenders header files/libraries. That's what i would call easy and powerful.

EDIT: *) ...and of course matching Blender's bitness...
« Last Edit: May 07, 2013, 03:02:29 am by elgonzo »
 

Offline elgonzo

  • Supporter
  • ****
  • Posts: 690
  • Country: 00
Re: CERN's contribution to KiCAD
« Reply #51 on: May 07, 2013, 02:55:21 am »
Yes sorry elgonzo, I was just playing with words and trying to be funny.

I think it's a fair point that you make too, though I am not sure to what extent Kicad has a stable architecture or stable extension mechanism. In fact from memory they are in the process of implementing a change of design.
Hopefully Kicad can get this stage soon.

I don't really know how much of the actual codebase has already been cleaned up and is stable. Looking at the bug tracker on  launchpad.net, the devs seem to take bug reports especially regarding stability problems very serious - which is a positive.

Python scripting in KiCAD is existent, but i doubt that it has already a reasonable feature set and is fit for prime-time (don't start looking for a documentation; there seems to be only a rather incomplete one).

I hope CERN can provide some substantial positive impulse for KiCAD. In my opinion, what KiCAD needs right now primarily is a significant improvement in usability or feature set (or in both, desirably). If no such concrete results materialize from CERNs engagement, i worry that KiCAD will drift more into obscurity and it would become harder and harder for the devs to find motivation for working on KiCAD.
 

Offline Bored@Work

  • Super Contributor
  • ***
  • Posts: 3932
  • Country: 00
Re: CERN's contribution to KiCAD
« Reply #52 on: May 07, 2013, 05:07:16 am »
Python scripting in KiCAD is existent, but i doubt that it has already a reasonable feature set and is fit for prime-time (don't start looking for a documentation; there seems to be only a rather incomplete one).

The thing with Python scripting in KiCad is that it come far to early (and that Python is a rubbish language, but we skip that for a moment ...).

They are doing the second or third step before the first. Scripting will not help them to clean up their horrible User Interface dialogs, an experienced User Interface designer would. It will not help them to clean up their graphic rendering engine, to fix their mouse and keyboard behavior, fix their bodged naming conventions, or to get their workflow right.

Everything that is wrong in the KiCAD core can't be fxed with scripts. At best some scripts will add some half ass patches over some of the things. At worst they will just add a pile of junk added to KiCad.  You can't script a turd.

In the old day there was this law on software development "Every program attempts to expand until it can read mail.". These days it seems on has to replace "can read mail" with "supports Python scripting". The result is the same, a rather useless feature, especially when there are still fundamental issues.

Quote
(don't start looking for a documentation; there seems to be only a rather incomplete one).

Now why am I not surprised? If the KiCad developers hate one thing, then it is writing documentation.
I delete PMs unread. If you have something to say, say it in public.
For all else: Profile->[Modify Profile]Buddies/Ignore List->Edit Ignore List
 

Offline firewalker

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: gr
Re: CERN's contribution to KiCAD
« Reply #53 on: May 07, 2013, 08:05:33 am »
Python might be many things, but rubbish isn't one.

Alexander.
Become a realist, stay a dreamer.

 

Offline Bored@Work

  • Super Contributor
  • ***
  • Posts: 3932
  • Country: 00
Re: CERN's contribution to KiCAD
« Reply #54 on: May 07, 2013, 01:52:47 pm »
Python might be many things, but rubbish isn't one.

Alexander.

The language design is brain-dead. It is a me-too language, which wasn't and isn't needed and doesn't satisfy any real-world need, except the fanboys wanking about it and bolting it uselessly to everything they can get their sticky hands on. And the worst, having spent a lot of time debugging internal Python libraries, like platform.py, I have first hand experience of the suckage of the internal code. Pure rubbish. If that is the best the masters of Python can do, well, they haven't even the slightest clue what they are doing.
I delete PMs unread. If you have something to say, say it in public.
For all else: Profile->[Modify Profile]Buddies/Ignore List->Edit Ignore List
 

Online amspire

  • Super Contributor
  • ***
  • Posts: 3764
  • Country: au
Re: CERN's contribution to KiCAD
« Reply #55 on: May 07, 2013, 02:47:18 pm »
Just had a quick look at the status of Python in KiCad. If you enable the scripting in the KiCad buid, it looks like pcbnew in Windows has python available, and in linux, there is python + wxpython so you can get an editing environment inside pcbnew.  The holdup for the Windows PCBnew is that wxpython apparently is not compatible with Mingw that is used to build most Windows KiCad and they are working on a way to get the existing Windows wxpython builds to work with the Mingw KiCad.

The current standard builds of KiCad do not have the scripting enabled by default, and the button on pcbnew for running scripts is missing in these builds. The current python library seems to have enough commands for things like footprint building scripts, but this needs to be enhanced. Things like file IO functions and Action Plugins (like call back triggers for things like "Right Click on a Component") still have to be added.

It looks like Eeschema will not get scripting just yet as planned changes mean that it does not make sense to add scripting to the current version at this stage.
 

Online amspire

  • Super Contributor
  • ***
  • Posts: 3764
  • Country: au
Re: CERN's contribution to KiCAD
« Reply #56 on: May 07, 2013, 02:48:06 pm »
I saw that Cern is setting up a donation-based fund raising scheme on the Cern website to help push along the work along. They are also encouraging companies to get involved in submitting code on the basis that they could offer commercial support for KiCad for organizations that want to use KiCad. The more companies start using KiCad, the more the pressure to turn KiCad into a complete solid package I guess.

Current fund raising targets  are 150,000 euros to "Make Kicad usable for very complex Printed Circuit Board designs with acceptable productivity" and 300,000 Euros to "Bring Kicad in line with the best proprietary tools, and outclass them in some respects". It may sound a lot of money, but I think Cern are thinking along the lines donations from corporations and institutions who would be prepared to donate a big sum to be able to start using free KiCad internally instead of expensive and closed commercial packages with expensive annual subscription or support fees.

There definitely does seem to be some very positive cooperation between the KiCad developers and the Cern developers which is very good to see. Things like the new GAL (Graphics Abstraction Layer) that seems to be very much a joint effort between the KiCad developers and Cern. The GAL will solve a lot of problems, including allowing the development of a push and shove router which seems to be a big aim of Cern. The Gal Specification PDF link in the following post is interesting:

https://lists.launchpad.net/kicad-developers/msg09872.html

It can be tested in a development build of KiCad compiled under Linux. Windows will come.

Some good might really come from this.

Richard.
 

Offline elgonzo

  • Supporter
  • ****
  • Posts: 690
  • Country: 00
Re: CERN's contribution to KiCAD
« Reply #57 on: May 07, 2013, 03:18:50 pm »
The thing with Python scripting in KiCad is that it come far to early (and that Python is a rubbish language, but e skip that for a moment ...).

Yep, the lack or inability of properly defining workpackages (we have talked about that before). It sometimes seems they are doing a little here, a little there and chasing pet projects.

As a scripting language, Python is not bad. It is extremely well documented. Also, it makes it very easy for you as developer to integrate it into your application, no matter whether your target is Linux, Windows, or MacOS in whatever bitness. Well, if you consider that rubbish, i would really like to know your recommendation for a scripting language to be used in an application...


Everything that is wrong in the KiCAD core can't be fxed with scripts. At best some scripts will add some half ass patches over some of the things. At worst they will just add a pile of junk added to KiCad.  You can't script a turd.

I agree with the first part; it should be common sense.
The second part, well, it's an assumption. But honestly and frankly, one i sometimes tend to share. (Not bitching about the devs or trying to lecture them, but it is not hard to understand that if there is no roadmap, hardly there will be any evolvement.)


In the old day there was this law on software development "Every program attempts to expand until it can read mail.". These days it seems on has to replace "can read mail" with "supports Python scripting". The result is the same, a rather useless feature, especially when there are still fundamental issues.

You seem to confuse the purpose of patch sets/hot fixes with the purpose of scripting. You might certainly have real-world examples where this confusion resulted in a mess. But you have to understand that such things happen because of a profound lack of understanding or plain ignorance, not because "that's the way it is".

Counter examples:
Blender, as i mentioned before. Or ULA scripts (not Python, but still scripting) in Eagle.
Basically almost any modern game engine (Seldomly, game designers define game logic and behavioral aspects in the low-level language the engine is written with. No, almost exclusively they use scripting environments).
Visual studio extensions (not necessarily scripting, but extensions nonetheless).
Etc, etc,...

Beware, you are moving on very thin ice with your argument :)


Now why am I not surprised? If the KiCad developers hate one thing, then it is writing documentation.
Stating the obvious, don't you :)
And granted, if they can't overcome their sloppiness regarding doc, whatever i said about extensions will vanish like magic smoke...
« Last Edit: May 07, 2013, 03:24:12 pm by elgonzo »
 

Offline elgonzo

  • Supporter
  • ****
  • Posts: 690
  • Country: 00
Re: CERN's contribution to KiCAD
« Reply #58 on: May 07, 2013, 03:51:55 pm »
It looks like the discussion regarding extensions/extensibility has developed its own dynamic. Just to make clear (and risking to be too talkative): I mentioned extension mechanisms as part of a response regarding the opinion that just being open to (code) contributions from the community is sufficient to improve the quality of OSS projects.

I certainly agree with the sentiment, that KiCAD team has much more severe issues to address (of which extensibility is no part of) and should not put emphasis on their Python scripting attempt. This would be at this time distracting and just add another construction site...
 

Offline Stonent

  • Super Contributor
  • ***
  • Posts: 3824
  • Country: us
Re: CERN's contribution to KiCAD
« Reply #59 on: June 11, 2013, 05:20:19 pm »
What's the pin count of an LHC?  :-DD
The larger the government, the smaller the citizen.
 

Offline madworm

  • Frequent Contributor
  • **
  • Posts: 373
  • Country: de
Re: CERN's contribution to KiCAD
« Reply #60 on: October 16, 2013, 08:15:03 pm »
Upcoming P & S routing. Sorry, I don't know when.



 

Offline madworm

  • Frequent Contributor
  • **
  • Posts: 373
  • Country: de
Re: CERN's contribution to KiCAD
« Reply #61 on: October 16, 2013, 08:46:46 pm »
Here's a comparison between the standard vs. "CERN-style" 2D rendering.

The right shows the "cairo" rendering, which is fully anti-aliased. OpenGL is also available, which looks almost the same (no AA as of now), but is much faster.
« Last Edit: October 16, 2013, 08:49:20 pm by madworm »
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 1945
  • Country: nl
Re: CERN's contribution to KiCAD
« Reply #62 on: October 16, 2013, 09:28:43 pm »
Well, if you put it like that... Left side looks like shit, right side looks decent.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: CERN's contribution to KiCAD
« Reply #63 on: October 16, 2013, 09:34:52 pm »
That left side looks significantly shittier with the text outlined. It does not look that way to me.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline madworm

  • Frequent Contributor
  • **
  • Posts: 373
  • Country: de
Re: CERN's contribution to KiCAD
« Reply #64 on: October 16, 2013, 09:37:03 pm »
That left side looks significantly shittier with the text outlined. It does not look that way to me.

Yes, you're probably running a pretty old version.

I've compared the latest normal pcbnew version vs. the latest in the CERN branch.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: CERN's contribution to KiCAD
« Reply #65 on: October 16, 2013, 09:38:06 pm »
I am running the latest stable (rev. 4024). I don't run testing anymore after it screwed up a PCB save... but that's as recent as it comes in the stable branch.

An aside: am I the only one who really hates anti-aliased text? It all looks fuzzy and blurry to me. Looking at that preview, I feel like I've got a foggy pane of plastic over either my eyes or the monitor! I like the anti-aliased graphics, but I'll take a well designed raster screen font any day over looking like it's time to call up the optometrist...

And please tell me that not rendering the clearances and rat's nest lines is not a direction they're going in. (Obviously the rats can be turned off. Can the clearances, though? :-//)
« Last Edit: October 16, 2013, 09:46:07 pm by c4757p »
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline madworm

  • Frequent Contributor
  • **
  • Posts: 373
  • Country: de
Re: CERN's contribution to KiCAD
« Reply #66 on: October 16, 2013, 09:40:57 pm »
Yes, there's that. That's why one uses version control :box:
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: CERN's contribution to KiCAD
« Reply #67 on: October 16, 2013, 09:42:57 pm »
Yes, there's that. That's why one uses version control :box:

Yep. :-[ I use it religiously with code. Never got into the habit of using it with PCB/schematic. Probably about time to start.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline madworm

  • Frequent Contributor
  • **
  • Posts: 373
  • Country: de
Re: CERN's contribution to KiCAD
« Reply #68 on: October 16, 2013, 09:55:50 pm »
And please tell me that not rendering the clearances and rat's nest lines is not a direction they're going in. (Obviously the rats can be turned off. Can the clearances, though? :-//)

Right now you can switch between normal (works as usual), openGL and Cairo (with AA). The latter two are view only. At least that is the way it compiles without messing with the code. The clearances might show up during routing, but I can't be sure. But the clearance fences didn't show up in the early demo videos as well. If the new router is as good as it appears to be, we might be OK without explicit visual feedback. It will just enforce the design rules... hopefully.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: CERN's contribution to KiCAD
« Reply #69 on: October 16, 2013, 09:59:11 pm »
If the new router is as good as it appears to be, we might be OK without explicit visual feedback. It will just enforce the design rules... hopefully.

This "I know you already have it, are used to it and like it, but trust us, you don't really need it, so we're taking it out because shiny" has become sadly rather common in open source software lately. *cough*gnome3*cough* Goddammit, the feature's already there, don't take it out! |O

I rather like having the clearances visible. I use them when placing the components - not just so the components themselves fit (of course, the DRC will enforce that), but so I can visualize where the tracks will go and where everything will fit together best.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline HackedFridgeMagnet

  • Super Contributor
  • ***
  • Posts: 1937
  • Country: au
Re: CERN's contribution to KiCAD
« Reply #70 on: October 17, 2013, 11:10:54 am »
Surely clearance will be visible if you want them. If they take that away they are going backwards.

How do you turn on the Open GL graphics, is it selectable or do you need to run the branch build?
Also I am running one of the recent daily builds but no push shove routing yet. Is that in another different branch.

I am really getting comfortable with Kicad now and my speed has increased a lot.
One thing I would like to be able to do though is override the track width of a segment more easily. ie it is basically one size normally but for space or current carrying capacity I want to change the track width of a particular segment. If it is larger I should be able to it without turning off the design rules or changing the assigned width of the whole net.
Any shortcuts here?

Yeah source control mandatory.





 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: CERN's contribution to KiCAD
« Reply #71 on: October 17, 2013, 11:16:20 am »
Design rules -> Global design rules, add the width you want to the list of track widths. Then back in the PCB, select the width one of three ways: toolbar at the top, right click in black space while in track mode -> track width menu, or keyboard W or Ctrl-W. Then new tracks will be done in that width. Hover over an existing track and press E to change it to the new width. You can't go smaller than the DRC-defined minimum for that net, but you can go larger.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline madworm

  • Frequent Contributor
  • **
  • Posts: 373
  • Country: de
Re: CERN's contribution to KiCAD
« Reply #72 on: October 17, 2013, 12:22:55 pm »
The preview stuff is in different branches.

http://www.ohwr.org/projects/cern-kicad/wiki/WorkPackages

The visuals are in: https://code.launchpad.net/~cern-kicad/kicad/kicad-gal

The P & S router: https://code.launchpad.net/~cern-kicad/kicad/kicad-pns-tom

---

The openGL GUI is preview only (no editing, just zoom + pan), just as the Cairo one. You can switch between them in the preview version. Crashes from time to time and doesn't load some boards.

I couldn't compile the P & S router branch, as I don't have wxWidgets 2.9 yet.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: CERN's contribution to KiCAD
« Reply #73 on: October 17, 2013, 12:26:11 pm »
Is the Cairo engine as slow as my experience with Cairo would lead me to believe? :-\ Seems like OpenGL would be the way to go.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline madworm

  • Frequent Contributor
  • **
  • Posts: 373
  • Country: de
Re: CERN's contribution to KiCAD
« Reply #74 on: October 17, 2013, 12:28:56 pm »
No. It is probably much slower >:D - personally I wouldn't want to use it.

The openGL one looks the same to me, but sans AA.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf