Re: gEDA-user: Working on a tiny schematics editor

[Andrzej <ndrwrdck@xxxxxxxxxxxxxx>]

On Mon, Dec 27, 2010 at 8:39 PM, Stefan Salewski <mail@xxxxxxxxxxxx> 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
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user