-
Brad Hards talks about running Qt on top of the Glib main loop: "We both agree: the ideal would be for all applications on the X11 desktop to use the same event dispatching mechanism. Here are Trolltech, we think the Glib main loop should be that mechanism." This is pretty cool. In particular, "... I can now write a Qt based extension to any GTK+ or GNOME program. Just think... I could write a plugin for the GIMP or for Eclipse, I could use the asynchronous GNOME VFS API.".
-
Several people have asked me for the Phonebook example program I wrote for a gtk-sharp tutorial. Get the source for the phonebook; it's a small example of using Gtk.TreeView.
-
I had missed this entry where Robert O'Callahan talks about bloaty objects used to represent SVG in Firefox. This is the case where representing a trivial object, such as a rectangle, uses a lot more memory than you would expect.
-
On Saturday there was a big car crash next to to the shopping mall that sits by the highway.
The gray car, driven by a 16-year old idiot, was overspeeding. He lost control of the car in a turn, jumped over the center barrier, and landed on a red car that was going the other way. Yesterday, the local paper said that the passengers of the red car were a man, his wife, and their 2-year old girl. The man died in the hospital.
-
Best line I have read this month:
I’m a hacker, but these days I just don’t want to deal with complicated software anymore — Joe Shaw
-
During my last trip to Boston, I plonked 100 USD on a Linksys WPS54G wireless printer sharing dongle. You plug it to your USB printer, and plug it to your LAN on the other end, or let it run wireless. It lets you share a printer, plain and simple. I rarely print stuff, but Oralia prints her lesson plans and other school materials all the time. Every morning she would do the dance of take-laptop-near-printer, plug-printer-to-laptop, print-a-few-pages, unplug-laptop-from-printer, turn-off-laptop.
Those printer dongles, of course, come with Windows software. So I googled for "linux linksys print server", and it told me that the dongle had an HTTP server in it as well so that you can configure it with a web browser. Wonderful!
Of course, you first have to figure out its address, which it picks up with DHCP. So, become root. Do a broadcast ping on my home subnet. The dongle doesn't respond. Go to my router's administration web page, ask it who has a DHCP lease. Find the IP address. Type it into my web browser. The printer dongle asks me for a password. I google for the factory password. I log in, change the password, and set up the printer dongle with a static IP address.
Next, launch gnome-cups. I tell it ipp://192.168.1.3, the address of my printer dongle. It detects a LaserJet 1200 all right, and sets up a printer named like that. Printing a test page works. Woohoo, and without wires!
Now, go to Oralia's laptop. Perform the same procedure with gnome-cups. She had a "LaserJet 1200" configured via parallel port already; gnome-cups decides to call the new wireless configuration "LaserJet 1200" as well. Once I go to OpenOffice to select a printer, I of course get two entries that say "LaserJet 1200", and no way to distinguish them.
Since I'm a l33t hax0r, I poke at /etc/cups/printers.conf, look for the entry that refers to ipp://blahblah, and change its label so that it says "LaserJet on the network". I tweak something else to make that the default printer. I decide not to erase the configuration for the parallel printer, because one day, when I'm on a trip and thus unable to assist Oralia personally, I'm sure that the goddamn dongle will stop working for some stupid reason and she'll have to actually plug the printer to her laptop.
And in the end I was really happy that both my wife and I were able to print through our wireless network.
I'll quote from Alan Cooper:
In spite of its weak and clumsy design, it is still a wonderful thing. It's like the fellow who leads a huge bear on a chain into the town square and, for a small donation, will make the bear dance. The townspeople gather to see the wondrous sight as the massive, lumbering beast shambles and shuffles from paw to paw. The bear is really a terrible dancer, and the wonder isn't that the bear dances well but that the bear dances at all.
Update (Sep/2006): upgrading the firmware is *ahem* fun.
-
I've been working on various things for Novell, among them a lot of Samba-related stuff in Nautilus, Nautilus-share, and gnome-vfs, and also on integrating Beagle searching into GtkFileChooser.
"But, Federico", you'll say, "Jon and Joe demonstrated Beagle integration in GUADEC 2004 in Kristiansand, and Fer did another patch to use GeditOutputWindow to integrate Beagle into the file chooser as well. You have wasted your time and ignored the work of others, you monopolistic community-killing bastard!"
But I'm a careful bastard, I'll retort, and I have insider knowledge on the guts and innards of our beloved GtkFileChooser. Also, I stole a bunch of code from Joe's and Fer's patches. Two days of mad hacking yields this:
Notice the "Search" shortcut on the top left? You select it and you get pretty much the same as you get in Nautilus:
Then you can look for papers written by another old bastard:
Did you notice that the previews work? Sorting the columns also works if you click on the column headers. The bookmark buttons get (de)sensitized as appropriate. And the interaction is smooth.
This patch still needs a bit of love. The file names don't have icons beside them (should be a 5-liner). I'm not completely happy about displaying the complete path name of each file, as these are too long, but it does help to know which folder your files are in.
But it works pretty well. Here is the patch if you want to play with it.
-
Next on my list: review Kris's awesome patch for totally asynchronous operation of the file chooser, and review patches in Bugzilla. I have total gnosis of the code right now; this is a good time to review patches.
-
Oralia got her driver's license today. Here in Xalapa you don't do a driving examination by actually doing a test drive with a supervisor. Instead, you answer a few questions in front of a computer. You pay 650 pesos and get your license with a crappy photo. The whole process took less than an hour.
This is in contrast to Mexico City, where a) you must spend a whole morning to get a driver's license, b) it is impossible to get one without bribing a government worker. They also don't do actual driving tests there. The only advantage is that licenses there don't expire (until they decide to change this rule in 6 years); the licenses here expire after 3 years.
Anyway. Not doing an actual driving exam means that any idiot can get a license. The money fits nicely into the government's pockets, and the roads are no safer.
-
Food TV as porn. They are right. They are sooooo right.
-
Why does my desktop background repaint so slowly?
After GNOME and GTK+ switched to using Cairo, we got a bug about the desktop repainting very slowly. How slow? On the order of 1.5 or 2 seconds to draw just the background photo of your dog and your desktop icons. You run into this bug each time you maximize a window, and then flip to an empty workspace. It turns out that this is a hairy bug, not just "Cairo is slow".
-
Gnome-settings-daemon reads the GConf keys for your desktop background image, loads the image from disk, spices it up with a gradient or a solid color, generates a server-side pixmap, and sets that pixmap as the window background for the root window.
-
Nautilus notices that this pixmap has changed. Nautilus uses a whole-screen window for its desktop, so it sets the background of the desktop window to be parent-relative. This means that the X server will automatically paint that pixmap to the desktop window when it gets exposed.
-
The desktop needs to be repainted. Nautilus doesn't do anything special to paint the desktop; it just draws icons. GTK+'s double-buffering mechanism notices that the desktop window has a background pixmap set for it, and it needs to copy that pixmap to a temporary pixmap used for double-buffering. This is the slow step, as Cairo and XRENDER are slow when using repeating pixmap patterns.
The ugly thing about this is that it is a corner case in the Cairo/XRENDER code, yet it becomes a hugely annoying problem because it happens every single time you see the desktop.
I wrote a workaround patch for GTK+ which uses a faster code path, but having this really sucks.
The sad thing is that we already have software out there, in the wild, which people will hate because it is slow as hell. Just because we didn't bother to test for performance when we wrote the goddamn thing.
Fortunately, Matthias Hopf and Carl Worth have been great at looking at the problems in the lower layers of the stack.
-