There is no implicit requirement for the library to have an understanding of the rendering engine. Nor is there a requirement for the library to deal in any other unit then real world units. All the library has to have is pointers to drawing functions in the application and that those application drawing functions would take care of zooming and panning.
It also seems to me that there are ways to reduce the amount of redrawing work. Without the viewer application having to be directly manipulating the libraries data structures. The viewer could have a list of drawing primitive objects, lines, circles, boxes, text etc that it builds as the page draws. The viewer wouldn't have to know which of these lines belong to which complex object. If it wanted to pan or zoom it would just use its list of primitives. When the user wants to sellect a group of things and drag them then its important that the select box real world dimensions are sent to the library or the location in real world coordinants of the pointer are sent so that the library can determine what has been selected and then when they are dragged the translation motion in real world coordinants are sent to the library. The library then should again have a function s_page_draw_selection_list...... again this new list of primitive objects could be retained by the viewer for rappid redrawing. Steve Meier Peter Clifton wrote: > 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 > > _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
