On Monday 17 April 2006 09:30, Michael Schumacher wrote: > 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. How about also getting GEGL on the Google Summer of Code 2006 program. It you can get one or two studends working on GEGL through the summer it could have a positive impact on it's progress and also be a great learning experience for the students involved. Also any projects that wants to apply needs to have their application in to Goggle by the end of this month. That leaves less than two weeks and I don't see either GIMP or GEGL on the list of mentoring Organizations. Hal > > > > 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 _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
