GSR - FR wrote: > http://google-code-updates.blogspot.com/2006/04/summer-of-code-2006.html Yes, we should definitely try to get some projects this time. I'll add a draft of my project proposal below. Comments, suggestions and corrections are welcome. I'm volunteering to be a mentor for this one as well, unless the discussion shows that my knowledge isn't sufficient and someone else wants to take it. Resource contribution, distribution and management system ========================================================= The initial idea: Provide a system that allows anyone to contribute and maintain resources (brushes, palettes, scripts, plug-ins, ...) for GIMP, and have it organized in a way that makes it easy for GIMP users to access these resources. The situation at present: There is one bigger hub for plug-ins and scripts, the so-called GIMP registry, at http://registry.gimp.org. It is used by some script and plug-in authors, but not well known to GIMP users, because it is somewhat hard to find useful things there. It is maintained on a low level, basically "keep it working". There are not standards set for publishing resources there, some projects are just links to the author's own pages. Other resources like brushes, patterns, palettes etc. are spread over the web, with some larger collections at Deviantart, http://www.deviantart.com/, and the GIMP User Group, http://gug.sunsite.dk/ This splits the community a bit - many people don't know about the brushes at Deviantart, for example. Another problem is the local resource management in particular installation. For novice users or users who aren't familiar with files and folders, it isn't obvious where to put downloaded files (or even that you have to extract them from an archive). The tasks: The project consists of two main parts, one called "Server" and the other "Client". 1. "Server" part Build a resource contribution and distribution system that allows authors to publish their resources easily, provide them with everything that is needed for a good presentation (like adding previews or example images) and allow contributions to existing resources (e.h. binaries of plug-ins for several platforms, this would be popular for Microsoft Windows or Mac OS X). Users should be able to learn about new and updated stuff, and browse and sort the collection by a number of attributes - version, gimp version, intended use (image manipulation, image creation, filter type, colors, ...). An example might be ccHost, which is used for e.g. ccMixter, http://ccmixter.org/. However, this is probably too complicated for this purpose - think more like Flickr. This system will most likely be web-based and usable with a normal browser, though it could allow for other backends (FTP, WebDAV, CVS/SVN) as well. Scalability is a major concern for us - if "slashdotting" means something to you, then you'll know what we're talking about. The system may (and probably has to) use a database to store metadata about some of the resources, but it shouldn't access the database for read access - the pages only have to be updated when a change occurs. This will also make it possible to create static mirrors more easily. Security is another concern - signing resources should be possible and even required for things like binaries. The programming language of choice would be Python. PHP and Perl are frowned upon by many GIMP developers, and Python can also be used for the second part of the project. The main goal of this part is to replace http://registry.gimp.org This task includes: - familiarize with the types of resources that can be distributed - investigation of the currently existing gimp resource distribution sites (Registry, Deviantart, GUG, other?...), analysis of their up- and downsides - design of the new system (or a plan to customize an existing one) - coding or adapting, respectively 2. "Client" part With the perspective of a rather large resource repository in mind, there should also be a way to access this repository from within GIMP. The most basic aspect is easy installation of resources, which can be done for scripts or plug-ins by using gimptool. Extending gimptool to handle alls resources known to GIMP would be a first step. However, this type of interface is not what we should force upon our users. A GIMP plug-in that can access the system built in the "server part" would be more appropriate. I haven't put much thought into this part yet, though. The programming language should be either C or Python - you won't be able to do this with Script-Fu, for example. Platform-dependency should be avoided - relying on e.g. apt or rpm would fail for the windows platform. The inherent danger of this approach is replicating functionality that is present in package manager on some platforms already, and thus interfering with these. This should be avoided. The main goal of this part is to make the new http://registry.gimp.org usable from within GIMP. This task includes: - use the server part as a real server - familiarize with GIMP plug-in programming - familiarize with local GIMP resource storage - coming up with a usable UI -- The GIMP > http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki > http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins > http://registry.gimp.org | _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
