On Saturday 22 May 2004 14:54, Sven Neumann wrote: > geert jordaens <geert.jordaens@xxxxxxxxxx> writes: > > 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. But the position of the previewed area and the current magnification are inherently properties of the preview itself. It seems pretty logical to make scroll and zoom buttons part of the preview widget and in that case it is the preview widget that will detect if the position or scale has been changed. So the most logical design is to let the preview call the plug-in algorithm and not the other way round. I can see nothing wrong with using signals in this case, because they are more flexible than the other standard solution of having call-back functions. Do you really propose that the plug-in itself handles all the GUI interactions for scrolling, zooming and resizing and that it also is responsible for recording the current position and scale and size of the preview? This seems very unelegant, to say the least. Also how do you handle plug-ins that have multiple previews? > 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. How are you going to decide the correct size for this area? When you make it substantially larger than the previewed area the response to user actions will become slower. It will happen frequently that this buffer will become invalid, e.g. when some parameters of the algorithm have been changed, when the user zooms out, when the image is scrolled over a larger distance. The only case where such a larger buffer might be useful is when the user only scrolls by very small amounts and in my experience that does not occur often. So having a larger buffer makes the design of the plug-in more complicated (how should it determine the "right" size for this buffer), it will cause a performance hit on many normal preview operations. Ernst Lippe
