Re: Project proposal: Resource contribution, distribution and management system (was: Re: [Gimp-developer] Google Summer of Code 2006, to whom it may concern)
On 4/17/06, Michael Schumacher <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: Project proposal: Resource contribution, distribution and management system (was: Re: [Gimp-developer] Google Summer of Code 2006, to whom it may concern)
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.___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: Project proposal: Resource contribution, distribution and management system (was: Re: [Gimp-developer] Google Summer of Code 2006, to whom it may concern)
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: Project proposal: Resource contribution, distribution and management system (was: Re: [Gimp-developer] Google Summer of Code 2006, to whom it may concern)
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: Project proposal: Resource contribution, distribution and management system (was: Re: [Gimp-developer] Google Summer of Code 2006, to whom it may concern)
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. > > Howev
Re: Project proposal: Resource contribution, distribution and management system (was: Re: [Gimp-developer] Google Summer of Code 2006, to whom it may concern)
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Project proposal: Resource contribution, distribution and management system (was: Re: [Gimp-developer] Google Summer of Code 2006, to whom it may concern)
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
