I think I've narrowed down the cause of this problem a little more.

I believe it is triggered by upgrades of kdebase (which contains kcontrol,
the KDE Control Center) to 4:3.5.4-1 or later.  The changelog for that
release contains the following entry:

  * New upstream release:
    + fixes setting of the xrdb resource Xft.antialias to always match what's
      configured in the control center, not in ~/.qt/qtrc. (Closes: #377147)

(Incidentally, #377147 was filed by me.)

I used Sergey's workaround successfully, but took snapshots of my .kde
directory at several steps to see if I could narrow down the issue.

1) DOT-KDE-2006.08.13.20.51.45.begin
2) DOT-KDE-2006.08.13.20.52.29.anti-aliasing-disabled
3) DOT-KDE-2006.08.13.20.54.29.anti-aliasing-disabled-re-logged-in
4) DOT-KDE-2006.08.13.20.55.02.anti-aliasing-re-enabled
5) DOT-KDE-2006.08.13.20.56.33.anti-aliasing-re-enabled-re-logged-in

The file of interest appears to be .kde/share/config/kdeglobals.  Here's a
diff of this file between steps 1) and 4):

--- DOT-KDE-2006.08.13.20.51.45.begin/share/config/kdeglobals   2006-08-13 
20:46:47.000000000 -0400
+++ 
DOT-KDE-2006.08.13.20.55.02.anti-aliasing-re-enabled/share/config/kdeglobals    
    2006-08-13 20:54:56.000000000 -0400
@@ -21,8 +21,9 @@
 History 
Items=file://$HOME/packages/xorg-x11/svn/branches/7.1,file://$HOME/packages/xorg-x11/svn/trunk
 
 [General]
+XftAntialias=true
 XftHintStyle=hintmedium
-XftSubPixel=
+XftSubPixel=none
 alternateBackground=238,246,255
 background=238,238,230
 buttonBackground=238,234,222

I don't know very much about how the kdeglobals file works; for instance,
if a parameter is unspecified, is a default value "inherited" from
anywhere?

At any rate, my principle of least surprise was violated.  In my case, when
I first opened kcontrol after upgrading to 4:3.5.4-2 (step 1, above), the
anti-alias box was checked, indicating that anti-aliasing was "on", despite
the lack of an "XftAntialias" line in my kdeglobals.

Unfortunately, I did not get to learn if and how the user's kdeglobals file
would be updated if kcontrol were not launched.

Would it make sense for kdebase to assume anti-aliasing is on in the
absence of an XftAntialias parameter setting in kdeglobals?

(Imagine me looking beseechingly at Chrisopher Martin here.)

Eric, I won't reassign this bug to kdebase for you, but I personally am
persuaded that it should be.

-- 
G. Branden Robinson                |    There's a fine line between
Debian GNU/Linux                   |    painting yourself into a corner and
[EMAIL PROTECTED]                 |    re-engineering the universe.
http://people.debian.org/~branden/ |    -- Glen R. Smith

Attachment: signature.asc
Description: Digital signature

Reply via email to