-
Joel describes a nice feature for his bug tracking system: an easy way for users to create annotated screenshots to describe bugs (scroll to the bottom of the article). This would be nice to have in bug-buddy.
-
I've been debugging a tricky problem with Nautilus and Gstreamer for the next release of Suse: Nautilus crashes if you do right-click->Properties on a .ram file. Debugging the crash is hard because GStreamer plug-ins are loaded dynamically, and they come without debugging symbols on this setup. I didn't know how to use the files from debuginfo RPMS when you have a dynamically-loaded module.
GDB has a command called add-symbol-file. You call it like
add-symbol-file <filename> <address>
In my case, the filename was for a GStreamer plug-in, from the debuginfo package. The address argument is the address at which that file's .text section got loaded in memory. But how do you figure this out? GDB can't do it by itself if the module was loaded with dlopen().
The trick is to use pmap and objdump to find out. Pmap will tell you the start address at which the module was loaded (call this start). Objdump can tell you the offset of the .text setion within the ELF module (call this offset). Then you can add start + offset to get the final address at which the .text section was loaded, and you can feed that value to gdb's add-symbol-file command.
$ pidof nautilus 12345 $ pmap 12345 | grep libgstplaybin 4194b000 64K r-x-- /opt/gnome/lib/gstreamer-0.8/libgstplaybin.so 4195b000 4K rwx-- /opt/gnome/lib/gstreamer-0.8/libgstplaybin.so $ objdump -h /opt/gnome/lib/gstreamer-0.8/libgstplaybin.so Idx Name Size VMA LMA File off Algn ... 9 .text 0000a024 000035d0 000035d0 000035d0 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE ... $ gdb ... (gdb) attach 12345 (gdb) p/x 0x4194b000 + 0x000035d0 $1 = 0x4194e5d0 (gdb) add-symbol-file /usr/lib/debug/opt/gnome/lib/gstreamer-0.8/libgstplaybin.so.debug 0x4194e5d0
-
Luis and Larry: GTK+ APIs are sometimes hard to use because we don't have the resources to conduct API usability tests like Microsoft does. Not that MS's APIs are particularly usable, either.
The other problem is that sometimes it takes time for one to use an existing API, and only after that time has passed will one grok which convenience functions would be convenient to have. For example, gtk_button_set_image() is a recent addition; it only appeared in GTK+ 2.6. Way before that, when stock buttons were introduced, people thought that no one would ever need to use a stock icon with a non-stock label. Much later, no one bothered to write a convenience function, because everyone already had their custom hacks in place.
Other things plain and simple require a lot of work to do completely right. Whipping off a custom widget is easy. Writing a fully correct and functional widget takes a lot of work:
- Does it implement the style-set handler correctly? You'll find out soon enough when a theme-happy freak complains that your widget breaks with some weird theme.
- Does it handle screen-changed? You won't find out so easily, as people seldom move windows across screens (real X screens, not combined monitors in the Xinerama sense).
- Is your widget fully usable with the keyboard only? And if it has focusable sub-parts, did you implement a custom focus handler?
- Does your widget implement all the accessibility hooks it needs?
Other times, perfectly usable APIs have implementation bugs, but people don't think that they are bugs; they just think that the API is weird. Then they do egregious things and don't report the bug.
And just like in like the most recent flamewar-de-la-semaine, API writers get a lot of requests but they don't have enough resources to implement them. Or maybe people just request things which they don't really care about that much. This is a particularly pressing problem for GTK+, which right now has 279 open bugs with requests for new APIs. How should we handle those bugs? Should we just WONTFIX the ones without a patch and that have been open for more than a year? If the requester had really cared, maybe he would have done something about it by now.
-
Many programs need a GtkButton with a stock icon, but a custom label instead of the stock one. So they have resorted to cutting&pasting code from gtkbutton.c or doing other things. I just filed a bug to sanitize eel_gtk_button_new_with_stock_icon(). Your programs should do the same, and they will work correctly given the presence of the global "gtk-button-images" setting, which one can use to control whether buttons have images shown in them.
(Sometimes even the functions from eel get cut&pasted in disparate places...)
-
The general problem is that no one ever finds out when new convenience APIs get introduced in GTK+ or the other low-level libraries of the platform. Programs which do cumbersome things because those APIs were missing seldom get updated. There are valuable resources for people who wish to clean up this sort of code:
- List of new symbols in GTK+ 2.2, 2.4, and 2.6
- The GTK+ good citizen's checklist
- Migrating from GnomeIconList to GtkIconView
- Migrating from GnomeAbout to GtkAboutDialog
- Migrating from GnomeColorPicker to GtkColorButton
It is good that APIs get cleaned up, generalized, and pushed to lower levels in the platform. But ISVs just hate this sort of shit: "You mean there's a new API again!? Can't you keep things stable for once?". The implementation of old APIs is not always made to use the newer ones underneath. This sometimes sticks out prominently in the user interface, where it is obvious when supposedly-global features are just not present in a few dusty corners.
From the viewpoint of the lower layers of the platform, ISVs are not just companies using the libraries for their programs, they also are the upper layers of the platform and the desktop itself. If you maintain part of the GNOME desktop, don't you hate it when there's a new API underneath and you have to gratuitously rewrite code? Of course it feels good to clean up your code and use a pre-made function, but wouldn't you rather be hacking on new features?
-
Gems from today's mail.
-
I wrote a little tutorial on Using jhbuild on Novell Linux Desktop.
-
Sign the petition for transparency in the World Intellectual Property Organization (WIPO).
-
David Turner started doing memory optimizations in Freetype, and he's got some interesting results. Thanks to Ben for the pointer.
-
This report of bugs with the gnome-love keyword set is really cool! If you are a hacker willing to dive into GNOME, check it out.
-
Today, as I started the car to drive it out of the garage to go for lunch, we started hearing some extremely painful meowing coming from somewhere. Oralia, remembering our last experience with a stray kitten, thought that the cat in question may be stuck inside the car's engine compartment. Fuck.
The cat was hard enough to see; it had managed to crawl between the front axle and the steering poles, right behind the engine. First we tried being friendly by offering him some ham, but he wouldn't come out. Then we tried to poke him a bit with a blunt stick; still nothing. He was startled or panicked or something, and it wouldn't move. Then we poured water on the engine; he meowed in tone of complaint but still didn't come out. Oralia called my dad for advice; he suggested honking the horn (which we did), pouring hot water (which we didn't), setting the car on fire, or just taking a goddamn taxi to lunch and letting the cat crawl out by himself.
I ended up going to buy a pair of thick gloves to pull him out. By turning the wheels all the way in one direction, I could make space for my arm to fit and grab the cat's legs. It was stuck pretty hard, and I feared that it would dislocate a leg. But he managed to be pretty... elastic. I had to push his hip a bit to make it pass below the steering pole. He was all wet from our own bucketful, and he was still pretty startled, so we fed him some more ham. Fortunately, he didn't have any scratches or cuts from the engine's moving parts, nor any broken bones.
And then he ran back into the garage. We bribed him out with some more ham, but he kept going back at the slightest distraction. Maybe the garage is warmer than the street. Eventually we went for lunch, and the cat was still there when we came back. We had to carry him around the corner and settle him down by some bushes. He'll manage.
-
Curtis: what you really want is to add support for rubberbanding in GtkTreeView. It shouldn't be very hard to do.
-
The GIMP needs a plugin to do this jaw-dropping kind of colorization. Thanks to Joakim for the link.
-
Matthias wrote a neat patch to avoid duplicating strings from GParamSpec.
-
Ben announced the bounties for memory reduction! This is pretty exciting; people are already submitting good patches.
-
Ben also pointed me to an interesting paper on the performance effects of gcc -Os versus -O2: is it worthwhile to optimize for size rather than for speed?
The results in the paper are interesting by themselves, but somewhat disappointing in the grand scheme of things: "Mozilla started up 2.68% faster with -Os". Reduction in page faults and cache misses were both well under 10%. Maybe we really need function reordering to get significant improvements.
-
Brandan Lennox and Will Cohen are working on a function reordering tool.
-
Oralia has been working tirelessly and meticulously on perfecting creamy soups. Today's victory: a fantastic cream of broccoli, chayote squash, walnuts, and Roquefort cheese.
Saturday... salmon in a creamy sauce of Portobello mushrooms, onions, tarragon and cardamom. It's the best creamy sauce I've ever had with fish. Also, we cloned a certain salad we had eaten at a restaurant: spinach and lettuce, tomatoes, walnuts, jamón serrano, Roquefort cheese, black olives, pepper, oil, sherry vinegar.
-
Bugzilla query for all the bugs with the memory keyword set. If there are other memory-related bugs, please add the keyword to them!
-
Tommi Komulainen has been doing a great job of finding static arrays in Pango that could be made const so that they'll live in the .rodata section of the library. This will make the arrays be shared across processes: one bug, another bug.
I started a list of concrete bugs about memory consumption. If you know specific bug numbers, or if you know about things that are already more or less tracked down and just need fixing, please list them there! That way people will have an easy way to pick bugs to fix.
-
Ben also started some pages with info about things that need to be investigated:
-
Acme inside gnome-settings-daemon uses GStreamer to control the volume. This adds 300 KB to the heap of g-s-d! How many users will actually have configured their Volume keys? Can we delay GStreamer initialization until such a key is used? Or can we use a more light-weight mechanism?
-
Gnome-settings-daemon has a little hack to synchronize the applications used to view files with a MIME type of text/plain or text/*. It uses gnome-vfs-mime for this, which amounts to 160 KB in the heap for the MIME lists. Can we get rid of that hack altogether? Maybe gnome-vfs-mime can be made smarter, so that it does the synchronization in-place, whenever it has to deal with text/plain or text/* files?
-
Each applet pulls in a hefty footprint. Can we make some of them in-process? Or can we combine some of them into a single executable?
-
Every app which links to bonobo gets 100 KB in the heap from bonobo_activation_i18n_get_language_list(), as this parses locale.alias. Glib now has g_get_language_names(). Are these pretty much equivalent? Could we hard-code some aliases for the most common languages so that the file doesn't need to be loaded?
-
-
Kjartan picked up a bunch of pending patches for VTE, and the result is great. VTE used to screw up the display when I ran MC under GNU Screen. It now works fine with Kjartan's package and I'm a happy man.