RSS/Atom feed Twitter
Site is read-only, email is disabled

Proposing projects for the Summer of Code

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

11 of 12 messages available
Toggle history

Please log in to manage your subscriptions.

Proposing projects for the Summer of Code Dave Neary 02 Jun 18:41
  Proposing projects for the Summer of Code GSR - FR 02 Jun 20:17
  Proposing projects for the Summer of Code Adam D. Moss 02 Jun 23:24
  Proposing projects for the Summer of Code Jay Cox 03 Jun 08:36
   Proposing projects for the Summer of Code Dave Neary 03 Jun 09:18
    Proposing projects for the Summer of Code Jay Cox 03 Jun 10:01
Proposing projects for the Summer of Code William Skaggs 02 Jun 19:14
Proposing projects for the Summer of Code David Neary 03 Jun 00:43
20050603080530.GA26410@gimp... 07 Oct 20:23
  Proposing projects for the Summer of Code Dave Neary 03 Jun 10:17
   Proposing projects for the Summer of Code Manish Singh 03 Jun 10:53
    Proposing projects for the Summer of Code Sven Neumann 03 Jun 13:06
Dave Neary
2005-06-02 18:41:46 UTC (almost 19 years ago)

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.

William Skaggs
2005-06-02 19:14:41 UTC (almost 19 years ago)

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

GSR - FR
2005-06-02 20:17:27 UTC (almost 19 years ago)

Proposing projects for the Summer of Code

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

Adam D. Moss
2005-06-02 23:24:23 UTC (almost 19 years ago)

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

David Neary
2005-06-03 00:43:47 UTC (almost 19 years ago)

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.

Jay Cox
2005-06-03 08:36:20 UTC (almost 19 years ago)

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

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

Dave Neary
2005-06-03 09:18:21 UTC (almost 19 years ago)

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.

Jay Cox
2005-06-03 10:01:57 UTC (almost 19 years ago)

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

Dave Neary
2005-06-03 10:17:55 UTC (almost 19 years ago)

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

Manish Singh
2005-06-03 10:53:56 UTC (almost 19 years ago)

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

Sven Neumann
2005-06-03 13:06:44 UTC (almost 19 years ago)

Proposing projects for the Summer of Code

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