[subsurface] Prettier profile colors (#89)

Dirk Hohndel dirk at hohndel.org
Mon Nov 28 13:42:40 PST 2011

On Mon, 28 Nov 2011 22:24:48 +0100, Henrik Brautaset Aronsen <subsurface at henrik.synth.no> wrote:
> On 28.11.11 21:29, Dirk Hohndel wrote:
> > On Mon, 28 Nov 2011 12:01:22 -0800, Linus Torvalds<torvalds at linux-foundation.org>  wrote:
> >> First off, the new background color is some kind of very light beige,
> >> which is neutral and fairly pleasing, but the new thin white gridlines
> >> are really hard to see. I bet it depends on just how contrasty the
> >> monitor settings are, but and for me it's kind of borderline usable,
> >> but it's borderline enough that I worry. The yellow warning markers
> >> are also much less visible.
> > I tried this on three different systems with different monitors. Haven't
> > found one where the gridlines work. The warning markers on the other
> > hand are now a bit less obnoxious - that I'm fine with :-)
> I guess the grid color should be more visible.  Not too much, though, it 
> was really too verbose in the previous version.

Not sure you have broad agreement on that statement :-)

> >> I like the new water fill colorization, though.
> > Me too, but if we do the 'darker blue as we go deeper' thing, then that
> > should be on a fixed scale - i.e. the deepest blue that you get should
> > be proportional to the deepest depth that is displayed ramble ramble ramble
> Yikes, what have I started? :)

ramble ramble ramble.

PAH. That would be /really/cool/ !!!

> >> Yes. Also, you still do three lookup tables right now for no good
> >> reason. Why don't you have one table that matches a color name into rgba
> >> for screen and rgb for print. And then have one table with the color_t
> >> enum as index into it that matches the different values to a color. And
> >> then simply use the color_t values to index into that one table.
> Well, I didn't remove the sac_color and velocity_color tables since they 
> where dependent on calculated index numbers.  Wouldn't want to mess up 
> more code in this commit.

Understood - but that's the next thing you should do. Remember, you can
do math with enums, so you can simply change the sac and velocity index
calculations to add the base index of the first correspondong enum. 
Should be straight forward.

> >> Finally: maybe you should make the "rgb_t" a "rgba_t". Now you have
> >> that odd "we have indexes to the color table, and then we have a
> >> separate alpha channel value". But who knows. I don't have a very
> >> strong opinion on this part.
> > I think if we go this direction we really want just one table with rgba
> > for screen and then rgb for print. After all the goal is to make things
> > more simple, right?
> Good thinking.
> I was planning to work some more on the patch tonight, but I cannot get 
> anything to build at home right now.   Worked like a charm at work.  
> Bah.  Feel free to fix my mess if you want :)

I doubt I'll get to that today - I'm playing around with more changes
for the Mac version to look more "Mac like" :-)


More information about the subsurface mailing list