I think we are pretty much on the same page too. I also think that the idea of an object being able to emit a signal when it changes such that an application can respond to the change is a good idea. Also, efforts to promote efficient drawing so that users aren't anoyed by slow screen actions is comendable.
Steve Meier On Thu, 2007-11-01 at 17:07 +0000, Peter Clifton wrote: > 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 _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
