Sven Neumann wrote:

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.
our posts corssed, agree with You that it can be added later.
 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. 
as does GtkPreview now, works for me.
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.
implement scrolling by changing the offset into the buffer was not my primary concern but a nice side effect.
My primary concern was to be able to render a larger buffer to be as acurate as possible for some plugin's and minimize
influence by edge conditions.


Reply via email to