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

Hi,
dneary@free.fr (2005-06-02 at 1841.46 +0200):

- Write a heal tool and an intelligent eraser tool (sharing as much code as possible between them)

Algorithm is out there. :]

- Reverse engineer PSD format for PS 10 and write the load/save plug-in (or adapt the existing one) to it

The same for brushes, even it it only manages to load the basic shape.

What is PS10, btw? PS7, PS CS (PS8), PS CS2 (PS9)... did I miss something?

And by extension:

- More control over brushes, like scalable pixmaps, run time control of pipe brushes...

GSR

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

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.

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 jaycox@gimp.org

PS: I think you would need a time machine to get photoshop 10 by this summer :)

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 jaycox@gimp.org

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 /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

Hi,

Manish Singh writes:

IIRC, gimpconfig needs an object that implements the GimpConfig interface, so it's not exactly *simple*.

The default implementation works just fine. So, assuming that you defined properties for what you want to save, it is as simple as adding

G_IMPLEMENT_INTERFACE (GIMP_TYPE_CONFIG, NULL)

to the get_type() function. This would be done by the base class of the settings object that a plug-in implements.

Sven