On Mon, Dec 27, 2010 at 8:39 PM, Stefan Salewski <[email protected]> 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 made) but I can't really see other architecture that wouldn't bring more problems than it would solve. > And here is again one important advantage of a rewrite: We don't have to > care much about breaking existing functionality. Yes, this is the advantage of starting from scratch. Unfortunately you can only have flexibility or users (and developers) or neither. That's a pretty much a single person show for years to come and unless you have significantly more patience than I did, you'll probably drop it when you find you've "learned enough" or "had enough fun" (which is still a very valuable experience). For your reference, the initial design of PSchem (pretty much all its current code base) took me several weeks (say 5~6) of intensive, full-time coding (like in your case, it was connected with learning Python and Qt). That was when I had both free time and enthusiasm (the latter coming mainly from learning new stuff). The funny thing, is that I'm not that far from making this tool truly useful in some niche application (I thing 1~2 months would be enough) but there is simply not enough motivation for doing it. Andrzej _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
