Contrast Redux

Posted on by James Cape

It appears I’m not entirely clear with my last post, specifically what I’m bitching about.

The black bolded text on the left is from the Nautilus File Management Preferences dialog, which uses GtkVBox and GtkHBox to simulate noborder frames. The grey bolded text on the right is from the FUSA preferences dialog, which uses a GtkFrame widget with it’s “shadow-type” property set to GTK_SHADOW_NONE.

That’s what I was referring to — though what brought the fury on was squinting to read a web page after I had already set a 200% zoom and the text was about 35 pixels tall.

Updates:

  1. Left = good, right = bad.
  2. If you can’t tell any difference between the two, try kicking your gamma up to something like 1.8 or 2.2 (xgamma -g 1.8). Since most people have gamma configured incorrectly, most people won’t notice any difference.
  3. I’m actually making a secondary point here as well: you cannot reliably set a widget-group label’s style in a gtkrc at present, so it is better not to try. Further, people do lots of silly things — an acquaintance of mine was starting a GTK+ UI to upload jobs to an S/390 mainframe over FTP, but didn’t immediately grasp the box model, and resorted to trying to do everything in a big GtkFixed. This could be simply the mentally destructive results of using VisualBasic, but when last I heard he was planning on doing it in Java instead (like I said, silly). 🙂

8 thoughts on “Contrast Redux”

  1. I still don’t get it. The Nautilus example appears to have more contrast than the grey on brown, FUSA example.

  2. OK, the update makes it clear, finally 🙂 What confused me was:

    “Notable offenders include a lot of GTK+ themes (the GtkFrame’s label widget rules—which doesn’t work where a V/HBox pair is used to group widgets, like Nautilus’ File Management Preferences dialog)”

    From your original post. Until I reread it several times, makes it sound like Nautilus was at fault.

  3. Using xgamma -g 1.8 (or 2.2) doesn’t set the gamma on screen to 1.8 or 2.2 though, it applies that value as a correction.

    If I follow the Monitor Calibration link you supply, I need to set a correction of 0.8 to get 1.8, and 0.7 to set it at 2.2.

  4. Oh, also the dotted pattern like that isn’t a good idea on CRTs. It should be solid horizontal lines, alternating between colour and black. I just checked with it at 640×480 and I need a correction of 1.0 for 2.2 (the default) and 1.1 to get 1.8…

  5. Ahhh… forgetting the contrast thing per se, this may have cleared something up for my poor brain. I had wondered and wondered why certain apps (GnomeSword for instance) have some bold labels in dialogs which appeared black, and others which appeared grey. I now suspect that it is to do with the shadow-type property. Some UI rework is obviously required in these apps.

  6. Pingback: the Jumpgate » Contrast, UIs, a camera, and resurrection

  7. Ahh yes, you are correct. I’m an idiot, I guess 🙂

  8. Actually, the problem is the theme is trying to do something that GTK+ almost (but not quite) handles.

    Basically, in the theme’s gtkrc file, they’ve got a line that says:

    widget_class “*.GtkFrame.GtkLabel” style “make_label_grey”

    Unfortunately, not all widget groups are layed out using GtkFrame (it’s actually easier to get the spacing perfect if you don’t use a GtkFrame, unfortunately), so not all “widget group titles” use the “make_label_grey” style information — and thus stay regular black.

    In this case, the fault is the directly the theme’s for trying to do something that isn’t possible, and indirectly GTK+’s for not making it possible.

Comments are closed.