Re: [Gimp-developer] GSOC 2008 ideas
Hi, On Fri, 2008-03-07 at 22:39 -0300, Joao S. O. Bueno wrote: == Tagging of GIMP resources == The tasks in this project include: * adding a way for gimp resources to be tagged This actually already exists in trunk with the GimpTagged interface. But it's probably OK to keep it here as a task. I would be willing to mentor this project. == On-canvas text editing == I would also mentor this one, but I can definitely not mentor two projects. Properly map Gimp Widgets and objects to Python Instead of mapping GIMP widgets to Python directly, it would probably make more sense to make sure that GIMP widgets are GtkBuildable. The GtkBuildableIface interface contains method that are necessary to allow GtkBuilder to construct an object from a GtkBuilder UI definition. This would make it a lot easier to write GIMP plug-ins as developers would have less hassle with UI code. == SVG brushes == VBR brushes in GIMP - basic shapes like ellipses, rectangles and rhombuses; with additional spikes - are scalable. In SVN trunk, all brushes including the pixmap-based ones can at least be scaled down. We do not yet have means for more advanced brushes (think about a brush consisting of two disjoint circles) that can be scaled up in a lossless way. Using SVG files as brushes could help to solve this. I don't think that SVG brushes is enough for a GSoC project. Adding a loader for SVG brushes can easily be done over a weeekend. What would make this a lot more interesting is to add the infrastructure in the paint core to actually make use of transformable brushes. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSOC 2008 ideas
Hi - here are the ideas listed again. I had trimmed down the previous list, as there are things that simply do not sound attractive enough for anyone to pick. Ideas for Gimp-python and the UF-Raw plug-in have been added. And we are still lacking mentors for pretty much everything else. :-) Also, there is still a little time for adding some more ideas, or try to focus some more. Regards, js -- [http://wiki.gimp.org/gimp/SummerOfCode2008ideas] = GSoC2008 Project Ideas = '' Please note that, although you are welcome to look at what is here, this is a workspace for mentors to write down and modify their ideas, and suggestions here should not be taken as necessarily viable projects until they have been finalized. Also, the fact that something appears here does not necessarily mean that anybody has volunteered to mentor it.'' Note to people who add stuff here: Please try to add information about a proposal's overall complexity and experience that could be helpful. E.G. experience with GTK+, image manipulation algorithms, web application development, ... == Tagging of GIMP resources == Currently resources such as brushes, gradients etc are shown to the user in an unstructured way, only sorted alphabetically. This greatly limits the number of items a user can deal with. People love to make collections of things and think of them by names for these collections, like sprinf flower brushes or fancy fonts. However, one resource can belong to more than one set, and there can be sets which are determined by other means than the content, maybe even without the user having to do anything manually - think Favorites, Most recently used and Most frequently used. It has been suggested that this should not be a finite set of categories, bug rather done by assigning tags. The tasks in this project include: * adding a way for gimp resources to be tagged * decide which types of resources (i.e. which types of gimp objects) should be tagged * find a nice way for users to manage tags (add them, remove them) * present tags in the UI (i.e. how do you show them in the brush list, font list, ...?) * think about how tags can assigned to resources (or resources to tags) == On-canvas text editing == Right now, the text tool opens a dialog window where the text has to be put, thereby creating a new text layer. Nearly every other option of the text tool - font, font size, color, line height, ... - is available in the text tool options dialog, so it would be nice to get rid of this dialog as well. There have been feature requests about being able to edit text directly on the image, like for example Inkscape does it. It may be that getting to the point where editing text on the image canvas is possible isn't that much of work, actually. But this is where the interesting challenges do begin: eventually, we do also want multiple styles in one text layer. This is not so straight forward anymore if your enter text in the image. Not present right now, so not having it isn't exactly a showstopper, but making it hard to ever get there is. And you will have to consider support for GTK+ input methods. They may be used to enter characters from languages (or, more precisely, scripts) beyond the simple Western scripts which define how our common keyboards are layed out. This is supported right now in any GTK+ text entry, not having it for on-canvas editing would be a regression. Tasks for this project include: * port the text core to PangoCairo * get on-convas text editing implemented * figure out if we do still need a text entry dialog (even Inkscape still has it in the properties of the text object) * make sure that GTK+ input methods work this this new approach * think about making it possible or not making it impossible to style the text while editing it this way == GIMP Python == mentors: Yosh or João With version 2.4, python becomes the preferred method of scripting plug-ins for GIMP. Python is an universal multipurpose cross-platform language, adopted as scripting language by several applicatives, easy to understand, with a feature rich set of standard libraries. GIMP python scripting is possible since 1999, before version 1.2 and it allows access either to GIMP's procedural database and to internal image pixel data, just like plug-ins written in C. However there are points that can be greatly improved. Things that can be done for a Google Summer of Code project: Properly map Gimp Widgets and objects to Python Wrap all libgimpwidgets to be acessible from python, so python plug-ins can have the same presentation as gimp components written in C (that is gradient and palette selectors, scale entries). Additionally map all remaining gimp objects to proper python objects, just as layers and images are already: palettes, gradients, brushes, patterns, fonts, Enhance the interface builder, add plug-in previews Add
Re: [Gimp-developer] GSOC 2008 ideas
== Integration of GHNS for GIMP == Though you can add more brushes, patterns, gradients can be added, Most users, not even pros usually add them off the internet. This is so as there is no architecture to quicky share/add from a centralized repository. This seriously limits sharing of resources among the users. GetHotNewStuff (GHNS) could probably help out here. On 3/8/08, Joao S. O. Bueno [EMAIL PROTECTED] wrote: Hi - here are the ideas listed again. I had trimmed down the previous list, as there are things that simply do not sound attractive enough for anyone to pick. Ideas for Gimp-python and the UF-Raw plug-in have been added. And we are still lacking mentors for pretty much everything else. :-) Also, there is still a little time for adding some more ideas, or try to focus some more. Regards, js -- [http://wiki.gimp.org/gimp/SummerOfCode2008ideas] = GSoC2008 Project Ideas = '' Please note that, although you are welcome to look at what is here, this is a workspace for mentors to write down and modify their ideas, and suggestions here should not be taken as necessarily viable projects until they have been finalized. Also, the fact that something appears here does not necessarily mean that anybody has volunteered to mentor it.'' Note to people who add stuff here: Please try to add information about a proposal's overall complexity and experience that could be helpful. E.G. experience with GTK+, image manipulation algorithms, web application development, ... == Tagging of GIMP resources == Currently resources such as brushes, gradients etc are shown to the user in an unstructured way, only sorted alphabetically. This greatly limits the number of items a user can deal with. People love to make collections of things and think of them by names for these collections, like sprinf flower brushes or fancy fonts. However, one resource can belong to more than one set, and there can be sets which are determined by other means than the content, maybe even without the user having to do anything manually - think Favorites, Most recently used and Most frequently used. It has been suggested that this should not be a finite set of categories, bug rather done by assigning tags. The tasks in this project include: * adding a way for gimp resources to be tagged * decide which types of resources (i.e. which types of gimp objects) should be tagged * find a nice way for users to manage tags (add them, remove them) * present tags in the UI (i.e. how do you show them in the brush list, font list, ...?) * think about how tags can assigned to resources (or resources to tags) == On-canvas text editing == Right now, the text tool opens a dialog window where the text has to be put, thereby creating a new text layer. Nearly every other option of the text tool - font, font size, color, line height, ... - is available in the text tool options dialog, so it would be nice to get rid of this dialog as well. There have been feature requests about being able to edit text directly on the image, like for example Inkscape does it. It may be that getting to the point where editing text on the image canvas is possible isn't that much of work, actually. But this is where the interesting challenges do begin: eventually, we do also want multiple styles in one text layer. This is not so straight forward anymore if your enter text in the image. Not present right now, so not having it isn't exactly a showstopper, but making it hard to ever get there is. And you will have to consider support for GTK+ input methods. They may be used to enter characters from languages (or, more precisely, scripts) beyond the simple Western scripts which define how our common keyboards are layed out. This is supported right now in any GTK+ text entry, not having it for on-canvas editing would be a regression. Tasks for this project include: * port the text core to PangoCairo * get on-convas text editing implemented * figure out if we do still need a text entry dialog (even Inkscape still has it in the properties of the text object) * make sure that GTK+ input methods work this this new approach * think about making it possible or not making it impossible to style the text while editing it this way == GIMP Python == mentors: Yosh or João With version 2.4, python becomes the preferred method of scripting plug-ins for GIMP. Python is an universal multipurpose cross-platform language, adopted as scripting language by several applicatives, easy to understand, with a feature rich set of standard libraries. GIMP python scripting is possible since 1999, before version 1.2 and it allows access either to GIMP's procedural database and to internal image pixel data, just like plug-ins written in C. However there are points that can be greatly improved. Things that can be done for a Google Summer of Code project: Properly map Gimp
[Gimp-developer] GSOC 2008 - ideas
Hi there! We have some ideas for Google Summer of Code project in the wiki, but all of tehna re dangling since last year. Mos t of tehm look good, but some may have been obsoleted in the current devel cycle, or would involve changes in code that is going away in the cycle. I am posting the full set of ideas bellow and asking for commetns on ideas, new ideas, and overall, people who would be willing to mentor a stundet through some of them. regards, js -- http://wiki.gimp.org/gimp/SummerOfCode2008ideas - [BOTTOM][TOP]GSoC2008 Project Ideas Please note that, although you are welcome to look at what is here, this is a workspace for mentors to write down and modify their ideas, and suggestions here should not be taken as necessarily viable projects until they have been finalized. Also, the fact that something appears here does not necessarily mean that anybody has volunteered to mentor it. Note to people who add stuff here: Please try to add information about a prorpsal's overall complexity and experience that could be helpful. E.G. experience with GTK+, image manipulation algorithms, web application development, ... Filetype registration There is currently no way to register a file type to open with GIMP from within GIMP itself. On some desktop environments and platforms, this makes registering types to open with GIMP awkward. We need a configuration GUI within GIMP, which does show the available types and/or file extensions, and a means (a backend) to register them according to the platform/environment. The latter should probably be modular and extensible, because this is different on each of them. Resource management. Currently resources such as brushes, gradients etc are shown to the user in an unstructured way, only sorted alphabetically. This greatly limits the number of items a user can deal with. People love to make collections of things, so this would greatly enhance the user experience. It has been suggested that this should not be a finite set of categories, bug rather tags. Create an SDI manager widget. Would allow all of GIMP's windows to be contained in a single parent window, as requested hundreds of times by Windows users. (This would be optional, not forced on people who don't want it.) Plug-in stability effort Tests have shown that it is possible to crash plug-ins when feeding them bogus data via the PDB API, for example when calling them from scripts (another interesting approach might be to run file loader plug-ins with [WWW] zzuf). Needed: a test framework to find the bugs, and then time to fix them. Additional file format plug-ins There is a number of file formats that GIMP should support, but doesn't or at least doesn't support fully, for example MNG. The MNG save plug-in needs to be modified to save images in MNG-LC profile. Then a loader can be easily written to work similar to the GIF loader. It also needs support for JPEG chunks. On-canvas text editing Right now, the text tool opens a dialog window where the text has to be put. Nearly every other option of the text toold is in its tool options dialog, so it would be nice to get rid of this dialog as well. Search-based menu browser The amount of menu entries in GIMP - either from plug-ins, scripts or internal functions - is huge. The name of a particular function might be easier to remember than its menu location. Being able to search for the function and applying it to the image without having to go through the menus can help (similar to Emacs' M-x feature). Unified UI for scripting We have three major scripting interfaces, Script-Fu, ?PyGimp and Perl-Fu. All of them allow to create an interface for a script easily, just by registering a function with their respective parameters. However, all widgets look a bit different depending on the binding. Redesign and reimplementation of Save and Export in GIMP. Change the semantics of Save and Save As so that images are always saved in the XCF file format. Only the native GIMP format really saves all the image information and allows to lossless continue editing later. So only saving as XCF should clear the dirty flag of the image. Saving to other formats than XCF is done by exporting the image. The File menu should have an Export menu item (and perhaps also Export As). Unit testing framework GIMP currently doesn't have a test framework that API changes or internal changes could be tested against. This is crucial to avoid regressions, especially with the major rewrite we will seen when GEGL is introduced. Work on GEGL [WWW] GEGL is a graph based image processing framework. It will be introduced into the GIMP trunk after 2.4 has been released. Processing is done by the nodes of the graph, which are implemented as so-called operations or 'ops'. A good introduction to the current state of GEGL is the [WWW]
Re: [Gimp-developer] GSOC 2008 - ideas
Hi, On Sun, 2008-03-02 at 07:44 -0300, Joao S. O. Bueno wrote: I am posting the full set of ideas bellow and asking for commetns on ideas, new ideas, and overall, people who would be willing to mentor a stundet through some of them. Sorry, the text you posted is so badly formatted that I am not willing to read it. But nevertheless I would like to say that IMO we should try to focus on GEGL and babl tasks for this year's SoC. That should bring us closer to our goal of full GEGL integration in GIMP. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
