Other people's activity logs:
Older dates can be visited here:
And now for a gratuitous baby picture.
Multiscreen hackfest for openSUSE
Here is a belated announcement for the multiscreen hackfest we are having at openSUSE this week and the next.
Do you have multiple monitors connected to the same machine? A laptop and a projector or an external display? Do you get a lot of pain from trying to get it all to work?
If so, be sure to participate in the multiscreen hackfest!
Some work we are doing:
Integrate Søren Sandmann's, Bryce Harrington's, and James Westby's work for gnome-desktop, gnome-settings-daemon, and gnome-control-center so that the Display capplet will let you configure your multiple monitors easily.
Pay attention to all the bugs in X drivers that we run into while testing the configuration tools. Document any quirks that need to be set in xorg.conf by hand.
Fix all the bugs in applications when used in multiscreen mode ("I clicked on a button but the dialog appeared in the wrong monitor").
Projects for Summer of Code 2008
This year I will mentor at most two of the following four projects:
Making evolution-data-server's calendar smaller and faster (for GNOME). E-d-s was written in the very early days of Evolution, and it needs some profiling love. In this project you will profile the calendar part of e-d-s to make it use less memory, and be faster as well with an optimized query engine.
Reducing memory fragmentation in GNOME (for GNOME). The GNOME platform libraries do many allocations of small objects. Your task will be to do an analysis of memory fragmentation, similar to what was done for Firefox 3.
Making removable hard drives Just Work(tm) (for openSUSE). Currently, when you plug in a blank hard drive through USB, nothing happens. The device node gets created in /dev/sdb or whatever, but you don't see anything happen in your screen. Your task will be to improve things around HAL, PolicyKit, and gnome-volume-manager to detect this situation, and to make the right thing happen.
Reliable unmounting of removable media (for openSUSE). When you want to unmount or eject a removable volume that is being used, you get a meaningless error message. There is no way to know which programs are still using the volume. Your task will be to make GNOME tell you which processes are using the volume, and give you a chance of killing them.
If you are a student, please see GNOME's very nice page on information for students. This will be useful to you even if you choose one of the projects for openSUSE. Don't miss out on this great opportunity to become a well-recognized member of the free software community and win USD 4500!
Philip, you are looking at this from the viewpoint of email. Email, addressbooks, and calendars are pretty different beasts.
Email has very particular access patterns, which are totally different from calendars and addressbooks.
With email, the prevailing model is that you display a usually huge linear list of messages, and even the summarized information can be pretty big. Searching is Nontrivial(tm).
In calendars, you almost always look at a subset of "events which occur in a certain range of dates", by virtue of the calendar's view (monthly/weekly/daily). Practically the only exception to this is when you want to do "show me events which contain $substring"; that's when you actually want to show a linear list of all the events that match.
Evolution still doesn't get this right, by the way. If I'm thinking, "when did I meet with Joe?", I type "Joe" in the search box — but Evolution keeps showing the current monthly/weekly/daily view, and I have to manually fiddle with the date ranges to actually find which days contain the event I'm looking for. Substring searches should switch to the "list view" mode.
Addressbooks are funny, because the access patterns for "my addressbook" and "my company's directory" are very different. Your addressbook contains at most a few hundred entries, and you may be able to deal with it comfortably by scrolling through a linear list, which is sorted by last name. You turn on searching when you don't remember a person's last name, so you type their first name in the search box.
In contrast, your company's directory is potentially huge and you never want to show it as a linear list. You actually want to type a person's name in a search box, and then pick a match from a small list. (Something must be wrong somewhere, as people keep mailing me when they mean my colleague with the beautiful name).
What does this have to do with evolution-data-server? E-d-s was always meant to be a local daemon to store your calendar and addressbook. It's the local Model in a Model/View split for all the processes which want to access your calendar/addressbook data. It was also meant to act as a local cache for remote calendars, which could be slow/huge/etc — that is, for stuff which is far away or not in the same scale as your own little appointments.
I really don't know how much of that data gets duplicated in the daemon's clients, but if it is a lot, then the clients are doing something wrong. For example, a calendar event (VEVENT in iCalendar parlance) contains a lot of administrative crap: a UUID, a sequence number, a stringified timezone identifier, blah blah blah, in addition to the actual human-readable stuff that I can see in my calendar (summary, start/end times, alarms). Here's a complete VEVENT:
BEGIN:VEVENT UID:20070925T174038Z-22251-100-1-25@cacharro DTSTAMP:20070925T174038Z DTSTART:20070926T160000Z DTEND:20070926T170000Z SEQUENCE:2 SUMMARY:openSUSE project meeting #opensuse-project CLASS:PUBLIC TRANSP:OPAQUE CREATED:20070925T174109 LAST-MODIFIED:20070925T174109 BEGIN:VALARM X-EVOLUTION-ALARM-UID:20070925T174109Z-5309-100-1-13@cacharro DESCRIPTION:openSUSE project meeting #opensuse-project ACTION:DISPLAY TRIGGER;VALUE=DURATION;RELATED=START:-PT15M END:VALARM END:VEVENT
That's 484 bytes of data, which is mostly fluff. These structures tend to explode in size when you parse them, but a neurotic calendar could keep the nice-and-small VEVENT string instead of a parsed structure, and re-parse it and re-generate it every time the event changes.
And again: my local calendar, which goes back to 2001, only contains about 500 events, and is 670 KB in size. The craziest calendar I've seen is Michael's, which has a couple thousand events, but that's not even an order of magnitude larger than mine.
Summary: there's no reason for e-d-s or calendar clients to have huge memory requirements; they are just doing something silly. You can keep a whole calendar, in memory, in less space than a fat JPEG from your digicam.
Ross posted about people wanting to write replacements for evolution-data-server, and I agree with him that doing so is a mistake.
When we originally wrote Evolution, a lot of backend-ish things were left in a "we'll fix this later" state. It was more important to have a simple, working backend and a totally awesome frontend GUI, than to have a super-optimized backend and a shitty GUI.
The code in e-d-s is a good example of something that could get a lot of easy love if people simply took the time to understand what is wrong with it in the first place.
Some things that could be done to e-d-s reasonably easily:
Evolution-data-server has a reputation for becoming a very big process with a small resident size. On my box, pmap(1) says that e-d-s has a 14 MB heap with 12 MB resident. That's tiny by today's heap standards. However, there are 8 or so threads with an 8 MB stack each, which is of course not even used. An easy cure for people's fears of the total VM size would be to fix the size of the stack in the threads.
Avoid scanning the entire list of calendar events when someone makes a query. The most fundamental API in the e-d-s calendar is, "give me all the events that fall within $range_of_timestamps". For example, the Evolution calendar's week view will say, "give me all the events for the current week". E-d-s then goes and looks at all the events it knows about, sees if they intersect the specified time range (generating recurrences if needed), and builds a list of results. This makes each query run in O(num_events) time — nobody cleans up their old events, so this degrades pretty quickly over time!
There are various ways to fix this. You could read the calendar.ics file into memory, but instead of storing a dumb linked list of events, you could store an interval tree based on the time range for events. An event that occurs only once has a range of [t1, t1 + duration]. An recurring event that repeats indefinitely has a range of [t1, ∞). If you are careful with the way you organize your data, you can avoid even looking at the memory pages for the event info, and just look at the pages where the interval tree is stored.
My calendar.ics file is 700 KB, and addressbook.db is 400 kb. So, why does e-d-s have a resident heap of 12 MB? "Use a database for the calendar" is total overkill, and less reliable than a simple text file. Someone needs to actually look at how much space e-d-s uses in memory for its various data structures, and then see why they become so big when loaded.
When your bathroom becomes kind of dirty and gross, do you demolish it and build a new bathroom? No, you clean it up. It's a shame that software seems so easy to demolish and rebuild.
I'm surrounded by beautiful women these days.
Pavlov has a great summary of reduction of memory usage in Firefox 3. It would be very interesting to try to reduce (for example) memory fragmentation in our platform libraries.
GtkFileChooser bug week: closing summary
Completion in the file chooser
The new completion code for GtkFileChooserEntry is in GTK+ trunk now! It works much more smoothly than before the bug week:
Instead of being a mishmash of asynchronous calls, the entry is now very careful about completion. There are two cases: autocompletion and explicit completion. Autocompletion is is when the entry automatically inserts-and-selects the common prefix as you type, and happens only in the Open modes. Explicit completion is what you invoke with Tab at any time; it inserts the common prefix and moves the cursor past it.
Completion will not happen unless the correct folder is completely loaded. When some form of completion needs to happen, the entry first parses its input to see if it needs to initiate a folder load. If the folder is already completely loaded, then completion happens immediately. Otherwise, the entry initiates a folder load or waits for the current folder to finish loading.
Tab completion is allowed to happen even if the cursor is not at the end of the entry. Also, Tab completion has a new feedback mechanism. You'll get an Emacs-like tip when there are ambiguities in completion, or no matches, or when you type invalid input. See the screenshot above!
The only remaining thing is to fix the popup suggestion window. The code has some FIXMEs that identify the correct place for the suggestion window to be activated or scrolled. Unfortunately, GtkEntryCompletion doesn't let us do these things easily, and it will need some changes. I'll work on that next.
What's next
I'll be merging all of the bug week's stable patches into a GTK+ package for openSUSE. These patches are all in the gtk-2-12 branch already.
I'd like the completion code to get some more testing before I backport it to GTK+ 2.12. If you can test SVN trunk, it would be greatly appreciated :)
Finally
Thanks to all the people who participated in the bug week! Bryan Yunashko for testing, Michael Meeks for fixing hard-to-find bugs, Will Lachance for adding polish to the file list, Chris Wang for figuring out the default response for dialogs, Carlos Garnacho for adding polish to the path bar, and everyone who tested fixes.
Pretty soon I'll organize a bug week for multiscreen-related bugs. Or a bug fortnight — there are so many bugs there.
I just read through the GNOME Foundation's Annual Report for 2008 (PDF), and it is very nice to see a well-produced, pretty-looking summary of the big things that have been going on in GNOME. I'm flattered to have been asked by the Foundation to write a preface for the report. This preface is more or less a summary of what I blurted out during the closing ceremony of last year's GUADEC. Go read it! :)
GtkFileChooser bug week: day 4
Michael found an interesting race condition in GtkFileSystemGnomeVFS: if two threads request the same folder, and the folder was not loaded already, then one of them won't get as much data from the file system as it requested. This is why the file chooser sometimes doesn't display icons — a bug that had me quite puzzled the few times I saw it.
Will Lachance fixed the display of dates for files which were modified today.
People are getting duplicated entries in the file list when using the Unix backend (especially in Debian/Gentoo). Can someone please try the patch in revision 19678 to see if it fixes things? I committed that the other day for a bug in the Unix backend, but I'm not sure if it helps with the bug about duplicated files.
Chris Wang found that GtkFileChooserDialog required a default response button to be defined so that pressing Enter in the filename entry would work correctly. He sent a patch so that the dialog will detect when it doesn't have a default button defined, and will automatically define one itself. This is why you hit Enter in Brasero's file chooser and nothing happened.
It turns out that other people have full git-svn clones of GTK+ and Glib:
If we find that a good number of maintainers and regular contributors are using Git for their daily work, we may as well just switch :)
GtkFileChooser bug week: day 3
I have Tab completion in the file chooser mostly done now. It seems to work much better than before; Tab completion is predictable and doesn't get in your way, it is faster, and it has nice tooltip-like feedback to tell you what it did (a la Emacs). The bug has the current patch attached, if you'd like to test it.
Now I need to finish the popup suggestion list, hopefully tomorrow with some hacking of GtkEntryCompletion.
People have been mailing me interesting patches or reminders of patches for the file chooser — thanks, guys! I want to integrate these patches tomorrow as well. Please catch me on irc.gnome.org #gtk+ or irc.freenode.net #opensuse-gnome.
You can get the Git repository for the completion patch like this:
git clone http://www.gnome.org/~federico/git/gtk+.git cd gtk+ git checkout origin/bgo314873-filechooser-tab-in-the-middle-of-entry
Git repository with GTK+'s full history
Ever since I discovered the joys of git-svn, I've been using it to interact with svn.gnome.org instead of using the normal svn client.
Since then I've been living with partial clones of GTK+'s repository, as I could never bear to clone GTK+'s entire history, which goes back to 1997. There have been over 19,000 commits in GTK+ during its lifetime.
Over the weekend I left a screen session in www.gnome.org, doing a full git-svn clone of GTK+'s history. The result is about 460 MB of pure love (about 180 MB for GTK+'s full history (!) and a lot more for the git-svn administration information (!!)).
Now you can have the full history of GTK+ on your machine, in very little space, with branches, tags, and everything!
Instructions
Download gtk+-git-svn-clone-20080304.tar.bz2 (198 MB).
Unpack it somewhere.
Edit gtk+/.git/config and find the lines that say this:
[svn-remote "svn"]
url = http://svn.gnome.org/svn/gtk+
If you only want anonymous, read-only access to SVN, leave it like that. If you have an SVN account, replace the "url" line to be "url = svn+ssh://username@svn.gnome.org/svn/gtk+".
Go to the toplevel gtk+ directory and run these commands:
git-svn fetch # will update all the branches/tags git-svn rebase # will update your master branch with the state of SVN trunk
To get a list of all of GTK+'s branches, do git branch -a.
That's it. I hope this is useful to the people in the GTK+ Hackfest will find it useful to avoid network latencies :)
Using a baby to test accessibility features
What if you lost the use of one of your hands, say, by having to carry a baby while your wife tries to get some sleep?
Today I enabled Sticky Keys in GNOME's accessibility options, and I'm happy to say that it Just Worked(tm). No restarting of anything, it's easy to figure out once you enable it, and it's also easy to disable.
Now I think I want a chorded keyboard.
GtkFileChooser bug week: day 1
The file chooser bug week is rolling along. Today's progress:
Made packages available for testing in the openSUSE Build Service.
Backported single-click shortcuts and skipping over the filename extension for openSUSE 10.3.
Reviewed and committed Garnacho's clever patch for enabling the scrollwheel in the path bar.
Worked on completion in the filename entry a bit more.
If you have outstanding patches for the file chooser (distros, this applies to you as well!), please catch me on irc.gnome.org #gtk+ or irc.freenode.net #opensuse-gnome.
Next week, March 03 to March 07, we'll hold a GtkFileChooser bug week in irc.freenode.net #opensuse-gnome.
What: We'll fix as many bugs in the file chooser as possible, review and merge pending patches from the GNOME bugzilla, and leave the file chooser in a beautiful state.
Who: WE NEED HACKERS AND TESTERS! See the wiki page for how to participate.
For GNOME in general: if you have patches for the file chooser in bugzilla.gnome.org that haven't been reviewed, integrated, or are generally just stalled there, this is the time to kick my ass. We'll update/integrate as many of those patches as possible.
In other, related news... I am almost done with fixing completion in the file chooser. I now have total gnosis of how completion should work, even with all the async loading, so that it will be fast, reliable, and smooth to use.
Get the git repo:
git clone http://www.gnome.org/~federico/git/gtk+.git
We are starting to organize Local User Groups for openSUSE. Join the discussion if you know other users of openSUSE within your area!
Nickolay Shmyrev is making a pretty interesting page on how to run GNOME on low-memory machines. Two hit-and-run thoughts... 1) What's with Spamassassin being the default in Evolution, when the Bogofilter plugin is sooooooo much faster? 2) That trick about symlinking locale directories to avoid disk seeks — is that something that could be fixed in gettext itself?
Today I needed to install the legendary SLED 10 to debug some stuff, but I had run out of partitions for the operating systems I normally have around for debugging purposes. Time to dip my toes in virtualization.
I used YaST's "create a virtual machine" module to install my first VM, ever — something akin to losing one's virginity. YaST installed the necessary packages, set up a disk image, read my installation ISOs correctly, and it Just Worked(tm). I'm really impressed! Mad props to those who made all the pieces work so smoothly.
Now I need more RAM for my VMs; I can see myself becoming a VM junkie if all works well.
Sucking with removable hard drives
My usual strategy for backups is to rsync my home directory from my laptop to my desktop box. This started to suck when the hard drive in the desktop box started getting rather full. So I thought, I'll get an external hard drive and figure out how to backup things properly.
Today I got a lovely 500 GB hard drive and an USB drive enclosure. It's black and shiny and has a pretty, reassuring blue LED on the front.
I plug the hard drive to the power, then to the USB port on my laptop, and I turn on the drive.
And nothing happens.
So I look at /var/log/messages. Sure enough, /dev/sdb appeared. But it has no partitions and it is not formatted.
I partition the drive, and format it (using YaST, since these days I can't be bothered to look up how to tell mke2fs to create a fucking ext3 filesystem).
I unplug and re-plug the USB cable to to the drive. An icon appears on my desktop, titled "500 GB Volume". Huh, I suppose I should have given it a name in YaST. Nautilus offers no way to rename it.
I double-click on the icon, and Nautilus brings up an empty window except for a lost+found directory.
So I drag some files to it. Ghetto backups, here we go!
And of course it tells me, You do not have permission to write to this folder. Root owns that partition, and I can't write to the hard drive I just purchased.
I guess the One Touch Backup button on the drive enclosure won't do much good...
Some time ago I wrote about annoyances with Tab completion in GtkFileChooser. I'm taking some time to fix things in the file chooser, with Tab completion being the first one.
The most annoying bug with Tab completion is that it doesn't work if the cursor is not at the end of the entry's text.
If you have "/home/fed" and the cursor is at the end, and you hit Tab, then the right thing happens: the text gets completed to "/home/federico/".
But if you have "/home/federico/photos/foo.jpg" and you move the cursor just to the left of the foo, and type th and hit Tab (expecting "thumbnails/" to be inserted), nothing happens. You also get this bug all the time in Firefox, when you do "Save link as": it suggests a reasonable filename in the file chooser ("lolcat.jpg"), but it invariably picks the wrong directory. You move the cursor to the beginning, intending to type "~/imagTab", but you get screwed because the file chooser won't do Tab completion in that situation.
This is because the code to do completion was pretty simple: it could only do completion if your cursor really was at the end of the text. This happens due to the way the code evolved. The file chooser's text entry keeps track of what you have typed so far, and when it looks like you have finished typing a directory name, it starts loading that directory asynchronously so that it can do completion on the filenames within that directory.
However, the code can't handle the situation when the cursor is in the middle of the text, instead of at the end: it would need to restart the "load a directory" process, based on the cursor's position, depending on which complete directory name is to the left of the cursor. But the code only changes the directory when the text changes, not when the cursor moves. It's crufty old code.
There's a lot of polish involved, so I'm dealing with things one by one:
The text entry starts loading the underlying folder as soon as it starts up, even if you never request completion. This is a performance problem.
The file chooser can't do completion until the underlying folder is loaded. If you hit Tab while the folder is still loading, you should get a hourglass cursor and possibly a beep ("I'm not ready yet").
The suggestion window for multiple matches should appear when you explicitly hit Tab, but only if there is more than one possible match.
You should get a beep if there are no matches when you request Tab completion.
The suggestion window should scroll if you hit Tab again while it is active.
I'm not convinced that GtkEntryCompletion has all the machinery it needs to be as polished as that, so some hammering may be needed...
Improving login time, part 8: What does the panel do before launching its applets?
(Index to the "Improving login time" series)
In the panel, there are two main slowdowns at startup before the panel starts loading applets:
The first gap is where PanelToplevel does its initial size_request. What's making it slow? Some sub-widget is probably loading images or something... what is funny is that with either a cold or a warm startup, it takes around 0.4 seconds.
The second gap happens right after the panel enters gtk_main(). From there it takes a while (around 0.45 seconds) until the panel actually starts activating applets. I haven't hunted down all the intervening idle handlers, and kcachegrind doesn't seem to be cooperating to find the culprit.
Patch to add instrumentation to gnome-panel, today's version.
Improving login time, part 7: Gnome-panel startup
(Index to the "Improving login time" series)
This is the second instance of Novell Hack Week! I'll be profiling gnome-panel's startup to reduce our login time.
This is a timeline of gnome-panel during a warm startup:
The timings are not very good since this wasn't taken during a cold, full-session startup; I'll do that tomorrow. But there are some interesting things already:
The panel takes a good while to read its profile information, which is its current configuration. Why? This should just be reading a bunch of GConf keys and possibly creating some toplevel panel windows.
After entering the main loop, the panel takes a good while before it starts activating applets. Why?
Applets get activated in quick succession, and they reply asynchronously when they are ready. Tomboy, the Mixer applet, and the Notification Area are especially slow. Why?
You want to weigh your baby, but your bathroom scale doesn't have enough precision. What do you do?
First, take your wok and wash it.
Second, place the wok on your kitchen scale. Adjust the tare to zero.
Third, put the wok back on the table. Make it soft with a blanket and a pillow. Put your baby in the wok.
Fourth, carefully place the wok plus baby on the kitchen scale. Watch the balance! Write down the weight.
Fifth, bathe your baby. Take the clothes and the diaper and weigh them. Write down that amount as well.
Finally, make a simple calculation:
weight-of-baby = weight-of-clothed-baby - weight-of-clothes
Now that the wok and the baby are clean, you can start cooking. A 3.5 Kg baby serves six people.
Colin Walter has words of wisdom about optional components that should be mandatory in distros and our GNOME builds.
A while ago Josselin Mouette made the file chooser use single-click to activate shortcuts. This was a very nice change; it made the file chooser seem more responsive. Unfortunately, it also revealed a bit of stupidity on my part from a long time ago.
For some time I had the firm belief that the file chooser was very well "mouse-able", but that keyboard navigation was rather bad. So I made it do things that seemed reasonable at the time: make the focus change to the correct widget as you activate things, keep a focus beacon always visible...
When you activated a shortcut in the left-hand pane of the file chooser, it would automatically focus the file list. This made sense at the time: "you went to the place you wanted to go, so you now want to select a file, right?"
Unfortunately, this made the code pretty complex. Focusing the file list may cause a file to be actually selected. This can in turn wipe out what is in the Location entry and replace it with the newly-focused file. The effect is that the file chooser pulls the rug from under your feet at various times.
I just made a simple change that makes the file chooser not focus the file list when you activate a shortcut. This gives surprisingly good results... now, shortcut navigation seems smooth and predictable. These changes are now in the gtk+-2.12 branch and in the development branch.
Moral number 1: get the keyboard focus right, but don't try to be too smart about it.
Moral number 2: keyboard-able and mouse-able UIs are surprisingly hard to get right.
Turning a rowdy wild-west saloon into a nice cafe with internet connection
I'm happy to announce that the openSUSE Code of Conduct has been adopted by the project.
This code is directly stolen from based
on GNOME's
Code of Conduct. Thanks to the people who made it
possible!
These little clay chimneys...
... serve as exhaust for hot air, which collects at the top of the house in Oralia's super-cozy room-of-her-own...
... which overlooks the balcony on the side of our bedroom, and the garage.
To get to that little room, you climb the staircase (not built yet). The staircase volume is lined on one corner with glass blocks, which let in a lovely light at any time of the day.
We fell in love with glass blocks when building the kitchen, as they are cheap and strong. To get light on two sides of the kitchen, its ceiling has an elevated portion which serves as skylight...
... which in turn doubles as a waist-high surface in the balcony — which we'll be able to use to place cold drinks and other amenities for warm days.
The bathroom has a large window, which will sit above the bathtub (not built yet)...
... and that window lets us have a little wall with glass blocks to surround the shower, so that the shower will get light on two sides. This trick of perforated-inside-wall-next-to-a-window is shamelessly stolen from Joel's office.
Oralia and our daughter, first contact:
Luciana Mena-Silva was born on 2008/Jan/19 at 07:45 (13:45 UTC). Weight: 3.540 Kg; length: 52 cm. Oralia Silva-Rueda and Federico Mena-Quintero are currently the happiest people in the universe.
The other day I got ready to start fixing multiscreen bugs.
Now I need to find a PCI video card, since both of my computers only have a single AGP slot.
Over at an agile testing blog, there's an interesting example of scripting MacOS apps with Ruby. What do we need to make this possible in GNOME? The scripting is the easy part; the hard part is actually adding support for this to every application.
I just merged intlclock into the Clock Applet. Woohoo! Thanks to Matthias, Bastien, Vincent, and Callum for the patches and encouragement.
Callum made a release of the new, standalone libgweather-2.21.1, and I released 2.21.2 shortly afterwards to prepare it for general consumption. Callum also updated gnome-applets to use the standalone version of libgweather.
If you get a broken build of any of those modules, it's probably my fault :)
I'm sorry that I can't work anymore on intlclock for the moment, so I leave everything up to Vincent and his cadre of superheroes. Our baby is due in three or four days, so Important Things(tm) need to be done by that time...
Intlclock's sources are now fully merged into the traditional Clock Applet (git clone http://www.gnome.org/~federico/git/gnome-panel-intlclock.git). They just need patch review, which Vincent was kindly doing today. All that remains is bug fixing, and actually committing all of this to SVN.
Matthias Clasen fixed a bunch of oversights on my part in the merged clock applet, and also in libgweather. Matthias is the kind of man who will mail you, "here, have these eight patches for various things" — and all the patches are perfect and most are nontrivial.
Bastien pulled libgweather out of gnome-applets, and now it is practically ready for release as a standalone tarball (libgweather is available in the libgweather module on svn.gnome.org).
Today I made gnome-applets use the standalone libgweather for the Weather Applet. It just needs patch review from Callum.
For now, both the Weather Applet and the clock duplicate the same code to read the humongous Locations.xml which libgweather now exports. For the next release we'll provide a nice API which applications can use (it's mostly already in place, just not quite ready for general consumption). Evolution will also want to use this for its own "specify a location" purposes.
Finally, I just realized what a royal pain in the international ass it must be for our translators to deal with that Locations.xml. I'll make their life slightly harder once I find the weather code for my city, which is not in that file yet :)
Oralia's unstoppable ninja belly:
Big-picture view, with charts and numbers, on energy consumption and energy-production trends.
For each type of fuel, how much energy does it store per unit of mass, compared to energy per unit of volume? This is why hydrogen-powered cars won't work; hydrogen provides a *lot* more energy than gasoline per unit of mass, but it needs a lot of space to be stored.
For each type of fuel, how much energy is produced based on the land area needed to extract it? (I.e. could you satisfy your energy needs by convering your house with solar cells?). Oil provides a lot of power for the the land that is required to extract it, between 10 and 100 watts per square meter. In contrast, biofuels on a good day provide about 1 watt per square meter. Cities consume more power than you could generate by covering them with solar cells — what infrastructure would you need to collect the energy generated elsewhere and route it to the city?
Go backward in time to September 2007.
Federico Mena-Quintero <federico@gnome.org> Tue 2008/Apr/22 10:51:41 CDT