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 fea
Hi,
Nicolas BENOIT <[EMAIL PROTECTED]> writes:
> > It did compile clean, but I had to install it maually. make
> > install-bin didn't seem to work.
> The target 'install-bin' isn't defined... Personnally, I always use
> the 'install' target. Well, I guess, I'll try to work this out.
AFAIK "inst
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
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 cod
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"
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 curr
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 b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Saturday 22 May 2004 02:19, Nicolas BENOIT wrote:
> I am currently trying to write a good documentation, but it isn't that
> easy... As I am not a 2D graphist, I just don't know which examples
> might be usefull and how the doc should be written.
W
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 gpointe
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 guchar*
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
> p
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 conside
On 05/21/04 01:35:49, Sven Neumann wrote:
Stephan Menzel <[EMAIL PROTECTED]> writes:
> Do you think there's a chance to include refocus in the gimp
> release at all?
I don't follow refocus development closely but if is actively
maintained and developed outside the GIMP source tree I'd prefer to
ke
15 matches
Mail list logo
