>> Just to make sure I undestand: when you parametrize the position of >> something, you are still supposed to be able to move it around via >> XCF_Move? > > Yes. The substitute and writeback routines should handle the copying > of the position information between the element and the parameter > structure. You should be able to move around locally. If you refresh > without doing a writeback, the refresh will copy the parameters back > into the element, and you will revert back to the position it was in > before. If the error is in your code, not mine, then this is probably > what you have done: invoked an extra refresh without writing new > values back the parameter structures. But I thought that should have > been done right after the "move" command was executed. Did you remove > the writeback call?
I think I know what's going on. Yes, you've nailed the problem. You only call pwriteback() in 8 places in events.c -- those are all preserved in my code, so that isn't a problem. The pwriteback() that's really important is in finish_op(). But that's not enough. What your code does is depend heavily on being able to draw things while in event handlers other than the expose (repaint) event. So the drag() code xor-paints as it goes. In Qt this is a no-op: you have no access to the drawing context on a widget (on-screen window) outside of a repaint event. A really hacky workaround would be to paint on a QPixmap -- this is allowed anywhere, and then blit the QPixmap in the expose. But that's wasteful as Qt already has a double- buffering scheme, and besides: it circumvents the real benefits one gets from doing all the painting where it belongs -- within Area::paintEvent(); To match Qt semantics, I have had to set areawin->gc to NULL outside of expose event handler. All drawing routines check for it being NULL, and merely schedule a repaint at next opportunity, instead of actually drawing anything. I have since removed a lot of painting code that was spread everywhere. That check really has to be replaced by an assert, and everytime the assert triggers the code is to be deleted. Prunes gobs of code ;) That's how Qt avoids repaint event storms: the user input events are treated with highest priority and they can't paint as that may take so long that you start lagging behind the mouse etc. What UI events can do is schedule a repaint of any part of any window, and then when the control returns to the event loop and there are no more UI events to process, all those repaint events are coalesced (union of their regions is taken), and a single repaint is done. This works very well in practice and avoids all sorts of misbehavior seen in some applications both on Windows and under X11. Heck, there were places in Xcircuit code where you did manual event coalescing -- obviously those were to fix a problem you've run into. So then, since your drawing routines are destructive due to parameter substitution, whatever is done in the drag() function is promptly undone as soon as the area gets repainted. That's probably what you meant by "extra" refreshes. In the Qt codebase, all refreshes are "extra" per your terminology. I don't know yet what the simplest way to work around this impedance mismatch is. Is it OK to call pwriteback(areawin->topinstance) willy-nilly? Perhaps simply putting it at the end of each and every event handler is a temporary workaround? Cheers, Kuba _______________________________________________ Xcircuit-dev mailing list [email protected] http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
