[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-dev: gschem -- Datastructures



Hi again,

Peter TB Brett writes:
 > [...]
 > > More like providing a common base object that you can later subclass,
 > > attribute... Nothing schematic/netlisting specific. Reading
 > > configuration file depends on application. It would like to remove the
 > > dependency of libgeda on guile (but wrap it in guile).
 > >
 > 
 > I have to respectfully disagree with this.  To me, libgeda seems like the 
 > ideal place to put EDA-specific GTK widgets (such as a schematic-drawing 
 > widget), as well as general functions and types for manipulating schematics, 
 > netlists and possible PCB layouts.  This would mean that if I write some 
 > application to manipulate geda schematics and netlists, I'd only have to link 
 > against one library rather than three, with the increased startup time 
 > entailed as the runtime linker figures out what to do with the three 
 > different inter-linking libraries.  However, it would be perfectly possible 
 > to split the library functions prototypes into a number of separate header 
 > files (one for schematics, one for netlists, one for Guile interpreter tools, 
 > one for logging).
 > 

I really think adding GTK widget and stuff, even if EDA-specific, to
libgeda (the root library of the project) is a very bad idea. Gnetlist
(but it is not the only one) should really not depend on GTK at all,
not even an unused pointer in a structure.

Plus ideally you should not access the data from a schematics file the
same way whether you are going to display it or extract other info
from it. For example: gnetlist has nothing to do of the outline of
your component. Why should it keep it in memory and makes traversing its
own model harder?

To me this means you have to 'subclass' libgeda with a netlist
specific library and another one for schematics to render. And the
EDA-specific GTK widgets can go in another one dedicated to UI.

Obviously we would have to rethink the way the tools (gschem,
gnetlist, gattrib...) interacts. I would love to see gschem
communicating with gnetlist directly but within two separate process
as with a pipe for example. My point is that it would be a good thing
to clearly separate the purpose and range of each tool.

If the problem is only the term 'library' replace it with
'*dedicated* module within libgeda' in the text above. It also works
fine :)


Regards,


Patrick


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