X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=SVI1rwl2fC9ITrZH77B6CEjiuCGxFeU5d66FFldeZTA=; b=SNjsyt/qdC316PWDBeuA8klT/ibTqIBUkNWP5jnsyDEybLbzaMaVqi1wg0s6doSzb3 ToTX5x6KmLd4cpwAYOuD9oIZsLSQOLbFJ8OKmM+CrnJMKoR5RYk3wpzzGMt/PL6b6tnH I+4cDl0X5zLDFxHGTYTSZBZS60PBPO9mbr6Yv8aZRHLctLFzDvyQHTWHYehhPx4dw1VL ADbFHElX2uXLy6F1DdFYbl8cxMO1jiBQj83LvkMF64FRbdNraAMMw3HKaIVueGf5PKyP OrmJqFYApfu4oD1nHiAaYXyf6dHDX1h0yp8IcjMd2G1BsiVuAAZp5MJSoWNYu4b1g9jg u0XQ== MIME-Version: 1.0 X-Received: by 10.25.83.209 with SMTP id h200mr2736667lfb.129.1451407172012; Tue, 29 Dec 2015 08:39:32 -0800 (PST) In-Reply-To: <20151229094603.782092b57563336883546bfd@gmail.com> References: <43CC8F96-6452-40FA-9DFB-E0983721C19C AT noqsi DOT com> <20151229094603 DOT 782092b57563336883546bfd AT gmail DOT com> Date: Tue, 29 Dec 2015 11:39:31 -0500 Message-ID: Subject: Re: [geda-user] Project leadership (design error in the core of gschem) From: "Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" To: gEDA users mailing list Content-Type: text/plain; charset=UTF-8 Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Tue, Dec 29, 2015 at 3:46 AM, Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: >> My personal opinion, especially after actually hacking the code for back >> annotation, is that there are design errors in the very core of gschem. >> A few smallish things that makes life harder in probably most flows, >> makes essential UI features impossible to implement. ... > > It would be good if you could bring the design erros forward. I think Igor2 already said of this in the last thread that he wanted to avoid saying because of the flamewar that would follow. I am a bit more rested so I will kick the bees nest in his place. gnetlist's one way functionality : gnetlist lets you take a schematic (which in libgeda world is a list of connections) and make a netlist but it won't let you take a netlist and map those nets back to connections on the schematic. PCB can be made to export a netlist. Ideally gnetlist would take a list of changes to a netlist or two netlists (old and back annotated) and spit out a list of changes to connections that you could carry over to gschem. nets vs connections: libgeda and gschem are only allowed to understand connections and even then in a limited way. To make back annotation work you ether have to fix the problem above or let libgeda/gschem understand that a list of connections is associated to a given net in the netlist. Right now gschem almost has this because there is a highlight functionality that lets you select a whole net and unintentionally maps the connections in the process. I debated this one with John a while back. It was particularly hard to deal with because John fundamentally does not want back annotation/notation unless it is via some his script(s). Basically I see value in not forcing every thing to make nets and connections equivalent *but* more of the the mechanism that grants them equivalence should be available in libgeda so the whole suite can use it more easily and not just gnetlist. connections vs buses: Because we don't want to acknowledge connections are in any way equivalent to nets we also can't group nets and call them a bus. The inability to group them in this way leads to the inability to do cool things like set properties for a whole bus when you go to rout a board or do a simulation. scripts: I see scripts as having a few flavors. Throw away, project specific, and prototype. The first two are mostly self explanatory but the last one (prototype) I thought was how we were to see how the user experience would be if we did X to the core. We are generating a low of the first two and almost never any of the third. Even when it does happen massive opposition hits when X new idea is suggested as an addition to the core of geda (libgeda) I want C plugins in libgeda it would make moving code that is a cool plugin into the core easier. (Side note: Vladimir I saw your feature request for a scheme interaction window. I actually think that is very cool.) scheme is good and bad: The effect of having scheme drive things in geda instead of just as a language was good in that it bent the programming style of C code contributions into a cleaner form than we might otherwise have had. It is bad though because having scheme drive C makes a lot of C programmers nuts. It is also bad for long term maintenance because the number of available scheme programmers is small and getting smaller. clunky use of glib: I don't like the way glists are used in libgeda. I accept glib as a dependency because glib is also used by gtk and geda is gtk heavy but still. If we ever put a hid on geda like we have on pcb it would be nice to remove that dependency. slots: The slotting mechanism is fundamentally worthless for a the majority of cases were I would want to use it. Look at the 7400 symbols were they have a whole extra symbol for the power pins. That is conceptually IMHO something that should be a slot but you can't do that because all symbols have to have the same number of pins and geometry. In places were slotting could be cool we don't use it right in the standard symbol library. Take the symbols for the larger xilinx chips. I would rather each section of the chips I/O be it's own slot so I can show the FPGA connections near what they are connected too instead of putting the FPGA on it's own page (most of the time). Likewise breaking it up into more symbols would mean not wasting most of a page on the empty area inside the FPGA symbol. -- Home http://evanfoss.googlepages.com/ Work http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/ -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQENBFYy4RYBCAC183JomLtbdAlcKiaPDoVHq52LDmVmH75aiEc69m7YxDt54/ai VtYCAobbGVIyn3Hlz3uhF6LnPl/6Lm1VdnCfpwu3KQhCO6ds10ow2C30X4ohCqOd hCVg5C+ILmQkEffFrFODy3ji+PYTF4pADvHCWsTMv0hf0llwFOJsBCK6cl02IffE JPqy4PjM1nZ9HpzT84JBaG/4OGvTZ8SQ2yFUl265jagvygPTf88H1xpZHH1r8dB1 stjUHLmPH8AOyDgKxFchgGeDc3p/vJtgDDIXAFfDXG0NSRovLmtaQdGxe47Zf/go bXiEM7YL2WqQe5zfEA919JxkEwlDKYniOSVzABEBAAG0N0V2YW4gRm9zcyAoVGhp cyBpcyBteSBwdWJsaWMga2V5LikgPGV2YW5mb3NzQGdtYWlsLmNvbT6JATkEEwEC ACMFAlYy4RYCGwMHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCIpQTcE8nN bbBaCACAm8pU5lG1ev2Fsw68Axtcl57SJrYieqX96c3YuYH9JpqMqJRnd9nDKw9X tQuvuH7tUk0VbOaDqReOYJVI/4c5wb9AaOFp6K2DUcupq6XhgXpvz3HzoPwjAdIj XuQzdRUx5+innTJrSkGuBYW/CZ2zqEx4xfLlq4rO0hoTUMR8QVp2cCrkw6BT0m86 APIw/ZnjoxM8IEzr7MxfRIg3qpzrZk28rmhx+k78Jyk61UhwcCPGIm/pjUopTwYJ 3YBdRB2cYD2aN7A1JVf5cRmSQYooHBGpH0kYvomGk97PKqypVuJ7OpG9xM58wUcC qUVt9hKlePLzP8csYjt8onqI7qIIuQENBFYy4RYBCADlH8spG3WkCx62vB5mr5Z0 SCDd/RcyA4A5y5EOj5KurQkrSWpgi9Ho1yKruMJ6blQR2qkc66KqH9pnXDm/ZI1M K/wdW3ngETxBmXoozzFMT89aEWIVR5/PFodWK1elekE9iJxACuR98Zg2QttTD3x8 A9w8VEyMLOXcDTrPFpHegMKswFBg5iuMulAdXAoGejWTI3n+qKFpabHm2Lfs6wjk 5rjucpTdeFK6UeWF1xAvNxXibuu5BlGwv53930qIXRwO/Gn2Rh5DXWxKU2fEIme/ xgQQmIsDeUoWbfybdjw/x7Q0LW4mINiLDQcGHHRQKFIxbAJCT3USPLGh5xwE9/Er ABEBAAGJAR8EGAECAAkFAlYy4RYCGwwACgkQiKUE3BPJzW0uYAf9Hf30n8tM3mR2 Zo6ESE0ivgdgjaJtAWrBUx7JzAzPjBnBOlNnu5Y9lVEqetvUPH6e3PvaHYUuaUU8 0HwxuKBW9nUprgV6uIu1DZmlcp+SxpbuCy7RDpNocRLNWWFMaYYzznmTgfnTgD4D gCq8Mf1mcfrluTkOAo+QNqbMfl1GISClopRqxVuAo59ewgMnFujwgd8w12BwWl24 CzqOs5HqcUslePj+LzcjSNgVCklYwKl+0dsb/fctMOCtHodwqm2CBJ+zydvNmYkD fxda/J91Z1xrah5ec++FL0L4vs+jCiIWJeupJFKlr1hCMZiiGH7W554loK5l4jv3 EY347EidAw== =Ta4p -----END PGP PUBLIC KEY BLOCK-----