Hi all, 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 > settings... > > 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. > > (snip) ...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 > > (snip) 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.. bye, --Mitch
