>From: Sven Neumann <sven@xxxxxxxx> > >What we are aiming for is a lot more complex than what GtkPreview is >providing. The goal is to have a widget that can zoom and pan. It >should also provide an API that allows to use the same image >processing routines for the preview as are used for the drawable. The >plug-in author shouldn't have to care much about the preview. Does this mean you continue with the plugins which create their own dialog and all interactive manipulation happens there, like gfig? I wish plugins like gfig would operate on the image/view, not in separate window like now. There are consequences: -Need for multirate images (MIP images) for low resolution preview -Plugin's preview area can be given as a rectangle on the image (just like 3D modellers allows user to define the area which is rendered) -Plugins can make data layers on the image (gfig would make a vector layer) MIP images would mean that large images may be efficiently edited at lower resolution. The operations are reflected to high resolution images later or when the system is idle enough. If a plugin wants a separate preview to its dialog, then that is just a new view to the image, embedded to the dialog. Regards, Juhana
