[Gimp-developer] Plugged-in tools
Hi, there has been a discussion, in 2002-2004, to allow plugged-in tools. On 2002-02-22, Sven Neumann wrote: not discussed, but already implemented ;-) The CVS version has preliminary support for pluggable tools that can be either loaded as a plug-in (separate process) or as a module. I haven't looked at the implementation details yet. What has become of this? Many of the existing plug-ins would profit of such an infrastructure, as well as new plug-ins become possible (see bug #74554). There has been repeatedly brought up the request for in-window applicability of the IWarp distort. Using IWarp in the preview pane is a nuisance and much inferior to, for example, the Photoshop Liquify tool. In fact, this has been the reason for me to consider hacking the GIMP in the first place. Then there is the issue of dialog preview visibility. Core dialogs like Levels and Curves are able to show preview directly in the image window, as opposed to plug-in dialogs which are restricted to small preview widgets. Again, this is much inferior to the real-image preview and has got me frustrated more than once. I know there have been a number of philosophical remarks in the past against pluggable tools. However, to a user ignorant to the constraining GIMP design mechanisms, these restrictions and their consequences to the UI appear arbitrary. Why stick with these at the cost of a bad UI? If it turns out unfeasible to expose the tool API, the IWarp filter could be merged into the GIMP core so it can used as a tool. However, this would not address the problem of bad preview in plugged-in filters, so maybe there is a better solution. Roland ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plugged-in tools
Hi Roland On 07/31/2010 02:32 PM, Roland Lutz wrote: Hi, there has been a discussion, in 2002-2004, to allow plugged-in tools. On 2002-02-22, Sven Neumann wrote: not discussed, but already implemented ;-) The CVS version has preliminary support for pluggable tools that can be either loaded as a plug-in (separate process) or as a module. I haven't looked at the implementation details yet. What has become of this? Many of the existing plug-ins would profit of such an infrastructure, as well as new plug-ins become possible (see bug #74554). No significant progress have been made, as far as I know no one is working on making tools pluggable. There has been repeatedly brought up the request for in-window applicability of the IWarp distort. Using IWarp in the preview pane is a nuisance and much inferior to, for example, the Photoshop Liquify tool. In fact, this has been the reason for me to consider hacking the GIMP in the first place. Yes not having IWarp on-canvas really makes the whole thing feel rather crippled. Tor Lillqvist started porting the IWarp plug-in to a tool a while back but never got around to finish it. I'm sure he would appreciate someone finishing the work: https://bugzilla.gnome.org/show_bug.cgi?id=162014 Then there is the issue of dialog preview visibility. Core dialogs like Levels and Curves are able to show preview directly in the image window, as opposed to plug-in dialogs which are restricted to small preview widgets. Again, this is much inferior to the real-image preview and has got me frustrated more than once. Doing previews on-canvas is indeed superior to our current dialogs that plug-ins uses, switching to GEGL will help us greatly with making things being previewed on the canvas. I know there have been a number of philosophical remarks in the past against pluggable tools. However, to a user ignorant to the constraining GIMP design mechanisms, these restrictions and their consequences to the UI appear arbitrary. Why stick with these at the cost of a bad UI? I think this is a tricky issue. In order for a tool to be easy to use, it needs to be very well integrated in the UI. It is hard to construct an API that is well designed and easy to maintain, but still allows tools to feel integrated. It would be very interesting to see an attempt at defining a useful API for pluggable tools. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Automatic tab style and removed tab title bar ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plugged-in tools
On 7/31/10, Roland Lutz wrote: There has been repeatedly brought up the request for in-window applicability of the IWarp distort. Using IWarp in the preview pane is a nuisance and much inferior to, for example, the Photoshop Liquify tool. In fact, this has been the reason for me to consider hacking the GIMP in the first place. Roland, There was an attempt to rewrite IWarp into a tool before, but this work wasn't finished. Check archives for February 2008. These days new tools are better implemented on top of GEGL. One such tool is currently in works as an objective of a Google Summer of Code project: http://git.gnome.org/browse/gimp/log/?h=soc-2010-cage Then there is the issue of dialog preview visibility. Core dialogs like Levels and Curves are able to show preview directly in the image window, as opposed to plug-in dialogs which are restricted to small preview widgets. Again, this is much inferior to the real-image preview and has got me frustrated more than once. This will change along with further integration with GEGL, AFAIK. I know there have been a number of philosophical remarks in the past against pluggable tools. However, to a user ignorant to the constraining GIMP design mechanisms, these restrictions and their consequences to the UI appear arbitrary. Why stick with these at the cost of a bad UI? Because every feature needs its programmer is the best I can come up with :) Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plugged-in tools
Pluggable tools would be nice, but the tool system is already set up to make it easy to add new ones. It's one of the easiest places in the gimp code for a new developer to work, although it would be a lot easier if there were more developer documentation. The problem with the iwarp tool wasn't in the framework, it was in the execution. It turns out to be very difficult to generate in-image previews at full scale fast enough to be responsive. There were also some difficulties, if I remember correctly, in adapting the code to work when the image window shows a rescaled version of only a portion of the layer. Doing the tool as a plug-in wouldn't help with those problems at all. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plugged-in tools
I think an IWarp tool would require mechanisms in GIMP that don't exist yet as none of the current tools, even if superficially similar (like the smudge tool) requires them. Also, the exact way an IWarp tool should behave should be specified before one starts coding on it;) Yeah, getting input on how the corresponding functionality UI works in PS might be useful, or not. GIMP is not supposed to be a PS lookalike. Should using an IWarp tool mean entering a separate mode where you then have to apply and exit it when done? That is somewhat ugly, isn't it? Or should an IWarp tool automatically do the final application of the displacement map that has been built up during subsequent IWarp brush strokes and whatnot when another tool is selected and used? Will that be unbearably slow? In a non-destructive GEGLified future, that probably doesn't matter much as the calculation of updated actual image pixels can be done in the background (as long as the preview is correct enough), or something. I quote my comment in the bug mentioned, The smudge tool is inherently quite different from what an IWarp tool would be. Each stroke of the smudge tool immediately affects the pixels the brush touches. There is no memory of previous strokes. In IWarp, on the other hand, what happens when you stroke is that the displacement map gets updated, and the effect on the *original* pixels from when the tool was started has to be recalculated. (At least, something like this is what I recall from when I was hacking on making IWarp a tool.) --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plugged-in tools
On Saturday, July 31, 2010 22:33:56 Tor Lillqvist wrote: I think an IWarp tool would require mechanisms in GIMP that don't exist yet as none of the current tools, even if superficially similar (like the smudge tool) requires them. Doing the iWarp tool in paint tool way was rejected because it destroys the image very fast. Krita has such implementation and I suggest you try it. Should using an IWarp tool mean entering a separate mode where you then have to apply and exit it when done? That is somewhat ugly, isn't it? This is the only way this tool can currently work without creating undue degradation of the image while working. Once gegl is fully integrateed however, It can be a sort of an effect layer/op in the graph. [SNIP] In IWarp, on the other hand, what happens when you stroke is that the displacement map gets updated, and the effect on the *original* pixels from when the tool was started has to be recalculated. (At least, something like this is what I recall from when I was hacking on making IWarp a tool.) CAGE tool currently under development already creates a piece of such a tool, a displacement map renderer. In fact, in many ways, the cage tool and iWarp are alike. Once cage tool is done, spawning an iWarp tool form its code should be trivial. All you need is to replace the UI code to brush instead of polygon editor and create the displacement map. Render pipleine should already be in place. -- Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plugged-in tools
On Sat, 31 Jul 2010, Tor Lillqvist wrote: Should using an IWarp tool mean entering a separate mode where you then have to apply and exit it when done? That is somewhat ugly, isn't it? That's how the Scissors tool works, so people are already used to it. This way, a separate warp history could be maintained in the tool area which could allow reverting arbitrary strokes. With GEGL, it might even be possible to re-open and revise a warp layer at a later time. In a non-destructive GEGLified future, that probably doesn't matter much as the calculation of updated actual image pixels can be done in the background (as long as the preview is correct enough), or something. This doesn't mean the warp 'strokes' shouldn't be understood as a single warping operation. The (yet invisible) grid they affect defines the way the drawable sould be transformed. This is not equivalent to composing several transformations (think of the 'Remove' deform mode). Roland ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
