Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Ernst Lippe <[EMAIL PROTECTED]> writes: > > However our goal is to provide a way to add a preview to > > plug-ins basically w/o changing their code. > > It is an interesting idea, but when you look at the > requirements for the preview as they were discussed last > year (see http://refocus.sourceforge.com/preview/requirements.html) > it was not part of the list. I am pretty sure this point was mentioned. IIRC it has already been discussed on GimpCon 2000 and I think it's the basic and most important design requirement. > There are several point that you will virtually always have > to change when you want to add a preview to an existing > plug-in, and in some cases (some plug-ins have pretty messy > code) these changes have to be rather drastic. Without going into much details of your answer, it is clear that you completely missed my point. Of course there are some changes needed to the plug-in code. How large the changes are depends on the quality of the code, mainly in the user interface parts of it. When I said that only few changes should be needed when adding a preview, I was assuming an otherwise well-designed and well-written plug-in. The point I was trying to make is that the actual image manipulation algorithm should not have to be touched. For the code that operates on the actual pixels, there must not be a difference between rendering the result or rendering the preview. This means that this routine can always work on a GimpDrawable and doesn't need to care if this struct wraps a real drawable or just some preview data. The preview doesn't even need to be tile-based (I think you said it would have to be). Plug-ins usually don't see any tiles, they work on pixel regions and that's exactly the API that they should be using when rendering a preview. > > I don't see how core operations would be useful at all. The only > > use of the temporary drawable is to allow the preview to be > > rendered using the same GimpPixelRgn routines that are used to > > render the final result. > > Uh, are you saying here that we can simply ignore those plug-ins > that call any of the core tool operations or other plug-ins? Yes. I think this is a safe assumption for the general case. Not too many plug-ins call other plug-ins. In the GIMP source tree there is not a single one that would need a preview and calls other plug-ins. > > Basically any plug-in that works on pixel rows is less than > > optimal and should be rewritten at some point. Good plug-ins are > > supposed to work on tiles rather than rows. > > I am afraid that with this definition there are very few "good" > plug-ins. That is correct, but if we provide a preview API that encourages to write good plug-ins, this number will increase. If our preview API is modeled after the bad sort of plug-ins, we will never get a reasonable codebase in the plug-ins directory. Of course my proposal also allows for a row-based algorithm since GimpPixelRgn provides that as well. > Now obviously you have a problem with having to allocate temporary > drawables in the GIMP core just for the sake of previewing. > > But what is the problem? Is it just a performance issue? As far as I > have seen, it is not a serious issue, I have a pretty slow computer > and the performance of the preview is quite acceptable. In most cases > the drawables are pretty small, much smaller than the real images. In > general I am pretty skeptical about design decisions that sacrifice > simplicity for performance's sake, in the long term that is generally > a bad strategy (yes there are some cases where it is a correct > decision but you should always analyze them pretty carefully). Performance is not the primary concern here. The problem is that if we encourages plug-ins to allocate temporary drawables in the core, we would have to add a framework that makes sure that these drawables aren't leaked. One of the main reasons to keep plug-ins as separate processes is to ensure that a badly written plug-in doesn't make the GIMP core leak memory. I am pretty sure that temporary drawables created by plug-ins will eat up our tile-cache quite fast. In the long run we will have to improve how resources allocated by plug-ins are handled in the core. The core should be able to undo all operations in case a plug-in crashes and it should free all floating resources when a plug-in finishes it's job. If such a framework is in place, we can easily change the preview code to optionally allow a preview in the image window. The plug-in will then simply work on a core drawable and this can happen completely transparently. > Most existing plug-ins will write their output only to their input > drawable. But for the preview we don't want to modify the original > drawable, but the plug-in must somehow be coerced to write its output > to something that the preview could read. If you really don't want to > change the plug-ins algorithm at all the only solution is to somehow > intercept the modifications
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Thu, 19 Feb 2004 16:00:08 +0100 Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > Ernst Lippe <[EMAIL PROTECTED]> writes: > > > The decision if the plug-in "needs" the temporary drawable > > is made by its designer and it is certainly not forced by > > the preview. It is perfectly possible to draw a row of > > pixels on the preview (indeed for a very long period that > > has been the only way you could draw on the preview, support > > for drawables is a recent addition). If a plug-in designer > > writes a plug-in in such a way that it can only output to > > a drawable, then it will always have to allocate a temporary > > drawable (unless you want to mess around with the original > > input drawable, which sound pretty horrible). > > But when the internal datastructures for the algorithm > > can be used to construct a single row for the preview > > there is no reason to use a temporary drawable. > > So you are seeing the GimpPreview as just a widget that plug-ins can > draw on. Basically, yes. > However our goal is to provide a way to add a preview to > plug-ins basically w/o changing their code. It is an interesting idea, but when you look at the requirements for the preview as they were discussed last year (see http://refocus.sourceforge.com/preview/requirements.html) it was not part of the list. If you would have proposed it as a requirement at that stage I would have rejected it, because I simply think that it is infeasible as it stands. There are several point that you will virtually always have to change when you want to add a preview to an existing plug-in, and in some cases (some plug-ins have pretty messy code) these changes have to be rather drastic. A few points: * How do you detect that parameters have been changed? Users will expect that the preview gets updated when they change some parameters. Many plug-ins do not need to detect this at the moment because the values only become relevant when the user presses the OK button. When rewriting such a plug-in you will have to add modification detection code, and you will also have to modify the code that collects the current values of the parameters and runs the underlying algorithm with these parameters. Some plug-ins completely mix their business logic with their GUI and in these cases it might require quite a bit of work to fix this. * Current plug-ins assume that they can write the results back to the input drawable. So you will either need to coerce to write back their results somewhere else or you will have to mess around with the original drawable (probably some hidden global "preview-mode" switch). * Current plug-ins are not very flexible in the area that they render. Some always generate the entire drawable, and others generate the area from gimp_drawable_mask_bounds. For the latter category you could of course think of a hack that changes the output of gimp_drawable_mask_bounds based on some hidden global "preview-mode" switch, but then you will also have to consider the consequence of this decision for all other places where this function may be used, not to mention the fact that the whole idea of global mode switches is inherently ugly. So I don't think that should try to find some solution without rewriting, but to find some framework that could easily fit a large set of the current plug-ins. > The change should be > limited to the plug-in dialog and a few hooks here and there. Unless there have been some major changes to the GIMP plug-ins since I last looked at them, I believe that this idea is not very realistic. > Your > preview widget could be part of this infrastructure since it provides > a way to draw pixels to the screen, but in its current state, it > certainly doesn't meet the goals I outlined above. > > > One of the design requirements of the preview is to provide a > > > convenient way for plug-ins to preview their results. Convenient means > > > that it should be possible to reuse the existing pixel manipulations > > > routines without or with small changes. Allocating temporary drawables > > > in the core is in my opinion not a viable solution for this problem. > > > > > > It should however be possible to keep the temporary drawables > > > completely on the plug-in side. To achieve this, the GimpDrawable > > > wrapper would have to know whether it needs to get the tiles from the > > > core (via shared memory or over the pipe) or allocate them in the > > > plug-in process. I think this change would be rather straight-forward. > > > > But unless I am mistaken, this temporary drawable has only > > a limited functionality, because you cannot use any of > > the "core" operations on it. > > So I am not really certain if it would be worth the effort. > > I don't see how core operations would be useful at all. The only use > of the temporary drawable is to allow the preview to be rendered using > the same GimpPixelRgn routines that are used to render the final result. Uh, are you saying here that we can simp
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Sven Neumann wrote: Ernst Lippe <[EMAIL PROTECTED]> writes: The decision if the plug-in "needs" the temporary drawable is made by its designer and it is certainly not forced by the preview. So you are seeing the GimpPreview as just a widget that plug-ins can draw on. However our goal is to provide a way to add a preview to plug-ins basically w/o changing their code. The change should be limited to the plug-in dialog and a few hooks here and there. Your preview widget could be part of this infrastructure since it provides a way to draw pixels to the screen, but in its current state, it certainly doesn't meet the goals I outlined above. It is certainly a step in the right direction, though, and I think that it is something that we should try to use (and improve) during the 2.1 cycle. It is more than a simple widget that you draw on too - you get feedback from the widget about which pixel region is currently in the viewport, and you can quite easily generate a drawable from that which you pass to your filter function. Given that there are now 2 developers interested in working on this (Ernst and dindinx) I think there is a good chance that working together on it (in GIMP CVS, so that we get some feedback from the plug-in authors who use it too) we will have a nice to use preview widget by 2.2 Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Wed, 18 Feb 2004 16:19:06 +0100 Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > Ernst Lippe <[EMAIL PROTECTED]> writes: > > > No, the preview itself does not generate any temporary drawables. > > However there is a utility function for the plug-in to generate > > such temporary drawables, when it finds that more convenient, > > but in that case it is the responsibility of the plug-in > > and not of the preview. It can function perfectly without > > any temporary drawables. > > Well, if the plug-in needs to allocate temporary drawables in order to > conveniently display a preview, than this is a problem of the preview. The decision if the plug-in "needs" the temporary drawable is made by its designer and it is certainly not forced by the preview. It is perfectly possible to draw a row of pixels on the preview (indeed for a very long period that has been the only way you could draw on the preview, support for drawables is a recent addition). If a plug-in designer writes a plug-in in such a way that it can only output to a drawable, then it will always have to allocate a temporary drawable (unless you want to mess around with the original input drawable, which sound pretty horrible). But when the internal datastructures for the algorithm can be used to construct a single row for the preview there is no reason to use a temporary drawable. > One of the design requirements of the preview is to provide a > convenient way for plug-ins to preview their results. Convenient means > that it should be possible to reuse the existing pixel manipulations > routines without or with small changes. Allocating temporary drawables > in the core is in my opinion not a viable solution for this problem. > > It should however be possible to keep the temporary drawables > completely on the plug-in side. To achieve this, the GimpDrawable > wrapper would have to know whether it needs to get the tiles from the > core (via shared memory or over the pipe) or allocate them in the > plug-in process. I think this change would be rather straight-forward. But unless I am mistaken, this temporary drawable has only a limited functionality, because you cannot use any of the "core" operations on it. So I am not really certain if it would be worth the effort. Furthermore, this functionality would only be needed for those plug-in algorithms where it is difficult to compute an entire row of pixels, and actually I cannot remember that I have ever seen one. So if you have some good examples, perhaps the problem could also be solved by changing the interface of the preview, e.g. adding support for drawing tiles on the preview. Anyhow, it does not have any real impact on the preview. At most, I would have to change a few lines in two of the helper functions. Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Ernst Lippe <[EMAIL PROTECTED]> writes: > The decision if the plug-in "needs" the temporary drawable > is made by its designer and it is certainly not forced by > the preview. It is perfectly possible to draw a row of > pixels on the preview (indeed for a very long period that > has been the only way you could draw on the preview, support > for drawables is a recent addition). If a plug-in designer > writes a plug-in in such a way that it can only output to > a drawable, then it will always have to allocate a temporary > drawable (unless you want to mess around with the original > input drawable, which sound pretty horrible). > But when the internal datastructures for the algorithm > can be used to construct a single row for the preview > there is no reason to use a temporary drawable. So you are seeing the GimpPreview as just a widget that plug-ins can draw on. However our goal is to provide a way to add a preview to plug-ins basically w/o changing their code. The change should be limited to the plug-in dialog and a few hooks here and there. Your preview widget could be part of this infrastructure since it provides a way to draw pixels to the screen, but in its current state, it certainly doesn't meet the goals I outlined above. > > One of the design requirements of the preview is to provide a > > convenient way for plug-ins to preview their results. Convenient means > > that it should be possible to reuse the existing pixel manipulations > > routines without or with small changes. Allocating temporary drawables > > in the core is in my opinion not a viable solution for this problem. > > > > It should however be possible to keep the temporary drawables > > completely on the plug-in side. To achieve this, the GimpDrawable > > wrapper would have to know whether it needs to get the tiles from the > > core (via shared memory or over the pipe) or allocate them in the > > plug-in process. I think this change would be rather straight-forward. > > But unless I am mistaken, this temporary drawable has only > a limited functionality, because you cannot use any of > the "core" operations on it. > So I am not really certain if it would be worth the effort. I don't see how core operations would be useful at all. The only use of the temporary drawable is to allow the preview to be rendered using the same GimpPixelRgn routines that are used to render the final result. > Furthermore, this functionality would only be needed > for those plug-in algorithms where it is difficult > to compute an entire row of pixels, and actually > I cannot remember that I have ever seen one. > So if you have some good examples, perhaps the problem > could also be solved by changing the interface of the > preview, e.g. adding support for drawing tiles on the > preview. Basically any plug-in that works on pixel rows is less than optimal and should be rewritten at some point. Good plug-ins are supposed to work on tiles rather than rows. If our preview widget encourages the plug-in author to work on a row-by-row basis, then we will never get plug-ins that operate on the pixels in the most efficient way. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Ernst Lippe <[EMAIL PROTECTED]> writes: > No, the preview itself does not generate any temporary drawables. > However there is a utility function for the plug-in to generate > such temporary drawables, when it finds that more convenient, > but in that case it is the responsibility of the plug-in > and not of the preview. It can function perfectly without > any temporary drawables. Well, if the plug-in needs to allocate temporary drawables in order to conveniently display a preview, than this is a problem of the preview. One of the design requirements of the preview is to provide a convenient way for plug-ins to preview their results. Convenient means that it should be possible to reuse the existing pixel manipulations routines without or with small changes. Allocating temporary drawables in the core is in my opinion not a viable solution for this problem. It should however be possible to keep the temporary drawables completely on the plug-in side. To achieve this, the GimpDrawable wrapper would have to know whether it needs to get the tiles from the core (via shared memory or over the pipe) or allocate them in the plug-in process. I think this change would be rather straight-forward. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Wed, 18 Feb 2004 13:51:40 +0100 Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > Ernst Lippe <[EMAIL PROTECTED]> writes: > > > > http://refocus.sourceforge.net/preview/gimppreview.html > > > > The major points in the discussion were that some people did not like > > the way that the preliminary version of the preview tried to prevent > > recursive updates and that the names did not start with GIMP. > > > > As far as I can tell these points have been fixed in the first > > official release. > > As far as I remember the major problematic point was the fact that the > preview creates temporary drawables in the core instead of handling > the preview completely on the plug-in side. Has this been addressed > as well? No, the preview itself does not generate any temporary drawables. However there is a utility function for the plug-in to generate such temporary drawables, when it finds that more convenient, but in that case it is the responsibility of the plug-in and not of the preview. It can function perfectly without any temporary drawables. Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Wed, 18 Feb 2004 10:18:58 +0100 Dave Neary <[EMAIL PROTECTED]> wrote: > Hi, > > Ernst Lippe wrote: > > Sven Neumann <[EMAIL PROTECTED]> wrote: > >>http://refocus.sourceforge.net/preview/gimppreview.html > > > > The major points in the discussion were that some people did not like > > the way that the preliminary version of the preview tried to prevent > > recursive updates and that the names did not start with GIMP. > > > > As far as I can tell these points have been fixed in > > the first official release. > > As a matter of interest, do you do any optimisation based on the current > viewport in the preview? Do you generate a viewport-sized (+ margin, say) > drawable from the original drawable that you pass to the function connected to > the "update-preview" signal? Something like this was present in the old preview, I deliberately removed it because it was an unnecessary overhead for some plug-ins. The first question that you face when you want to add this, should the drawable be scaled or not? There is not much point in using an unscaled drawable because the plug-in could easily extract it from the original image, and there is no performance advantage by doing it in the preview. Also, I have added a utility function to the preview (gimp_preview_get_temp_drawable) for doing this, so it is very easy for the programmer to do this in the signal handler. If you want to send a scaled drawable, for several algorithms this is simply useless overhead because they can't use it. There are many plug-in algorithms that are not scale-invariant in the sense that the scaled version of their output is different from the output when they use a scaled input. Also several algorithms have an output area that is different from their input area. Yet another class of algorithms are those that simply generate a new image that is independent from the input image. For all these classes of algorithms a scaled drawable is simply useless overhead. So when you really want to let the preview generate a scaled drawable, it should definitely be optional. In that case there would be yet another parameter for the preview, and the internal code would have to be more complicated (at the moment it only draws directly to the underlying GtkImage and that should be modified to write to the drawable as well). Also, I am not convinced that there would be a real performance advantage, for most plug-ins that I have seen, the plug-in algorithm itself will be the main bottle-neck. For those algorithms that really want a scaled drawable there is another utitility function (gimp_preview_get_scaled_drawable). Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Ernst Lippe <[EMAIL PROTECTED]> writes: > > http://refocus.sourceforge.net/preview/gimppreview.html > > The major points in the discussion were that some people did not like > the way that the preliminary version of the preview tried to prevent > recursive updates and that the names did not start with GIMP. > > As far as I can tell these points have been fixed in the first > official release. As far as I remember the major problematic point was the fact that the preview creates temporary drawables in the core instead of handling the preview completely on the plug-in side. Has this been addressed as well? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Ernst Lippe wrote: Sven Neumann <[EMAIL PROTECTED]> wrote: http://refocus.sourceforge.net/preview/gimppreview.html The major points in the discussion were that some people did not like the way that the preliminary version of the preview tried to prevent recursive updates and that the names did not start with GIMP. As far as I can tell these points have been fixed in the first official release. As a matter of interest, do you do any optimisation based on the current viewport in the preview? Do you generate a viewport-sized (+ margin, say) drawable from the original drawable that you pass to the function connected to the "update-preview" signal? Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Fri, 06 Feb 2004 16:51:28 +0100 Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > David Odin <[EMAIL PROTECTED]> writes: > > > Anyway, this isn't clear in my mind for now. I'll propose a draft > > on this list as soon as I have more valuable thing to show. > > I hope you are aware that there is an implementation already. We were > not happy with the API and some implementation details but it is > definitely worth to at least have a look at it: > > http://refocus.sourceforge.net/preview/gimppreview.html The major points in the discussion were that some people did not like the way that the preliminary version of the preview tried to prevent recursive updates and that the names did not start with GIMP. As far as I can tell these points have been fixed in the first official release. Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Juhana Sadeharju <[EMAIL PROTECTED]> writes: > >What we are aiming for is a lot more complex than what GtkPreview is > >providing. The goal is to have a widget that can zoom and pan. It > >should also provide an API that allows to use the same image > >processing routines for the preview as are used for the drawable. The > >plug-in author shouldn't have to care much about the preview. > > Does this mean you continue with the plugins which create their own > dialog and all interactive manipulation happens there, like gfig? GFig is supposed to be completely replaced by the vectors tool sooner or later so that's probably not a good example. > I wish plugins like gfig would operate on the image/view, not > in separate window like now. We are mainly seeking for a short-term solution here that allows to add a preview to existing plug-ins w/o too many changes. What you are asking for is pluggable tools. This was attempted in the 1.3 series but we backed this change out because it exposed too much internals that are not yet in the state where we want anything but the core to work with it. > MIP images would mean that large images may be efficiently edited at > lower resolution. The operations are reflected to high resolution > images later or when the system is idle enough. A GEGL-based GIMP is supposed to allow exactly that but we will have to do some rather major changes before this becomes real. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Tentative 2.2 feature list
>From: Sven Neumann <[EMAIL PROTECTED]> > >What we are aiming for is a lot more complex than what GtkPreview is >providing. The goal is to have a widget that can zoom and pan. It >should also provide an API that allows to use the same image >processing routines for the preview as are used for the drawable. The >plug-in author shouldn't have to care much about the preview. Does this mean you continue with the plugins which create their own dialog and all interactive manipulation happens there, like gfig? I wish plugins like gfig would operate on the image/view, not in separate window like now. There are consequences: -Need for multirate images (MIP images) for low resolution preview -Plugin's preview area can be given as a rectangle on the image (just like 3D modellers allows user to define the area which is rendered) -Plugins can make data layers on the image (gfig would make a vector layer) MIP images would mean that large images may be efficiently edited at lower resolution. The operations are reflected to high resolution images later or when the system is idle enough. If a plugin wants a separate preview to its dialog, then that is just a new view to the image, embedded to the dialog. Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Dave Neary <[EMAIL PROTECTED]> writes: > I'm not sure what you mean by this - wouldn't the preview just be a > copy of the drawable which gets rendered? What API is needed? I have > trouble following the problems you see. I'm a bit confused now since we discussed all details of the widget several months ago. It might be worth to dig out that discussion again because it had a very good list of requirements. The main point is that of course since you want to preview a plug-in's result, the plug-in shouldn't have to run the complete drawable thru whatever pixel manipulation routines it applies. There wouldn't be a need for a preview widget then, you could simply apply the effect. The preview widget needs to be smart enough to cause only the visible area to be processed (from an idle handler so that the GUI remains responsive). For a zoomed preview it needs to pass scaled data to the plug-in's pixel manipulation routines which may then have to adapt to the scale ratio that is applied. Ideally the same pixel manipulation routines of the plug-in should be used for rendering the actual result on the drawable as for rendering the preview. Since we don't want to introduce major changes to the plug-in, the preview API should probably provide a fake drawable that the plug-in can work on. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Fri, Feb 06, 2004 at 04:51:28PM +0100, Sven Neumann wrote: > Hi, > > David Odin <[EMAIL PROTECTED]> writes: > > > Anyway, this isn't clear in my mind for now. I'll propose a draft > > on this list as soon as I have more valuable thing to show. > > I hope you are aware that there is an implementation already. We were > not happy with the API and some implementation details but it is > definitely worth to at least have a look at it: > > http://refocus.sourceforge.net/preview/gimppreview.html > I wasn't aware of this. I'll have a look. Thanks. DindinX -- [EMAIL PROTECTED] Despite the cost of living, have you noticed how it remains so popular? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, David Odin <[EMAIL PROTECTED]> writes: > Anyway, this isn't clear in my mind for now. I'll propose a draft > on this list as soon as I have more valuable thing to show. I hope you are aware that there is an implementation already. We were not happy with the API and some implementation details but it is definitely worth to at least have a look at it: http://refocus.sourceforge.net/preview/gimppreview.html Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Sven Neumann wrote: David Odin <[EMAIL PROTECTED]> writes: What we are aiming for is a lot more complex than what GtkPreview is providing. The goal is to have a widget that can zoom and pan. This would be cool. It should also provide an API that allows to use the same image processing routines for the preview as are used for the drawable. The plug-in author shouldn't have to care much about the preview. I'm not sure what you mean by this - wouldn't the preview just be a copy of the drawable which gets rendered? What API is needed? I have trouble following the problems you see. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Fri, Feb 06, 2004 at 04:02:37PM +0100, Sven Neumann wrote: > Hi, > > David Odin <[EMAIL PROTECTED]> writes: > > > It looks so. While it is true that GtkPreview has been deprecated > > without a replacement widget without a good reason (in my opinion, and > > obviously in Sven's opinion too), GimpOldPreview is much more than only > > a wrapper around GtkPreview. Besides, we (I ?) could do a better job by > > integrating GimpPreview (or whatever its name will be) more with gimp's > > internal. > > Integrating with GIMP's internal? There's no need for such a widget in > the GIMP core (and we have GimpPreview in the core already). What we > are looking for is a preview widget that is especially modeled for the > need of GIMP plug-ins. How would this integrate with internals? I > guess I somehow misunderstood you here. > Sorry. I haven't been clear enough here. GimpPreview as I see it should be able so show exactly the same thing as a Drawable, but with a different scale. For instance, it should be able to show the composited image, with a background layer or whatever. This sort of thing could involve more than just gdkrgb functions, that's why I said this _could_ use more gimp's way of rendering than gtk's. Anyway, this isn't clear in my mind for now. I'll propose a draft on this list as soon as I have more valuable thing to show. Regards, DindinX -- [EMAIL PROTECTED] Laugh alone and the world thinks you're an idiot. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Tentative 2.2 feature list
On Fri, Feb 06, 2004 at 03:45:21PM +0100, Sven Neumann wrote: > Hi, > > David Odin <[EMAIL PROTECTED]> writes: > > > To be more precise, since the GTK+ team has deprecated GtkPreview, > > I would have like to see if the gimp couldn't have its own widget > > for this. I won't promise it will be done on time, though. Let's put > > this on the "maybe included" list. > > GtkPreview is still available, there's nothing that keeps us from > using it. > If needed, yes. > What we are aiming for is a lot more complex than what GtkPreview is > providing. The goal is to have a widget that can zoom and pan. It > should also provide an API that allows to use the same image > processing routines for the preview as are used for the drawable. The > plug-in author shouldn't have to care much about the preview. > Exactly, selection and layers handling should be there two. But please, see my other mail. Regards, DindinX -- [EMAIL PROTECTED] If law school is so hard to get through, how come there are so many lawyers? - Calvin Trillin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, David Odin <[EMAIL PROTECTED]> writes: > It looks so. While it is true that GtkPreview has been deprecated > without a replacement widget without a good reason (in my opinion, and > obviously in Sven's opinion too), GimpOldPreview is much more than only > a wrapper around GtkPreview. Besides, we (I ?) could do a better job by > integrating GimpPreview (or whatever its name will be) more with gimp's > internal. Integrating with GIMP's internal? There's no need for such a widget in the GIMP core (and we have GimpPreview in the core already). What we are looking for is a preview widget that is especially modeled for the need of GIMP plug-ins. How would this integrate with internals? I guess I somehow misunderstood you here. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Tentative 2.2 feature list
Hi, David Odin <[EMAIL PROTECTED]> writes: > To be more precise, since the GTK+ team has deprecated GtkPreview, > I would have like to see if the gimp couldn't have its own widget > for this. I won't promise it will be done on time, though. Let's put > this on the "maybe included" list. GtkPreview is still available, there's nothing that keeps us from using it. What we are aiming for is a lot more complex than what GtkPreview is providing. The goal is to have a widget that can zoom and pan. It should also provide an API that allows to use the same image processing routines for the preview as are used for the drawable. The plug-in author shouldn't have to care much about the preview. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Tentative 2.2 feature list
On Fri, Feb 06, 2004 at 01:16:28PM +0100, David Neary wrote: > > Hi, > > Sven Neumann wrote: > >Dave Neary <[EMAIL PROTECTED]> writes: > >>As a matter of interest, why do we not simply take the old GtkPreview > >>code an rename it GimpPreview, put it in libgimpwidgets and use that? > >>Just wondering. > > > >Because the old GtkPreview code is not what we would like to see as a > >GIMP preview widget? It shares a few characters in the name but that's > >about where the similarity ends. > > Ah - I recalled you saying on several occasions that you didn't understand > why GtkPreview had been deprecated, that you thought it was a very good > widget. I must have misunderstood. > It looks so. While it is true that GtkPreview has been deprecated without a replacement widget without a good reason (in my opinion, and obviously in Sven's opinion too), GimpOldPreview is much more than only a wrapper around GtkPreview. Besides, we (I ?) could do a better job by integrating GimpPreview (or whatever its name will be) more with gimp's internal. Regards, DindinX -- [EMAIL PROTECTED] The best way to hold a man is in your arms. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Tentative 2.2 feature list
On Fri, Feb 06, 2004 at 12:38:33PM +0100, David Neary wrote: > > >>5) Preview widget to replace GimpOldPreview > > > >That's a rather large change. If we get someone interested and a > >proposal for an implementation is posted early enough, then it should > >probably go in. > > David Odin has said he would like to do this for 2.2, which is why it's on > the list. > To be more precise, since the GTK+ team has deprecated GtkPreview, I would have like to see if the gimp couldn't have its own widget for this. I won't promise it will be done on time, though. Let's put this on the "maybe included" list. Regards, DindinX -- [EMAIL PROTECTED] The more beautiful the woman is who loves you, the easier it is to leave her with no hard feelings. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
