-
Cubes spin, fish swim, windows wobble, and it's all as useful as pink neon lights under decrepit cars.
What if we had bling with a purpose?
When you double-click an icon on your desktop, Nautilus could set a property on the new window, saying "this is the (x, y) position from which I should be made to pop up". The window manager would then swoosh the window from the small icon to its final, big size on the screen.
Similarly, when you click on a link in a Tomboy note, it could use the same mechanism to say, "swoosh this window from the link's position to its final location".
When you open a GtkExpander it would set a window property, which the window manager would interpret as, "this window should grow smoothly from its current size to this other size".
-
I'm working on merging Intlclock's sources into gnome-panel/applets/clock. This is painstaking work, as the sources diverged a long time ago so it's not just a matter of cut&paste.
Intlclock uses an IntlClockUI object, separate from an IntlClock object, which are then tied to a PanelApplet. The normal Clock applet uses a simple ClockData struct tied to a PanelApplet. Whereas IntlClock sometimes uses priv->fieldname, Clock prefers cd->field_name — that sort of thing. One nice thing about having to go through all the source code is that I've found a few places where duplicated code can be factored out into a single function, or where similar kinds of easy cleanups can be done.
My strategy is that I have Intlclock's sources, and when I merge something from Intlclock into Clock, I delete it from Intlclock. So, the code that is left over is what I still need to merge.
Meanwhile, we'll need to rip out libgweather from gnome-applets and make it a separate module, so that both the new clock and the weather applet can use it (and maybe Evolution uses it, too, for its weather calendar?).
Dear lazyweb, does somebody want to help out by splitting out libgweather from gnome-applets? That would save me a ton of work :)
-
Ulrich Drepper has released his massive paper on memory and caches.
-
The old clock applet uses this layout:
And Intlclock uses this layout:
Pink means a label or an icon; yellow means a toggle button; gray means an invisible layout container.
It's funny how GUI code evolves. In the case of Intlclock, p->panel_box is completely unused except as an intermediary between the applet widget and the real p->panel_button. Inside that button there is a smaller box, which contains the weather widgets and the actual label for the time display. At some point along the code's evolution, p->panel_box must have been used in place of this smaller box. After the code got shuffled around, possibly to move the weather widgets inside the button, that p->panel_box got left over as a vestige of something that once served a useful function.
-
Distros waste a lot of time reimplementing each other's features, and later trying to merge everything together in a public project like GNOME.
Later, Fedora imported it, made their own packaging changes, and added some cool features.
Later, Ubuntu imported it and made their own packaging changes.
Meanwhile, gnome-panel's clock diverged on its own. Now we have four clocks which must be merged by hand.
Imagine if GNOME used a decentralized version control system. Novell would have made a branch of gnome-panel's clock and implemented intlclock there. Later, Fedora would have cloned Novell's sources, made their own branch for packaging fixes, and a branch for features. Ubuntu would have cloned any of those sources, and made their own packaging fixes.
One lazy weekend, someone would have looked at the patches from the various distros. "Oh, these three distros are patching exactly the same thing for the system's set-the-time tool!" They would have removed that crap and added a nice, configure-time option to avoid having distro-specific patches.
Meanwhile, the overworked maintainers of gnome-panel would have said, "these people are doing good work; I can take care of other things in the panel instead of making my own divergent changes to the clock".
Etcetera. It's sad that we have tools to collaborate but don't really use them for GNOME at large, including the distros. The Linux kernel has beat us there.
Update: Matthias Clasen points out that there was a patch from Sun to do timezones in the clock from 2003. It got merged into gnome-panel three years later, while openSUSE/Fedora/Ubuntu had already done their thing.
-
I am working on merging openSUSE's and Fedora's versions of the International Clock Applet (Intlclock), so that then I can merge them to the baseline gnome-panel that we all love.
First I unpacked each SRPM. openSUSE's uses an older tarball of Intlclock, so I unpacked that tarball and put the contents in a Git repository. Then I created an "opensuse" branch and committed each patch from the SRPM into it.
Second, I created a "fedora" branch, unpacked the tarball that Fedora uses into it, and also committed each patch from the SRPM in there.
This makes it easy to get diffs between both divergent versions, while still keeping RPM patches separate. Right now for me it's easy to get a mega-diff between each distro's version, but I have to dissect the patch by hand to see where the divergences are. If the distros had used a Git repository from the beginning, this would have been much easier to figure out.
Oh, and what about raytracers?
I was playing with the preferences in Intlclock, and there is one to show or hide the world map that gets shaded according to the position of the sun. I noticed that the map was slow to show and fast to hide.
Then I looked at the code.
First, it loads and renders an SVG. This is a beautiful map of the world with detailed outlines of the continents. This is Mexico:
Each landmass has a white Bézier path, and an identical path that is filled with dark blue and then Gaussian-blurred. Here you can see a blurred Peninsula of Yucatán (the circled area is part of the state of Tabasco, which recently got horribly flooded due to global warming):
The city markers, those red dots, are also SVGs. Each one has a lovely gradient.
Then the Intlclock takes that beautifully rendered SVG and shades it according to the position of the sun:
How does Intlclock compute the shading? Why, it uses a little raytracer, of course:
get_sun_position (current_time, &sun_latitude, &sun_longitude); for (y = 0; y < height; y++) { lat = y_coord_to_latitude (y); for (x = 0; x < width; x++) { lon = x_coord_to_longitude (x); shading = some_vector_math (lat, lon, sun_latitude, sun_longitude); shade_pixel (x, y, shading); } }Let's summarize what has gone horribly wrong so far:
-
Using an extremely detailed SVG and rendering it at only about 300x100 pixels (that's the size of the world map as Intlclock displays it).
-
Using a blurred outline which you can't even see in that tiny rendered version.
-
Using even tinier markers with some gradients thrown in.
-
Adding a little raytracer just because, hey, why not?
I cannot help but think that the floods due to global warming were caused, at least in part, by all of our computers churning out SVGs and raytraced maps of the world.
-
-
... On the other hand, you *have* to love code that has stuff like
unix_time_to_julian_date() greenwich_sidereal_time() ecliptic_to_equatorial() solve_keplers_equation()
-
Magnus has started a blog on improving gnome-main-menu!
-
Cory Doctorow uses Gedit. Are we l33t or what?
-
Magnus Boman has been profiling gnome-main-menu and application-browser:
We'll use this information soon to make main-menu and the app-browser really fast!
Update: people have asked about how this was generated. First, you need to instrument your code. Then, you can use this tool to plot timelines.
-
Interesting post on design mistakes which may affect your program's performance.
-
I'm glad to see the openSUSE Board being announced. Hopefully the experience from being in the GNOME Foundation Board will help us not make the same mistakes again.
-
Emacs tip of the day: you know when you hit C-s foo to search for "foo" within the function you are looking at, then you hit C-s repeatedly to look for other occurrences, but you don't want to go past the end of the function? Do M-x narrow-to-defun first (C-x n d), then search, then do M-x widen (C-x n w) when you are done.