Re: gEDA-dev: gschem -- Datastructures

[Patrick Bernaud <b-patrick-at-NOSPAMwanadoo_dot_fr>]

Hi again,

Peter Clifton writes:
 > [...]
 > Sounds like a beneficial change though. Peter Brett and I are looking at
 > an improved attribute editing widget. (Peter B. is doing the
 > implementation). Our widget will hopefully make it more obvious to new
 > users which attributes will need filling in.

Have you looked at my rewrite of the attribute editor dialog? It does
not help with which attribute to fill but may be a good basis.


 > [...]
 > Is this a nice place to eventually integrate scalable objects?

Not sure what you mean by 'scalable objects'.


 > [...]
 > GObject may make ref-counting and destruction of objects and pages etc..
 > much cleaner. I'm thinking that its signal handling may be beneficial.
 > 
 > As a first hash, I'd not intended to use GObjects, mostly due to a lack
 > of experience using them, instead leaving object boundary respectful
 > function calls, which would roughly map to signals, or methods if
 > converting to GObject.
 > 
 > Let me know if you think it is best to use GObject from the outset. I
 > think porting to GObject will be more tricky though, but perhaps ought
 > to get done as part of the refactor. (This is more a re-write than a
 > refactor in some places).

GObject is interesting but may add more work to your refactor. Plus
you are not subclassing much. I think you can ignore it at least for
now for model structures but not for UI objects (WINDOW, NB...).


 > > [...]
 > >   - move to GObject's almost every structures, especially OBJECT;
 > 
 > Does this impose any speed limitations?

Nothing noticeable. I am not running very recent hardware and did not
notice any difference in speed on a small test program.


 > >   - separate libgeda from the schematics stuff: creating a libgschem
 > >     and a libgnetlist C libraries on top of libgeda would be a good
 > >     thing. It has already been discussed before on the list.
 > 
 > libgeda just for reading the config files?

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).


 > >   - remove the dependency of libgeda on gtk and guile (for guile see
 > >     next point).
 > 
 > I'd actually LIKE to see more of gschem in libgeda. As I may have
 > mentioned before, I would actually like to see a gschem_area widget,
 > like your preview widget implementation, completely inside libgeda such
 > that it can be linked in from other programs. (Like a library manager
 > for example).
 > 
 > My "evil" plan for that would be that gschem could then subclass that
 > widget to add the editability.

Nice idea to provide a base widget for view. But I have to disagree
with you on moving UI related code from gschem to libgeda. My plan is
to remove any GtkWidget* and stuff like that from TOPLEVEL and libgeda.

I would rather move UI stuff into another library on top of libgeda if
absolutely necessary.


Regards,


Patrick


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