Ever lay awake at night wondering what happens when you hit a web page with a java applet on a vanilla Ubuntu? Me neither. It turns out that it's this:

Embarrassment of riches! There are a few problems with this feature:

1. While it's great that you help me install the plugin, I have no idea what all these things are. All I wanted was "java".
2. There is no "default" or "recommended" choice. I can see that one of them is selected, but for all I know that's because the choices showed up in this order at random.
3. Even if I were inclined to think that the selected choice is selected for a reason, there's another choice that's exactly the same.
4. "No description found in plugin database." is not exactly helpful. In fact, it could be just the thing to help me here.
5. If I wing it and install one of these, and then it turns out it doesn't work (perish the thought!), the little notification at the top of the web page isn't going to show up again (because a java plugin, working or not, would be installed). So there's no way I can come back to this screen.
6. If I am the kind of user who understands that the choices in this dialog represent packages in the system, then I don't know what they are called, because the package names are not mentioned. So if I want to uninstall a plugin that doesn't work, I don't know what to uninstall.

There is another dialog in the Firefox settings for plugins:

Strangely, there is no option to uninstall plugins here, just disable. But I guess that if I disable the java plugin, I can revisit that java web page and get that plugin selection dialog again (and try a different one). Still, it takes a bit of detective work to figure that out, it could be made more obvious.

This example demonstrates the difference between starting on a problem, and actually solving it. I'm very pleased that we have these helper dialogs now, but it needs a bit more thought put into it.

Bug: #320989
I actually picked this example because there used to be two or three options in that dialog, but now there are five.

The issue comes up at every election.

Politicians are liars. They never keep their promises. You can't trust them.

Yes, true. But why? You can complain all day that knives are sharp, but if you don't understand why they are then you're not going to make any progress.

Now let me see if I remember how it is that politicians come to power in a democracy. Oh yes, people choose them. How revealing. Don't you find it ironic to criticize a politician for doing precisely what causes you to vote for him?

Imagine that every Monday you go to the store to buy a loaf of bread. They have ten different products. Nine of the ten have pink spots on them. You buy a bread with pink spots and head home. Once you get home you complain about the pink spots. Who would you say is to blame for the pink spots?

But wait, why do almost all the products have pink spots? Because the people making the bread know that you always choose one with pink spots on it. They don't make it with pink spots because they want to, they do it so that you will buy it.

Why do they lie?

Politicians exhibit a certain behavior. The behavior is making promises they have no intention of keeping. What can we do about this? Well, behavior responds to stimuli. If you want to change someone's behavior you have to give them an incentive.

It's no different here. Suppose a politician ran for office. One who was different from all the others. Suppose he didn't make any promises. Suppose all he said was "I intend to try my best" and "I'm very hopeful that we'll be able to achieve this". Would you vote for someone like that? Probably not.

So your incentive towards honest politicians is.. negative. You're rewarding deceit.

Why do we make them lie?

So why are we so eager to force people into making promises? We think this is an effective social instrument, don't we? If someone has said they're willing to do something, but they haven't committed themselves to it, then all too often we want to "help" them decide, don't we? How often do parents say "do you promise to do it"?

You find yourself right in the middle of a power struggle. You want someone to do something for you, but the person isn't really that eager. What's more, you're losing. Because you can't force him to do it. So one last hope is to make him promise you, make him commit to it. Then you think they'll be too ashamed to reneg.

We use promises in every day life to increase our power over other people. This is the way our culture functions, and we don't seem to have any qualms about it, do we? Face it, whenever you are forcing a promise out of someone, you either successfully stamp your power on them, or you make them lie. That's right, make them. You make them promise something they would not have volunteered. And it might even be something they can't deliver. But since you've forced this promise out of them, well what can they do about it?

So what about these pesky politicians? Well, we think that if a politician makes a promise, then there's just a chance he will actually do something about it. If he doesn't make a promise, he certainly won't. This is what we believe. Consequently, we want them to promise us everything. Have you ever heard a voter say he's disappointed with a politician for promising him something he wanted?

Why do we want them to lie?

But the truth is we want them to lie. We want them to promise not only what they know they can deliver, but so much more than that. Who's going to get more votes, a politician who only makes promises he can reasonably keep or one who makes lots of them? Not the conservative one. No, because he doesn't seem to care about our problems. He will only commit to the problems he knows he can solve, but what about my problems? I need more than he can deliver, more than he can promise. So I choose the guy who tells me he can deliver everything.

See the thing is elections are more about emotions than they are about facts. The people who get really caught up in politics don't do this over the cold facts, they feel there is something special to the whole process. As voters we love someone who can speak to us in a way that makes us feel like he understands our situation. Does that mean he can solve all our problems? No, but we sure like to dream it, don't we?

