GNOME Bugzilla – Bug 158012
"Use theme colors for content" glitch
Last modified: 2007-02-12 15:17:36 UTC
(I'm not sure if this is as it was intended or not, but it's not what I expected, and this feature isn't documented at all, so it's impossible to tell.) 1. (I have my Gtk+ theme to black text on white background. This weirdness probably exists for all themes, but if you want to follow along with my colors, use black-on-white.) 2. Try to print-preview something that uses: - pink text -- gnome_print_setrgbcolor(pc, 1.0, 0.5, 0.5) - a pink stroked polygon -- gnome_print_stroke() - a pink filled polygon -- gnome_print_fill() Result: This works fine: the text, empty polygon, and filled polygon are all pink. 3. Check the "Use theme colors for content" box Result: The text and stroked polygon turn black, but the filled polygon turns a very faint gray, almost white. Strange. Expected: Filled polygons that are the same color as empty polygons and text with the checkbox off, should be the same color with the checkbox on. I don't think this feature/checkbox should exist at all, but if it does, it should behave as expected. And if it doesn't behave as expected, it should be documented as to what and why. So I would consider any one of "removing it", "fixing it", or "well documenting it" as resolving this bug in my mind (though simply documenting the current behavior it is the least optimal).
The purpose of that "use theme colors fo content" is there solely for accessibility. Some users apparently require the ability to switch to their theme colours. If you use your theme as screen gravy, do not check that check box. Of course you will not want to see it that way. Which colours the various items become has to do with the exact definitions of your theme. "Black text on white background" is only one little part of the theme specifications. All filled polygons will be the same single colour.
Ugh. Please don't close this bug. I know the checkbox is for accessability. (I don't know what "screen gravy" is.) I know all filled polygons are the same single color -- that was part of my bug report. It's *which* color that baffles me. I'm a developer. I want my program to be accessible. As it is now, when you check this checkbox, parts of the preview disappear. I don't think anybody wants that in a print-preview, especially people who will be using this checkbox in the first place. In Gnumeric, for example, this causes the arrowheads to disappear when this is checked. Surely this isn't by design! "NOTABUG" is defined as "The problem described is not actually a bug, but a design choice of some sort". I admitted that the current behavior *might* be by design, but if so, it needs to be documented. Or are you saying the absense of documentation is also a design choice? ... I finally broke down and read the libgnomeprintui source code. I see that it uses style->bg for fills. Maybe that's the right thing for it to do. But developers need to know this -- and making them read the source code doesn't count. Suggested fix: to the gnome_print_fill() and gnome-print-preview APIs, add a note such as: "In the Print Preview window, if the 'Use theme colors for content' box is checked, filled polygons are drawn with the Gtk+ theme's 'bg' color, which may be very faint. If a solid polygon needs to be visible, you should both fill() and stroke() it." If we want developers writing accessible programs, we should do everything possible to make it easy for them to do so.
The behaviour is exactly what the accessibility people wanted. I was arguing against the checkbox because I thought the behaviour is ridiculous but was persuaded that no, while it may look strange it is exactly what is needed. So either that is correct or not. If there is documentation needed, then it should be: "As a developer, do not ever look at how the preview looks like with that checkbox on."
This is news to me. I don't understand why having parts of the print-preview simply disappear is desireable, or even acceptable. Or why developers should be in the dark about what the people using their program actually see. But that's not the real problem here. The current behavior is different from what Bill Haneman said it should be in comment 54 of #96802, and summarized by you in comment 55, and confirmed by him in comment 56 -- he said that filled shapes should be drawn as fg_gc outlines with bg_gc filling. Bill Haneman appears to be the technical lead for the Gnome Accessibility Project, so I'd say that drawing filled shapes as outlines would be "exactly what the accessibility people wanted". So the real question is: After the accessibility people came up with a spec, why was it not implemented? Perhaps the correct thing to do now is to mark this bug a dupe of #96802, and re-open #96802.
*** This bug has been marked as a duplicate of 96802 ***
Reopening. 96802 has gotten no comments for 10 days, and a bug sitting closed for more than 10 days is never going to get looked at again. It should be open until fixed, not closed until somebody from the accessibility team gets around to re-testing old patches (but I don't have the power to re-open that bug). It's pretty easy to see that Bill's spec in bug 96802, comment 54 (and nicely summarized in comment 55) hasn't been fully implemented: - Look at comment 54 and comment 55, and note what styles his spec calls for: text, base, fg, bg. - Click on the final patch, press ctrl-F, and search for "style->". Now look at all the styles actually used: base, text, white, black, bg. Note the 'fg' style is never used. If you dupe this to bug 96802, then re-open 96802: this is not a dupe of a 'FIXED' bug, and marking it as such is incorrect. I don't want this bug to get lost. Thanks.
Created attachment 34080 [details] [review] Use 'fg' style as outline for filled shapes Simple patch to use 'fg' style for outline of filled shapes, as required by Bill Haneman's spec in comment 54 of bug 96802.
Commited this so we can get some comments :-)