Hello everyone,

I was told that I should write here if I'd like to help on the rewrite for the colormap editor and since I've got more time now, it's a good new starting point to do something useful ;)

So I thought using GimpViewRendererPalette as a basis would be okay, since I realized that a colormap and a palette are not exchangable for performance reasons?!

Regards, Olof

Sven Neumann wrote:

Well, I thought the lookup for indexed images wouldn't be that good if it goes through a list of colors like in GimpPalette.

I don't see how that could be related to changes in the colormap editor.

Because it prohibits the use of a palette instead of a colormap (directly), at least thats what i thought.

And my plan is to use GimpViewRendererPalette and make a GimpViewRendererColormap from it so that both editors would mostly look the same.

Having both editors share some code is a good idea indeed. One way to do that would be to create an internal GimpPalette object from the colormap and to actually use the palette editor. Changes to the palette would then have to be reflected in changes to the colormap and vice versa.

So either that or only use the surroundings and write the renderer specific to colormaps (which shouldn't be too hard, since it's only exchanging iteration through the list of entries for the palette by iterating through the entries of the colormap).

This would be a little bit ugly though. Perhaps with some more refactoring, a cleaner solution can be found.

Sven Neumann wrote:

next time, please reply to the list instead of only responding to my email address. We should keep this discussion on the list.

I hope this time my client does the right thing, *grr*

This would be a little bit ugly though. Perhaps with some more refactoring, a cleaner solution can be found.

One thing what could be done is representing the current colormap as a palette and therefore as a entry in the list of palettes. That would be quite similiar to the four internal gradients, only that it requires a bit more support (the colormap has no named entries, reflecting the changes on the palette to the actual colormap for the image, and so on). The colormap editor wouldn't be necessary anymore. I'd think this is useful because it eliminates one additional dialog and fits more with the rest of the palette system, plus maybe other "special" palettes could be implemented.

Regards, Olof

Sven Neumann wrote:

I am not sure if merging colormaps and palettes is going to help to avoid the confusion that already exists between the two. And as far as I can see the Colormap editor has a very different use case than the Palette editor. So it seems to need a different user interface as well.

I really don't think the use case is that different even if I don't use it something near to often. At least it would be easier to manage.

Anyway, to get some feedback a (big) patch is attached that reimplements the colormap editor using a GimpViewPalette:

- It's not really cleaned up yet, but I'll do that as soon as possible,

- mostly a rewrite based on the implementation in gimppaletteeditor.c

- zooming like in the palette editor is not implemented (mainly because I think it should be common to both (and also other?) editors and I didn't have time for it yet; also it looks not that bad now),

- saving and loading of colormaps should be easy to add (but then, how should that be done? either truncating the palette if it's to big or simply resize the colormap? I'm not quite sure how it's supposed to behave),

- ...

So, I hope you can comment on it :)

Regards, Olof