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

[Stefan Salewski <mail@xxxxxxxxxxxx>]

On Sun, 2010-12-26 at 12:38 -0500, John Doty wrote:
> Stephan, this project is interesting. I'll try it on Ubuntu when I get
> back to Noqsi. I  think I'll pass on trying it on a Mac for now (all I
> have here in Cambridge).
> 
> I am puzzled, however, by your motivation:

I wrote something about it in my initial post:

http://archives.seul.org/geda/user/Oct-2010/msg00122.html

> 
> On Dec 26, 2010, at 8:48 AM, Stefan Salewski wrote:
> 
> > I think one reason for start writing it was my desire to assign
> > attributes/classes to subnets, to transfer this information to PCB
> to
> > support manually- and auto-routing with already specified parameters
> for
> > traces.
> 
> Semantics like this are the responsibility of gnetlist back ends, not
> gschem. Indeed, the limits of our ability to continue to extend gEDA
> seem primarily to derive from semantics inappropriately "wired in" to
> the gnetlist front end, and to a lesser extent in gschem. The
> kludginess of some back ends derives from the same problem.
> 
> There is nothing in gschem that prevents attaching arbitrary
> attributes to net segments. Unfortunately, the gnetlist front end
> insists on digesting the data according to rigid (and sometimes
> wrong!) theories of its semantics before handing it to the back end.
> In most cases the digested data is just what the back end writer needs
> (that's why simple back ends are easy to write with just a tiny bit of
> Scheme knowledge), but if it's not things become difficult. In this
> case, there appears to be no way to access net segments or their
> attributes from a gnetlist back end.
> 

I know all this from earlier discussions.
For me there were three ways:

1. Accept current state.

2. Learn some scheme/guile, dig into the gschem/gnetlist code, try to
improve it, hope that is accepted by Ales and others. 

3. Write from scratch

1. is what I did for some years. I think that gschem/gnetlist works ok,
with Peter C.'s cairo drawings it looks not bad. But we all see that
there is no more active development. Older developers with guile
knowledge retire, so simple fixes and extensions become nearly
impossible. New developers are rare, and they do not like to crawl all
that old mixed c/guile code.

2. is what I should have done -- maybe?

3. is the most fun.

Early after starting with gEDA, my feeling was that a complete rewrite
would be a good idea. The problems: Much work. The questions: Which
language, which GUI Toolkit. My current feeling is: Writing a basic
schematic editor, with PCB netlist export, can be done in 1k hours from
a smart person, so it is not impossible. I don't think that I am really
smart, and I am currently still learning GTK, so I have no good chances
to get something powerful as gschem in 1000 hours. But on the other
hand, now, after about 200 hours of work, I have already a very basic
viewer for schematics. In only 1000 lines of Ruby code. Printing, saving
the file again, moving symbols around, that all should be very easy.
Netlist generation for PCB: I guess it should be not too difficult and
fun. I have to admit that I have no clue about hierarchical design at
the moment, I have never done that with gschem. Adding all that dialogs,
storing/loading configuration, and all the other details will consume
much time, but is very easy.

Of course, Ales H. has done fine work in old days. When he started in
1998 -- most computers where driven by relays or vacuum tubes, with tape
storage and teletyper output ;-) -- mixing guile and C may have been a
good idea. Today we have GTK with Cairo  and nice OO languages like
Ruby. That makes writing schematics editors and netlist generation much
easier. And Ruby is really a friendly language, so that the project
should become more open. I guess the total code base will not be more
than 10k lines. Collaboration is of course limited by all the different
languages and GUI toolkits. Some may prefer Python/C
++/C#/D/Java/Vala/Lua and other, or QT/FLTK/wxWidgets. And maybe OpenGL.

All that is true for PCB also -- a complete rewrite would be not a fully
stupid idea. But I think there is not so much benefit of OO languages
and modern toolkits for PCB. Gerber generation, polygon handling, DRC,
Autorouter, all that is very difficult, it has not become easier in the
last 10 years. And for performance reasons interpreted languages are of
course no option anyway.

Best regards

Stefan Salewski




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user