Dave Neary ([EMAIL PROTECTED]) wrote:
Manish Singh wrote:
Dave, ask yourself why you replied to this. The thread was long finished,
and *you* certainly didn't contribute anything meaningful to it. And if
you must reply to this, don't clutter the list with it further.
My contribution was
I would like to point out that even if you feel compelled to
respond to a rude comment (usually it is better to be silent),
you still have the choice whether to be more rude or less rude.
Being more rude will almost always escalate the problem.
At this point the evolution of this discussion is
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
Hi,
just a quick note that the online version of the GIMP Reference
Manuals has been updated:
http://developer.gimp.org/api/2.0/
Lots of thanks to Mitch for bringing the application documentation
uptodate after all the GUI code reorganization that happened after the
2.0 release.
These docs
Cc: [EMAIL PROTECTED]
From: Roger Leigh [EMAIL PROTECTED]
Date: Mon, 24 May 2004 01:18:30 +0100
Robert L Krawitz [EMAIL PROTECTED] writes:
From: Roger Leigh [EMAIL PROTECTED]
Date: Sun, 23 May 2004 14:03:36 +0100
Does anyone know how (for the Debian
Hi,
Robert L Krawitz [EMAIL PROTECTED] writes:
If we do this right, then we can change libgimpprint to our heart's
content and the GIMP plugin will go merrily on its way, without ever
having to be recompiled or relinked. When the GIMP supports 16 bits,
only the plugin needs to change, and
Hi again,
your post (and other mails on the gimp-print-devel list) make me
believe that there isn't much hope for a stable gimp-print API to
appear during the next weeks. Is that right? This means that we have
to change our plan to ship gimp-2.2 with an updated print plug-in. It
also means that
From: Sven Neumann [EMAIL PROTECTED]
Date: 25 May 2004 11:19:10 +0200
your post (and other mails on the gimp-print-devel list) make me
believe that there isn't much hope for a stable gimp-print API to
appear during the next weeks. Is that right? This means that we
have to change
From: Sven Neumann [EMAIL PROTECTED]
Date: 25 May 2004 10:54:00 +0200
Robert L Krawitz [EMAIL PROTECTED] writes:
If we do this right, then we can change libgimpprint to our heart's
content and the GIMP plugin will go merrily on its way, without ever
having to be recompiled
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,
Robert L Krawitz [EMAIL PROTECTED] writes:
The core API's pretty close, but we're probably not quite ready to go
beta. However, we're not that far off, either. What's your plan for
2.2?
We haven't set a fixed date for the feature freeze yet but we should
do that soon. I'd like to
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
22 matches
Mail list logo
