rdw89@ecs.soton.ac.uk (Williams RD) (05/31/91)
Here's a rather annoying feature of the new multibit icon definitions. It seems that it only occurs when using greyscales. Set the 'monitors' control panel to 256greys, then using the 'color' control panel change the highlight colour to a colour (rather than B/W or 'grey'). Everything appears ok - the colour (blue say) is represented by an equivalent greyscale. BUT the icl representation of icons becomes fundamentally unstable from then on - just opening the 'general' control panel (or anything else that allows you to change colours in some way) resets the icons on your screen to the standard 1 bit representation. You can temporarily correct this by reselecting 256 (or 16) greys from 'monitors' - but it just doesn't convince the computer permanently! Now I expect you're wondering why one would ever want to have anything other than 'grey' or B/W highlight on a greyscale monitor? Suppose the 'grey' highlight just isn't the shade you want, or you just switched to greys from a colour monitor. Anyway, why can't it cope with maintaining grey representation of colours?
franklin@snowball.ucdavis.edu (Paul Franklin) (06/09/91)
In article <7898@ecs.soton.ac.uk> rdw89@ecs.soton.ac.uk (Williams RD) writes: >Now I expect you're wondering why one would ever want to have anything >other than 'grey' or B/W highlight on a greyscale monitor? >Anyway, why can't it cope with maintaining grey representation of colours? I have experienced this problem several times, as I have a grey monitor. It can be triggered in many different ways, notably with ResEdit, which always succeeds to destroy any color table. Why doesn't Color QuickDraw force every color to its grey equivalent, and not let the color table change (I can display 256 of 256 possible greys, so it shouldn't have to). --Paul Franklin --pdfranklin@ucdavis.edu