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

On 4/17/06, Michael Schumacher wrote:

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.

I wonder if you have read this:
http://lists.freedesktop.org/archives/create/2006-March/000314.html ;-)

Alexandre

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

On Mon, Apr 17, 2006 at 09:52:32PM +0400, Alexandre Prokoudine wrote:

On 4/17/06, Michael Schumacher wrote:

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.

I wonder if you have read this:
http://lists.freedesktop.org/archives/create/2006-March/000314.html ;-)

we have been discussing a gimptool-get which would be similar to debians apt for a very long while.

the same way that the web site redesign has been "in my head" and the tools sitting right on my computer, i think that this framework already exists in the minds of people who are currently working on gimp and still involved.

my idea is that these people should get this stuff off from their computers and get it working within the gimp project. then, since gimp is free and gpl, creative commons can get it, fix the problems and gpl and cc can start to work together again. or for the first time, i dunno.

we all have personal agendas. me included. i feel that a time of testing everyones little personal agendas for what will work and what will not work has been long enough for everyone to work it out for themselves.

creative commons was as bad to gimp as google was. not including gimp in things. i tried to discuss this with people involved there and all i got was some fuzzy blog things about creative commons not being a commune. i will be honest with anyone involved with that stuff, this is no way for projects to communicate or work together.

that being said, it is difficult to show anything while all this stuff sits on the developers computers and doesn't make it to the public.

blah, blah, blah...

carol

Hal V. Engel wrote:

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.

Bill Skaggs, who volunteered to be the organization administrator, has already written a draft of the application mail. We want Sven or Mitch to have a look at it before it is sent. There are also some other project proposals, which are supposed to be presented here this week.

Also, my proposal doesn't arrive out of the blue. It is the result of a discussion we had on IRC yesterday. Many of the more time-critical things are discussed there, so if anyone is interested to be up to date, lurking on channel #gimp on server irc.gimp.org can be useful.

HTH, Michael

eek! i am replying to my own reply! On Mon, Apr 17, 2006 at 12:18:26PM -0700, Carol Spears wrote:

On Mon, Apr 17, 2006 at 09:52:32PM +0400, Alexandre Prokoudine wrote:

On 4/17/06, Michael Schumacher wrote:

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.

I wonder if you have read this:
http://lists.freedesktop.org/archives/create/2006-March/000314.html ;-)

we have been discussing a gimptool-get which would be similar to debians apt for a very long while.

the same way that the web site redesign has been "in my head" and the tools sitting right on my computer, i think that this framework already exists in the minds of people who are currently working on gimp and still involved.

my idea is that these people should get this stuff off from their computers and get it working within the gimp project. then, since gimp is free and gpl, creative commons can get it, fix the problems and gpl and cc can start to work together again. or for the first time, i dunno.

we all have personal agendas. me included. i feel that a time of testing everyones little personal agendas for what will work and what will not work has been long enough for everyone to work it out for themselves.

creative commons was as bad to gimp as google was. not including gimp in things. i tried to discuss this with people involved there and all i got was some fuzzy blog things about creative commons not being a commune. i will be honest with anyone involved with that stuff, this is no way for projects to communicate or work together.

that being said, it is difficult to show anything while all this stuff sits on the developers computers and doesn't make it to the public.

news from the front:

manish singh (yosh on irc) has agreed to put his idea for the framework for gimptool-get into something that can be useful as a SoC project.

carol

On Apr 17, 2006, at 12:18 PM, Carol Spears wrote:

my idea is that these people should get this stuff off from their computers and get it working within the gimp project. then, since gimp
is free and gpl, creative commons can get it, fix the problems and gpl and cc can start to work together again. or for the first time, i dunno.

Creative Commons are not the only ones involved in that list. I can say for certain that at least Inkscape is tracking that, and working on implementing things directly.

Sometimes, though, getting things that can be shared is the trick. As those get worked out, more assets can be. Inkscape, for example, has been able to read *.gpl palette files for a while now. And I know at least one of the Scribus developers who follows that list and implements things that make sense.

Anyway, I just wanted to point out that other projects are following that list, and if anything is done that makes the gimp happy, then there are people out here trying to make sure that other things "play nice" with it.

On Monday 17 April 2006 04:58 pm, Michael Schumacher wrote:

Bill Skaggs, who volunteered to be the organization administrator,

^^^^^^^^^^^
/me smiles evilly!

has already written a draft of the application mail. We want Sven or Mitch to have a look at it before it is sent. There are also some other project proposals, which are supposed to be presented here this week.

HTH,
Michael

On 4/17/06, Michael Schumacher wrote:

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.

PHP is frowned upon, perhaps, but it's news to me that perl is frowned upon by many gimp developers, especially considering how much it's used in various little scripts in the gimp build process. At any rate, I say as long as it's reasonably portable and sufficiently scalable, why limit ourselves?

Rockwalrus

Alexandre Prokoudine wrote:

On 4/17/06, Michael Schumacher wrote:

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.

I wonder if you have read this:
http://lists.freedesktop.org/archives/create/2006-March/000314.html ;-)

Probably - I am subscribed to the create mailing list, but I didn't remember this particular message. Create was also mentioned in the discussion we had on IRC, but as one of the primary goals is to replace the registry which contains GIMP-specific stuff (I don't think any program except a GIMP derivate could use the plug-ins and scripts currently), only part of this effort may be useful for it.

However, if something like http://www.garshol.priv.no/download/xsa/ (or another format, as this seems to be unmaintained) is used as an interface, I don't see a reason why other applications shouldn't make use of it as well - we would already have to provide some things only to specific GIMP versions, and this requirement could be extended to "($version of) $app", "$fooapp, $barapp, ..." and so on. And if Create is successful, there wouldn't be a need to distuingish, even :)

Michael