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

Reply via email to