On Fri, 2004-05-21 at 21:57 +0200, Sven Neumann wrote:
[Thanks for CCing me on this, Sven; I don't follow gimp-developer as
closely as I would like these days]
There seem to be a couple of options. Let me try to summarize the ones
that I see:
- Use GtkPreview.
GtkPreview is
Hi,
Federico Mena Quintero [EMAIL PROTECTED] writes:
- Come up with a full-featured preview widget.
We could use the widget that Ernst Lippe wrote but since there
hasn't been any effort so far to discuss it's API again and to
get it into CVS I am not sure if it makes
On Monday 24 May 2004 19:11, Federico Mena Quintero wrote:
This is the right way to go. I'd say the list of requirements for a
preview widget for the GIMP are at least the following:
1. Have a way for the filter to specify whether the preview can zoom or
not; this is for filters which are
On Saturday 22 May 2004 14:54, Sven Neumann wrote:
geert jordaens [EMAIL PROTECTED] writes:
Signals :
1. preview_draw : draw preview area from current preview buffer.
2. preview_update: Call-back for rendering function followed by
preview_draw or call preview_draw from
On Saturday 22 May 2004 22:40, Nathan Carl Summers wrote:
On 22 May 2004, Sven Neumann wrote:
So this API would allow you to queue a redraw even after the buffer is
only halfway written. Of course you would also have to run the main
loop for the redraw to actually happen. Anyway, I consider
Hi,
Ernst Lippe [EMAIL PROTECTED] 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
Hi,
Nathan Carl Summers [EMAIL PROTECTED] writes:
There are a lot of image applications that perodically update the
preview. In fact, this is essentially what the gimp color balance tools
do -- load a large image and adjust the sliders intermittantly and you can
watch the previews go by.
On Tuesday 25 May 2004 14:57, Sven Neumann wrote:
Hi,
Ernst Lippe [EMAIL PROTECTED] 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
On Monday 24 May 2004 09:26, Sven Neumann wrote:
Hi,
Nathan Carl Summers [EMAIL PROTECTED] writes:
There are a lot of image applications that perodically update the
preview. In fact, this is essentially what the gimp color balance tools
do -- load a large image and adjust the sliders
Hi,
Ernst Lippe [EMAIL PROTECTED] writes:
Sure, but the question is if we expect the small preview area of a
plug-in to behave in that way? I'd say the answer is no.
Why? The primary function of the preview is to preview the effects
of certain parameters on the image. It seems only
Agree with Ernst that it's not bad to have the preview widget hold data
like other then it's physical limits :
- 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
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
Hi,
geert jordaens [EMAIL PROTECTED] writes:
1. a completely passive widget that has no other function then to
visualize a preview image.
2. a more actively involved preview widget would have (1) and the
basic navigation lets say horizontal and vertical scroll bars.
3. This would be
Hi,
Christopher Curtis [EMAIL PROTECTED] writes:
This is just a random thought off the top of my head, but maybe it
will inspire someone...
It would probably be very cool if the preview functionality could be
implemented so that it could also act as a filter.
That's really not feasible to
I think come up with a simple preview widget is the way to go. At least
all people willing to
add preview's could start doing it the same way.
What I've seen from plugin's is that they are frequently using pixel
regions to render images.
If the pixel region isn't generic enough the I would
Hi,
geert jordaens [EMAIL PROTECTED] writes:
What I've seen from plugin's is that they are frequently using pixel
regions to render images. If the pixel region isn't generic enough
the I would start with the functionality described from the current
tutorial on the GimpPreview by Ernst which
Hi,
let me try to come up with a list of requirements for a simple preview
widget that allows to be extended to a full-featured beast later.
- It should be a GtkWidget so that if can be embedded into the plug-in
dialog like any other widget. This is not the case with the
GimpOldPreview
staring from the back.
Again, sorry, but I don't understand this. What's the displayed area?
What do you mean when you say render
We are talking about a preview therefore the (displayed)preview area is
the area that is visible to the user.
Will use in for further explanation preview buffer to
Hi,
geert jordaens [EMAIL PROTECTED] writes:
A minimum for the preview widget would be :
Widgets :
1. The preview area
2. Horizontal/Vertical scrollbars if needed.
agreed
Signals :
1. preview_draw : draw preview area from current preview buffer.
2. preview_update:
Sven Neumann wrote:
Hi,
geert jordaens [EMAIL PROTECTED] writes:
A minimum for the preview widget would be :
Widgets :
1. The preview area
2. Horizontal/Vertical scrollbars if needed.
agreed
Signals :
1. preview_draw : draw preview area from
Hi,
geert jordaens [EMAIL PROTECTED] writes:
implement scrolling by changing the offset into the buffer was not
my primary concern but a nice side effect. My primary concern was
to be able to render a larger buffer to be as acurate as possible
for some plugin's and minimize influence by
Sven
We can keep the buffer outside the preview widget and only have it
create an internal buffer if no external buffer is supplied. The API
I have in mind is something like the following:
/**
* Set a pointer to an external buffer.
*
* The buffer will be of type guchar* for now but using a
Sven
ignore the previous posting
We can keep the buffer outside the preview widget and only have it
create an internal buffer if no external buffer is supplied. The API
I have in mind is something like the following:
/** * Set a pointer to an external buffer.
*
* The buffer will be of type
Hi,
geert jordaens [EMAIL PROTECTED] writes:
void gimp_preview_set_buffer (GimpPreview *preview,
gpointer buffer,
gint rowstride);
Sounds fine to me. However if possible a internal buffer in the
preview
On 22 May 2004, Sven Neumann wrote:
So this API would allow you to queue a redraw even after the buffer is
only halfway written. Of course you would also have to run the main
loop for the redraw to actually happen. Anyway, I consider this rather
bad style. IMO, if the preview takes
Hello,
This is just a random thought off the top of my head, but maybe it will
inspire someone...
It would probably be very cool if the preview functionality could be
implemented so that it could also act as a filter.
Such that, for instance, someone could grab a looking glass and
attach an
26 matches
Mail list logo