At 04:40 PM 12/24/2003 +0100, you wrote:

Here's the list of names on the Friends of GIMP list at the momenta

What is supposed to be the point of such a list? If you pulled names from a changelog you are probably making a list of the more active developers of the GIMP who are probably already on the gimp-devel mailing list.

Cheers!

Kevin. (http://www.interlog.com/~kcozens/)

Owner of Elecraft K2 #2172 |"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:ve3syb@ve3yra.#con.on.ca.na| Try to assimilate the world!" #include | -Pinkutus & the Borg

On Wed, 24 Dec 2003 16:40:14 +0100 David Neary wrote:

Here's the list of names on the Friends of GIMP list

Jay Cox

Chris Lahey

Only 18 friends?

Does the Gimp need more friends?

Or does the "Friends of Gimp" have some other meaning that we newbies do not understand?

Owen

Hi Dave,

David Neary writes:

Here's the list of names on the Friends of GIMP list

Please excuse my ignorance, but would you mind to explain the purpose of this list again? I still do not understand how you want to use this collection of email addresses for.

Sven

Hi,

Quoting Kevin Cozens:

What is supposed to be the point of such a list? If you pulled names from a changelog you are probably making a list of the more active developers of the GIMP who are probably already on the gimp-devel mailing list.

A couple of people asked this question - I thought I'd explained the idea pretty well, but I guess I missed the mark.

The list is a list of people who were active in the project several years ago, but who have gone on to other things. It would be nice to get some of them back working on the GIMP, if they have the time. So this is a little effort on our part (on my part) to communicate better with some people who are likely to be interested in what's happening with the gimp. The list is pretty incomplete, as Daniel Egger says, that's why I sent it here to get more suggestions. And as you say, some of these people are still on the developers list.

Basically, the two groups where we can hope to get volunteers are people who have already helped with the gimp, and people who have never done so. The problem with the latter group is that they don't have the accumulated knowledge of experience, and we don't know who they are. The former group are both experienced, and known. Therefore, they're easier to get in touch with :)

So - that's the idea. Any additions to the list are graciously accepted.

Cheers, Dave.

From: Dave Neary

A couple of people asked this question - I thought I'd explained the idea pretty well, but I guess I missed the mark.

Gone with the wind?
How about changing the title of the list to "retired GIMP coders"? Then everyone would know what you really mean.

Sooo... who would like to go through the list and ask if they would have time to work with GIMP? Ask their employers if they would sponsor GIMP project by allowing the people work on GIMP a few hours a week?

Note the "coders" in the new title. The list excludes all those who have contributed great ideas to the list, but who have not coded.

If you really look for volunteers, then here I am. Anyone coder would like to implement with me an alternative selection tool (as existing tool seems to be practically unusable)? For the start...

Regards, Juhana

Hi,

Juhana Sadeharju writes:

If you really look for volunteers, then here I am. Anyone coder would like to implement with me an alternative selection tool (as existing tool seems to be practically unusable)?

GIMP has a bunch of selection tools and they seem to work quite well for a lot of people. I think I know what problems you are refering to but it would help the discussion if you could specify which selection tools you are talking about and how they could be improved.

Sven

Hi,

Dave Neary writes:

The list is a list of people who were active in the project several years ago, but who have gone on to other things. It would be nice to get some of them back working on the GIMP, if they have the time.

IMO everyone should be free to leave the project at any time. These people decided that they don't want to actively contribute any longer or they had other reasons that keep them from contributing. I don't think it makes sense to try to bring them back in this way.

Instead we should focus on new developers. People who aren't busy with other things and who will bring in some new ideas. So we need to make the code more attractive to hack on. We need to document it better, we need to explain and discuss changes on this list. If we succeed to attract some new developers this way, perhaps we can also get some of the old coders back to work on The GIMP. However I don't think the latter should be of any priority.

this is a little effort on our part (on my part) to communicate better with some people who are likely to be interested in what's happening with the gimp. The list is pretty incomplete, as Daniel Egger says, that's why I sent it here to get more suggestions. And as you say, some of these people are still on the developers list.

IMO you should better spend that effort on communicating this to everyone out there. Look at it, would you start coding on a project that you left years ago just because someone sends you a mail? This plan looks a lot like wasted effort to me.

Basically, the two groups where we can hope to get volunteers are people who have already helped with the gimp, and people who have never done so. The problem with the latter group is that they don't have the accumulated knowledge of experience.

It's not that many of the people on your list have experience with the current GIMP code. Not much is left from the old days. A lot of things changed and I would find it rather dangerous to get the same people back on the code that wrote it originally. They might assume that the code still works the way it used to work five years ago.

Sven

On Wed, 31 Dec 2003, david gowers wrote:

in the realm of 'discussion', does anyone here know why GimpPalette is implemented using a list? it seems a lot saner to use an array. i would like to convert it to use an array if possible, as it would simplify future enhancements, and hopefully remove the need for the 'position' attribute.

Lists are more flexible structures than arrays! I don't remember where is the "position" attribute, anyway I'll be happy if palettes were sorted not only by name and the often used ones can be moved in a sort of "favorite" section. ;)

Happy new year, Marco

Hi,

david gowers writes:

my involvement has been impeded by these things:

