>From: Sven Neumann <[EMAIL PROTECTED]>
>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
-Plugins can make data layers on the image (gfig would make a vector
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.
Gimp-developer mailing list