Re: GTK-xemacs transparency patch

William M. Perry writes: Good point. While the code seems stable, it likely has the air of a proof of concept in some respects of the implementation: Yes. Since it seemed to work with any combo of font-size, gutter, toolbar and menu, I tried to fix other things first. These offsets should go in the not too distant future, though. There's a method that works for me: use a monochromatic backdrop. Not a picture, or anything with notable contrast, but something that adds just a hint of structure, like certain sorts of paper do. (I think some studies say that's actually ergonomic -- for whatever they're worth.) Also, if the backdrop can be tinted or dimmed (smoked glass anyone?), the contrast-issue becomes a little less significant, enabling a wider choice of backdrops. (I'm seriously considering adding such a feature when I find the time. I guess it's more or less expected these days.) I think for most people, it will be an all-or-nothing deal, anyway. The only reason I didn't make it a single variable (yet) is that this makes it easier for me to spot tabs in space- formatted texts and vice versa. Without that, it would probably neatly collapse into a single variable ("gtk-transparency", 0..100 %, or better still, "gtk-tint" '(50 100 200) with the list denothing "half-bright" red, unchanged green and enhanced blue values for the backdrop, hopefully to be used with saner values in the Real World) as this would allow the (lisp-) interface to remain consistent as features are added. Can't say, will look into it. At least if I can figure out enough of the existing xemacs code in a half-way reasonable while. ; ) I will be away for the weekend, but hope to submit a cleared up patch next week. Thankyou for your time and quick response, and have a nice weekend! Azundris -- www.azundris.com