Go forward in time to September 2007.
Our digital cameras all have intervalometers now. What happens when you set your camera to take a picture every minute and hook it to a high-altitude helium balloon?
Why I love Emacs, part N. Before:
imgContainer::imgContainer() : mSize(0,0), mAnim(nsnull), mAnimationMode(kNormalAnimMode), mLoopCount(-1), ...
After M-x glasses-mode:
img_Container::img_Container () : m_Size (0,0), m_Anim (nsnull), m_Animation_Mode (k_Normal_Anim_Mode), m_Loop_Count (-1), ...
I installed openSUSE 10.3 (which has GNOME 2.19) on my desktop machine, and recycled my old home directory from GNOME 2.16. My first login greeted me with this window:
What's wrong with this dialog?
It appeared in the upper-left corner of the screen. If you are going to ask me a question which I don't know how to answer, at least be nice enough to center the dialog on the screen.
"Expected was model": bad grammar.
How am I supposed to know the right answer? What's the difference between the "X setting" and the "GNOME setting" — is the X setting "pc104" and is the GNOME one "microsoftpro", or the other way around? Will it harm my computer to pick the wrong option? Will I be able to type if I pick wrong?
I just know that my keyboard looks like this:
It's definitely not a "microsoftpro" keyboard since it says IBM at the top. About "pc104"... who knows? Do you really expect me to count the one hundred-something keys to make sure?
Take the GIT user's survey 2007.
My Summer of Code students, trustworthy gentlemen that they are, have finished their work.
Mathias Hasselmann implemented natural sizing and height-for-width geometry in GTK+. You know these problems? 1. You create a treeview, and the window is by default too small to contain it comfortably. 2. You write an image viewer, and scaling a widget proportionally to an image gets hard — or you create a wrapped label and it never seems to fit nicely. Mathias's code solves both problems. First, GTK+ widgets can now say "this is my preferred natural size" instead of just saying "this is my minimum size" (GtkRequisition). Second, widgets can now say "if I were X pixels wide, I would prefer to be Y pixels tall". No other toolkit does this well.
Sayamindu Dasgupta implemented pre-configuration and lockdown for Nautilus and GtkFileChooser. A system administrator can now define default items which will appear in user's desktops (and which users will not be allowed to remove): with this you can create links to your university's web site or whatever. Also, a sysadmin can now confine the user to a set of restricted directories: don't want your users browsing outside of /home/username and /mnt/company-share? Simply restrict them to those directories. Nautilus and the file chooser will not even show other paths in the file lists. The restricted directories will appear as part of the shortcut panes in Nautilus windows and in GtkFileChooser dialogs.
... And this is where I discover that I am a total idiot for not taking a picture of both of my students while at GUADEC. For reference, Sayamindu is the guy who cloned himself and managed to help out simultaneously in every conference room with the microphones and projectors; Mathias is the guy who was running around in a yellow sweater, hacking on everything at once.
There was a complete gamelan just dumped there in a basement room of the Birmingham Conservatory. We should have requested a recital!
The best thing about GUADEC is the informal conversations that appear in the hallways, the streets, restaurants, bars...
Dave Mason recalls the "Bob Young all-nighter" that we pulled in the pre-1.0 days of GNOME.
I'm working on making Firefox uncompress images on demand rather than keeping everything uncompressed in memory all the time. Pavlov has been kindly helping me get acquainted with the Mozilla sources, as I've never touched that code base before (plus he's the perfect man to do it, since he wrote most of the code in Mozilla that deals with image loading). Today's progress: accounting how much memory Firefox uses for (uncompressed) pixmaps. Next week I'll work on discarding images based on a timeout, and seeing what difference it makes.
Yesterday we made a tasty and rather quick dinner: grilled fish with cilantro chutney.
Ingredients:
(Chutney recipe based on Mangoes and Curry Leaves, a great cookbook which Sayamindu hand-picked for us while in Birmingham!)
This is the inside of the vault over the bathroom, the one that used hexagonal chicken-wire mesh. It was easy to give even tension to the mesh over the steel bars, so it did not buckle when applying the concrete on top. The inside of the vault still needs to be evened out and polished with a mixture of cement and sand.
In contrast, this is the vault over my office, which used rhombus mesh for plaster. This kind of stupid mesh stretches a lot, and very unevenly at that. So, it got very bumpy when the concrete got laid on top. We'll have to use some sort of pickaxe to even out the biggest bumps, and then cover everything with the polishing layer.
The bathroom's vault (foreground) already has a layer of polished concrete on top, versus the office's vault (background), which is still rough on the outside. (Yes, our builders have taken to using rebar that sticks out of the roof as a holder for soda bottles...)
I've been trying to figure out a Git-based workflow for working with openSUSE's patched packages. For example, openSUSE 10.3 is the bleeding edge distro being developed, with GNOME 2.19.x packages in it. These packages, modulo details, are the same as the ones that were in openSUSE—10.2, except they have newer source tarballs (to move from GNOME 2.16 to GNOME 2.19), and of course updated patches against those tarballs.
I want this workflow to solve the following problems:
Each time the distro gets a major update of packages (like from GNOME 2.16 to 2.19), some old patches need to be dropped, some need to be re-diffed, and some need a complete rewrite. What if instead of doing all this grunt work, we did a periodic "git rebase" against the latest development packages — that way it may be easier to keep the patches up to date.
Having openSUSE 10.3 right now with a GNOME 2.19 desktop is really nice for development of upstream features. However, sometimes this work needs slight modifications to work in the distro. I'd like to have a Git branch with my work in progress, which could later be extracted easily as patches for upstream or patches for the distro.
Something tells me that one could have a "pristine" master branch for the upstream tarballs, a "distro" branch (or "distro-version-x", "distro-version-y", etc.) for the distribution's patches, and any number of "personal" branches for development. I just haven't figured out a clever way of juggling that.
The three finished vaults. They just need a final layer of polished concrete to make them waterproof. (The orange pipe is for electrical cabling.)
The roof over our bedroom, with space for a dormer window.
I'm amazed at how easy it is to build these vaults: they require no formwork and they are self-supporting during construction. It took two days and a half to form the largest vault: set all the steel bars, tie them together, and stretch and tie the wire mesh over the bars. Pouring concrete took half a day for the initial, thin shell, and whole day for the thick crust. Total: four days.
In comparison, the gable roof over our bedroom is about as big as the largest vault. Our workers spent four days setting up timber formwork (which was expensive to obtain!), and they did the pour on the fifth day — but needed an extra worker to mix the concrete and help carry it up to the second floor.
So... the vaults required no formwork at all, and they were faster to build. They required less people to build, and were cheaper in terms of materials. And they can support a greater load than the gable roof, even though they have the same thickness!
For a few months I've wanted to change the focusing screen on my D200. These DSLRs, for all their sophistication (and price!), have decided to do away with the really good focusing screens that were the default on mechanical, manual-focus cameras. They simply use ground glass screens which are nice and bright for autofocus lenses, but don't really help when you want to focus manually.
Dave and Radek, both men of impeccable taste, had recommended the Katz Eye focusing screens, so I ordered one. It arrived while I was at GUADEC, and today I finally got off my ass to install the focusing screen on the camera. I had been procrastinating, thinking that I would have to disassemble the camera and do scary stuff inside — on my old Nikon F2 one could simply remove the viewfinder and pentaprism, pop out the old screen and install a new one, but the D200 doesn't have a removable viewfinder.
It turns out that changing the focusing screen is really easy. You simply detach the lens, and pull a wire that sits on the roof of the mirror chamber. That wire is what holds the focusing screen in place. The new screen is equally easy to drop into place.
And the difference is HUGE! The screen has a split prism in the middle, a microprism ring around it, and ground glass everywhere else. Now it's obvious when things are in focus, and photography is a pleasure again.
Thanks to Alberto Ruiz and Andreas Nilsson we now have a beautiful icon for Sabayon!
![]() |
![]() |
Old | New |
The finished second vault, and the third vault in progress of being formed:
Hexagonal chicken-wire mesh, which our builders used for the third vault, is *much* better than the much finer rhombus mesh for plaster that we used on the first two vaults. It's easier to stretch and much harder to cut yourself while handling it. With the hexagonal mesh, the third vault came out much nicer than the first two — I'll get pictures soon.
This is Oralia under the small vault, in what will become our reading alcove — it gets lovely sunshine in the afternoon. You'll notice Oralia's prominent belly, due to a baby inside. Eeeeeek!
My GUADEC presentation: Eggs, wine, and sugar: making your application friendly to Sabayon (ODP).
Come on, people, not everyone has linked to their GUADEC slides in the wiki. We had some really interesting presentations; go make them available!
Go backward in time to July 2007.
Federico Mena-Quintero <federico@gnome.org> Fri 2007/Aug/03 15:16:32 CDT