Re: gEDA-user: Working on a tiny schematics editor
On Dec 26, 2010, at 5:41 PM, Stephan Boettcher wrote: > Stefan Salewski writes: > >> OK, shame on me for missing that option. But I do not think that this >> really proves that a gschem rewrite is obsolete. > > I may believe that writing a second gschem editor is worse use of your > time than improving the existing one, but it is not up to me to judge > how you use your time. > > For your stated purpose, writing this graphical editor seems wrong, but > now that it exists, it is interesing to try to put it to good use. It > may start as a new netlister with integrated graphical viewer. The > viewer may be the best verification that your parser works correctly. > >> There are so many similar problems, wishful improvements. All big task >> currently, no one really does it. Such an improvement should take at >> most some hours in Ruby. > > A really useful result will be a parser with a clean, documented > netlisting API, that people can use to write netlisters who do not want > to use/learn guile. Maybe I should try to do the same for python :-) > I would work on a python netlister in geda. Yes I could pick up scheme again, but I didn't enjoy it when I used it before. >> And this example unfortunately shows one weak point of gEDA: The initial >> authors and experts have retired, functionality may be already there, >> but most of us do not know or understand it. > > ... documentation, again. > > -- > Stephan > > > ___ > 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: Seeing new symbols without restarting
Brilliant! Just what I needed Oliver __ From: DJ Delorie To: gEDA user mailing list Cc: geda-user@moria.seul.org Sent: Mon, December 27, 2010 11:30:41 AM Subject: Re: gEDA-user: Seeing new symbols without restarting In the symbol chooser dialog, there's a arrow-circle icon that means "refresh symbol lists off disk". ___ geda-user mailing list [1]geda-u...@moria.seul.org [2]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:geda-user@moria.seul.org 2. 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: Seeing new symbols without restarting
In the symbol chooser dialog, there's a arrow-circle icon that means "refresh symbol lists off disk". ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Seeing new symbols without restarting
I am sorry if this is a retarded question, but is there a way for gschem to see new created symbols (placed in a local symbol directory) without restarting? Oliver ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Resistor values…
On 12/27/2010 02:56 AM, Vanessa Ezekowitz wrote: No. Zero is almost always wrong. Exactly my point - it is*supposed* to be wrong. > The only sensible default value in this case is a copy of the reference > > designator. No, that's wrong too. This seems like one of those cases where more than one set of defaults is needed, along with some documentation. The first wave of documentation is always a how-to-start, so the very first level default set has to support that, and if it is good, it will have a simulation to run from it, and a pcb drawn from it, even if that needs two slightly different schematics to accomplish that purpose. John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Resistor values…
John Doty wrote: On Dec 27, 2010, at 3:56 AM, Vanessa Ezekowitz wrote: On Sun, 26 Dec 2010 23:55:04 -0500 al davis wrote: On Saturday 25 December 2010, Vanessa Ezekowitz wrote: * If the part in question can usually be described by a single value, for the purposes of the signal flow in the schematic that is, then give it a default of "value=0". No. Zero is almost always wrong. Exactly my point - it is *supposed* to be wrong. But *I* use 0 as a value rather frequently. Depends on what you're doing with the toolkit. +1 My prefered value, for stuff I don't know yet is "?". "0" and "inf" are actual resistor values. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Resistor values…
On Mon, 2010-12-27 at 09:43 -0500, John Doty wrote: > On Dec 27, 2010, at 3:56 AM, Vanessa Ezekowitz wrote: > > > On Sun, 26 Dec 2010 23:55:04 -0500 > > al davis wrote: > > > >> On Saturday 25 December 2010, Vanessa Ezekowitz wrote: > >>> * If the part in question can usually be described by a > >>> single value, for the purposes of the signal flow in the > >>> schematic that is, then give it a default of "value=0". > >> > >> No. Zero is almost always wrong. > > > > Exactly my point - it is *supposed* to be wrong. > > But *I* use 0 as a value rather frequently. Depends on what you're doing with > the toolkit. Likewise.. I often use "zero" ohms resistor links to act as placeholders were resistor "might" be required for slowing down edges, or isolating a signal for probing. Any default should be blank, or an invalid value. "?" would work, but I'm not going to paint this particular shed any further. -- 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) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Working on a tiny schematics editor
On Dec 26, 2010, at 3:28 PM, Stefan Salewski wrote: > I do not think that this > really proves that a gschem rewrite is obsolete. There are so many > similar problems, wishful improvements. All big task currently, no one > really does it. What many pcb users really seem to want is a HID for schematics. If such a thing existed, we could hope that most of the pressure to damage gEDA in order to specifically serve pcb would abate. And if it used the .sch format, they could still move into the wider world of gEDA when they find the need. 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: Resistor values…
On 12/27/2010 08:43 AM, John Doty wrote: Perhaps we need a real gnucap back end with this property? Or a plug-in that does this? Sure, send some rent money and I'll create and test it within two months. John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Working on a tiny schematics editor
On Mon, Dec 27, 2010 at 8:39 PM, Stefan Salewski wrote: > > Indeed I remembered something about a Python gschem clone, I mentioned > that in my initial post: > > http://archives.seul.org/geda/user/Oct-2010/msg00122.html Ouch! Sorry about that. I hardly check this mailing list nowadays. > I was not able to remember your name or the project name at that time. > Some of your ideas seems to be very interesting, I will have a look when > more of the basic functionality of my editor works. I'll be happy to assist you with that. If I was to briefly cover strong and weak points of PSchem (or rather my design decisions), here is the list: Database: + IMHO this is the only way to design a robust EDA tool. As a user I want integrity of the design and automation (netlisting, parametrization etc.). Otherwise, I can simply type my netlist by hand or draw a schematic (if I need one, for example for publication) in graphics editor. + It was good to separate database from the rest of the tool and design an abstract API for accessing it. This way third party tools can access the design without parsing backend files (of course they still can do it, if needed). Besides, designing the API made me think how to structure data, and making an EDA tool is all about structuring data. + It serves as a "Model" in the MVC pattern. Everything you do on it is immediately visible to all "Views" (seems like obvious thing to have but it doesn't work in file oriented GSchem). + For the same reason it enables "advanced" features like hierarchy, design parametrization, performing some design-wide DRC/ERC checks etc. - Its API is Python centric (I'm OK with this limitation for other functions but database should really be accessible from a variety of programs). OTOH, it's so much easier and cleaner to design an API in a dynamic OO language - you can juggle objects or containers around instead of flattening all data structures down to primitives. - Some functionality (like built-in R-tree indices) is not available for performance reasons. - For flexibility we want all "cellviews" to sit in separate backend files (so that one can copy/move them around in the filesystem), this, however, requires some additional sanity checks that wouldn't be necessary if the backend design unit was a "cell" or a "library". - It's not OpenAccess, which is recently being pushed by some major players. Sadly, OpenAccess license precludes its use in an opensource program. Scripting: + Writing the whole program in a dynamic, scripting language worked very well. With right libraries there is essentially no performance penalty. Ideally, I'd never make an "installer" or "package" for it, to encourage tweaking the source code. + Embedded interpreter proved to be very useful at development stage - I could debug a lot of errors without restarting the program. Most errors are data related and dynamic in nature (depend on the content of the database) and debugging them would be non-trivial without being able to peek the current state of the database or graphics scene. - Embedded interpreter is not that easy to plug into the GUI. Ideally, every user action should go through this interpreter leaving a trace in the interpreter window. Unfortunately, some UI actions bypass Qt's signal/slots mechanism or are tied to other parts of the framework. - Writing the program in Python limits you to stock libraries. In my case the "core" was the QGraphicsView framework from Qt4. While it worked well in general, it enforced some less than optimum design decisions (OTOH, if I was to write such framework from scratch, I'd probably do it worse). Qt: + Love its lack of external dependencies and platform support. Currently PSchem only requires Python and PyQt4 and works on Windows and Linux almost without changes. + Comes with a built-in graphics canvas. + Generally more robust and better tested than Gtk, especially if you add bindings into the picture (BTW, PyQt4 is great). - Some of its features are not very flexible.. Canvas: + IMHO its a "must" in an EDA tool, next to a database. I strongly recommend you to find and use a Gtk counterpart of the QGraphicsView. - QGraphicsScene requires all graphics items to extend QGraphicsItem. This means that essentially each object in the database has to be shadowed with a corresponding QGraphicsItem object. That itself is not a big issue, but ideally all the indexing should sit directly in the database (currently indexing only works if the schematic/symbol is displayed) so this functionality is not available in batch mode database access. OTOH, indexing tends to be important mostly in the interactive editing. - a bit short on features - I wish it had better support for item grouping or layering. In theory it can all be done by adding some custom code to "paint()" methods but that would be more efficiently addressed at the framework level. Overall I found this set of features pretty compelling. There are weak points (often coming from tradeoffs I m
Re: gEDA-user: Resistor values…
On Dec 27, 2010, at 3:56 AM, Vanessa Ezekowitz wrote: > On Sun, 26 Dec 2010 23:55:04 -0500 > al davis wrote: > >> On Saturday 25 December 2010, Vanessa Ezekowitz wrote: >>> * If the part in question can usually be described by a >>> single value, for the purposes of the signal flow in the >>> schematic that is, then give it a default of "value=0". >> >> No. Zero is almost always wrong. > > Exactly my point - it is *supposed* to be wrong. But *I* use 0 as a value rather frequently. Depends on what you're doing with the toolkit. > > I chose zero here because anyone who sees it in their schematic file should > instantly think, "Oops, I forgot to set the value of that part". From my own > experience, it is easier to spot something that is visibly flat out wrong > than to look for something that is just not there. Then make a library with symbols like that. Don't expect others to agree that it's the right way to go. Don't change the default library, because that will break many things. > > Setting it to zero by default could even be used to signal Gschem to add an > extra highlight to those symbols bearing it. Yuck. Keep tools simple and clean. > Perhaps the default, highlight-sensitive string should be exactly "0.0" or > some variation of that, since no sane user would type anything but a single > "0" when they mean "zero". Your definition of "sane" appears to be very self-centered. > >> The only sensible default value in this case is a copy of the reference >> designator. > > No, that's wrong too. If I wanted to see the refdes's, I'd keep PCB in that > view mode instead of putting it in value mode, Al's talking about simulation, not pcb. > and in the schematic, doing this would just lead to doubled refdes's > everywhere initially, which could get confusing in densely packed schematics. That's a reason why my Mathematica back end substitutes the refdes for the value in the model if the value is absent. Perhaps we need a real gnucap back end with this property? Or a plug-in that does this? > >> Justification ... For simulation, all modern simulators, and >> some not-so-modern simulators have a means of assigning values >> to parameters. >> >> In a spice format, you could say: >> .param R1=10k >> or something like that. >> Some let you use parameters in other ways, making it even more >> useful. > > Where does this tie in with what default the symbol might have in its > "value=" attribute? If you're directly assigning that 10K value to R1 within > your spice code using its refdes as the basis for the assignment, then it > seems to me you're already overriding whatever value was specified in the > Gschem schematic and/or the symbol library. But you have to construct the netlist in a way that allows that. Is the value of R1 a constant or a parameter? Attributes in the schematic control this. > >>> * If it is a discrete part that is specified entirely by its >>> part number rather than a measurement, like a diode or a >>> transistor, then pick a reasonable default; "value=1N914" or >>> "value=2N". >> >> As I recall, those are specific devices that were popular 40 >> years ago. Not sure how relevant they are today. Unless you >> link to something, they are just arbitrary strings, no better >> than any other. > > I mentioned the 2N and 1N914 because they are easy to use and easy to > find. Being general purpose components, they make excellent teaching aids, > and I use them myself from time to time for the occasional LED driver or > small signal amp (nothing big by anyone's standards here). That said, the > examples I gave could have applied to any of a hundred other part classes, > though. Would my argument been any different if I'd named some modern power > MOSFET or the latest Atmel microcontroller instead? > > Discrete transistors aren't as popular as they were a few decades ago in > computer technology, but they are still in common use in the analog world > (power supplies, amplifiers, radios, telephones, hobby electronics). > > If my suggestions aren't to peoples' liking, then try something a little more > logical: if you don't want to go with something well known for a given > symbol's default because that something is "too old" or "outdated", then at > least go with whatever is the number one selling item in that class (as > measured by end-user distributors like Radio Shack rather than wholesalers > and manufacturers). You're virtually guaranteed to get it right most of the > time that way. Why don't you just make a library that fits your prejudices rather than trying to force them on everybody else? > >> The best default would be something that is more universally >> meaningful, and not specificm like "D" or "diode" for a diode, >> or "NPN" for an NPN transistor. > > If that were the case then there's no point at all, because the symbol file > itself, by definition, already tells you what it is. You (and the
Re: gEDA-user: Working on a tiny schematics editor
On Mon, 2010-12-27 at 19:49 +0900, Andrzej wrote: > On Mon, Dec 27, 2010 at 4:23 PM, Andrzej wrote: > > On Fri, Oct 8, 2010 at 2:31 AM, Stefan Salewski wrote: > >> Some weeks ago I started working on a very basic schematics editor, > >> compatible with current gschem file format. I am writing it in Ruby, > >> using GTK/Cairo. > > > > I while ago I started my own schematics editor - pschem: > > Stefan, > > I've added a screenshot displaying the same schematic as one in your example: > > http://code.google.com/p/pschem/wiki/Screenshots > Thanks. Indeed I remembered something about a Python gschem clone, I mentioned that in my initial post: http://archives.seul.org/geda/user/Oct-2010/msg00122.html >Can you remember, some years ago someone wrote about a Python editor on >this list, I never have heard about it again. I was not able to remember your name or the project name at that time. Some of your ideas seems to be very interesting, I will have a look when more of the basic functionality of my editor works. And here is again one important advantage of a rewrite: We don't have to care much about breaking existing functionality. 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: Resistor values…
Vanessa Ezekowitz writes: > On Sun, 26 Dec 2010 23:55:04 -0500 > al davis wrote: > >> On Saturday 25 December 2010, Vanessa Ezekowitz wrote: >> > * If the part in question can usually be described by a >> > single value, for the purposes of the signal flow in the >> > schematic that is, then give it a default of "value=0". >> >> No. Zero is almost always wrong. > > Exactly my point - it is *supposed* to be wrong. He said: _almost_ always. I do not want to see wrong but valid defaults in an attribute. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Working on a tiny schematics editor
On Mon, Dec 27, 2010 at 4:23 PM, Andrzej wrote: > On Fri, Oct 8, 2010 at 2:31 AM, Stefan Salewski wrote: >> Some weeks ago I started working on a very basic schematics editor, >> compatible with current gschem file format. I am writing it in Ruby, >> using GTK/Cairo. > > I while ago I started my own schematics editor - pschem: Stefan, I've added a screenshot displaying the same schematic as one in your example: http://code.google.com/p/pschem/wiki/Screenshots It was taken on Windows but Linux version is just as functional. As you can see the gEDA import filter is still far from perfect. Many gschem constructs an still unsupported (I've been using it mostly for getting the design into Pschem so I can debug other functions). It's probably more interesting to look at capabilities of the underlying framework. Some key features: - Pschem is built on top of a design database (think of it being a database editor rather than a vector graphics tool). Contrary to many commercial packages the database format is to be as open and as human readable as possible (probably xml, albeit the backend is not yet implemented), - Scriptable with access to a design database API (and essentially all other functions too, as at least for now Pschem is fully implemented in Python), - Supports design hierarchy, - (Planned) support for parametrized cells and attributes, - Uses a canvas based MVC framework (from Qt) for efficient rendering. - Potential for extending to a PCB/layout tool (not planned for now). Andrzej ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Resistor values…
On Sun, 26 Dec 2010 23:55:04 -0500 al davis wrote: > On Saturday 25 December 2010, Vanessa Ezekowitz wrote: > > * If the part in question can usually be described by a > > single value, for the purposes of the signal flow in the > > schematic that is, then give it a default of "value=0". > > No. Zero is almost always wrong. Exactly my point - it is *supposed* to be wrong. I chose zero here because anyone who sees it in their schematic file should instantly think, "Oops, I forgot to set the value of that part". From my own experience, it is easier to spot something that is visibly flat out wrong than to look for something that is just not there. Setting it to zero by default could even be used to signal Gschem to add an extra highlight to those symbols bearing it. Perhaps the default, highlight-sensitive string should be exactly "0.0" or some variation of that, since no sane user would type anything but a single "0" when they mean "zero". > The only sensible default value in this case is a copy of the reference > designator. No, that's wrong too. If I wanted to see the refdes's, I'd keep PCB in that view mode instead of putting it in value mode, and in the schematic, doing this would just lead to doubled refdes's everywhere initially, which could get confusing in densely packed schematics. > Justification ... For simulation, all modern simulators, and > some not-so-modern simulators have a means of assigning values > to parameters. > > In a spice format, you could say: > .param R1=10k > or something like that. > Some let you use parameters in other ways, making it even more > useful. Where does this tie in with what default the symbol might have in its "value=" attribute? If you're directly assigning that 10K value to R1 within your spice code using its refdes as the basis for the assignment, then it seems to me you're already overriding whatever value was specified in the Gschem schematic and/or the symbol library. > > * If it is a discrete part that is specified entirely by its > > part number rather than a measurement, like a diode or a > > transistor, then pick a reasonable default; "value=1N914" or > > "value=2N". > > As I recall, those are specific devices that were popular 40 > years ago. Not sure how relevant they are today. Unless you > link to something, they are just arbitrary strings, no better > than any other. I mentioned the 2N and 1N914 because they are easy to use and easy to find. Being general purpose components, they make excellent teaching aids, and I use them myself from time to time for the occasional LED driver or small signal amp (nothing big by anyone's standards here). That said, the examples I gave could have applied to any of a hundred other part classes, though. Would my argument been any different if I'd named some modern power MOSFET or the latest Atmel microcontroller instead? Discrete transistors aren't as popular as they were a few decades ago in computer technology, but they are still in common use in the analog world (power supplies, amplifiers, radios, telephones, hobby electronics). If my suggestions aren't to peoples' liking, then try something a little more logical: if you don't want to go with something well known for a given symbol's default because that something is "too old" or "outdated", then at least go with whatever is the number one selling item in that class (as measured by end-user distributors like Radio Shack rather than wholesalers and manufacturers). You're virtually guaranteed to get it right most of the time that way. > The best default would be something that is more universally > meaningful, and not specificm like "D" or "diode" for a diode, > or "NPN" for an NPN transistor. If that were the case then there's no point at all, because the symbol file itself, by definition, already tells you what it is. You (and the simulator) already you're using a diode or an NPN transistor or whatever by virtue of the fact that you chose to instantiate the symbols for those parts. The original poster was asking about adding values to resistor symbols so that they show "R1" and "10k" on the schematic diagram only. I was expanding on that idea to handle named parts as well - what *kind* of diode or transistor the PCB will end up having stuffed into it at build time. Since "value=" has no meaning at all with such things, I suggested it be re-purposed in those cases. > For a simulator that reads spice format, you could then say: > .model D D > .model NPN NPN > to make the names meaningful. It might be useful to make an > "include" file to define these things. I'd say that one would need to know precisely what kind of transistor one is using in a circuit before a simulation begins, or it may end up with invalid results. I don't know whether the "value=" attribute is the right place to put that information, but I can't think of a better place. > > * If the part is something l
