Sven Neumann wrote: > Create an SDI manager widget > Do we really want to ask someone to waste his/her time with this? It > is in my opinion not implementable in a sane way and we would likely > not accept the results then. If this is supposed to be kept on the > list then we need to agree first that we really want such a thing. Whether to put this on the list depends on how many other projects get proposed and how many different ones students are interested in working on. Having it on the list doesn't obligate us to accept the project. We can always "turn it down" during the voting process. > Plug-in stability effort > The proposal concentrates on possible crashes when plug-ins are passed > invalid PDB data. Is that really an issue that is worth working on? It > would probably be a lot more worthwhile to improve the PDB API and to > add better checks in libgimp. 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. > Additional file format plug-ins > Shouldn't this perhaps be titled "Improve MNG support"? Are there enough additional file formats to be added that would make this a good candidate for an SoC project? Would it be better to talk about creating additional file format "plug-ins" for GEGL rather than GIMP? > On-canvas text editing > Nice, but pretty much depends on the port of the display code to > Cairo. Perhaps concentrate more on rich text support instead of > focusing on the on-canvas editing? A better project regarding text would be to improve the text tools and the API relating to working with text. ie. bugs 122706, 125144, and 169616. On-canvas text editing could be part of the improvements depending on the relatives sizes of the tasks. > Unified UI for scripting > I don't understand this proposal. We provide unified widgets for this > in libgimpui and our scripting interfaces use them (well, perhaps > Perl-Fu doesn't). So the look and feel should already be pretty much > the same. IMO this proposal is based on wrong assumptions. Perhaps > what's really needed is a maintainer for perl-fu. 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. > Unit testing framework > Tests are definitely needed but we might want to make it clearer what > exactly needs testing. [snip] > Benchmarking > The text for this does IMO focus too much on the actual optimization > work while it should probably focus more on what we expect from a > benchmarking framework. Should probably also include regression > testing as it helps a lot to also have a regression test when doing > optimizations. I think the above two items are different aspects of one project. Some of the unit tests could also be used as benchmarks. -- Cheers! Kevin. http://www.ve3syb.ca/ |"What are we going to do today, Borg?" Owner of Elecraft K2 #2172 |"Same thing we always do, Pinkutus: | Try to assimilate the world!" #include <disclaimer/favourite> | -Pinkutus & the Borg _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
