Hi, Ernst Lippe <[EMAIL PROTECTED]> writes:
> > 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? Ernst, could you please read my proposal. I said that I want to derive GimpPreviewScrolled from GtkScrolledWindow. Please note that GtkScrolledWindow does not have the fullsized window, it just has the scrollbars and an API that seems to fit our needs. > > 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. Yes, on the higher-level API but the low-level preview widget shouldn't need to know anything about zooming. > > 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. Outside the preview widget base class which should be suitable for other needs as well. Think about the brush preview in GimpPressionist. This preview doesn't need zooming, it doesn't need a drawable API, it probably doesn't even need scrolling. That's about the level of complexity that the base class should have. Of course a derived class needs to know about the size and scale of the previewed area and I never proposed to keep this data outside of this derived class. > 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). No, that wasn't my main objection. My main objection was that you introduced temporary drawables at the core side of the wire instead of keeping them in libgimp. Actually I am quite confident that we don't even need them on the libgimp side. We should be able to get away with preview tiles. The core doesn't need to know about them (but we could change that in order to allow a preview in the image window). I also dislike large parts of the API but you designed it before GObject introduced interfaces so there wasn't much chance to get it right back then. > 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. I don't think that any changes to the GIMP core will be necessary. > 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. That's why I brought this up on the list. Actually I couldn't care less about plug-in previews but since people are willing to add them and ask me what widget they should be using, I am trying to provide them with the funtionality they need. You had a lot time to bring your preview widget into The GIMP after 2.0 but you remained silent. What else can I do but propose an alternative? The alternative I proposed is designed to allow the widget to be extended later. The goal is to bring it to a point where it does all what your proposal does. Sven _______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