What was Obama's campaign all about? Hope. And what is hope exactly? It's the [possibly delusional] belief that something will happen that hasn't happened yet and hasn't shown any signs of happening either. And we buy this, because every once in a while we want to hope, we want to be delusional, we want to think that a better day is coming. Our experience tells us otherwise, but dammit we need hope sometimes.

Because what is the alternative? Realism. Things will never get better, and if they do it will probably be a change that won't make a big difference. And it might not even last. We are stuck with the way things are and that's that, hopefully it won't get worse. That's the realistic perspective on life. But what's more seductive, optimism or realism?

There are people out there who are trying to keep track of promises that were made to see what the politician actually did after being elected. Fine, I see nothing harmful in keeping track. But understand why the guy said those things. Because you, the voter, wanted him to.

I had a small revelation this week. I got svn builds working, both with Mono, and at along last, KDE4. It turns out it doesn't have to be maddeningly error prone.

Mono SVN

To build Mono you should look at the release tarballs of a recent release, like 2.0.1. That tells you which modules you need. It doesn't really tell you much about the order in which you should build them, however. Then you grab the sources from svn. The names of the modules in trunk/ largely match the names of the tarballs in the release.

I found this order to work okay:

1. libgdiplus
2. mcs (download only, mono module builds both)
3. mono
4. debugger
5. mono-addins
6. mono-tools
7. gtk-sharp
8. gnome-sharp
9. monodoc-widgets
10. monodevelop
11. paint-mono (from http://paint-mono.googlecode.com, yes it runs!)

When you're checking out from svn, don't check out the entire history (this would take forever to download), use

svn checkout -r HEAD <url>

so that you only get the current HEAD.

Before you set out, it's also a really good idea to set up a special build/runtime environment for this process. That way your existing Mono (if you have it installed) won't interfere with the svn build.

Now for the building. Generally, this is all you need:

1. ./autogen.sh --prefix=/opt/mono-svn
2. make
3. make install

There are slight variations in that some packages use bootstrap.sh instead of autogen.sh, but this you'll find in the respective READMEs. And those instructions actually worked for me. :cap: The mono module is a bit more complicated, because there is the whole concern about building mono using mono. So I recommend using

make get-monolite-latest

first to bootstrap the build. And then it works.

Sometimes you'll have failures because of missing dependencies. There will be a message like "You need package Hello". In that case look in your package manager for something resembling libhello-dev and that's more than likely it.

Last but not least, you obviously need a working toolchain.

KDE4

To build KDE4 there is a great tool called kdesvn-build. It comes with a sample config file you just tweak and then run the script.

Again, you'll probably have some failures, but kdesvn-build saves *all* output. So just look in log/latest/<module>/<operation>.log and you should be able to figure out what happened. Cmake has a very nice summary at the end of its output, where you can see exactly what was set up to be built.

The same note applies with respect to missing libraries as with Mono.

NOTE: KDE and Qt are massive and the amount of disk space this will cost you runs in gigabytes, so make sure you have plenty. My kde-sources directory with a full KDE build in progress is now 7gb, I kid you not. Mono is much smaller: 2gb.

Technology is a market. As all markets, it's prone to the forces of supply and demand, of perceived demand, of risk, and hype, and potential revenue in the wide digits. But let's face it, far too much time is spent standing around wondering what the "next big thing" is going to be.

Phones

That's where Apple is different. They just say "We want this, so we're building this. To hell with everyone else." Now, if this were a tree in an empty forest (if it were empty, there wouldn't be any other trees, would there?), noone would know about their products. But Apple has this talent for attracting attention. They're so secretive, and they love to surprise you. So when they stand next to that new statue and lift the veil, the technology press feels obligated to clap and cheer despite themselves, because of the anticipation.

Now, in this market of ours, Apple creates an action, widely perceived. This sends all those drones waiting for "the next big thing" running out of the room to their labs. The action creates a reaction. Google says "We want to build a phone, also with a rich runtime environment, but one that *doesn't* make the owner feel like he lives in Guantanamo Bay." Would Google have created Android without the iPhone? Who knows, but the fact is they didn't. Along come other responses. Palm is getting in on the game now. And Nokia finally got to work on a Linux-based phone platform (what on earth have they been waiting for all these years??).

It's a strange thing. Now, all these companies are rolling up their sleeves to build better phones. So why the hell didn't they before? The same exact companies that have been selling junk for a decade are now trying to improve their products. Why? Because Apple got everyone thinking that there is a demand for this. Before the iPhone, all the companies kept stealing quick glances at each other, scrambling to deliver whatever new tiny piece of junk the other was selling.

Apple, despite the murkiest of intentions, have brought about a positive development.

Software

Vendors in free software don't spend a lot of time on marketing, it's not their game. And even if they did, they don't have armies of marketeers and astronomical advertising budgets, so it's a different kind of marketing. KDE4 might be the best example of that; they really made an effort to be heard. But they're not in a position to stir up the same kind of hype that Apple can do with hard cash on the table. And thus the role of free software is often that, not of actor, but of reactor.

Free software is often the re-implementor. It doesn't seem very glamorous, but it delivers a very important product. OpenOffice is clearly a ploy to replace Ms Office, but its users are nevertheless very grateful that it's there. Mono isn't a "new thing", but it does bring the rich .NET runtime to Linux. Linux itself is just a reimplementation of Unix, but who could argue it hasn't been a wonderfully positive force? And how much good has the Wine project done, enabling countless people to run their legacy apps?

Sometimes a reaction is just the thing you need to get what you want. Stallman spent a decade warning people about the "java trap". Now that java is free software, does that make the people who worked on Classpath, Kaffe and all the other free java projects feel stupid? I doubt it, because it was their response that led to a free java. Sun, who had been forever clutching to java like a kid to his teddybear, didn't want to give up control of java. But they realized that left unchecked, this activity in the community would replace java and they would lose all control over it. So they made it free. But someone had to make them do it.

So I'm researching .NET/Mono for an application I might be doing for Windows. There are two important constraints:

• The application shall not require installation privileges. (Or users in locked down environments might not be able to run it.)
• The application shall be maximally robust with respect to runtime environment. (So that I can leave it behind with the best possible hope that it will work for years.)

The first rules out shipping an install bundle of any sort, and the runtime environment is presumed to be a vanilla Windows install. At most I can hope for a .NET runtime since it comes with XP-SP2 (I think) and certainly Vista and onwards. As for the second, I've considered things like py2exe, which bundles code with .dlls for Qt and whatever else the python code actually uses. While this seems to produce a self sufficient bundle (without requiring an install), how do I know if py2exe is going to be around in a few years when I may need to rebuild? And the Qt libs for that matter, they depend on OS-level libs that may change over time, that I have no control over.

So .NET seems to be the best only choice. Now, I obviously want to be able to run it on Mono as well, if for no other reason than to run it myself. So I have to stay clear of .NET-only bits.

That means hello Windows Forms (WPF is out, Mono doesn't support it). Now, I should say first off the bat that I'm not a gui coder. I don't like gui, it takes too much work to produce a really good gui, and it's way more hassle than I like to put up with. Nevertheless, I've seen a few of them. And Windows Forms... it's something else. On the face of it, the .NET library seems to be stocked reasonably, with classes for gui controls (System.Windows.Forms) and for drawing primitives (System.Drawing).

But then you look at some example code and you have to pinch yourself cause it's so unbelievable. I should preempt here by saying that all the gui toolkits I have seen in recent history handle layouting the same way: with layouts. You create a container that is, say, a grid, and put some widgets in it. The layout takes care of distributing the widgets in the container in a particular way. This takes care of resizing, because the widgets scale to the size of the container (and the containers, in turn, to the size of the gui). Containers can be nested to produce panels and so on.

Far be it for me to say that I like coding gui this way. It's a huge pain to set all this up. And it doesn't make resizing work well either, you have to put in a lot of extra effort just for that part. But at least it's a reasonably clean solution, and it's how Swing, WxWidgets, and I'm pretty sure Gtk and Qt as well, work.

Not Windows Forms. In Windows Forms you have containers, but there are no layouts. Everything is positioned with coordinates. As in here is a button, put it 5 pixels from the edge of the container; here's another button, put it in this location I have computed manually based on the first button. This has implications:

• positioning is pixel based,
• dimensioning is absolute - no resizing possible,
• there is no rendering.

As it turns out, the gui form is basically a canvas you can paint on. Widgets and drawing mix freely on the same pane. But remember that Drawing api I mention? It's pixel based, no Qt or Cairo rendering for shapes or fonts. Neither does .NET have any kind of svg-based rendering that I know of.

The whole thing makes me feel like a time traveler. Remember that Windows Forms isn't a deprecated library, it's still actively used (and Mono just recently got done implementing it).

So why bring this up? It's good to remember sometimes that just because something is hyped a lot doesn't make it good. Remember, .NET 3 only appeared recently, in 2006. That makes Windows Forms the designated gui toolkit right up to that point. Swing, ugly as it may be to look at (and sluggish as it's always been) came out with Java 1.2 in 1998. (As a matter of fact, I think even AWT had layout managers in 1995.)