Hi, Ernst Lippe <ernstl@xxxxxxxxx> writes: > 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? No, I want to use the GtkScrolledWindow API for the scrolling and the standard GtkWidget API for resizing. I want to completely leave scaling out of this first basic widget. It will allow us to get rid of GtkPreview and that's the main problem we need to solve now. Of course it's a good idea to think beyond that and I agree that we will need a more complex preview widget than what I proposed to start with. However this is all not finished and I am open for other ideas. Actually I am not too happy with the proposed API, especially the fact that the buffer is outside the preview and how scrolling would have to be handled. So I am perfectly willing to reconsider it. What is the point about plug-ins that have multiple previews? I fail to see the problem; perhaps you can explain it to me. I am currently trying to come up with a proposal for GimpDrawablePreview, an extension to the GimpPreview interface that should allow plug-ins to reuse their rendering function for the preview. > 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. I agree but it certainly doesn't hurt to allow this kind of use. That's why I say that we need a simple but very flexible widget first. Most plug-ins will never use it's API but access it on a higher level. But if a plug-in wants to do non-standard things, then it shouldn't have to start with a GtkDrawingArea again. Sven
