Re: gEDA-user: Reinventing the wheel
Am 18.05.2011 um 04:25 schrieb Kai-Martin Knaak: kicad is the EDA chosen by some high profile open hardware projects: * reprap (http://reprap.org/wiki/KiCad) As a RepRapper I can say, there is no such thing like a choosen EDA. People use what they like most and that's Eagle for some 90% of the RepRap electronics sets (there exist many in parallel). BTW, what are the show cases for geda/pcb? http://reprap.org/wiki/Generation_7_Electronics ? At least worth mentioning :-) Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Pressing = key causes PCB to freeze for a few minutes
On Tue, May 17, 2011 at 03:04:18PM -0400, Vanessa Ezekowitz wrote:
On Mon, 16 May 2011 23:29:46 +0200
Kai-Martin Knaak k...@lilalaser.de wrote:
Peter Clifton wrote:
the two '=' or remove the whole part 'a={= Key=}', what will
remove this key-binding for this menu-item.
Yes, I can recommend removing this key binding.
I do in my local builds for the same reason, plus the fact that
sometimes the optimiser makes mistakes and causes shorts on my boards!
For me, the Auto-Optimize step (in particular the Unjaggy and De-bumpify
optimizations) actually removes some hand-placed vias - particularly those
which I've placed up against an SMT pad as part of hand-routing the majority
of the board. I only noticed this today, but I can't be sure when that
behavior started.
As for keys, I would like to see a default hotkey added to turn Orthogonal
Moves on/off (I toggle this setting quite frequently while cleaning up after
the autorouter).
Ditto. What about + which is a little cross after all?
I'm aware it's Shift-= on american keyboards, which is currently
defined as auto-optimize. But I am of the strong opinion that
operations which may perform a large number of changes to the
board should not have keyboard accelerators, so that you can
not trigger them my mistake.
I'm aware that they can be undone, but even then...
Regards,
Gabriel
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On 17/05/2011, John Dotyj...@noqsi.com wrote: On May 17, 2011, at 9:56 AM, Russell Shaw wrote: Most guis hide what they do. I believe in them showing the commands they send internally as a script would (or atleast have the option to show that) so the user can paste the commands into an external file if needed. I've done GUIs that wrap scripts, but it only works in very simple, shallow cases. An API that supports GUI well is very different from an API that supports scripting well. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com On 18/05/11 04:57, Eduardo Costa wrote: Hi guys, That's not true at all John. Have you ever heard/seen a program called Alias Wavefront Maya? It used to be from Silicon Graphics, but they sold it to Autodesk a couple of years ago. A program for 3D CGI which has quite an innovative popup menu system with something called hotboxes and cardinal menus (the one shown bellow). 200% productive, and much better than anyother existing/deployed nowadays: http://imageshack.us/photo/my-images/504/polygonquickmenunothingrx6.jpg/ and driven from MEL (sort of an intepreted c languaje they roled for the purpose of scripting such a huge program). Believe me, you wouldn't even think it is scripted because they didn't abuse of it, yet it lets such menu system be 10 times more powerful! I do share many of your points Russell, while I'm happy (still) using geda. It seems to me is going somewhere I don't really want to be in a future. I've got almost done a c-library I wrote implementing this menu systems for my own programs. Haven't looked at it for a time, but it could work with gtk or other toolkits as long as they allow low level event handling. Anyways, if you are really going for it, and are going to use old'good c, I'll be pleased to hear your thoughts and cooperate. Hi, I'm a gtk hater, and am open to new widget toolkit user interface paradigms, even if it means writing new widgets or toolkits from scratch (which i've done before). I found the useability of a 20yo unix box sch/pcb cad program far better in certain ways than current cad packages. It involved the left hand and an external multi-button puck device in most of the screen-panning operations, leading to much less mouse-finger fatigue. It made all the current Windows cad packages look like kiddies toys by comparison. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On 18/05/11 12:28, Kai-Martin Knaak wrote: Russell Shaw wrote: The problem with KiCAD is 1) C++, 2) Qt. The problems I encountered with gnetlist were 1) scheme I think Scheme could be made much more attractive in geda if it was adequately explained in documentation or a tutorial. I haven't looked lately to see if there's more documentation on it compared to last time i looked. 2) poor documentation ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
Can I enter my own project Super OSD? [1]http://code.google.com/p/super-osd On 18 May 2011 03:25, Kai-Martin Knaak [2]k...@lilalaser.de wrote: Stefan Salewski wrote: While gEDA/PCB has some serious users and a large list of projects done with gEDA, KiCAD users seems to be more childreen type, making boards with a power LED and a led driver chip... kicad is the EDA chosen by some high profile open hardware projects: * reprap ([3]http://reprap.org/wiki/KiCad) * micropendous ([4]http://code.google.com/p/micropendous/) * nanonote ([5]http://en.qi-hardware.com/wiki/Main_Page ) Doesn't look like child play to me... BTW, what are the show cases for geda/pcb? Projects You'd proudly show on public presentations? One project I know of is ronja by Karel Kulhavy ( [6]http://ronja.twibright.com/ ). What else? ---)kaimartin(--- -- Kai-Martin Knaak Email: [7]k...@familieknaak.de Öffentlicher PGP-Schlüssel: [8]http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list [9]geda-user@moria.seul.org [10]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. http://code.google.com/p/super-osd 2. mailto:k...@lilalaser.de 3. http://reprap.org/wiki/KiCad 4. http://code.google.com/p/micropendous/ 5. http://en.qi-hardware.com/wiki/Main_Page 6. http://ronja.twibright.com/ 7. mailto:k...@familieknaak.de 8. http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 9. mailto:geda-user@moria.seul.org 10. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
I'm a gtk hater, and am open to new widget toolkit user interface paradigms, So, you build pcb with --enable-gui=lesstif ? ;-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Maker Faire at the San Meteo Fairgrounds this weekend
Hi Gang, Is anyone else going to Maker Faire this weekend? http://makerfaire.com/ Maybe we could arrange to meet up and chat. Clif ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On Tue, 17 May 2011 22:30:27 -0400 DJ Delorie d...@delorie.com wrote: BTW, what are the show cases for geda/pcb? There's a list on gpleda.org: http://geda.seul.org/wiki/geda:links First, let's be clear that popularity is no indication of usefulness or goodness of something. But, if a product is less widely-chosen, perhaps there is something that can be done to improve the learning curve for new users... e.g., I was frustrated with gEDA when I first started using it, and thought KiCAD looked easy to use and cool. But I found that I didn't like the feel of KiCAD (Wxwidgets was probably part of the problem...), and eventually figured out the tricks needed to make the gEDA system work. Now I love gEDA and am really comfortable with it, but I must say that it's difficult to learn. Perhaps a comprehensive tutorial/manual that explains the usual PCB workflow would help. I know there are lots of ways to use gEDA, but for new users, a basic and sensible standard workflow could be identified. With the reminder that popularity is not necessarily related to the goodness of a tool... I see that KiCAD does have some fairly popular projects using it, while I haven't seen the same for gEDA. I don't see any project on the gEDA projects using gEDA list that I would consider as high-profile as the following: * reprap (http://reprap.org/wiki/KiCad) * nanonote (http://en.qi-hardware.com/wiki/Main_Page ) * Versaloon debugger/programmer (http://www.versaloon.com/) (First open-source SWD device and first OpenOCD SWD support.) Certainly there are many complex and good designs done in gEDA, but as far as serious high-profile projects, it looks like KiCAD has the lead. No matter, gEDA is what works well for me and that's all I really care about! Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On 19/05/11 02:13, DJ Delorie wrote: I'm a gtk hater, and am open to new widget toolkit user interface paradigms, So, you build pcb with --enable-gui=lesstif ? ;-) I do it with gtk whenever i want to poke at it. I know how gtk works, but it's far too convoluted and burdensome for developing non-trivial widgets for non-trivial applications. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
Russell Shaw wrote: I think Scheme could be made much more attractive in geda if it was adequately explained in documentation or a tutorial. +1 I wouldn't mind to learn (a new language). But to learn a new language by almost non-commented code is just too much of a barrier. ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On 18/05/2011, Russell Shaw rjs...@netspace.net.au wrote: On 17/05/2011, John Dotyj...@noqsi.com wrote: On May 17, 2011, at 9:56 AM, Russell Shaw wrote: Most guis hide what they do. I believe in them showing the commands they send internally as a script would (or atleast have the option to show that) so the user can paste the commands into an external file if needed. I've done GUIs that wrap scripts, but it only works in very simple, shallow cases. An API that supports GUI well is very different from an API that supports scripting well. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com On 18/05/11 04:57, Eduardo Costa wrote: Hi guys, That's not true at all John. Have you ever heard/seen a program called Alias Wavefront Maya? It used to be from Silicon Graphics, but they sold it to Autodesk a couple of years ago. A program for 3D CGI which has quite an innovative popup menu system with something called hotboxes and cardinal menus (the one shown bellow). 200% productive, and much better than anyother existing/deployed nowadays: http://imageshack.us/photo/my-images/504/polygonquickmenunothingrx6.jpg/ and driven from MEL (sort of an intepreted c languaje they roled for the purpose of scripting such a huge program). Believe me, you wouldn't even think it is scripted because they didn't abuse of it, yet it lets such menu system be 10 times more powerful! I do share many of your points Russell, while I'm happy (still) using geda. It seems to me is going somewhere I don't really want to be in a future. I've got almost done a c-library I wrote implementing this menu systems for my own programs. Haven't looked at it for a time, but it could work with gtk or other toolkits as long as they allow low level event handling. Anyways, if you are really going for it, and are going to use old'good c, I'll be pleased to hear your thoughts and cooperate. Hi, I'm a gtk hater, and am open to new widget toolkit user interface paradigms, even if it means writing new widgets or toolkits from scratch (which i've done before). I found the useability of a 20yo unix box sch/pcb cad program far better in certain ways than current cad packages. It involved the left hand and an external multi-button puck device in most of the screen-panning operations, leading to much less mouse-finger fatigue. It made all the current Windows cad packages look like kiddies toys by comparison. Yes, with Maya you also need to have a hand on the keyboard and the other on the mouse. But Maya is a properly huge and complex sytem meant for 2D/3D compositing and animation. The good point on this sytem is that you can have as many menus as needed. They are extremely ligthweight in terms of memory and cpu costs, and can show up depending on current context, previous selected option (resembling a deeper submenu in a hierarchy), etc. There are many ways they can be employed without even the need for a keyboard at all, still boosting productivity by a factor of tens in respect of current windows-looking menu systems. As a big plus, they relieve the application from having to use valuable screen space to draw and maintain stupid toolbars with stupid icons. All you need is right-click somewhere, move the mouse a bit on the direction of your preferred option, and release: http://www.youtube.com/watch?v=zeYyKkOOxIo In either case, I also have experience programming others than xlib and relevant toolkits. This menus that I propose/like do not have to be used if other methods are suitable or better. As long as we can have some good geda software that is not constantly going to be limited by ancient stuff, yet is not directly going to the evil hands of svg and similar crap and human/cpu-unfriendly formats just because windows users want to look at the files with their browsers, it's fine for me. In either case, whatever your 20 y/o software does can also be done nowadays with xlib, motif, opengl, a mixture of all three, or whatsoever. So, again, if you are at any time going to get hands on it, I'll be glad to help. Regards, ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On May 17, 2011, at 8:25 PM, Kai-Martin Knaak wrote: BTW, what are the show cases for geda/pcb One of gEDA's great strengths is that it works well with other tools, so it's a great toolkit when the project isn't contained within a pure EDA environment. The trouble is that such a project is dependent on things other than gEDA, and so it can be tricky to import into an environment different than that in which it was developed. The spaceflight hardware project at https://github.com/noqsi/SXI is an example. In the environments we use at Noqsi, a simple make generates all of the data products, including extensive documentation. However, incompatibilities in other LaTeX setups cause trouble: that's why we have a private copy of tikz, and some other workarounds in the Makefiles. There may be other issues: we are only concerned with portability between Noqsi and Osaka U. environments for this particular project. So, as a demo, it's not so great, even though its organization is a tremendous timesaver for us. But by all means, take a look at it if you want. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Pressing = key causes PCB to freeze for a few minutes
On Wed, 18 May 2011 13:54:15 +0200
Gabriel Paubert paub...@iram.es wrote:
On Tue, May 17, 2011 at 03:04:18PM -0400, Vanessa Ezekowitz wrote:
On Mon, 16 May 2011 23:29:46 +0200
Kai-Martin Knaak k...@lilalaser.de wrote:
Peter Clifton wrote:
the two '=' or remove the whole part 'a={= Key=}', what will
remove this key-binding for this menu-item.
Yes, I can recommend removing this key binding.
I do in my local builds for the same reason, plus the fact that
sometimes the optimiser makes mistakes and causes shorts on my boards!
For me, the Auto-Optimize step (in particular the Unjaggy and De-bumpify
optimizations) actually removes some hand-placed vias - particularly
those which I've placed up against an SMT pad as part of hand-routing the
majority of the board. I only noticed this today, but I can't be sure
when that behavior started.
As for keys, I would like to see a default hotkey added to turn
Orthogonal Moves on/off (I toggle this setting quite frequently while
cleaning up after the autorouter).
Ditto. What about + which is a little cross after all?
I'm aware it's Shift-= on american keyboards, which is currently
defined as auto-optimize.
Fittingly unshifted = would also work, since the two lines could imply
parallel, as in move the object parallel to the path the mouse takes.
--
There are some things in life worth obsessing over. Most
things aren't, and when you learn that, life improves.
http://digitalaudioconcepts.com
Vanessa Ezekowitz vanessaezekow...@gmail.com
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On Wed, 2011-05-18 at 19:26 +0200, Kai-Martin Knaak wrote: Russell Shaw wrote: I think Scheme could be made much more attractive in geda if it was adequately explained in documentation or a tutorial. +1 I wouldn't mind to learn (a new language). But to learn a new language by almost non-commented code is just too much of a barrier. ---)kaimartin(--- The problem in not only missing documentation, but the fact that not all geda guile code is really clean and beautiful, as stated by one of the experts some time ago on this list. I don't know if that is true, but I have seen that even experts had to work hard to make small improvements. I think that learning lisp/scheme/guile is an interesting (academic) task. But I think that gEDA is not a really good point to start learning, because: 1. the C-guile interaction and 2. the risk of breaking something. And finally: It is hard to see the real benefit of mixing c and guile in geda for simple people like me. For PCB C plugins seem to work fine. Guile may be really fine for writing extensions/exporters, but very few people really do it. And guile itself seems to be not a masterpiece of software -- gentoo package maintainers have to struggle with version conflicts, guile is not used much at all (OK, gimp has guile script support). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
Kai-Martin Knaak kn...@iqo.uni-hannover.de writes: Russell Shaw wrote: I think Scheme could be made much more attractive in geda if it was adequately explained in documentation or a tutorial. +1 I wouldn't mind to learn (a new language). But to learn a new language by almost non-commented code is just too much of a barrier. Learning a programming language by examples is hazardous. Judging the code by lack of comments without knowledge of the language is too. Comments that help those who do not know the language to understand the code belong in tutorials, but not production code. Well written code should be understandable, with full knowlegde of the semantics of the language, but not necessarily without that knowledge. I do think that most code needs comments, but mostly exactly not the comments that are present in the code. I once learned TeX by reading the source of LaTeX2.09 (before reading the TeXbook). Nowadays I start with the language reference manual, skip the tutorial, and _then_ jump into example code. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
Is there a Python api for gEDA? Because that would be really nice... On 18 May 2011 20:56, Stefan Salewski [1]m...@ssalewski.de wrote: On Wed, 2011-05-18 at 19:26 +0200, Kai-Martin Knaak wrote: Russell Shaw wrote: I think Scheme could be made much more attractive in geda if it was adequately explained in documentation or a tutorial. +1 I wouldn't mind to learn (a new language). But to learn a new language by almost non-commented code is just too much of a barrier. ---)kaimartin(--- The problem in not only missing documentation, but the fact that not all geda guile code is really clean and beautiful, as stated by one of the experts some time ago on this list. I don't know if that is true, but I have seen that even experts had to work hard to make small improvements. I think that learning lisp/scheme/guile is an interesting (academic) task. But I think that gEDA is not a really good point to start learning, because: 1. the C-guile interaction and 2. the risk of breaking something. And finally: It is hard to see the real benefit of mixing c and guile in geda for simple people like me. For PCB C plugins seem to work fine. Guile may be really fine for writing extensions/exporters, but very few people really do it. And guile itself seems to be not a masterpiece of software -- gentoo package maintainers have to struggle with version conflicts, guile is not used much at all (OK, gimp has guile script support). ___ geda-user mailing list [2]geda-user@moria.seul.org [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:m...@ssalewski.de 2. mailto:geda-user@moria.seul.org 3. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
Colin D Bennett co...@gibibit.com writes: First, let's be clear that popularity is no indication of usefulness or goodness of something. But, if a product is less widely-chosen, perhaps there is something that can be done to improve the learning curve for new users... Why is there so much discussion here about the needs of potential new users, instead of the needs of current, loving, existing users? Let's make the tools perfect for us (that includes discoverability and documentation improvements), and not cater for not-yet-users. When we love the tools, they will eventually also leran how to love them. See: e.g., I was frustrated with gEDA when I first started using it, and thought KiCAD looked easy to use and cool. But I found that I didn't like the feel of KiCAD (Wxwidgets was probably part of the problem...), and eventually figured out the tricks needed to make the gEDA system work. Now I love gEDA and am really comfortable with it, Q.e.d. but I must say that it's difficult to learn. Perhaps a comprehensive tutorial/manual that explains the usual PCB workflow would help. I know there are lots of ways to use gEDA, but for new users, a basic and sensible standard workflow could be identified. Yes. Well, the results may be essentially the same, but still, the emphasis must be the needs of those how already use the tools, else the delepoment may run into dead ends. In the end, the development caters the needs of whoever is doing the development, and that is how it must be. Those of us (like me) who just argue their needs on this list, but do not write code, can just hope to steer the development a little bit towards their needs. That brings me to another point: I somehow feel a barrier of entry for contributing code to gEDA/PCB, more than with other projects. This is a combination of a lot of little details which have been discussed before. Maybe there is change in the right direction now, but I do not see any. If it were easier, some new users may already have written a tutorial based on their learning experience, or make the existing tutorials easier to find. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Pressing = key causes PCB to freeze for a few minutes
On Wed, May 18, 2011 at 03:09:10PM -0400, Vanessa Ezekowitz wrote:
On Wed, 18 May 2011 13:54:15 +0200
Gabriel Paubert paub...@iram.es wrote:
On Tue, May 17, 2011 at 03:04:18PM -0400, Vanessa Ezekowitz wrote:
On Mon, 16 May 2011 23:29:46 +0200
Kai-Martin Knaak k...@lilalaser.de wrote:
Peter Clifton wrote:
the two '=' or remove the whole part 'a={= Key=}', what will
remove this key-binding for this menu-item.
Yes, I can recommend removing this key binding.
I do in my local builds for the same reason, plus the fact that
sometimes the optimiser makes mistakes and causes shorts on my boards!
For me, the Auto-Optimize step (in particular the Unjaggy and De-bumpify
optimizations) actually removes some hand-placed vias - particularly
those which I've placed up against an SMT pad as part of hand-routing the
majority of the board. I only noticed this today, but I can't be sure
when that behavior started.
As for keys, I would like to see a default hotkey added to turn
Orthogonal Moves on/off (I toggle this setting quite frequently while
cleaning up after the autorouter).
Ditto. What about + which is a little cross after all?
I'm aware it's Shift-= on american keyboards, which is currently
defined as auto-optimize.
Fittingly unshifted = would also work, since the two lines could imply
parallel, as in move the object parallel to the path the mouse takes.
I don't really care. Well, on a Spanish keyboard, + does not need
any modifier but = is actually Shift-0.
As I've already said, the only things that worries me is potentially
pervasive and time-consuming operations triggered by single keystrokes.
Especially since I'm sometimes forced to use different keyboards,
American of French (and occasionally other ones, but it's unlikely
that I use PCB on these machines) so I may easily hit the wrong key.
Regards,
Gabriel
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On May 18, 2011, at 1:56 PM, Stefan Salewski wrote: The problem in not only missing documentation, but the fact that not all geda guile code is really clean and beautiful, as stated by one of the experts some time ago on this list. I don't know if that is true, but I have seen that even experts had to work hard to make small improvements. I think that learning lisp/scheme/guile is an interesting (academic) task. But I think that gEDA is not a really good point to start learning, because: 1. the C-guile interaction and 2. the risk of breaking something. The prevailing style for gnetlist back ends has several problems: 1. The near-universal use of recursion for iterating over lists. In most cases, the code is executed for side effects, typically output. For those cases (for-each) is a much simpler and clearer construct. (map) may also be useful in other cases. Recursion is a cool theoretical idea, but in practice it should be a last resort for when simpler iteration constructs don't work cleanly. 2. Excessively long functions. These are hard to read, hard to debug, and hard to maintain. A good scheme function is so simple it's almost trivial. Scheme allows procedural programming, but clumsily: one should prefer functional composition in most cases. 3. The use of (display) where (format) is more reasonable. I used to favor (display), but Peter B. dragged me kicking and screaming to (format). Thanks, Peter. Last year, I rewrote my Osmond-PCB back end based on these ideas, and I think the new version is much simpler and clearer. I submitted it as a patch, but it hasn't made it to release yet. I think it illustrates just how good the gnetlist API is for flat PCB-oriented netlist generation: the back end receives the data in very conveniently digested form. gnet-osmond.scm Description: Binary data John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: BUG: gaf hierarchy problems with old backup files
I have a collection of similar projects, each of which refer to a common set of hierarchical sub-schematics, which were located in the directory of the first project. I needed to prepare a tarball for one of the other projects, so I cleaned up the mess, and moved the symbols and schematics of the common sub-circuits into the ../lib directory. I added lines to gafrc like this: (component-library ../lib) (component-library .) (source-library ../lib) (source-library .)) Everthing worked fine for the project that I had to tar up. Then I tried to open the project where the common subcircuits were previously stored, and there I could not descend into the sub-schematic with H-d. Worse, gsch2pcb did not find the source= schematics either and deleted all the included components from the layout. It took a while to figure out what was different between the project where everything worked, and there it did not work: There where backup~ and #autosave# files left in the direcory for the .sch file that were moved. After removing the backup~ and #autosave# files of the moved files everything works as expected. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
Stephan Boettcher wrote: Why is there so much discussion here about the needs of potential new users, instead of the needs of current, loving, existing users? Let's make the tools perfect for us (that includes discoverability and documentation improvements), and not cater for not-yet-users. In my case, this is essentially the same. If students find geda more difficult and less attractive than eagle, I have a hard time to convince them to use the right tool. but I must say that it's difficult to learn. Perhaps a comprehensive tutorial/manual that explains the usual PCB workflow would help. full ack. In the end, the development caters the needs of whoever is doing the development, and whose contributions get accepted. There is a heap of 45 patches for pcb and 20 patches for geda rotting on launchpad. That brings me to another point: I somehow feel a barrier of entry for contributing code to gEDA/PCB, more than with other projects. This is a combination of a lot of little details which have been discussed before. ack. It starts with a developer mailing list that is closed to mortal users but discusses issues which affect said users. The wiki only features edit buttons on application. Some major usability issues effectively have the status won't fix. Examples are the next to unusable default library of geda and the lack of proper findreplace mechanisms, in gschem and in pcb. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
Stephan Boettcher wrote: Judging the code by lack of comments without knowledge of the language is too. I referred to the lack of documentation, rather than lack of comments. The particular case I had in mind, is the interaction of gnetlist's C front-end with the scheme back-ends. There seems to be no documentation whatsoever, what data structure the front-end should use to communicate with the back-end. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On Wed, 18 May 2011 18:39:43 -0600 John Doty j...@noqsi.com wrote: On May 18, 2011, at 6:31 PM, Kai-Martin Knaak wrote: Examples are the next to unusable default library of geda As has been discussed many times, this cannot be fixed, since there is no narrow, common use case for gEDA. Even the big $$ tools can't get this right, so how can we? A narrowly targeted, inflexible tool like Eagle can maybe, kind of, but that's not gEDA. Maybe we could put together a sort of “jumpstart” add-on library for new users who just want to design basic circuit schematics and get a PCB designed. The library would include only high-quality symbols that adhere to the same paradigms (e.g., no hidden power pins). You could leave out all the SPICE symbols and many of the rarely-used special symbols since this is a library for the basic and simple schematic-pcb workflow. Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GL on non-accelerated hardware?
On Mon, 16 May 2011 10:17:34 +0100 Peter Clifton pc...@cam.ac.uk wrote: Anyway, it would be worth testing to check I tested it on my notebook. It has an Atom CPU with an intel GPU. With the GL renderer it can do 7fps. With the original renderer it is 7.2. No significant change. Levente -- Levente Kovacs http://levente.logonex.eu ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On Wed, 18 May 2011 18:39:43 -0600 John Doty j...@noqsi.com wrote: On May 18, 2011, at 6:31 PM, Kai-Martin Knaak wrote: Examples are the next to unusable default library of geda As has been discussed many times, this cannot be fixed, since there is no narrow, common use case for gEDA. Even the big $$ tools can't get this right, so how can we? A narrowly targeted, inflexible tool like Eagle can maybe, kind of, but that's not gEDA. KMK didn't say what he means by unusable, but if I had to suggest: My use of the suite is always the same - draw up a schematic in GSchem and import it into PCB when it comes time to do so. The first thing that comes to mind is that, for both Gschem and PCB, the libraries need recategorized. Start by getting rid of PCB categories newlib, pcblib and pcblib-newlib, and subcategories within such as geda, generic, and not_vetted_ingo need to go as well - all of these are completely vague and really aren't helpful. Recombine everything into one big monolithic library, then divide it back out by component type (IC, electromechanical, interconnects, resistors, capacitors, ...), and perhaps by brand after that.Think of how Digi-Key lays out their Product Index on their website, but simplify it. GSchem's library is already reasonably well categorized in this regard. Then, add a new level above all of that, in both programs, to categorize according to use case. Gschem might include such things as PCB design, ASIC, even plumbing. PCB might include categories for PCB design, floorplans, I could even see it being used to lay out something big like a University campus. Each program would need an Unsorted category to catch what doesn't fit into the defaults. One should add an All category to both programs to bypass this mechanism, as inevitably some footprints and symbols will be misfiled. Then there is the previously discussed idea of setting default PCB footprints on various symbols in gschem. Such changes wouldn't break an existing workflow, just as the recent addition of PCB's schematic import facility (which works pretty well) doesn't stop people from using gsch2pcb and similar tools. -- There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves. http://digitalaudioconcepts.com Vanessa Ezekowitz vanessaezekow...@gmail.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: polystitch vs pcb+gl_experimental
I have been attempting to build polystitch.c against pcb+gl_experimental without much luck. Also had some issue against pcb git head... Has anyone else had any luck with polystitch.c building against recent versions? cheers, Geoff ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On May 18, 2011, at 7:57 PM, Geoff Swan wrote: Actually I think gEDA is not too bad for components/symbols really. What the default library lacks, gedsymbols often has. With a little bit more promotion of gedasymbols I think people wouldn't have such an issue. In terms of the usability of the default symbols - I just treat them as a starting point. It is unlikely anyone will have done a symbol exactly to my preference, and even if they have I like to add a whole bunch of extra attributes. The default library and gedasymbols remove a lot of the heavy lifting. A full symbol/footprint library is something that I expect to build for myself - I am not going to be happy unless I have closely checked each symbol. I am very thankful for being able to base my work from what others have done - but I am not planning on being in the position of having a dead pcb because I didn't check a 3rd party footprint properly. Exactly. The real issue is that the UI doesn't encourage newbies to perceive this. The library browser should really import the symbol into the project, and open it in gschem for customization. As far as the guile/scheme gnetlist backend is concerned... I did manage to modify one of the BOM backends to pull some extra attributes I add to my symbols. My first look at guile/scheme hurt my head - too many brackets. But after the initial shock it wasn't too bad. Indeed. It's easier than it looks. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: polystitch vs pcb+gl_experimental
I have been attempting to build polystitch.c against pcb+gl_experimental without much luck. Also had some issue against pcb git head... Has anyone else had any luck with polystitch.c building against recent versions? I build mine with head as of May 1. Let me rebuild and see what happens... ... seems to work OK ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: polystitch vs pcb+gl_experimental
cheers, I'll look more closely at me setup On Thu, May 19, 2011 at 12:16 PM, DJ Delorie [1]d...@delorie.com wrote: I have been attempting to build polystitch.c against pcb+gl_experimental without much luck. Also had some issue against pcb git head... Has anyone else had any luck with polystitch.c building against recent versions? I build mine with head as of May 1. Let me rebuild and see what happens... ... seems to work OK ___ geda-user mailing list [2]geda-user@moria.seul.org [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:d...@delorie.com 2. mailto:geda-user@moria.seul.org 3. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On Wed, May 18, 2011 at 09:24:53PM +0100, Thomas Oldbury wrote: Is there a Python api for gEDA? I once made a GPMI plugin for PCB. Unfortunately it contains only a small set of interface libraries so what can be done was limited. I've written an SVG exporter prototype in tcl, an interactive extension to draw non-90-deg arcs in awk, and a HGPL exporter that I really use in 'production'. GPMI supports 10 script languages including both python and guile. Altough I totally agree with those who say guile keeps some people back from really making extensions or modifications to gEDA, my reasoning is probably totally different from the previous ones in this thread. I believe it is the wrong way to bind a tool to a specific scripting language and force the user to learn a new language for each new tool. It is not (only) about being lazy to learn: there are very different tasks out there and some tools are more suited for some tasks. Once one knows 2-3 different scripting languages, it may already cover a large area of possible tasks well enough that learning a new one has nearly zero benefit. Unfortunately in case of pcb-gpmi burdens are elsewhere. My current theory is that such project would work only if it was fully integrated in the tool, shipped with default installation. It takes some efforts to compile the plugin and naturally it has dependencies (like why would I try to rewrite the interpreters of all those languages when I could use their libs?). As far as I know, i am the only one who ever tried the pcb-gpmi. Probably those who dare to start compiling non-singe-c-file plugins and fetch external libraries are not that much interested in scripting PCB in python (or anything else) as they are already good enough in C. To work around this I provided .deb packages but it's probably the same story, those who really would use the stuff are not on debian. So all in all, all positive feedback but 0 efforts in even trying it out. I can imagine something similar would happen to a gschem/geda variant. Maybe the burden is slightly smaller if only python is hacked onto gschem/geda, but then, in my opinion, that's not much better than having only guile is. I think it starts to be good at like 3..4 very different languages. Python itself is not the solution to anything. Menawhile pcb-gpmi is bitrotten; I am still using it with an old version of PCB (even debs are still available) but since the low user count I started the big configuration system refactoring of gpmi in trunk which most probably makes it fail to configure on non-linux systems. Regards, Tibor Palinkas ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
