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
