On Tuesday 25 May 2004 14:57, Sven Neumann wrote: > 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. What do you mean with the GtkScrolledWindow API? Do you want to actually use GtkScrolledWindow with some image widget inside it that shows the rendered image (that is pretty expensive when the rendered image is large) or do you just want to implement a new widget that has the same API? > 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. But zooming is actually a pretty complicated issue, and it will have a profound influence on your API. > 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. The point is that when you maintain many important parameters such as size and scale outside the previews you will have to keep track of which data belongs to which preview and you will have to hunt around to find the neccessary data. This is messy. > > 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. One of your main objections against my API was that it would require modifications to the rendering function (because I believed they were pretty minor, that was no problem for me but apparently you thought that this was unacceptable). As an alternative you proposed some alternatives, like temporary drawables and some global mode switch that caused all drawing operations to use a temporary drawable when that drawable was in "preview-mode". When you insist that the rendering functions may not be changed at all, you will probably have to come up with something like this. Finding a framework that allows this, should be the major design challenge at this point. It will require some important changes in the Gimp core. This design item will have a very big influence on the preview's API. So why don't you tackle this point first? So far you have not presented a detailed design solution. Instead of finding some quick ad hoc solution for a few plug-ins I would say that it is much more important to get this one right. I am afraid that your proposals so far sounded like horrible hacks in my ears, but perhaps if would work them out in more detail I might be convinced otherwise. Of course, when your real problem is how to add a nice functional preview to a few plug-ins, I know an easy solution :) > > 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. But an API where the preview simply tells the plug-in "give me this area at this magnification" is very flexible. When the plug-in decides that it is better to render a larger area and cache it, it can do so if it really wants to. Ernst Lippe
