geert jordaens <[EMAIL PROTECTED]> writes:
> A minimum for the preview widget would be :
> Widgets :
> 1. The preview area
> 2. Horizontal/Vertical scrollbars if needed.
> 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.
Gimp-developer mailing list