On Thu, 2007-11-01 at 06:42 -0700, Steve Meier wrote: > I also think that objects in libgeda should know which application > function to call in order to draw them selves. > > This allows the application to ask the page to draw itself and the page > to ask the complex components, segments, arcs, boxes, text etc to draw > themselves. Instead of the application having to go through the page and > get each item and then do the drawing.
This is one approach (as taken by the PCB HID system), however a potentially more flexible approach is for the GUI to watch for changes which might make it need to redraw. The frontend should be in the best position to know what drawing updates are needed. If not, then a more serious problem occurs. Libgeda changes things, dangling pointers remain in portions of gschem code which are manipulating objects, and crashes can occur. (Libgeda needs to tell gschem what changed in these cases, so we can fix drawing too). PS.. in many places guile hooks are present, they are pretty impotent, in that should they change the object list in certain ways, gschem / libgeda will crash, or miss the new objects in the list it's busy iterating over. If we take the approach of having libgeda directly call drawing functions / hooks in gschem, an implicit knowledge of the rendering model is built into libgeda, and as we are seeing with modern X11 desktops, those can change. > When I say an object should draw itself I mean that the object should > call the appropriatly registered application function. In my view this > way if the library changes the application won't get broken. This isn't sufficient, as libgeda doesn't know what state the rendering system in the client (gschem) is. We can't continue to have multiple non-grouped / backbuffered drawing actions taking place, as it is a _severe_ performance hit on modern desktops. (Esp. with compositing). If we s/drawing function/changed hook/, we might be onto a more sound footing. PS.. time permitting, I am willing (actually want to) work on this MVC stuff. Without it, we can't do various tasks which other packages might take for granted. As far as I know, Peter B is interested to get this working too, so we're not just talking about the MVC stuff as a theoretical "would be nice", but are actually working to fix things with it. I admit (and am sorry) that the cleanups so far have broken Bernd's work (Which I didn't have to test against), but think we'll all benefit from the changes eventually. Bernd's proposed fix, retuning a GList of changed items for gschem to redraw is hopefully going to be a solution for him until more complete MVC changes land. (And I may have to "steal" the idea for fixing some cues dropped / drawing artifacts whilst consolidating lines in the short(ish) term. Peter C. _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
