The Steady State The­o­ry says, in rough terms that the uni­verse has been and will be more or less as it cur­rent­ly is, be­cause there are par­al­lel pro­cess­es of cre­ation and de­struc­tion.

So, gal­ax­ies ex­haust but then there are new galax­ies, and the thing, as a whole, re­mains un­changed, in a way. Sure, it's not the same galaxy, and noth­ing that was in the old gal­axy re­main­s, but if you avoid specific­s, things are the same.

I feel the same thing hap­pens in the free soft­ware uni­verse. The two forces are re­ac­tion and fea­tures.

Re­ac­tion is the cre­ative force. Most, if not al­l, free soft­ware is re­ac­tive. It itch­es, I scratch, scratch­ing is re­ac­tive. There are many ex­am­ples:

• There is no free desk­­top! Let's cre­ate KDE!

• KDE is not the right kind of free, sort of! Let's cre­ate GNOME!

• KDE and GNOME are too heavy, bloat­ed and what­ev­er! Let's cre­ate XFCE!

• XFCE is not as lean and mean as be­­fore! Let's cre­ate LXDE!

• LXDE is (we'll find some­thing) let's cre­ate WHAT­EV­ER-DE!

This even hap­pens with­in a pro­jec­t:

• Hey, we cre­at­ed KDE!

• KDE 1.x has no ob­­ject mod­­el and GNOME does, let's do KDE 2.0 on COR­BA!

• Hey, that sucked, let's do KDE 2.0 on DCOP and KPart­s!

• Well, that's old an crufty, let's do KDE 3.0 clean­er!

• KDE 3.x looks old, let's throw all the UI away and do KDE 4!

And I am sure those fa­mil­iar with any soft­ware prod­uct that has lived long enough to go through ma­jor rewrites and up­heaval can do sim­i­lar list­s.

How­ev­er, some­times, the com­plains just don't go away.

• Net­s­cape 4.x is slow and crufty! We rewrote it as Mozil­la!

• Mozil­la (Sea­­Mon­key) is slow and crufty! We rewrote it as Fire­­fox!

• Fire­­fox is slow and crufty! We wrote Chrome us­ing we­bkit!

And guess what peo­ple say about Chrome? It's slow.

So, the les­son there seems to me that writ­ing a lightweight, gen­er­al­ly use­ful, web brows­er is im­pos­si­ble. Why? Be­cause of fea­tures.

As projects age, they grow fea­tures. Like the strange ear and nose hair men start grow­ing in their 30s, fea­tures are a fact of the life­cy­cle. And with fea­tures come code, be­cause that's how you do fea­tures.

And code is a li­a­bil­i­ty, as (I hope) you all know. The more code you have, the more ex­pen­sive it is to add things, and to be swift about im­prov­ing your ap­pli­ca­tion. Most suc­cess­ful projects die, or grow senes­cen­t, hob­bled by the weight of their fea­tures.

So how does a project stay young? I can think of a few ways.

It may have a be­nign (or evil, for that mat­ter) dic­ta­tor, with the right amount of hos­til­i­ty to­wards fea­tures (Lin­ux). It may be so exquisite­ly mod­u­lar that fea­tures don't cou­ple with each oth­er (emac­s). It may rein­vent it­self ev­ery 5 years and throw ev­ery­thing away (KDE). It may have a very clear fo­cus on one fea­ture and a cul­ture around it (Bac­u­la).

And for each of those mech­a­nism­s, there are in­count­able ex­am­ples of projects with too an­noy­ing dic­ta­tors, projects ov­erengi­neered to ab­sur­di­ty, stalled rewrites that nev­er re­lease and ab­so­lute fo­cus on a fea­ture noone cared about.

Sor­ry, the uni­verse is a tough place.

Short and sweet:

In Niko­la my stat­ic site/blog gen­er­a­tor, the Tag pages used to just be a big list of ti­tles link­ing to the posts in the tag. Now they can (op­tion­al­ly) look just like the blog does, but fil­tered. Check it out.

Mi­nor tweaks still need­ed (like, men­tion­ing the tag some­where in the ti­tle), but the ba­sic func­tion­al­i­ty (fil­ter­ing, pag­i­na­tion, lay­out, etc) is com­plete.

To enable it in your site, just use master from git and enable TAG_PAGES_ARE_INDEXES = True in your conf.py.

This site has been lat­er­al.pyc­s.net, lat­er­al.­fib­er­tel.­com.ar, lat­er­al.blogsite.­com, and has been, for sev­er­al years, ralsi­na.me.

Well, I am slow­ly go­ing to dep­re­cate that URL, and the new URL will be //ralsi­na.me where you al­ready can find it since a few months ago.

It will in­volve some work mov­ing com­ments around and such, but noth­ing much should change, all old links should re­main valid, and all com­ments should stay at­tached to the right post.

I will con­tact the var­i­ous plan­ets that ag­gre­gate it, but since the feed will re­main con­stant thanks to feed­burn­er, I ex­pect not to lose any­one in tran­si­tion.

My team has been work­ing on port­ing some PyQt stuff to Mac OS­X, and we have run in­to sev­er­al Qt bugs, sad­ly. Here are two, and the work­arounds we found.

Na­tive di­alogs are bro­ken.

Us­ing QFile­Di­a­log.ge­tEx­ist­ingDi­rec­to­ry we no­ticed the fol­low­ing symp­tom­s:

• If you do noth­ing, the di­a­log went away on its own af­ter about 20 sec­ond­s.

• Af­ter you used it on­ce, it may pop up and dis­­ap­­pear im­me­di­ate­­ly. Or not.

So­lu­tion: use the Don­tUse­N­a­tive­Di­a­log op­tion.

Wid­gets in QTreeWid­getItems don't scrol­l.

When you use Wid­gets in­side the items of a QTreeWid­get (which I know, is not a com­mon case, but hey, it hap­pen­s), the wid­gets don't scroll with the item­s.

Solution: use the -graph­ic­ssys­tem raster options. You can even inject them into argv if the platform is darwin.