Re: [Gimp-developer] Plug-in preview API proposal

2003-04-01 Thread Sven Neumann
Hi,

Ernst Lippe [EMAIL PROTECTED] writes:

 Irony is always difficult on a written medium like e-mail.
 (I should have included some smileys)
 Of course, I know that this was not a very realistic option,
 but perhaps it might trigger the core developers to think
 about a good name for this preview :)

I wasn't kidding, we actually consider to rename the core widget. It
turns out that most places in the core use gimppreview.h only to
access some magic numbers that are scheduled to be moved into the core
anyway. Now if only we could come up with a good name for the core
widget ...


Salut, Sven

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Plug-in preview API proposal

2003-04-01 Thread Sven Neumann
Hi,

Ernst Lippe [EMAIL PROTECTED] writes:

 The only way to avoid this overhead is to make interface more
 complicated, analogous to the GimpPixelRegions, there should
 be an _init interface that the preview uses to inform the plug-in
 about the total area that it wants, and a _render_tile interface
 that tells the plug-in that it should render a specific tile.

I don't think the GimpPixelRgn API is overly complicated. Of course an
iterative API as I propose it needs an iterator structure but I don't
see how this approach would be overly complicated.

 If you want to rewrite an existing rendering function to this
 new interface you will have to make major changes. (Essentially
 this is very similar to the steps that you have to make when
 you want to change a recursive function into an iterative function.
 It is always possible, but the results are generally completely
 unreadable.) Basically, what you will have to do is to record
 local variables in functions in some global structure, and
 to retrieve these values when you have to compute the next
 tile.

Exactly. This is something every good plug-in should do anyway.  Most
plug-ins already render on a tile-by-tile basis or at least do it
row-by-row. Shouldn't it be relatively easy to make this a function
which is called from the main-loop?

 As a plug-in author, I believe that my proposed interface is
 very natural. I have already converted a few plug-ins and
 that was fairly straight-forward. I definitely would not
 like having to rewrite those plug-ins in such a way that
 they could efficiently compute individual tiles.

well, rewriting some plug-ins to operate on tiles would be a major win
but I agree that it is nothing we want to do that this point in time.

 Also I must say that I am a bit disappointed that calling the
 GTK main loop is so expensive (or that there apparently is
 no other way to process new GUI events). Giving control to
 the main event loop at regular intervals during computations
 is a standard solution to avoid freezing of the GUI in
 cooperative multi-tasking systems.

sure, but it is usually done by returning to the main event loop, not
by driving it manually. If you do the latter, you introduce the need
to write reentrant functions. This is usually not necessary in a
single-threaded environment and I don't think we should put that
burden on the plug-in developers. As you said in your document, using
global variables is a bad habit but since you looked at some plug-ins
you know that it is rather common. I agree that your API may look
natural (after a much needed cleanup) but I fear that most plug-in
authors will not understand the implications of the design.


Salut, Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Keybindings

2003-04-01 Thread Owen
I've updated keybindings.txt,tex and pdf to match the cvs as at 31 Mar

http://www.webone.com.au/~oc/gimp/keybindings.pdf
http://www.webone.com.au/~oc/gimp/keybindings.tex
http://www.webone.com.au/~oc/gimp/keybindings.txt


Owen
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Plug-in preview API proposal

2003-04-01 Thread David Necas (Yeti)
On Mon, Mar 31, 2003 at 10:11:36PM +0200, Ernst Lippe wrote:
 On Mon, 31 Mar 2003 11:21:06 -0800 (PST)
 Nathan Carl Summers [EMAIL PROTECTED] wrote:
 
  (off-the-cuff) Perhaps GimpThumbnail?
 
 It is a nice short name, but I have the impression that a thumbnail
 is a reduced size version of the original image, and for most plug-ins
 I would expect that the preview normally shows a small part of the image
 at its real size.

And I'm afraid GimpThumbnail could be useful for something
else (e.g., thumbnails ;-) and then this thing would have to
receive some other name...

What about something like GimpProofView?
- it't not longer than GimpThumbnail
- it resembles GimpPreview
- proof is a relatively good word (though mostly used
  in printing only, in this sense)
- the view is just a tag, but proof alone is strange

It's quite easy to invent new words and phrases for me,
thanks to my miserable English ;-)  but proof view seems
to be already invented, according to Google.

Regards,

Yeti

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer