Sven Neumann wrote:
our posts corssed, agree with You that it can be added later.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.agreedSignals : 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. as does GtkPreview now, works for me.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. implement scrolling by changing the offset into the buffer was not my primary concern but a nice side effect.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. 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. Geert |