Hi, geert jordaens <geert.jordaens@xxxxxxxxxx> writes: > A minimum for the preview widget would be : > > Widgets : > 1. The preview area > 2. Horizontal/Vertical scrollbars if needed. agreed > Signals : > 1. preview_draw : draw preview area from current preview buffer. > 2. preview_update : Call-back for rendering function followed by > preview_draw or call preview_draw from callback. > (if possible send signal > preview_draw from within callback to display rendering progress). > 3. preview_changed : Call-back to determine which part of the > drawable that must be rendered for preview. > (after scrollbar position changed) I don't think any of this should be part of the GimpPreview widget. IMO it's the plug-in's job to push the pixel data to the preview, not the preview's job to request it. Such a framework can be added later as I outlined in the proposal I just sent to the list. The preview widget itself doesn't need to know about the drawable it previews, nor what part of it is previewed. It just displays a buffer the size of the preview and that's it. Perhaps we optionally need an API that allows to keep the buffer outside the preview widget. That would allow the plug-in to render a larger version and implement scrolling by changing the offset into the buffer. Sven
