Angus Leeming wrote:
> On Thursday 22 August 2002 10:50 am, Rob Lahaye wrote:
>
>>Hi,
>>
>>Following inconsistency:
>>
>>(*) Preferences-dialog: Display graphics = "Grayscale"
>> Graphics-dialog: Display graphics = "Default"
>> Then my color image is in grayscale.
>>
>>(*) Preferences-dialog: Display graphics = [whatever].
>> Graphics-dialog: Display graphics = "Grayscale".
>> Then my color image is in color!!
>>
> What happens if you change your Preferences setting to [whatever] and then
> close, re-open your document with the "Grayscale" InsetGraphics?
>
> If the resulting image is in Grayscale, then it's that ol' Preferences
> setting that's not being propogated. Else the bug lies in InsetGraphicsParams.
Ah got it; a "break" missing in insetgraphicsParams.C:
switch (display) {
[...]
case InsetGraphicsParams::GRAYSCALE:
pars.display = grfx::GrayscaleDisplay;
=====> "break;" missing here
case InsetGraphicsParams::COLOR:
pars.display = grfx::ColorDisplay;
break;
So the "GRAYSCALE" falls immediately into the COLOR case!
Will add this to my upcoming patch to the new Graphics dialog!
>>-----------------------------------------------------
>>Why do we have the Display modes stored and saved in so many different
>>ways?
>>Can we get rid of at least two entries?
>>Any major objections for such an improvement?
>
> None whatsoever.
Let me try; my plan is following:
1) Have only one "Displaytype enum" in graphics/GraphicsTypes.h. I think that's
the place where this belongs. The enum is here encapsulated by "namespace grfx
{...}".
I'm not at all familiar with this namespace thing.
Don't know what's going to happen and how to solve that. We'll see.
Any hints in advance? Otherwise I'll come with questions soon.
2) I want to change the \display_graphics argument in preferences:
mono -> monochrome
gray -> grayscale
no -> none
so that they are the same as the one we use in the graphics inset.
Is that acceptable?
Regards,
Rob.
