Re: [Gimp-developer] Proposing projects for the Summer of Code
On Thu, 2005-06-02 at 18:41 +0200, Dave Neary wrote: Hi, There are lots of Summer project sized tasks around the GIMP that we could propose to Google. As a start: ... - Work on a framework to make plug-in settings saveable across sessions (this might be done now, is it?) Persistent parasites can easily be used for this. Parasites are not the ideal solution and I'm not sure how many plugins use them. - Reverse engineer PSD format for PS 10 and write the load/save plug-in (or adapt the existing one) to it There are only 2 significant supportable features of the psd format that we dont currently support. These are loading/saving of paths and saving of layer masks. All the information on the path format is semi-publicaly available (It shipped on the photoshop 6.0 CD). We already support loading layer masks, so supporting saving them will be no big deal. Every other feature of the psd file format would require things that gimp just does not support. Things like CMYK mode, adjustment layers, layer effects, layer sets, clipping groups, etc. (Any one of which is a major project) There is a new file format called psb (photoshop big?) that was first exposed in photoshop cs. It is only used for files that are larger than 30,000 pixels in one direction. I don't think you can get the documentation for this format without signing an NDA. I have no idea if it is simply a small revision to the psd format that corrects the size limitations, or if it is a tripple-des encrypted version of xcf. I have yet to run across one that I didn't create myself. Jay Cox [EMAIL PROTECTED] PS: I think you would need a time machine to get photoshop 10 by this summer :) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposing projects for the Summer of Code
Hi Jay, Jay Cox a écrit : On Thu, 2005-06-02 at 18:41 +0200, Dave Neary wrote: - Work on a framework to make plug-in settings saveable across sessions (this might be done now, is it?) Persistent parasites can easily be used for this. Parasites are not the ideal solution and I'm not sure how many plugins use them. Parasites are not an ideal solution for this. You would idieally want a GimpPluginSettings object which you can then save/load with gimp_plugin_settings_save|load(). The storage should be a file, or part of the existing gimprc file (given RML's talk on many small files, this might be better). Persistent parasites have a problem - either they're per session or per (image|drawable). If they're per session, then the next time you start up all your plug-ins have reverted to their defaults. If they're per image, then you have to change your defaults for each application. The main point to bear in mind is that this should be trivial for a plug-in author. PS: I think you would need a time machine to get photoshop 10 by this summer :) OK, so I've made enough of a fool of myself :) I'm not a Photoshop user, okay? Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposing projects for the Summer of Code
On Fri, 2005-06-03 at 09:18 +0200, Dave Neary wrote: Hi Jay, Jay Cox a écrit : On Thu, 2005-06-02 at 18:41 +0200, Dave Neary wrote: - Work on a framework to make plug-in settings saveable across sessions (this might be done now, is it?) Persistent parasites can easily be used for this. Parasites are not the ideal solution and I'm not sure how many plugins use them. Parasites are not an ideal solution for this. You would idieally want a GimpPluginSettings object which you can then save/load with gimp_plugin_settings_save|load(). The storage should be a file, or part of the existing gimprc file (given RML's talk on many small files, this might be better). Persistent parasites have a problem - either they're per session or per (image|drawable). If they're per session, then the next time you start up all your plug-ins have reverted to their defaults. If they're per image, then you have to change your defaults for each application. If you call gimp_parasite_attach() with a parasite that has the persistent flag set, it will be saved to the parasiterc file and reloaded the next time you start up gimp. I can't think of any plugins that actually do this though... The downside of parasites is that they are loaded at startup and are always in memory. The parasiterc has the potential to grow indefinitely. Jay Cox [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposing projects for the Summer of Code
On Fri, Jun 03, 2005 at 09:18:21AM +0200, Dave Neary wrote: Hi Jay, Jay Cox a ?crit : On Thu, 2005-06-02 at 18:41 +0200, Dave Neary wrote: - Work on a framework to make plug-in settings saveable across sessions (this might be done now, is it?) Persistent parasites can easily be used for this. Parasites are not the ideal solution and I'm not sure how many plugins use them. Parasites are not an ideal solution for this. You would idieally want a GimpPluginSettings object which you can then save/load with gimp_plugin_settings_save|load(). The storage should be a file, or part of the existing gimprc file (given RML's talk on many small files, this might be better). Persistent parasites have a problem - either they're per session or per (image|drawable). If they're per session, then the next time you start up all your plug-ins have reverted to their defaults. If they're per image, then you have to change your defaults for each application. There are also persistent parasites that can be attached to the app. This is how the png plugin stores its default settings currently. They are backed by gimpdir/parasiterc. The main point to bear in mind is that this should be trivial for a plug-in author. The most convenient way would be to handle it transparently, but I can't think of a way that doesn't involve larger infastructure changes. The hard part is a simple API that handles portable data serialization. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposing projects for the Summer of Code
Hi, Manish Singh a écrit : There are also persistent parasites that can be attached to the app. This is how the png plugin stores its default settings currently. They are backed by gimpdir/parasiterc. Jay pointed this out too. Thanks for the info. The main point to bear in mind is that this should be trivial for a plug-in author. The most convenient way would be to handle it transparently, but I can't think of a way that doesn't involve larger infastructure changes. It's a 3 month project, infrastructure changes are possible :) The hard part is a simple API that handles portable data serialization. We have that, don't we? At least, that was my understanding of the gimprc objects. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposing projects for the Summer of Code
On Fri, Jun 03, 2005 at 10:17:55AM +0200, Dave Neary wrote: Hi, Manish Singh a ?crit : There are also persistent parasites that can be attached to the app. This is how the png plugin stores its default settings currently. They are backed by gimpdir/parasiterc. Jay pointed this out too. Thanks for the info. The main point to bear in mind is that this should be trivial for a plug-in author. The most convenient way would be to handle it transparently, but I can't think of a way that doesn't involve larger infastructure changes. It's a 3 month project, infrastructure changes are possible :) Well, my thinking was a GimpPlugIn class, which a plugin derives from. The class implements the basic GUI itself, and UI elements are tied directly to PDB arguments. This sort of API shakeup is probably something that should happen along with GEGL integration, and would require a fair amount of discussion to nail the details down. So I dunno if that sort of job falls in the scope of the Google thing. The hard part is a simple API that handles portable data serialization. We have that, don't we? At least, that was my understanding of the gimprc objects. IIRC, gimpconfig needs an object that implements the GimpConfig interface, so it's not exactly *simple*. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Proposing projects for the Summer of Code
Hi, There are lots of Summer project sized tasks around the GIMP that we could propose to Google. As a start: - Add text boxes to the text tool - Write a heal tool and an intelligent eraser tool (sharing as much code as possible between them) - Work on a framework to make plug-in settings saveable across sessions (this might be done now, is it?) - Convert all the GIMP utility code to real GObject widgets, and then complete the Python binding for libgimp* - Design and write a shapes tool - Reverse engineer PSD format for PS 10 and write the load/save plug-in (or adapt the existing one) to it - Add save for web plug-in - (Re)write a plug-in distribution system which integrates with the GIMP There are lots more. I'm not sure what timetable Sven's working on for 2.4, but I believe we're almost at feature freeze, which means that people can start working on these projects, and integrate into CVS once 2.4.x comes out - project deadlines are September 1st, and we should have a release to integrate against by then. Some of these are small, and are probably only a week or two of work. Others will have trouble being finished after 3 months solid work. Should we make the proposals? Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposing projects for the Summer of Code
Dave Neary wrote: Should we make the proposals? Doing this means that somebody is going to have to invest quite substantial energy in evaluating candidates, defining a specific project, handholding during the project, and evaluating the results. The only people capable of doing this, realistically, are Sven and Mitch, or perhaps Pippin if it is a gegl-related project. So I think it is up to them to decide whether they have the time to commit. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposing projects for the Summer of Code
Dave Neary wrote: - Reverse engineer PSD format for PS 10 and write the load/save plug-in (or adapt the existing one) to it Photoshop is up to version ten now?? Bloody hell... and I remember when we felt all clever for figuring out some of the new PS4 PSD features... --adam -- Adam D. Moss - [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposing projects for the Summer of Code
Hi, Dave Neary wrote: - Reverse engineer PSD format for PS 10 and write the load/save plug-in (or adapt the existing one) to it Photoshop is up to version ten now?? Bloody hell... and I remember when we felt all clever for figuring out some of the new PS4 PSD features... I'm guessing I skipped a version - PS 8 CS or 9 seem to be the most recent. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
