Re: GTK-xemacs transparency patch
Valdis.Kletnieks(a)vt.edu writes:
On Mon, 11 Feb 2002 21:38:57 +0100, Cristalle Azundris Sabon said:
> Personally, I've found that moving the scrollbars outwards till
> they touch the borders (provided by the window manager), leaving
> no padding between those borders and the scrollbars.
Umm.. huh? This didn't parse very well?
Okay, I put a shot up at
http://www.azundris.com/hacks/themes/scrollbar.png
You will notice a setup like this:
XXXXXXXXXXXO.|
XXXXXXXXXXXO.|
XXXXXXXXXXXO.|
|||+-- border provided by window manager (black)
||+--- "padding" (anthra)
|+---- vertical scrollbar (anthra)
+----- text area (blue)
Since the window resizes in char cells and the scrollbar's width
is not a multiple of a char cell's width, there is a delta, or
modulo:
char_width - (scrollbar_width mod char_width)
This is the padding in the right (it also occurs on the bottom).
Since we -- urks. I just noticed that sentence left off in the
middle. It was supposed to read something like:
"Personally, I've found that moving the scrollbars outwards till
they touch the borders (provided by the window manager), leaving
no padding between those borders and the scrollbars, is almost
necessary for the transparency to look like people would expect
it to."
> This is necessary if the window is resized in multiples of
> characters rather than pixels, and the scrollbar's with is
> not a multiple of a char's width (same for height).
What about proportional-spaced fonts?
I guess I'll leave that one for my elders and betters to answer. : )
I'd think it'd still work with nominal (or average) cells.
The code indicates that xemacs would also handle windows that
resize in pixels, but I don't find that terribly desirable
whole and large.
regards,
Azundris