> Yes, the dnd effect is nice, but for whatever reason, it does not
> work if data is dragged from the same program.
I don't follow you: I see the green circle in the input demo when dragging from
Multiline to Normal, and in my app when dragging text
from one window to another one.
> In general, I have a hard time
> figuring out how a "damage" situation is communicated to Cocoa. The code I
> added seem to have the ability to invalidate graphics regions, but somehow
> it is never called.
The call you use [view setNeedsDisplayInRect:], and its friends
[view setNeedsDisplay], [view display] and [view displayRect]
correspond to the standard Cocoa logic where we ask for redisplay
and return control to the system event loop which calls
[view drawRect] correspondingly. But FLTK uses a very
different logic where the event loop is entirely FLTK-built
(I did all to keep this logic in order to share as much as possible
of the existing code). Thus, [view drawRect] is called seldom
(creation, resize, deminiaturization) whereas partial updates
are piloted by Fl_X::flush() calls. This in turn requires the
essential lockFocus/unlockFocus calls. Finally, damages are
forced into the graphics context clip region at this point:
void Fl_Window::flush() {
make_current();
fl_clip_region(i->region); i->region = 0;
draw();
}
This is basically my current understanding of how damages are
communicated to and processed by FLTK/Cocoa.
> My last prot has been such a long time ago that I
> don't know anymore where to hook in :-(
Prot ??? Project?
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
