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. Steve Meier Peter Clifton wrote: > On Thu, 2007-11-01 at 08:23 -0700, Steve Meier wrote: > >> I fail to see how this prevents having multiple views for a model. >> > > >> The viewer provides the drawing function and graphics context. The >> library just uses what the viewer provides. If the viewer wants one >> window to display one representation then the viewer calls draw page >> with a particular gc that gets passed along to each of the pages sub >> objects. >> > > It implies that all multiple views must co-operate via a common > interface. Lets say for example that my "viewer" might not be graphical? > It might be a feed-forward to gnucap, it might be an attribute editing > window (NB: Just an example, I don't intend to re-write gattrib). > > In these cases, I don't care about repainting objects behind a changed / > damaged object, I just care about the changed object. In the gschem > case, I might need to repaint overlapping objects. This then requires me > to have redraw logic in gschem _anyway_ to find the overlaps, and > request they be redrawn. > > I'm of the opinion libgeda should be an file IO, data-structure and EDA > database library. Its remit should not include "driving" a GUI. > > >> But the nice thing is ... is that the viewer can be very ignorant of the >> internals of the library structures. >> > > That is the PCB approach, and I don't think its right for gschem. If > gschem doesn't know about libgeda's API, then what good is it. I think > we should have libgeda enabling EDA operations, not defining the > operating policy for any app which wants to use it. > > 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
