On Thu, 2007-11-01 at 09:52 -0700, Steve Meier wrote: > If your application isn't graphical then it wouldn't call s_page_draw. > In my implimentation if the primitive drawing functions arn't registered > then I dont draw even if you call s_page_draw. > > I never said gschem should be ignorant of libgeda's api the api is what > should remain fixed. But not necessarily the data structures behind the api. > > What I don't want is gschem to be directly manipulating and relying of > the data structures of libgeda. So sure if you want a libgeda fuction > that returns a list of all the drawing primitives of a complex object > and a libgeda function that returns a list of all the objects on a page > great. But gschem shouldn't be just reaching in and grabbing > page->complex_obj and expecting it to be there.
I think we're on the same page Steve, I really do. I'm all for hiding more of the internals away, and have been working to change the "list of objects on the page" away from being a self-linked list, and into a GList of OBJECTS. I do think that the OBJECTS should correspond to the drawing primitives, and should be part of the API though. There should be ways to "get at" those objects without lifting them right out of the page structure. Peter C. _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
