Re: [Gimp-developer] Plug-in preview API proposal
On Mon, 31 Mar 2003 22:50:00 +0200 Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > Ernst Lippe <[EMAIL PROTECTED]> writes: > > > P.S. Of course the most logical solution is to change the name of > > the core widget. My widget is derived from Shawn Amundson's GimpPreview > > widget that was written in 1998, and that was long before some > > GIMP developer tried to claim that name. It is clear that > > this is an obvious infringement of our trademark. > > I quick grep through the sources shows that we'd have to change more > than 150 files and I doubt that this could safely be done by a naive > search-and-replace operation. So this is probably not a reasonable > option. 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 :) greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in preview API proposal
Hi, Ernst Lippe <[EMAIL PROTECTED]> writes: > P.S. Of course the most logical solution is to change the name of > the core widget. My widget is derived from Shawn Amundson's GimpPreview > widget that was written in 1998, and that was long before some > GIMP developer tried to claim that name. It is clear that > this is an obvious infringement of our trademark. I quick grep through the sources shows that we'd have to change more than 150 files and I doubt that this could safely be done by a naive search-and-replace operation. So this is probably not a reasonable option. 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
On Mon, 31 Mar 2003 20:17:51 +0200 Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > Ernst Lippe <[EMAIL PROTECTED]> writes: > > > As promised here is my API proposal for a plug-in preview widget. > > You can find it at http://refocus.sourceforge.net/preview. > > In the section "Design" in "Calling the render function" you state: > > A somewhat smarter version of this preview used a different > approach. The rendering function had to call back to the GTK main > loop, so it could process new events. > > I wouldn't call this a smart version since this is something that you > better not try to implement. Why do you want to drive the GTK+ main > loop yourself? This only leads to really complicated behaviour (as you > seem to have experienced yourself). The easiest approach to this > problem seems to be to split the rendering function into small > chunks. Instead of calling some function that processes events, the > render function returns after computing a small tile of the preview > image. The standard GTK+ main loop takes back control, user events are > processed and if it ever becomes idle again, the list of invalid tiles > is examined and the render function is called with the next area to > update. Did you consider this approach? Yes, and I did not like it. One of the goals for this preview was that it should be easy to use the same function for rendering to the preview and to the final image. In many cases it is not too difficult to convert an existing rendering algorithm so that it will only render a specific area of the final result. But many plugin algorithms have a considerable setup time, which means that there is a lot of overhead when you call the rendering function for each output tile. 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. 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. To summarize, if the preview should ask the plug-in to render individual tiles (and when the preview is zoomed out or when the preview is large there can be a large number of tiles that must be rendered) it will either be inefficient for some plug-ins or plug-in authors will have to implement a complicated interface. 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. 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. greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in preview API proposal
On Mon, 31 Mar 2003 11:21:06 -0800 (PST) Nathan Carl Summers <[EMAIL PROTECTED]> wrote: > On 31 Mar 2003, Sven Neumann wrote: > > > > I'd even prefer to have everything that is related to this widget be > > under the same namespace. Unfortunately GimpPreview is already taken, so > > we either need to change the name of the core object or find a new one > > for the plug-in preview. > > (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. greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in preview API proposal
On Mon, 31 Mar 2003 19:58:29 +0200 Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > Ernst Lippe <[EMAIL PROTECTED]> writes: > > > As promised here is my API proposal for a plug-in preview widget. > > You can find it at http://refocus.sourceforge.net/preview. > > > > Please examine it critically, this should be a preview that > > should be usable for a very wide range of plug-ins. > > > > Because I would like to reuse this proposal (or what is left of it > > after the discussion) for the final documentation I > > also welcome minor comments such as spelling mistakes, grammar > > corrections, coding errors and such. > > one thing that I noted at first glance is the namespace. It is > absolutely unacceptable to have any types or function names in the > GIMP API that don't have a GIMP prefix. I'd even prefer to have > everything that is related to this widget be under the same > namespace. Unfortunately GimpPreview is already taken, so we either > need to change the name of the core object or find a new one for the > plug-in preview. I fully agree that the names must be changed. The problem is how? Maurits suggested GimpEffectPreview, which is not a bad name, but I don't really like having to preview every function with gimp_effect_preview_ . I know it is a bit old-fashioned but I still think that source code should be readable on a tty with 80 characters. greetings, Ernst Lippe P.S. Of course the most logical solution is to change the name of the core widget. My widget is derived from Shawn Amundson's GimpPreview widget that was written in 1998, and that was long before some GIMP developer tried to claim that name. It is clear that this is an obvious infringement of our trademark. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in preview API proposal
Hi, Ernst Lippe <[EMAIL PROTECTED]> writes: > As promised here is my API proposal for a plug-in preview widget. > You can find it at http://refocus.sourceforge.net/preview. In the section "Design" in "Calling the render function" you state: A somewhat smarter version of this preview used a different approach. The rendering function had to call back to the GTK main loop, so it could process new events. I wouldn't call this a smart version since this is something that you better not try to implement. Why do you want to drive the GTK+ main loop yourself? This only leads to really complicated behaviour (as you seem to have experienced yourself). The easiest approach to this problem seems to be to split the rendering function into small chunks. Instead of calling some function that processes events, the render function returns after computing a small tile of the preview image. The standard GTK+ main loop takes back control, user events are processed and if it ever becomes idle again, the list of invalid tiles is examined and the render function is called with the next area to update. Did you consider this approach? 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
On 31 Mar 2003, Sven Neumann wrote: > I'd even prefer to have everything that is related to this widget be > under the same namespace. Unfortunately GimpPreview is already taken, so > we either need to change the name of the core object or find a new one > for the plug-in preview. (off-the-cuff) Perhaps GimpThumbnail? Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in preview API proposal
Hi, Ernst Lippe <[EMAIL PROTECTED]> writes: > As promised here is my API proposal for a plug-in preview widget. > You can find it at http://refocus.sourceforge.net/preview. > > Please examine it critically, this should be a preview that > should be usable for a very wide range of plug-ins. > > Because I would like to reuse this proposal (or what is left of it > after the discussion) for the final documentation I > also welcome minor comments such as spelling mistakes, grammar > corrections, coding errors and such. one thing that I noted at first glance is the namespace. It is absolutely unacceptable to have any types or function names in the GIMP API that don't have a GIMP prefix. I'd even prefer to have everything that is related to this widget be under the same namespace. Unfortunately GimpPreview is already taken, so we either need to change the name of the core object or find a new one for the plug-in preview. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Plug-in preview API proposal
As promised here is my API proposal for a plug-in preview widget. You can find it at http://refocus.sourceforge.net/preview. Please examine it critically, this should be a preview that should be usable for a very wide range of plug-ins. Because I would like to reuse this proposal (or what is left of it after the discussion) for the final documentation I also welcome minor comments such as spelling mistakes, grammar corrections, coding errors and such. greetings, Ernst Lippe <[EMAIL PROTECTED]> ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
