Hi, On Thu, 2007-03-08 at 01:43 -0500, Kevin Cozens wrote: > It is pretty easy to crash many (most?) of the plug-ins when passed bad data > from some script. Checks in libgimp can stop GIMP from crashing but will only > go so far to stop the plug-in from crashing. I think it would be a worthwhile > project to get done at some point. In terms of SoC, it would be a low priority > project. > > This also raises the question as to whether the plug-in-template can handle > being passed bad data or not. If not, it should be updated to show new plug-in > authors how to properly write a plug-in to deal with the possibility of > receiving bad data. The question is, is this a serious problem at all? If a script is broken and the result is a plug-in that crashes, is that really a problem? A crashing plug-in shouldn't cause further harm and there's a warning that informs the script author that there's a problem. The script can then be fixed. Making a plug-in deal with all kinds of bogus parameters can become a major hassle and it is IMO not worth the extra code complexity. As long as the parameters are well documented, it's not much of a problem if the plug-in crashes when being passed invalid parameters. Also this whole problem will basically solve itself with the revamped PDB API because it will allow us to do much better parameter checking in libgimp. > This would be useful. While libgimpui may provide unified widgets it still > requires a certain amount of gtk+ coding to build the dialog. For example, > pygimp supports radio buttons but Script-Fu does not. If there was a libgimpui > routine that took some data with the information needed to build the UI, all > language bindings would be able to have dialog boxes without the need to > include the gtk+ related calls needed to build a dialog. Adding radio button > support to Script-Fu may not be difficult to someone who is used to gtk+ > programming but it would be trivial if the dialog box creation was handled by > a libgimpui routine. Sorry, but I have to disagree. If we would try to move this completely into libgimpui, then you would have to deal with libgimpui functions. Which means that you are dealing with an API that is not as well known and well documented as the GTK+ API. And it means that a language binding for these functions has to be written before it can be used. It seems much simpler to actually write down a couple of lines of GTK+ code. If you think that a particular widget is missing in libgimpui, feel free to suggest that it is being added. Again, I have to add that as soon as we switch to the new PDB API, it will also become a lot easier to write plug-in and script user interfaces. You will then be able to use the convenience widget constructors in gimppropwidgets. That will save you a lot of coding and it will lead to a more consistent look and feel. Sven _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
