- scale - selection limits
- ...
For instance you can have a plug-in that displays 2 scrollable previews one showing the before and one the after effect.
Even nicer they could have to be synchronized(position/scale).
The way I see it :
The plug-in does the rendering(math) the preview shows it however the preview widget is controlled by the user
and knows when it's time to ask the plug in for an update. If one of the rendering parameters changes the plug in should
query the preview widget to get it's current view position and render. After warts fill the previews buffer and signal the preview
to redraw.
1. a completely passive widget that has no other function then to visualize a preview image.
The widget would have a internal buffer where we can put the image data.
As with GtkPreview a function gimp_preview_draw_row (....) would almost be the only
visual API for a plug in developer.
- Rendering functions do not have to be changed.
- only GtkPreview would change to call the new widget.
2. a more actively involved preview widget would have (1) and the basic navigation lets say horizontal and
vertical scroll bars. When creating give the widget it size and the current selection limits (x1,y1);(x2,y2)
one which a preview has to be made. The widget should have a signal to have it fill it's buffer whenever the scrollbar position changed.
A API that returns (x1',y1');(x2',y2') depending on the scroll bars to be used in the callback function or have the values available as attributes.
- Rendering functions do not necessarily have to be changed. A call back function wrapped around the rendering function could be used.
3. This would be like 2 but also would have scaling or other features.
Geert
