Tomas Ogren wrote:
> install_cmap works.. min_colors(256) which the docs used to say doesn't
> work (except for cvs gtk+). As long as Gimp depends on the unreleased
> 1.2.8 or truncates the min_colors setting from gimprc to max 6*6*6,
> there shouldn't be a problem AFAIK. I don't really know how the plugins
> are supposed to find gimp-core's colormap other than using the same
> I'd like to keep install_cmap ... so you can keep the default colormap
> "free" if you want..
Ok, I've hacked some code (will be in cvs as soon as I found an annoying
crash it causes...) which replaces the color_cube with a min_colors variable.
The main app now parses gimprc before showing the splash and both
min_colors and install_cmap are told to GdkRGB before it's initialized.
This part works fine on my linux box at home in all modes and I don't see
any reason why it should break with other visuals...
Raphael Quinet wrote:
> IMHO, telling the plugins if the Gimp app has installed a colormap
> will not help much (as long as our goal is to reduce colormap flashing
> between the app and the plugins) because if the app did install a
> colormap, you cannot be sure that the plugins will use exactly the
> same one. This is even more tricky when the app uses a non-default X
> visual, because some plugins do not choose the same visual.
...while the plugin thing is a bit more complicated.
The code I currently use passes gimprc's min_colors and install_cmap
settings to the plugin. The plugin does exactly the same as the app
and it seems to work.
BTW, I found that GdkRGB seems to be designed with cross application
colormap consistency in mind, because it does the right thing if I
(a) set install_cmap to FALSE. In this case my gnome-only desktop
with it's dozens on GdkRGB instances shares a uniform colormap with
no flashing at all even if I set min_colors to 216.
If I (b) set install_cmap to TRUE there of course is flashing between
the gimp and the rest of the desktop, but all gimp plugins which use
gimp_ui_init() choose the same set of colors for their colormap.
(Resulting in flashing between identical or at least very similar
colormaps which looks quite ok).
> Until recently, there was a problem with some plug-ins such as
> "Filters/Map/Map Object" and "Filters/Light Effects/Lighting Effects"
> which did not use the same method as the main app for selecting the
> visual and colormap. As a result, these plugins were starting with
> the PseudoColor visual, which gave some ugly colormap flashing and
> reduced the quality of the previews.
> Well, unfortunately the problem is even worse with 1.1.20: I just
> tried these two plug-ins in order to check if they got better with the
> new code, but they crash. Most plugins work fine, but the two
> mentioned above crash shortly after opening their window. The crash
> seems to happen when they try to display the preview, and generates
> the following error:
> Gdk-ERROR **: BadMatch (invalid parameter attributes)
> serial 653 error_code 8 request_code 72 minor_code 0
So this behaviour described by Raphael is the last remaining obstacle
I see. Maybe we should just let these plugins do their stuff by simply
not using gimp_ui_init().
A proper solution would of course be to eliminate plug-ins/libgck/* (which
is the library the plugins use for their previews) but unles someone
volunteers we will have to live with their colormap flashing.
And _please_ correct me if this is not true.
And BTW, do I have to increase the GimpProtocol version number if I change
the GPConfig message? hm..