Sven Neumann <[EMAIL PROTECTED]> writes:
> Perhaps it would be better to not have the actual user interface in a
> gimpprint library. If you want to make it easy to write a GTK2 GUI on
> top of libgimpprint, then you could provide a model on top of
> libgimpprint that people can easily write a vie
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 wo
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 tha
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:
> > 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 on
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 s
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 s
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 b
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,
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 f
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 co
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
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 a
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 recomp
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 chang
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 w
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,
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,
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 sur
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 i
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 de
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 st
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
23 matches
Mail list logo