After upgrading to Lucid Lynx I found that all Qt based applications would not have anti-aliased fonts anymore. For example Skype would look awful with these pixelated fonts. Unfortunately Google didn’t help me out, so I started a little research of my own into this issue. I was previously able to tweak font settings using ~/.fonts.conf so I thought to start there.
To make a very long story a whole lot shorter; assigning pixelsize turns off font hinting for Qt apps. I wasn’t able to figure out why, but I did find a solution for my particular setup, resulting in the following ~/.fonts.conf:
Arial
12
13
You really have to look carefully to notice the difference with the original: it’s the qual="all" attribute in both test nodes. That did the trick for me.
Been on an Amsterdam-San Francisco flight again, so more time to read. An excerpt from “The Design of Everyday Things”:
Would you like a pocket-size device that reminded you of each appointment and daily event? I would. I am waiting for the day when portable computers become small enough that I can keep one with me at all times. I will definitely put all my reminding burdens upon it. It has to be small. It has to be convenient to use. And it has to be relatively powerful, at least by today’s standards. It has to have a full, standard typewriter keyboard and a reasonably large display. It needs good graphics, because that makes a tremendous difference in usability, and a lot of memory — a huge amount, actually. And it should be easy to hook up to the telephone; I need to connect it to my home and laboratory computers. Of course, it should be relatively inexpensive.
What I ask for is not unreasonable. The technology I need is available today. It’s just that the full package has never been put together, partly because the cost in today’s world would be prohibitive. But it will exist in imperfect form in five e years, possibly in perfect form in ten.
Do you think what I think? I reckon that Donald A. Norman must be the owner of an iPhone. At least the quote above is a perfect description of today’s smartphones. In particular the iPhone, which, in my opinion, is a one of a kind both in design and usability. Now this book is first published in 1988, so Norman was ~10 years off, though not bad. Funny to bump into, in the already quite interesting book.
There are some problems that you can only really solve, let alone understand, by diving into code. Lucky enough the Open Source movement has spread like wildfire these days, also for developer tools. So besides that it’s fun and very educating to read someone else’s source code, in come cases it’s also really, really helpful to find out how a program is doing its tricks internally to really understand how to best use it. In particular this problem case that I’ve been investigating including a combination of SCons, SWIG and Python.
It’s a pretty straightforward setup. You’ve got this C++ library which you want to export to Python. You’ve already setup an interface to Lua, using SWIG. Now the cool thing about SWIG is, that it’s really easy to export the same interface to different scripting languages, so you want to use SWIG’s power to use your existing setup and extend that from Lua to Python as well. You take your existing .i file, divide it up into two separate files, a general one and a Lua specific one. Say common.i and lua.i where you include common.i in lua.i. Then you can create your new python.i with the Python specific instructions for SWIG, again including common.i. Problem solved.
Well, not if you’re using SCons as your build tool and you put the %module statement in common.i. That does work for Lua, but for Python strange things will happen with SCons’ build dependencies on the .py wrapper file generated by SWIG. I had to go all the way into SCons’ Tool/swig.py to find out what the problem was. While SCons scans for %module statements, which, if found SCons uses to define the .py file build dependencies for Python extensions, %include statements aren’t honored as such. That’s when I undestood that the problem was my Python specific python.i which didn’t have a %module statement! I put that into common.i, reusing it for Lua and Python, thinking that would be ok. However, that setup will mislead SCons to thinking that there are no %module statements at all. So build dependencies will be incorrect, leading to build errors.
Lesson learned: when using SCons, always put the %module statements for SWIG in the .i file that is used to directly generate the scripting language extension from.