- lack of documentation (hard to find my way around the gimp sourcetree without general guides as to what goes where (where to find/add a particular feature.)

http://developer.gimp.org/api/1.3/app/ is the best we can offer you at the moment. At least you don't have to dig around in several hundreds files living in the same directory without any clear dependencies. The new source code structure should be a lot easier to understand and it has definitely become easier to work on one area w/o the risk of breaking unrelated stuff. This was almost impossible with the 1.2 code base.

You should also have a look at devel-docs/structure.xml. This document is a first draft of an explanation of the GIMP source code structure. I haven't got around to finish it yet but perhaps it can be helpful already.

- lack of knowledge of general 'modus operandi'. for example, i have a whole directory just for enhancement ideas. they are all practical in the sense i know how to implement them in general. i don't know whether to add them to bugzilla, because i don't know what the policy is for enhancement requests.

The policy is that you are supposed to add your enhancement requests to Bugzilla with severity set to "enhancement". Please check for similar reports before you create a new one. Duplicate reports cause us a lot of unneeded maintainance work.

in the realm of 'discussion', does anyone here know why GimpPalette is implemented using a list? it seems a lot saner to use an array.

Probably because manipulating an array is a lot more cumbersome than using a list, in particular if you want to insert/remove and reorder entries. I don't see how a simple array would be saner but I didn't look into the details of GimpPalette lately. Perhaps a GArray might be a reasonable alternative?

i would like to convert it to use an array if possible, as it would simplify future enhancements, and hopefully remove the need for the 'position' attribute.

Could you outline how this would simplify future enhancements?

Sven

Hi,

Marco Lamberto writes:

I'll be happy if palettes were sorted not only by name

Are you refering to how the list of palettes is sorted or to the order of the colors in the palette?

Sven

PS: http://adrian.gimp.org/sortpal/

On 31 Dec 2003, Sven Neumann wrote:

I'll be happy if palettes were sorted not only by name

Are you refering to how the list of palettes is sorted or to the order of the colors in the palette?

The list of palettes. ;)

At 07:57 PM 12/31/2003 -0500, david gowers wrote:

in the realm of 'discussion', does anyone here know why GimpPalette is implemented using a list? it seems a lot saner to use an array.

Just as a guess, if you mean 'linked list' by 'list', then its probably to avoid the headaches created by using a fixed array to hold an indeterminate amount of information (ie. an unknown number of palettes).

Cheers!

Kevin. (http://www.interlog.com/~kcozens/)

Owner of Elecraft K2 #2172 |"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:ve3syb@ve3yra.#con.on.ca.na| Try to assimilate the world!" #include | -Pinkutus & the Borg

i definitely want to get more involved with gimp development. (at the moment, i would most like to upgrade the palette-editor to match or exceed a general palette editor i wrote previously.)

my involvement has been impeded by these things: - lack of documentation (hard to find my way around the gimp sourcetree without general guides as to what goes where (where to find/add a particular feature.)

- lack of knowledge of general 'modus operandi'. for example, i have a whole directory just for enhancement ideas. they are all practical in the sense i know how to implement them in general. i don't know whether to add them to bugzilla, because i don't know what the policy is for enhancement requests.
how far in the future can they be? (eg. a few enhancement ideas i have would rely on gegl's colorspace transformation system)

in the realm of 'discussion', does anyone here know why GimpPalette is implemented using a list? it seems a lot saner to use an array. i would like to convert it to use an array if possible, as it would simplify future enhancements, and hopefully remove the need for the 'position' attribute.

--
david gowers

Just to change the subject ..

-- - Jean-Luc

Le 02.01.2004 03:02, david gowers a écrit :

kevin:
you misunderstood.
it makes sense to store the Palettes as a list.. but not the contents of the palettes. what i meant was that each GimpPalette has a GList of GimpPaletteEntries.

GArray-based allocation would be one way to optimize memory allocation, which

is currently unnecessarily inefficient(2 mallocs per each palette entry?!.) and slows the palette editing down significantly for large palettes (>256). it may be able to eliminate the 'position' attribute for each palette entry, which as noted in gimppalette.h is EEK*.

next best would be allocating the GimpPaletteEntries using a GMemChunk while ordering them using the current GList arrangements. this appears straightforward and i could probably make a patch for it easily.

* and appears to be because there is a widget for each color in the gimp palette editor, rather than a single widget for the entire grid. which i don't see a good rationale for either. maybe its just a hack that avoids having to calculate which color was clicked on using the realized widget dimensions.

---
david gowers

david gowers writes:

kevin:
you misunderstood.
it makes sense to store the Palettes as a list.. but not the contents of the palettes. what i meant was that each GimpPalette has a GList of GimpPaletteEntries.

GArray-based allocation would be one way to optimize memory allocation, which is currently unnecessarily inefficient(2 mallocs per each palette entry?!.) and slows the palette editing down significantly for large palettes (>256). it may be able to eliminate the 'position' attribute for each palette entry, which as noted in gimppalette.h is EEK*.

next best would be allocating the GimpPaletteEntries using a GMemChunk while ordering them using the current GList arrangements. this appears straightforward and i could probably make a patch for it easily.

* and appears to be because there is a widget for each color in the gimp palette editor, rather than a single widget for the entire grid. which i don't see a good rationale for either. maybe its just a hack that avoids having to calculate which color was clicked on using the realized widget dimensions.

It appears you didn't even look at the code before claiming that each palette color has its own widget.

ciao, --mitch

kevin:
you misunderstood.
it makes sense to store the Palettes as a list.. but not the contents of the palettes. what i meant was that each GimpPalette has a GList of GimpPaletteEntries.

GArray-based allocation would be one way to optimize memory allocation, which is currently unnecessarily inefficient(2 mallocs per each palette entry?!.) and slows the palette editing down significantly for large palettes (>256). it may be able to eliminate the 'position' attribute for each palette entry, which as noted in gimppalette.h is EEK*.

next best would be allocating the GimpPaletteEntries using a GMemChunk while ordering them using the current GList arrangements. this appears straightforward and i could probably make a patch for it easily.

* and appears to be because there is a widget for each color in the gimp palette editor, rather than a single widget for the entire grid. which i don't see a good rationale for either. maybe its just a hack that avoids having to calculate which color was clicked on using the realized widget dimensions.

---
david gowers