Re: gEDA-user: Reinventing the wheel
Must it be round? ___ 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
> It would be great if we also had an easier way to contribute symbols > back (perhaps with just a mouse click or two). The only limit I put on gedasymbols is accountability. I want to make sure that if a symbol or footprint is up there, you know who's responsible for it. Solutions which meet that need would be acceptable to me Well, my time is limited too, they'd have to be easy solutions :-) ___ 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 Sat, May 21, 2011 at 1:26 AM, Kai-Martin Knaak wrote: > Colin D Bennett wrote: > >> Not to get into the whole light/heavy symbol debate > > Maybe, it is time to look at this issue again. When I first read geda > documentation, there were already references that this had been discussed > ad nauseam. As a result, the default lib was the way it was and is. This > is six year back now. Since then, this topic has not been raised on the > mailing list. But there are > > Except for some bug fixes, the default lib stayed the same for all the > years. No symbols were added, none was removed, nothing was restructured. > > If the default lib is to be changed now, then there should be some kind > of new consensus on the heavy/light issue. Else, the effort might end in > religious war and, or frustration. There will always be a place for both heavy and light. People's work flows vary too much to limit gEDA to just one. One thing worth thinking about is closer integration of gschem and pcb with gedasymbols.org. If our programs obtained symbols directly from there it would get people out of the mind-set that there is just one library of symbols. The reality is that our community provides a bazaar of different symbols and philosophies of symbol creation. It would be great if we also had an easier way to contribute symbols back (perhaps with just a mouse click or two). ___ 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 wrote: > Not to get into the whole light/heavy symbol debate Maybe, it is time to look at this issue again. When I first read geda documentation, there were already references that this had been discussed ad nauseam. As a result, the default lib was the way it was and is. This is six year back now. Since then, this topic has not been raised on the mailing list. But there are Except for some bug fixes, the default lib stayed the same for all the years. No symbols were added, none was removed, nothing was restructured. If the default lib is to be changed now, then there should be some kind of new consensus on the heavy/light issue. Else, the effort might end in religious war and, or frustration. ---<)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+kmk&op=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
Kai-Martin Knaak writes: > Stephan Boettcher wrote: >> My colleagues use eagle. I review their gerbers with gerbv. They >> envy my hierachical schematics and scripting fu, > > Funny. I got the impression, the scripting abilities of eagle are one > of the few things eagle really excels at. I've heard so, yes, one of our engineers does eagle scripting once in a while. But he had to learn how to script eagle. I did not learn any new language, I script in sed, awk, python, gnumeric. Both are good things. -- 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 do you have this notion of _right tool_? Because my job is at risk if I am notorious for using that odd piece of messy software nobody else can get results with. After all, I am supposed to help the colleagues solve their electronics problems... > My colleagues use eagle. I review their gerbers with gerbv. They > envy my hierachical schematics and scripting fu, Funny. I got the impression, the scripting abilities of eagle are one of the few things eagle really excels at. ---<)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
Colin D Bennett wrote: > If you put default footprint attributes on the symbols, it is an > invitation to error. It's better to force the user to specify a > footprint for each component. If you want to force users, you can put in a footprint with an invalid value. No footprint attribute at all just heightens the barrier. Footprint attributes not only contain a value. They also contain placement information relative to the symbol. I am no fan of forcing users. But your argument does not convince me anyway. No default footprint value is an invitation to error, too. Newbies hardly know the difference of SO16 and SO14-wide. Default footprint attribute values should of course correspond to reasonable footprints in the default lib of PCB. So default will produce reasonable results that can be manufactured. If the user wanted SMD, he or she will notice during placement. ---<)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
Andrew Poelstra wrote: > This already invalidates your point. The point is, that instances of the default library should be instantly usable for major use cases. And they should be good blueprints for the creation of the users own instances. The symbols in the current default lib fail for both. Most importantly, there is no footprint attribute. But there are more issues. Most of the symbols contain no license attributes, no description, no documentation, no symversion, no value. They are quite inconsistent. Some contain attributes geda won't recognize in a useful way (e.g. FND5148-1.sym features auth, date, fname and rev. The values of these attributes look like variables because they are terminated by $-characters.) There is even a symbol with no attribute at all. (input-orcad-1.sym). The recommended technique of split symbols is not to be found in the default lib. Instead, the three logic blocks of the 4000 are all contained in a single symbol. ---<)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
We're going over old ground now... [1]http://www.delorie.com/pcb/component-dbs.html "First, in gschem/gattrib, the the GUI has a way of querying the database for potential values of attributes - such as choosing variants, picking parts from official part lists, sticking to on-hand inventory, etc." Agreed on both counts. Default footprints would be misleading - having some choice and an easy way to select seems the most logical compromise. I have a bunch of symbols I've created myself where I put a footprint attribute in but set it TBD - because I know that depending on project I'll be switching between through hole and SMT... References 1. http://www.delorie.com/pcb/component-dbs.html ___ 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 Thu, May 19, 2011 at 6:45 AM, Stephan Boettcher wrote: > I still do not know where the pcb users manual is to be found. I found PCB home page (pcb.gpleda.org) top level link in navigation box on the left: "Manual". Choose your version. One could argue about how good or complete it is, but certainly not that it can't easily be found. Jared ___ 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
k...@aspodata.se (Karl Hammar) writes: > Stephan: > ... >> I still do not know where the pcb users manual is to be found. > ... > > You can find it in the git repo. as pcb/doc/pcb.pdf, > but you have to build it first. :-) -- 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: ... > I still do not know where the pcb users manual is to be found. ... You can find it in the git repo. as pcb/doc/pcb.pdf, but you have to build it first. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ 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
> No, but what would be really cool is if gschem knew about PCB symbols > so that when you open the properties window, footprint is a dropdown > list of available PCB footprints. We're going over old ground now... http://www.delorie.com/pcb/component-dbs.html "First, in gschem/gattrib, the the GUI has a way of querying the database for potential values of attributes - such as choosing variants, picking parts from official part lists, sticking to on-hand inventory, etc." ___ 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 Thu, May 19, 2011 at 10:27 AM, Stephan Boettcher wrote: > Kai-Martin Knaak writes: > >> Stephan Boettcher wrote: >> >>> The way to promote gedasymbols and to fix the default library is to >>> remove the default library, except for a small set of very generic >>> symbols. >> >> ack. >> This set of symbols should provide the ability to start working as is >> and generally be examples for complete working symbols. That is, they >> should contain footprint attributes. And when applicable simulation >> attributes, too. HOWTOs and manuals may refer to these items. > > nack. There is no way for a footprint attribute to be generic. > > These symbols shall exactly not be examples, and exactly not just work. > > They shall be symbols that can be use as they are for any workflow, by > adding the required attributes after instantiation, or by editing a copy > in a project lib, i.e., the first easy steps in learning symbol editing. > No, but what would be really cool is if gschem knew about PCB symbols so that when you open the properties window, footprint is a dropdown list of available PCB footprints. ___ 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 Thu, May 19, 2011 at 02:12:06PM -0400, Vanessa Ezekowitz wrote: > On Thu, 19 May 2011 08:36:50 -0600 > John Doty wrote: > > > On May 19, 2011, at 8:21 AM, Kai-Martin Knaak wrote: > > > > > Vanessa Ezekowitz wrote: > > > > > >> KMK didn't say what he means by "unusable", > > > > > > Most immediately: The symbols in the default lib do not contain footprint > > > attributes. Not even an empty ones. This prevents them to "just-work" for > > > the most common work-flow of geda: gschem -> gnetlist -> pcb -> gerbv > > > > What's the footprint for a transistor? A resistor? A 7400? All of these > > come in many packages and many also expect a 1:1 mapping from package to > > footprint, but that isn't how it works. > > But that *is* how it works - to a new user or a seasoned user, ultimately > footprint = package. We've had this discussion before, and the answer is > clear: > > Choose some reasonable defaults that will work for the majority of use cases. > Through hole or large gauge SMT unless there is no other option, and using > the most commonly available parts. > > If a person instantiates a transistor, give it a TO92-3 footprint (though I > prefer TO-18 for its retro look). > > Resistors? I use a footprint I created that fits 1/8 and 1/4W and folds the > resistor in half to save board space. > This already invalidates your point. Many hobbyist users don't care about TO resistor footprints, since you can fit the leads into pretty well any hole spacing. Me, I use 0805's since I have a lot of those. I have a friend who always uses 0603's for the same reason. Sometimes the I use massive SMT footprints or weird TO spacing to fit a lot of traces under the part. The moral is that defaults cannot make sense for even the simplest of parts. Capacitors are much worse, transistors worse still. All this without even considering paste width, etc. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ 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 Thu, 19 May 2011 08:36:50 -0600 John Doty wrote: > > On May 19, 2011, at 8:21 AM, Kai-Martin Knaak wrote: > > > Vanessa Ezekowitz wrote: > > > >> KMK didn't say what he means by "unusable", > > > > Most immediately: The symbols in the default lib do not contain footprint > > attributes. Not even an empty ones. This prevents them to "just-work" for > > the most common work-flow of geda: gschem -> gnetlist -> pcb -> gerbv > > What's the footprint for a transistor? A resistor? A 7400? All of these > come in many packages and many also expect a 1:1 mapping from package to > footprint, but that isn't how it works. But that *is* how it works - to a new user or a seasoned user, ultimately footprint = package. We've had this discussion before, and the answer is clear: Choose some reasonable defaults that will work for the majority of use cases. Through hole or large gauge SMT unless there is no other option, and using the most commonly available parts. If a person instantiates a transistor, give it a TO92-3 footprint (though I prefer TO-18 for its retro look). Resistors? I use a footprint I created that fits 1/8 and 1/4W and folds the resistor in half to save board space. Resistor packs? Use whatever SIPx footprint fits the part. Signal diodes like a 1N914? Same footprint (just tweak the drill diameter for thick-leaded parts like 1N4001) Capacitors? I use one I made with 200 mil lead spacing and about 50 mil width for ceramics, and the default ACY100 for electrolytics. ICs? Use an SOIC footprint unless the part only comes in some other form. IC sockets? Obvious - use a DIP footprint. The above probably covers 90% of use-cases, and besides, the user probably needs to be able to hand-assemble their creations initially (prototypes before a production run), and you can't do that if the initial board is covered in 0603, TSSOP, BGA, and similar parts, and/or parts of any kind that have to be bought at some only-sells-1000-at-a-time distributor. > > ack. > > The historically grown structure is less than stellar. And the scope needs > > to be reduced to what can sensibly be delivered. The libs should not > > suggest completeness where thay can only provide a (good) starting point. > > It isn't so much the libs, as the lib browser, which sends the selected > part straight to the schematic, thus giving the user the false impression > that they're finished with it. What's needed here is a minimal attribute editor right in the library browser window. Click a symbol, and the bottom of the window expands to show the most important attributes of the symbol: refdes, footprint, slot# if applicable. Click again in the schematic window and the symbol is placed with whatever attributes have been set. -- "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 ___ 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 Thu, 19 May 2011 16:21:31 +0200 Kai-Martin Knaak wrote: > Vanessa Ezekowitz wrote: > > > KMK didn't say what he means by "unusable", > > Most immediately: The symbols in the default lib do not contain > footprint attributes. Not even an empty ones. This prevents them to > "just-work" for the most common work-flow of geda: gschem -> gnetlist > -> pcb -> gerbv If you put default footprint attributes on the symbols, it is an invitation to error. It's better to force the user to specify a footprint for each component. If it seems like extra work for a user to assign footprints, consider that the user had better be reviewing each and every component's footprint in the schematic anyway... though you know you'll forget to check one component for which the default package is wrong. Ideally, footprint assignment would be easy and convenient, however. This could be improved by providing a footprint browser in gschem to quickly locate the right symbol name. 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 Thu, 19 May 2011 15:57:12 +0200
Kai-Martin Knaak wrote:
> Stephan Boettcher wrote:
>
> > The way to promote gedasymbols and to fix the default library is to
> > remove the default library, except for a small set of very generic
> > symbols.
>
> ack.
> This set of symbols should provide the ability to start working as is
> and generally be examples for complete working symbols. That is, they
> should contain footprint attributes.
Not to get into the whole light/heavy symbol debate, but since we're
talking about making this uniform, simpler, and easier for new users, I
think there would be less opportunity for error if symbols did not
include a footprint attribute, UNLESS there is only one footprint
possible. For instance, what footprint does a resistor symbol use?
Or, what footprint does an SPDT switch use? A battery? A transistor
(and of course many logical-physical pin mappings for transistors!).
Speaking of transistors, this brings to mind the mapping of schematic
pins to PCB footprint pins. Because I don't want to create a different
PNP, NPN, N-MOSFET, P-MOSFET, etc. symbol for each package pinout, I
use logical pin names ("numbers") in my symbols:
G, D, S (gate, drain, source) for MOSFET
B, C, E (base, collector, emitter) for BJT
P, N (P-doped and N-doped terminal) for all types of diode incl. LED
--> anode and cathode are less appropriate because they refer to
actual current flow (which may be reverse biased, esp. for
zener)
The I have corresponding footprints such as
SOT23__MOSFET_1G_2S_3D - MOSFET in SOT-23 package with gate on pin
1, source on pin 2, and drain on pin 3.
The result is that you need fewer variants of symbols and there is less
of the "magic" pin 1 = +, pin 2 = - assumption between symbols and
footprints on these generic parts, where pin numbering is not
standardized. It is much harder to make a footprint-symbol pin
mapping error since there is a single logical-physical mapping that
takes place in just one step (selecting the footprint).
If you think that the current gschem library's polarized capacitor and
diodes are sufficient, consider that gschem's “led-3.sym” has the
opposite polarity (pin 1 is negative terminal) of led-1.sym and
led-2.sym!! The casual user is very likely to overlook this. Even if
the pin numbers were shown, "pin 1" has no meaning for an LED, in
contrast to an IC package.
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
Kai-Martin Knaak writes: > Stephan Boettcher wrote: > >> The way to promote gedasymbols and to fix the default library is to >> remove the default library, except for a small set of very generic >> symbols. > > ack. > This set of symbols should provide the ability to start working as is > and generally be examples for complete working symbols. That is, they > should contain footprint attributes. And when applicable simulation > attributes, too. HOWTOs and manuals may refer to these items. nack. There is no way for a footprint attribute to be generic. These symbols shall exactly not be examples, and exactly not just work. They shall be symbols that can be use as they are for any workflow, by adding the required attributes after instantiation, or by editing a copy in a project lib, i.e., the first easy steps in learning symbol editing. -- 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
On May 19, 2011, at 8:21 AM, Kai-Martin Knaak wrote: > Vanessa Ezekowitz wrote: > >> KMK didn't say what he means by "unusable", > > Most immediately: The symbols in the default lib do not contain footprint > attributes. Not even an empty ones. This prevents them to "just-work" for > the most common work-flow of geda: gschem -> gnetlist -> pcb -> gerbv What's the footprint for a transistor? A resistor? A 7400? All of these come in many packages and many also expect a 1:1 mapping from package to footprint, but that isn't how it works. > > >> The first thing that comes to mind is that, for both Gschem and PCB, >> the libraries need recategorized. > > ack. > The historically grown structure is less than stellar. And the scope needs > to be reduced to what can sensibly be delivered. The libs should not suggest > completeness where thay can only provide a (good) starting point. It isn't so much the libs, as the lib browser, which sends the selected part straight to the schematic, thus giving the user the false impression that they're finished with it. 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: Reinventing the wheel
On Wed, May 18, 2011 at 04:25:40AM +0200, Kai-Martin Knaak 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 (http://reprap.org/wiki/KiCad) > * micropendous (http://code.google.com/p/micropendous/) > * nanonote (http://en.qi-hardware.com/wiki/Main_Page ) Thanks for the links. I never noticed that reprap and nanonote were KiCad, and I never heard of micropendous before (and it looks useful). ___ 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
Vanessa Ezekowitz wrote: > KMK didn't say what he means by "unusable", Most immediately: The symbols in the default lib do not contain footprint attributes. Not even an empty ones. This prevents them to "just-work" for the most common work-flow of geda: gschem -> gnetlist -> pcb -> gerbv > The first thing that comes to mind is that, for both Gschem and PCB, > the libraries need recategorized. ack. The historically grown structure is less than stellar. And the scope needs to be reduced to what can sensibly be delivered. The libs should not suggest completeness where thay can only provide a (good) starting point. ---<)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+kmk&op=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
Stephan Boettcher wrote: > The way to promote gedasymbols and to fix the default library is to > remove the default library, except for a small set of very generic > symbols. ack. This set of symbols should provide the ability to start working as is and generally be examples for complete working symbols. That is, they should contain footprint attributes. And when applicable simulation attributes, too. HOWTOs and manuals may refer to these items. In addition, there should be a discoverable mechanism to exclusively use a specific set of libs. Currently gschem and gnetlist use a multiple fall-back strategy to find actual instances of footprints and symbols. This is the kind of automatism that introduces nasty design failures. It makes the user feel less in control and uneasy. The cvs way to mirror the contents of gedasymbols.org on the local hard disk should be installed by default. ---<)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+kmk&op=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
John Doty writes: > So, is it really that bad? In the end, when you really need to look something up, giyf, it is all there. But terribly disorganised. For most things that may need looking up I am completely unaware that they even exist. As I said eleswhere, the first thing I tend to read is some kind of reference manual. Those things are typically not very verbose and give me a complete overview what the program, API, language, library can do for me. I could not point to such documents for gaf or PCB. I still do not know where the pcb users manual is to be found. I found it several times in the past after some googling, and after I read it, I still have no idea what the possibilities are on the pcb actions command line, because it appears to be incomplete both in coverage of the actions as well as the parameters for the actions. This is not a complaint, since I get along with what I know. I may just miss out on a lot of nice features that I do not know about. What I did find early (and enjoyed a lot) was the file formats documentation. -- 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
On May 19, 2011, at 4:26 AM, Stephan Boettcher wrote:
>> 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.
>
> Ok, yes, that is a valid point... the lack of documented APIs.
Here's a start, posted once before.
gnetlist:get-packages level
Yields a list of refdes values for the set of schematics. Duplicated values are
only listed once. The "level" argument must be present, but is unused.
gnetlist:get-non-unique-packages level
Yields a list of refdes values for the set of schematics. Duplicated values are
listed as many times as they appear. The "level" argument must be present, but
is unused.
gnetlist:get-pins refdes
Yields a list of pin numbers for the specified refdes value.
gnetlist:get-all-nets level
Yields a list of net names for the set of schematics. Duplicated values are
listed as many times as they appear (once per segment?). The "level" argument
must be present, but is unused.
gnetlist:get-all-unique-nets level
Yields a list of net names for the set of schematics. Duplicated values are
only listed once. The "level" argument must be present, but is unused.
gnetlist:get-all-connections net
Yields a list of all connections to the named net. Each element of the list is
itself a two element list of the form (refdes pinnumber).
gnetlist:get-nets refdes pin
This is apparently intended to yield the netname connected to the given pin
along with all pins connected to that net, including the pin in the initial
query. A little experimentation, however, shows that it does not reliably list
all of the connections, possibly due to a problem with net= connections. Most
(all?) existing back ends that use this appear to use only the netname.
gnetlist:get-pins-nets refdes
Yields a list of (pinnumber . netname) pairs detailing all connections for the
given refdes.
gnetlist:get-package-attribute refdes attribute
Yields the value of the named attribute attached to a symbol instance with the
given refdes. Yields "unknown" if the attribute is absent. It only yields one
value, regardless of how many matching attributes exist in the set of
schematics. If there is more than one instance only the first instance
encountered is inspected, so it may yield "unknown, even if a matching
attribute is present.
gnetlist:get-toplevel-attribute attribute
Yields the value of the named attribute at top level, that is, an attribute
present in one of the schematics unattached to any object. Yields "not found"
if no matching attribute is present.
gnetlist:get-renamed-nets level
When gnetlist expands a hierarchical subcircuit, it first assigns every net
within the subcircuit a unique name based on the refdes of the subcircuit
instance and, if present, the netname within the subcircuit. If a net is
attached to the higher level circuit, gnetlist then changes the name of the
subcircuit net to the name of the higher level net to which it is attached.
"gnetlist:get-renamed-nets" returns a list of lists of pairs of names. The
first name in a pair is the initial unique netname within the subcircuit, the
second is the higher level netname it has acquired. The "level" argument must
be present, but is unused.
gnetlist:get-attribute-by-pinseq refdes pinseq attribute
Yields the value of the named attribute attached to the pin with the named
pinseq attribute to the package with the named refdes attribute.
gnetlist:get-attribute-by-pinnumber refdes pinnumber attribute
Yields the value of the named attribute attached to the pin with the named
pinnumber attribute to the package with the named refdes attribute.
gnetlist:vams-get-package-attributes refdes
Yields a list of the names of attributes attached to the symbol at schematic
level?
gnetlist:get-slots refdes
Yields a list of all slot attributes associated with a given refdes. Duplicated
values are listed as many times as they appear.
gnetlist:get-unique-slots refdes
Yields a list of all slot attributes associated with a given refdes. Duplicated
values are listed only once.
gnetlist:graphical-objs-in-net-with-attrib-get-attrib netname attrstring
attribute
This searches for a graphical symbol attached to a net with the given netname.
The symbol must have attrstring (of the form name=value) attached. It yields
the value of the specified attribute,
gnetlist:get-calling-flags
Yields a list of lists of command line flags and values. Each flag must be
known to the gnetlist front end. For example, the "--nomunge" flag will yield
("nomunge_mode" #t).
gnetlist:get-command-line
Broken or unimplemented? Yields #f.
Higher level functions built atop these are in:
wherever/share/gEDA/scheme/gnetlist.scm
wherever/share/gEDA/scheme/gnetlist-post.scm
These are fairly comprehen
Re: gEDA-user: Reinventing the wheel
Geoff Swan writes: >> >> > > 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. It can be fixed, ... > 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. The way to promote gedasymbols and to fix the default library is to remove the default library, except for a small set of very generic symbols. I do use some symbols from the defaul library, generic resistors, capacitors, transistors, switches, but nothing else. Basically only the very generic drawings. The first thing a new user shall (have to) learn is making symbols, and (for a pcb workflow) footprints, or (for a simulation workflow) models, because, as John said, it cannot be done right for everybody, so we shall not try, and if it were possible, nobody wants to to the work anyway. -- 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
Kai-Martin Knaak writes: > 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. Why do you have this notion of _right tool_? Let them use what they want. My colleagues use eagle. I review their gerbers with gerbv. They envy my hierachical schematics and scripting fu, but still, they are happy. All I say is: look if you want help from me with these things, use gEAD, else, do it yourself. >> 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. just what I said see below ... >> 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. That are two of those little details, major ones. -- 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
Kai-Martin Knaak writes: > 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. Ok, yes, that is a valid point... the lack of documented APIs. -- 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
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
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: Reinventing the wheel
> > 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. 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. 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. ___ 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 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 ___ 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 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: 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 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. 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: 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 find&replace 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
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
Re: gEDA-user: Reinventing the wheel
Colin D Bennett 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: 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
Kai-Martin Knaak 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
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
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: Reinventing the wheel
On 18/05/2011, Russell Shaw wrote: > > On 17/05/2011, John Doty 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
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+kmk&op=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 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
On Tue, 17 May 2011 22:30:27 -0400 DJ Delorie 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
> 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
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
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
> On 17/05/2011, John Doty 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
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: Reinventing the wheel
DJ Delorie wrote: > There's a list on gpleda.org: > > http://geda.seul.org/wiki/geda:links What would be the top five with regard to public visibility, nerdiness, or technological impact? ---<)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
> BTW, what are the show cases for geda/pcb? There's a list on gpleda.org: http://geda.seul.org/wiki/geda:links Personally, climate control and electrical monitoring in my house is done by gEDA/PCB projects. ___ 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: > The problem with KiCAD is 1) C++, 2) Qt. The problems I encountered with gnetlist were 1) scheme 2) poor documentation ---<)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
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 (http://reprap.org/wiki/KiCad) * micropendous (http://code.google.com/p/micropendous/) * nanonote (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 ( http://ronja.twibright.com/ ). What else? ---<)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 May 17, 2011, at 12:57 PM, Eduardo Costa wrote: > 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: That's not the toolkit approach: it's just scripting within an integrated tool. Toolkits work well with other toolkits, so gEDA works with the simple, classic UNIX tools like make and AWK, as well as things like LaTeX. With gEDA, once you've captured the design with gschem, you never need to use GUI at all to make data products like netlists, BOM, simulation outputs, and documentation. 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: Reinventing the wheel
On Mon, 16 May 2011 16:41:11 -0700 Steven Michalske wrote: > On May 16, 2011, at 4:25 PM, al davis wrote: > > > On Monday 16 May 2011, Steven Michalske wrote: > >> But lawyers can use that clause as a loophole to invalidate > >> legitimate patents. > > > > Minor side effect of "lawyers can use that clause as a loophole > > to invalidate ILLegitimate patents" ... which outnumber the > > ligitimate ones a million to one. > > > A software licence should not be used for this purpose... As a person with > patents, I can't afford to contribute substantual code back, but I can use > all the code I want. Because my patents are legitimate. You don't want to open *that* can of worms here, Steven. If your patents are in regards to a piece of software or a software algorithm, they aren't legitimate, no matter what the laws of the issuing country may say. You "can't afford it" because you have this idea in your head that locking up your code will somehow result in a substantially higher profit than if the code had been open. -- "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 ___ 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
That's a shot of it: http://imageshack.us/f/84/shoti.png/ It lacks a two cadinal pointers in the image, as I was testing don't remember what when I had stop it. I also forgot to say is done right on top of Xlib and uses XResources for font color, background and border color. No dependencies or whatsoever on thirdy-party libraries. Regards, On 17/05/2011, 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. > > Regards, > > > On 17/05/2011, John Doty 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 >> >> >> >> >> ___ >> 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
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. Regards, On 17/05/2011, John Doty 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 > > > > > ___ > 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 Tue, 2011-05-17 at 15:36 +0200, Stefan Salewski wrote: > On Tue, 2011-05-17 at 12:02 +0100, Peter Clifton wrote: > > > Core features in the PCB editor can be pretty complex. We have a lot of > > code for dealing with polygon geometry, > May we consider use of clipping libraries like > > http://angusj.com/delphi/clipper.php Why - is ours broken? (Answer - a little, but I don't know theirs would be any better) Is theirs faster? I could believe theirs "might" be faster (it uses a scan-line based algorithm which ours does not). Is it optimised (like ours is) for speed performing iterative computation on existing polygons without touching unaffected geometry? This might make a real difference PCB's speed. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ 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 11:15 AM, DJ Delorie wrote: > >> There are already two IPC architectures in place between gschem and >> PCB: >> >> 1. Text files. >> 2. The user. > 3. dbus > > (at least, we had it working at one point) dbus is one of the approaches I had in mind when I wrote: > General-purpose IPC is complex, fragile, and always less flexible than > intended. 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: Reinventing the wheel
> There are already two IPC architectures in place between gschem and > PCB: > > 1. Text files. > 2. The user. 3. dbus (at least, we had it working at one point) ___ 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
Hi John, Russell Shaw wrote: > There's no reason why a schematic and pcb editor can't have tight > coupling and still interact with all external tools. John Doty wrote: > The architectures are different. To flexibly interact with external > tools, you need the interfaces to be simple text files. Anything more > complex is a serious barrier, in general. What do you mean by "the architectures are different"? The reason I ask is that I am sceptical that a different architecture is required to allow IPC. There are already two IPC architectures in place between gschem and PCB: 1. Text files. 2. The user. I think the general consensus is that these are good IPC mechanisms; they can get the job done. However, they are poor for a variety of use cases that people have. For some of these, the biggest disadvantage is that they are too slow. Cheers, Rob signature.asc Description: This is a digitally signed message part ___ 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 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 ___ 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 01:41, John Doty wrote: On May 17, 2011, at 9:06 AM, Russell Shaw wrote: It seems like too much redundancy to have two projects with similar uses (which i wouldn't like), and i don't like forking either. But your vision is an integrated tool, while gEDA is a toolkit. I'm still studying geda, but if i did some real work on it, it would end up having an extra file format, extra guis, and a closer sch/pcb link. Please, no. These are tools that represent extremely incompatible design philosophies. They work well together only because the interface is clean and simple, and avoids the minefield of integration. 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. ___ 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 01:06 +1000, Russell Shaw wrote: > > I'm still studying geda, but if i did some real work on it, it > would end up having an extra file format, extra guis, and a closer > sch/pcb link. > Maybe a good starting point is defining a new extended file format. (For current pcb footprint keepouts and copper arcs are missing...) If that format is fine, someone may write importers and exporters for gschem, PCB, maybe KiCAD. But even this is a big task -- some like the gschem format with position dependent meaning, some like XML, YAML, SVG. I think it is not a bad idea to have separate tools for schematic capture and PCB layout work -- the tasks are really different, sometimes done by different people. A closer coupling would be fine -- back annotation and cross probing. That is easier in an integrated tool. ___ 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 9:06 AM, Russell Shaw wrote: > It seems like too much redundancy to have two projects with similar > uses (which i wouldn't like), and i don't like forking either. But your vision is an integrated tool, while gEDA is a toolkit. > > I'm still studying geda, but if i did some real work on it, it > would end up having an extra file format, extra guis, and a closer > sch/pcb link. Please, no. These are tools that represent extremely incompatible design philosophies. They work well together only because the interface is clean and simple, and avoids the minefield of integration. 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: Reinventing the wheel
On Wed, 2011-05-18 at 00:41 +1000, Russell Shaw wrote: > > The problem with KiCAD is 1) C++, 2) Qt. > > C++ was a *really* bad idea. Qt i don't like because it was fundamentally > architected just for the sake of hiding code from users using the MOC > preprocessor that used to be closed source. Anyway, it's C++ too. > KiCAD uses wxWidgets, not (direct) QT. Qucs uses QT. Many people seems to like QT. When I started learning GUI programming for Linux some years ago, I decided for GTK, against QT. Because GTK is more in the spirit of FOSS. But most people seems to vote for QT, against GTK. Popularity of QT may drop, when there is less support from Nokia in future. C++: I have never managed to really learn it -- with a background in Pascal/Modula/Oberon I was never really happy with C++. But for a PCB layout tool C++ may be still the best choice. Ruby and Python are nice for non time critical applications. Vala may be a nice option, as long we are programming for GTK/Gnome. ___ 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 00:30, Stefan Salewski wrote: On Tue, 2011-05-17 at 23:59 +1000, Russell Shaw wrote: Instead of blindly reinventing the wheel, i always look in detail at what currently exists. Maybe KiCAD is a better starting point for you? Written in C++ with wxWidgets, it is available for multiple OS including windows. Here in Germany KiCad is more popular than gEDA/PCB, even for Linux users. I do not really understand this, I have never find time and motivation to really test KiCad myself. 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... On the KiCAD developer mailing list there is much activity, but there are only a few really smart and active developers, so development progress is slow. Indeed, nearly all windows KiCAD users seems to be only consumers, without any contributions. And there is Fritzing or Qucs -- Qucs has schematics and simulation support, but PCB backend is missing. Once I had the strange idea to implement a PCB or schematics mode for inkscape. Really crazy. The problem with KiCAD is 1) C++, 2) Qt. C++ was a *really* bad idea. Qt i don't like because it was fundamentally architected just for the sake of hiding code from users using the MOC preprocessor that used to be closed source. Anyway, it's C++ too. If i got familiar enough with geda, i'd adapt it, but it's a tradeoff of how much work it would take compared to something new. The biggest problem is changes without affecting current users. IMO, more progress would be made by exchanging code between separate projects. It seems like too much redundancy to have two projects with similar uses (which i wouldn't like), and i don't like forking either. I'm still studying geda, but if i did some real work on it, it would end up having an extra file format, extra guis, and a closer sch/pcb link. ___ 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 00:30, Stefan Salewski wrote: On Tue, 2011-05-17 at 23:59 +1000, Russell Shaw wrote: Instead of blindly reinventing the wheel, i always look in detail at what currently exists. Maybe KiCAD is a better starting point for you? Written in C++ with wxWidgets, it is available for multiple OS including windows. Here in Germany KiCad is more popular than gEDA/PCB, even for Linux users. I do not really understand this, I have never find time and motivation to really test KiCad myself. 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... On the KiCAD developer mailing list there is much activity, but there are only a few really smart and active developers, so development progress is slow. Indeed, nearly all windows KiCAD users seems to be only consumers, without any contributions. And there is Fritzing or Qucs -- Qucs has schematics and simulation support, but PCB backend is missing. Once I had the strange idea to implement a PCB or schematics mode for inkscape. Really crazy. The problem with KiCAD is 1) C++, 2) Qt. C++ was a *really* bad idea. Qt i don't like because it was fundamentally architected just for the sake of hiding code from users using the MOC preprocessor that used to be closed source. Anyway, it's C++ too. If i got familiar enough with geda, i'd adapt it, but it's a tradeoff of how much work it would take compared to something new. The biggest problem is changes without affecting current users. IMO, more progress would be made by exchanging code between separate projects. ___ 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 00:30, Stefan Salewski wrote: On Tue, 2011-05-17 at 23:59 +1000, Russell Shaw wrote: Instead of blindly reinventing the wheel, i always look in detail at what currently exists. Maybe KiCAD is a better starting point for you? Written in C++ with wxWidgets, it is available for multiple OS including windows. Here in Germany KiCad is more popular than gEDA/PCB, even for Linux users. I do not really understand this, I have never find time and motivation to really test KiCad myself. 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... On the KiCAD developer mailing list there is much activity, but there are only a few really smart and active developers, so development progress is slow. Indeed, nearly all windows KiCAD users seems to be only consumers, without any contributions. And there is Fritzing or Qucs -- Qucs has schematics and simulation support, but PCB backend is missing. Once I had the strange idea to implement a PCB or schematics mode for inkscape. Really crazy. The problem with KiCAD is 1) C++, 2) Qt. C++ was a *really* bad idea. Qt i don't like because it was fundamentally architected just for the sake of hiding code from users using the MOC preprocessor that used to be closed source. Anyway, it's C++ too. ___ 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, 2011-05-17 at 23:59 +1000, Russell Shaw wrote: > > Instead of blindly reinventing the wheel, i always look in detail > at what currently exists. Maybe KiCAD is a better starting point for you? Written in C++ with wxWidgets, it is available for multiple OS including windows. Here in Germany KiCad is more popular than gEDA/PCB, even for Linux users. I do not really understand this, I have never find time and motivation to really test KiCad myself. 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... On the KiCAD developer mailing list there is much activity, but there are only a few really smart and active developers, so development progress is slow. Indeed, nearly all windows KiCAD users seems to be only consumers, without any contributions. And there is Fritzing or Qucs -- Qucs has schematics and simulation support, but PCB backend is missing. Once I had the strange idea to implement a PCB or schematics mode for inkscape. Really crazy. Best wishes, Stefan Salewski ___ 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 00:15, John Doty wrote: On May 17, 2011, at 7:45 AM, Russell Shaw wrote: A well-stocked workshop is nothing more than a multitool workshop. With that attitude, you'll botch the job. There's no reason why a schematic and pcb editor can't have tight coupling and still interact with all external tools. The architectures are different. To flexibly interact with external tools, you need the interfaces to be simple text files. Anything more complex is a serious barrier, in general. That's why the matching pcb/schematic editors will work seamlessly, but external tools will only work by importing and exporting file formats. If an external tool had a way of "remote control" by scripting, then some degree of closer coupling between the tools could be done. The only disadvantage to external tools is that an interface layer is needed. A separate piece of complex code for every interface, yes. This isn't too bad in gEDA, because we don't try to integrate the diverse collection of downstream tools with gschem: it's a pretty clean, simple flow. The coupling could simply be an ipc protocol between separate programs. Specialized IPC is good in its place. General-purpose IPC is complex, fragile, and always less flexible than intended. Agreed. ___ 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 7:45 AM, Russell Shaw wrote: > A well-stocked workshop is nothing more than a multitool workshop. With that attitude, you'll botch the job. > There's > no reason why a schematic and pcb editor can't have tight coupling and > still interact with all external tools. The architectures are different. To flexibly interact with external tools, you need the interfaces to be simple text files. Anything more complex is a serious barrier, in general. > The only disadvantage to external > tools is that an interface layer is needed. A separate piece of complex code for every interface, yes. This isn't too bad in gEDA, because we don't try to integrate the diverse collection of downstream tools with gschem: it's a pretty clean, simple flow. > The coupling could simply be > an ipc protocol between separate programs. Specialized IPC is good in its place. General-purpose IPC is complex, fragile, and always less flexible than intended. --- John Doty Noqsi Aerospace, Ltd. This message contains technical discussion involving difficult issues. No personal disrespect or malice is intended. If you perceive such, your perception is simply wrong. I'm a busy person, and in my business "go along to get along" causes mission failures and sometimes kills people, so I tend to be a bit blunt. ___ 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/11 23:43, Stefan Salewski wrote: On Tue, 2011-05-17 at 23:35 +1000, Russell Shaw wrote: I was expert at using high-end HP DCS/PCDS on unix boxes 20 years ago before it got discontinued, and a few other cad systems since then. A very first task i would do is create a decent gui for drawing the symbol and footprint in the schematic/pcb library, and make a decent library browser. makes me not really confident. I've thought of all the implementation and usage problems for a *long* time. I've been coding on lower level problems for quite a while too. Great -- the FOSS EDA world really needs some more smart and active people. Instead of blindly reinventing the wheel, i always look in detail at what currently exists. The more i figure out geda, maybe i could do something with it. It's just that i have to do it at arms length because i can't stand using it. ___ 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, 2011-05-17 at 23:35 +1000, Russell Shaw wrote: > > I was expert at using high-end HP DCS/PCDS on unix boxes 20 years > ago before it got discontinued, and a few other cad systems since then. > > >> A very first task i would do is create a decent gui for drawing the > >> symbol and footprint in the schematic/pcb library, and make a decent > >> library browser. > > > > makes me not really confident. > > I've thought of all the implementation and usage problems for a *long* time. > I've been coding on lower level problems for quite a while too. > Great -- the FOSS EDA world really needs some more smart and active people. ___ 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/11 22:40, John Doty wrote: On May 17, 2011, at 4:36 AM, Russell Shaw wrote: Hi, A schematic/pcb editor is not "huge" unless it's done in an inelegant way. A very first task i would do is create a decent gui for drawing the symbol and footprint in the schematic/pcb library, and make a decent library browser. Then i would make a drawing mode so that whatever symbol i click on in the schematic, will appear under the mouse in the pcb. Likewise, clicking a pcb symbol hilights it in the schematic. I'd design everything from the ground up to decent reverse annotations so that pin and gate swapping in the pcb appears in the schematic. Hierarchical schematics is a must too. OK, you want an integrated tool. Integrated tools are great: I have a nice, handy multitool on my belt. It's the tool I use most. By serializing all the gui actions internally, undo/redo and scripting is easy to add. Creating a schematic and pcb should be done productively within the first hour of never having used the program, yet have no limitations for power users. Impossible. A multitool cannot do all of the things a well-stocked workshop can. The architectures are different. A well-stocked workshop is nothing more than a multitool workshop. There's no reason why a schematic and pcb editor can't have tight coupling and still interact with all external tools. The only disadvantage to external tools is that an interface layer is needed. The coupling could simply be an ipc protocol between separate programs. Your program will probably never export designs to other layout programs. It will never support a variety of simulators. It will never support symbolic circuit analysis. It will never support scripted documentation generation. Or the other things in the open-ended list a toolkit can support. A main priority was to draw schematics for input to a spice or microwave circuit simulator (simulator writing is my other interest), and have an easy gui way of displaying the results. That's fine for an integrated tool: target the specific flow you want. It's no doubt what the majority of users would prefer, at least at the start, and gEDA will still be around for those who need more. Everything in geda is 180deg opposite to what i'd do. ___ 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, 2011-05-17 at 12:02 +0100, Peter Clifton wrote: > Core features in the PCB editor can be pretty complex. We have a lot of > code for dealing with polygon geometry, May we consider use of clipping libraries like http://angusj.com/delphi/clipper.php ___ 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/11 22:31, Stefan Salewski wrote: On Tue, 2011-05-17 at 20:36 +1000, Russell Shaw wrote: On 17/05/11 02:44, DJ Delorie wrote: Hi, A schematic/pcb editor is not "huge" unless it's done in an inelegant way. A very first task i would do is create a decent gui for drawing the symbol and footprint in the schematic/pcb library, and make a decent library browser. Then i would make a drawing mode so that whatever symbol i click on in the schematic, will appear under the mouse in the pcb. Likewise, clicking a pcb symbol hilights it in the schematic. I'd design everything from the ground up to decent reverse annotations so that pin and gate swapping in the pcb appears in the schematic. Hierarchical schematics is a must too. By serializing all the gui actions internally, undo/redo and scripting is easy to add. Creating a schematic and pcb should be done productively within the first hour of never having used the program, yet have no limitations for power users. Everything in geda is 180deg opposite to what i'd do. gEDA/PCB may be not the ultimate tools, but they work not bad, when you have learned to use them. (I guess for KiCAD it is similar) Most other commercial tools, like the popular eagle, or the more than 10k Euro professional tools, needs a long learning period. I was told that companies consider a 3 month learning period with seminars for employees when they switch their 10k professionals tools. EDA design is different from custom office tools! And an application interface is not bad, just because it is not like latest Apple/Windows style. I really would be happy if we can try YOUR EDA suite soon -- but I know how fast these great projects can fail. Your sentence I was expert at using high-end HP DCS/PCDS on unix boxes 20 years ago before it got discontinued, and a few other cad systems since then. A very first task i would do is create a decent gui for drawing the symbol and footprint in the schematic/pcb library, and make a decent library browser. makes me not really confident. I've thought of all the implementation and usage problems for a *long* time. I've been coding on lower level problems for quite a while too. ___ 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 4:36 AM, Russell Shaw wrote: > > Hi, > A schematic/pcb editor is not "huge" unless it's done in an inelegant way. > > A very first task i would do is create a decent gui for drawing the symbol > and footprint in the schematic/pcb library, and make a decent library browser. > Then i would make a drawing mode so that whatever symbol i click on in the > schematic, will appear under the mouse in the pcb. Likewise, clicking a pcb > symbol hilights it in the schematic. > > I'd design everything from the ground up to decent reverse annotations so > that pin and gate swapping in the pcb appears in the schematic. Hierarchical > schematics is a must too. OK, you want an integrated tool. Integrated tools are great: I have a nice, handy multitool on my belt. It's the tool I use most. > > By serializing all the gui actions internally, undo/redo and scripting is easy > to add. > > Creating a schematic and pcb should be done productively within the first > hour of never having used the program, yet have no limitations for power > users. Impossible. A multitool cannot do all of the things a well-stocked workshop can. The architectures are different. Your program will probably never export designs to other layout programs. It will never support a variety of simulators. It will never support symbolic circuit analysis. It will never support scripted documentation generation. Or the other things in the open-ended list a toolkit can support. That's fine for an integrated tool: target the specific flow you want. It's no doubt what the majority of users would prefer, at least at the start, and gEDA will still be around for those who need more. > > Everything in geda is 180deg opposite to what i'd do. > I cheer for your success. Both approaches are needed. --- John Doty Noqsi Aerospace, Ltd. This message contains technical discussion involving difficult issues. No personal disrespect or malice is intended. If you perceive such, your perception is simply wrong. I'm a busy person, and in my business "go along to get along" causes mission failures and sometimes kills people, so I tend to be a bit blunt. ___ 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, 2011-05-17 at 20:36 +1000, Russell Shaw wrote: > On 17/05/11 02:44, DJ Delorie wrote: > > Hi, > A schematic/pcb editor is not "huge" unless it's done in an inelegant way. > > A very first task i would do is create a decent gui for drawing the symbol > and > footprint in the schematic/pcb library, and make a decent library browser. > Then i would make a drawing mode so that whatever symbol i click on in the > schematic, will appear under the mouse in the pcb. Likewise, clicking a pcb > symbol hilights it in the schematic. > > I'd design everything from the ground up to decent reverse annotations so > that pin and gate swapping in the pcb appears in the schematic. Hierarchical > schematics is a must too. > > By serializing all the gui actions internally, undo/redo and scripting is easy > to add. > > Creating a schematic and pcb should be done productively within the first > hour of never having used the program, yet have no limitations for power > users. > > Everything in geda is 180deg opposite to what i'd do. > gEDA/PCB may be not the ultimate tools, but they work not bad, when you have learned to use them. (I guess for KiCAD it is similar) Most other commercial tools, like the popular eagle, or the more than 10k Euro professional tools, needs a long learning period. I was told that companies consider a 3 month learning period with seminars for employees when they switch their 10k professionals tools. EDA design is different from custom office tools! And an application interface is not bad, just because it is not like latest Apple/Windows style. I really would be happy if we can try YOUR EDA suite soon -- but I know how fast these great projects can fail. Your sentence >A very first task i would do is create a decent gui for drawing the >symbol and footprint in the schematic/pcb library, and make a decent >library browser. makes me not really confident. Best regards, Stefan Salewski ___ 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, 2011-05-17 at 20:36 +1000, Russell Shaw wrote: > On 17/05/11 02:44, DJ Delorie wrote: > > > >> I've always been interested in CAD programs and thought of making > >> a schematic/pcb one from scratch. > > > > I've never truly understood why people would rewrite a (potentially) > > huge application set "just because". Why not start with the existing > > tools and just rewrite the parts you're interested in? Like, start > > with pcb's HID modules but swap out the core? > > > > (and if you really want to get *that* involved in pcb layout tools, > > there *are* parts of pcb that could stand to be ripped out and > > replaced... ;) > > Hi, > A schematic/pcb editor is not "huge" unless it's done in an inelegant way. Core features in the PCB editor can be pretty complex. We have a lot of code for dealing with polygon geometry, and I wouldn't even know where to start when in comes to the auto-router and topo-router! [...] > Creating a schematic and pcb should be done productively within the first > hour of never having used the program, yet have no limitations for power > users. Always a good aim to have. Granted gEDA can do better in this regard, but IMO gschem and PCB are very intuitive for drawing with. (Perhaps the bias of experience applies here). What I would concede is that our forward / backwards annotation and cross probing work-flows are pretty un-discoverable. These are all things we aim to improve, but it is not an instant change. Knowing the gEDA and PCB code bases well, I strongly feel that it would be less work (and more productive) to slowly refactor and fix those. It is almost certain that you will be able to build these features from scratch in less time than it takes to refactor all the old code, BUT - you would also have to implement a TON of features which already work. > Everything in geda is 180deg opposite to what i'd do. In terms of code, UI design, architecture design? There is no wrong answer here of course, and there are plenty of things in gEDA which I would not implement the same had I written them myself. Please feel free (as far as licenses are compatible), to borrow any bits of code from gEDA as you bootstrap your efforts. It would be interesting to see another project develop where different ideas can be tested without the burden of legacy code and user-base. I hope that if you continue with this, we can share some ideas - and perhaps help improve gEDA in the process. Finally, this has become a little off-topic for geda-user (which has a very wide audience, not all interested in development details - especially as this case sounds to be heading, of new, non-gEDA tools!) Perhaps you could apply to geda-dev and move any development discussion there? -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ 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/11 02:44, DJ Delorie wrote: I've always been interested in CAD programs and thought of making a schematic/pcb one from scratch. I've never truly understood why people would rewrite a (potentially) huge application set "just because". Why not start with the existing tools and just rewrite the parts you're interested in? Like, start with pcb's HID modules but swap out the core? (and if you really want to get *that* involved in pcb layout tools, there *are* parts of pcb that could stand to be ripped out and replaced... ;) Hi, A schematic/pcb editor is not "huge" unless it's done in an inelegant way. A very first task i would do is create a decent gui for drawing the symbol and footprint in the schematic/pcb library, and make a decent library browser. Then i would make a drawing mode so that whatever symbol i click on in the schematic, will appear under the mouse in the pcb. Likewise, clicking a pcb symbol hilights it in the schematic. I'd design everything from the ground up to decent reverse annotations so that pin and gate swapping in the pcb appears in the schematic. Hierarchical schematics is a must too. By serializing all the gui actions internally, undo/redo and scripting is easy to add. Creating a schematic and pcb should be done productively within the first hour of never having used the program, yet have no limitations for power users. Everything in geda is 180deg opposite to what i'd do. ___ 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
hit send too soon On May 16, 2011, at 4:30 PM, Kai-Martin Knaak wrote: > Steven Michalske wrote: > >> In a perfect world this would not be an issue. But lawyers can use that >> clause as a loophole to invalidate legitimate patents. > > The notion of software patents is by no means obvious. In fact, it is > subject to serous doubt. See the undulating tale of conflicting judgments > by the (European) Court of Justice. > > > >> Big point here, I was talking to some of the google compilier guys >> and finding out that most of the big compiler guys around consider >> gcc to be a dead man walking, largely due to GPLv3 issues. This is >> not limited to Google either, but includes Apple > > Neither of them is notorious for their contributions to the gcc > code base. They both have the resources to roll their own compiler > from scratch. Why don't they? > It is used as an argument for the gpl. With quotes of, without the gpl gcc would not have c++ or the objective c compiler. But I can't stand behind that statement, because it assumes the worst out of everybody. Apple has released lots of core technologies without the demands of gpl distribution rules. Launchd, clang and llvm, libdispach, blocks(closures) for c code, part of clang, Webkit. And many others. > >> and many of the other players. > > like the FSF? > > > >> The latest revision of the gpl threatens input from companies. > > smells like FUD > It's from lawyers, that are paid to protect patents. Where I work we had big review processes to protect ourselvs from violating the v2 license, now we have an explicit ban. > >> Not the only reason, I am more than willing to share code, even >> at no cost. Although, I'm not selfish enough to demand that all >> of their work must be given freely to me. > This is not in the gpl, but often with the users/developers perception. "How dare you make money off of my code, and not give the changes back to me." > There is no such clause in GPL3 > > The cases of openoffice shows how important the absence of loopholes > in the GPL is to the continuous freedom of open sources software is. > Oracle demonstrated how big players try to chain software written by > others to their legal stronghold. And not having loopholes is a good thing, no disagreement. But here the gpl did the same thing, put in a patent, and everyone gets free access to it and your related patents. That put a loophole in the patent system. Realistically there should be no patented material in the code. > > ---<)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 ___ 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 16, 2011, at 4:30 PM, Kai-Martin Knaak wrote: > Steven Michalske wrote: > >> In a perfect world this would not be an issue. But lawyers can use that >> clause as a loophole to invalidate legitimate patents. > > The notion of software patents is by no means obvious. In fact, it is > subject to serous doubt. See the undulating tale of conflicting judgments > by the (European) Court of Justice. > The clauses are not limited to just software patents. Imagine building hardware with gschem, 100% legal and your design is yours. Now, you accidentally included a symbol with a gpl licence. Now I know we release the bulk of our symbols with explicitly free use licenes. But I may have used tom's that was pure gpl. And Tom saw my > >> Big point here, I was talking to some of the google compilier guys >> and finding out that most of the big compiler guys around consider >> gcc to be a dead man walking, largely due to GPLv3 issues. This is >> not limited to Google either, but includes Apple > > Neither of them is notorious for their contributions to the gcc > code base. They both have the resources to roll their own compiler > from scratch. Why don't they? > > >> and many of the other players. > > like the FSF? > > > >> The latest revision of the gpl threatens input from companies. > > smells like FUD > > >> Not the only reason, I am more than willing to share code, even >> at no cost. Although, I'm not selfish enough to demand that all >> of their work must be given freely to me. > > There is no such clause in GPL3 > > The cases of openoffice shows how important the absence of loopholes > in the GPL is to the continuous freedom of open sources software is. > Oracle demonstrated how big players try to chain software written by > others to their legal stronghold. > > ---<)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 ___ 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 16, 2011, at 4:25 PM, al davis wrote: > On Monday 16 May 2011, Steven Michalske wrote: >> But lawyers can use that clause as a loophole to invalidate >> legitimate patents. > > Minor side effect of "lawyers can use that clause as a loophole > to invalidate ILLegitimate patents" ... which outnumber the > ligitimate ones a million to one. > A software licence should not be used for this purpose... As a person with patents, I can't afford to contribute substantual code back, but I can use all the code I want. Because my patents are legitimate. But this is straying from this lists topic. I wish the best of luck to those that wish to reinvent this wheel, a gpl compatible library with a less restrictive licence bsd, MIT, etc... Could be used to extend pcb and gschem. And allow commercial interests to support us. > ___ > 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
> Sorry for the OT bit, but v2 got a black eye from v3, commercially > that is. I know of two companies shying away from all gpl, because > of the "or later" clause in v2 and how you can apply v3 to it. Is > that still in our gpl v2 license? That phrase does not allow the user to change the licence, it merely allows them to use terms from a newer one. The license remains GPLv2 even if they do that. However, it applies to *distribution* not *reception* so if the company chooses v2.1 or v2.0 as their means, the recipient cannot retroactively apply v3.0 to them. ___ 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
Steven Michalske wrote: > In a perfect world this would not be an issue. But lawyers can use that > clause as a loophole to invalidate legitimate patents. The notion of software patents is by no means obvious. In fact, it is subject to serous doubt. See the undulating tale of conflicting judgments by the (European) Court of Justice. > Big point here, I was talking to some of the google compilier guys > and finding out that most of the big compiler guys around consider > gcc to be a dead man walking, largely due to GPLv3 issues. This is > not limited to Google either, but includes Apple Neither of them is notorious for their contributions to the gcc code base. They both have the resources to roll their own compiler from scratch. Why don't they? > and many of the other players. like the FSF? > The latest revision of the gpl threatens input from companies. smells like FUD > Not the only reason, I am more than willing to share code, even > at no cost. Although, I'm not selfish enough to demand that all > of their work must be given freely to me. There is no such clause in GPL3 The cases of openoffice shows how important the absence of loopholes in the GPL is to the continuous freedom of open sources software is. Oracle demonstrated how big players try to chain software written by others to their legal stronghold. ---<)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 May 16, 2011, at 2:45 PM, DJ Delorie wrote: > >> Biggest determent to the open source is now GPLv3 > > OT here, since our stuff is still GPLv2 > > Sorry for the OT bit, but v2 got a black eye from v3, commercially that is. I know of two companies shying away from all gpl, because of the "or later" clause in v2 and how you can apply v3 to it. Is that still in our gpl v2 license? But the whole bit countering your issues with reinventing the wheel, was on your topic. > ___ > 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 Monday 16 May 2011, Steven Michalske wrote: > But lawyers can use that clause as a loophole to invalidate > legitimate patents. Minor side effect of "lawyers can use that clause as a loophole to invalidate ILLegitimate patents" ... which outnumber the ligitimate ones a million to one. ___ 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 Mon, 2011-05-16 at 12:44 -0400, DJ Delorie wrote: > > I've always been interested in CAD programs and thought of making > > a schematic/pcb one from scratch. > > I've never truly understood why people would rewrite a (potentially) > huge application set "just because". Why not start with the existing > tools and just rewrite the parts you're interested in? Like, start > with pcb's HID modules but swap out the core? > > (and if you really want to get *that* involved in pcb layout tools, > there *are* parts of pcb that could stand to be ripped out and > replaced... ;) > > I have no idea whom you cite, sorry. Many people dream about designing and building an own house -- and most computer science students dream about writing a compiler from scratch -- at the beginning of the education. Later they learn how difficult it is (writing a good one for a complicated language) and do something easier. Of course, only a very young child can do really something from scratch -- older people always build on existing knowledge, even when they write new code. Reasons for writing from scratch: - licenses - other programming language - other GUI toolkit - other operating system - other target audience (Fritzing has other target than gEDA/PCB/KICAD - learning - fun CLANG <--> gcc , wayland <--> xfree86, inkscape <--> xfig -- a few promising rewrites from scratch. I think for learning purposes writing something from scratch is always a good decision. In most cases improving existing software is much more pragmatic. In my opinion, writing a PCB layout tool from scratch is very much work -- at least 5k hours for a very smart guy. (A group of people may need much more than 5k hours total, because they have to agree on language and Toolkit before starting and may waste much time with discussions.) For a simple schematics editor the task is much easier in these days, we have support through nice OO languages like Ruby or Python, GUI Toolkits like GTK or QT, and drawing support by libraries like cairo. So it was my idea that writing a (basic) gschem clone can be done in 1k hours resulting in about 15k lines of code. I started writing just for fun in last summer, now after about 400 hours of work I think that my initial estimation was not too bad, I think 25% is done. But I am still learning GTK, Cairo and Ruby, so progress was slow. If I really should finish that work, what is the benefit? 15k lines of code instead of 120k, only Ruby code, instead of C mixed with guile, and a smarter user interface. Not much, but maybe a better skeleton for other contributors? I don't know. Today, I think that working on the PCB (Topo)-Router instead of a gschem clone would have been a much more valuable task. But until one year ago Anthony's progress was so awesome, that it was my feeling that I had not much to offer in that direction. Now Anthony an his router has vanished -- but still I think that that task is better suited for really smart people, smarter than me. From time to time, when I have contact to a smart one with interests in electronics and programming, I tell him about that topic. Now that Anthony's homepage has disappeared, it is even more difficult to catch smart guys. ___ 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
> Biggest determent to the open source is now GPLv3 OT here, since our stuff is still GPLv2 ___ 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 16, 2011, at 10:21 AM, DJ Delorie wrote: > >>> Why not start with the existing >>> tools and just rewrite the parts you're interested in? >> >> License? > > True. One of the benefits of the GPL is that people can bsae their > work off existing work, but not everyone wants to offer that benefit > to others. > Biggest determent to the open source is now GPLv3 Private companies are now turned away from GPLv3. As it has some nasty clauses in it for their IP. In a perfect world this would not be an issue. But lawyers can use that clause as a loophole to invalidate legitimate patents. Big point here, I was talking to some of the google compilier guys and finding out that most of the big compiler guys around consider gcc to be a dead man walking, largely due to GPLv3 issues. This is not limited to Google either, but includes Apple and many of the other players. The latest revision of the gpl threatens input from companies. Another reason to reinvent the wheel is when the wheel is not exactly what you need. http://www.youtube.com/watch?v=CjcyHicm3NA&feature=youtube_gdata_player http://www.rotacaster.com.au/ > I really don't feel bad for people who need to start from scratch due > to a desire not to share their code, though. Their choice, their > pain. > Not the only reason, I am more than willing to share code, even at no cost. Although, I'm not selfish enough to demand that all of their work must be given freely to me. > > ___ > 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
> > Why not start with the existing > > tools and just rewrite the parts you're interested in? > > License? True. One of the benefits of the GPL is that people can bsae their work off existing work, but not everyone wants to offer that benefit to others. I really don't feel bad for people who need to start from scratch due to a desire not to share their code, though. Their choice, their pain. ___ 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
> Why not start with the existing > tools and just rewrite the parts you're interested in? License? > (and if you really want to get *that* involved in pcb layout tools, > there *are* parts of pcb that could stand to be ripped out and > replaced... ;) Might interfere with someones script running someplace? ___ 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 16, 2011, at 10:44 AM, DJ Delorie wrote: > >> I've always been interested in CAD programs and thought of making >> a schematic/pcb one from scratch. > > I've never truly understood why people would rewrite a (potentially) > huge application set "just because". Why not start with the existing > tools and just rewrite the parts you're interested in? Like, start > with pcb's HID modules but swap out the core? Because when the theory is all epicycles and no physics, there's no foundation upon which to stand. 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: Reinventing the wheel
> I've always been interested in CAD programs and thought of making > a schematic/pcb one from scratch. I've never truly understood why people would rewrite a (potentially) huge application set "just because". Why not start with the existing tools and just rewrite the parts you're interested in? Like, start with pcb's HID modules but swap out the core? (and if you really want to get *that* involved in pcb layout tools, there *are* parts of pcb that could stand to be ripped out and replaced... ;) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
