-
Evolution lets you turn on spam checking for when you fetch new mail. If I turn off spam checking in Evolution, I get a large amount of spam in my inbox. However, I can mark it as spam by hand and delete it faster than the automatic spam-checking can (and then the "fetch new mail" process is nice and quick). Is spamassassin really that bad?
-
Recently, EOG got destroyed.
Why do we let the HIG Nazis destroy beautiful user interfaces that were actually designed to be comfortable? The last time I looked, these are guidelines, not rules that you must follow blindly just because they are written somewhere.
Let me tell you a story about how I started writing EOG.
Back in the stone age, when RHAD Labs still existed, some company released Compupic, a proprietary image viewer for Windows and Linux. It was very nice, much nicer than any other image viewer available. It had some beautifully fast scrolling and zooming, and it was evident that a lot of work had been put into it. (I think the product still exists, only for Windows.)
I was worried that people would start using this proprietary image viewer on free systems: "Better than LView Pro? On Linux!? I gotta get me some of that!" (In the present, those would be the people who buy a DRM-laden iPod and then complain that Banshee is written in Mono.)
At that time I had already started writing EOG, as a replacement for Electric Eyes, a small image viewer from the Enlightenment team that unfortunately wasn't comfortable to look at really big images. At that time I had started downloading satellite photos, and a friend of mine had started his Graphic Arts degree, so he would routinely mail me huge JPEG posters.
Compupic set the bar for how an image viewer should behave. It was just smooth to use, and no other image viewer came close.
Writing the initial image view for EOG took a few weeks. Rewriting it, and making it fast and comfortable, took months.
I wanted EOG to be a full-fledged program to organize and categorize images, like Compupic was, but I never finished it. I only left the "image viewer" part finished, and it was indeed nicer than Compupic's. The subsequent maintainers of EOG have done a terrific job at making it an image browser (I think by now everyone agrees that F-Spot is just the Right Way(tm) to actually categorize images.)
EOG's rationale is very simple:
-
You view a photo by looking at the whole thing (zoom-to-fit): you see the cathedral and the beautiful sunset around it, while ponies dance in the atrium. Then you pick an interesting spot to focus on, like that gargoyle who looks angry at the ponies shitting all over his front yard. You move your head closer to that spot, or use a loupe (zoom in), and indeed confirm that the gargoyle is really angry. Then you start to explore interesting areas around that spot by moving your eyes and your hands (scroll around by dragging); that's when you start to appreciate the beautiful tracery on the stained glass window by the gargoyle. Eventually you'll zoom out, and zoom back into the ponies just because they are so goddamn cute.
-
Therefore, the only controls you need are an easy way to zoom (scroll wheel), and to pan (drag with mouse button 1).
Over the years, people have tried to mess up this beautifully simple user interface in various ways.
First, they said, "the scroll wheel is backwards". In EOG, Down is zoom out, and Up is zoom in, just like in your stereo with physical sliders. They complained, "but this goes against what the GdkEvents say, which is Down should make $value bigger, and Up should make $value smaller!". Screw that. The program should behave the way normal people expect it to, and if you even know what a GdkEvent is, you are by definition not a normal person.
Then they said, "the zoom factor should be configurable". Believe me, I spent days looking for a suitable zoom factor, the amount by which each click in the scroll wheel will zoom the image. Increasing or decreasing the zoom factor by a constant 5% is pretty comfortable. Larger values are too coarse, and finer values make it seem like it takes forever to zoom to a comfortable size.
Then they said, "the scroll wheel should scroll". These people must all have panoramic cameras which they use vertically, because 99% of the population shoots pictures in 4:3 aspect ratio, or if you are old fashioned, 3:2.
EOG lets you do this: find a comfortable zoom factor quickly, and then examine the image gradually by panning.
I hope we can go back to sanity :)
-
-
Steve Frécinaux's git-send-bugzilla sounded like a cool hack when he posted about it, but now that I've seen it in action, I must say that it is really goddamn nice: Mathias used it to upload his gtk-extended-layout patches to Bugzilla.
-
... And speaking of gtk-extended-layout, the top GTK+ question from the Beijing hackers was always something like "how do I make this GtkTreeView inside a GtkPaned have a reasonable size at startup, as well as my whole GtkWindow?". Right now, doing that is ridiculously cumbersome and painful, and you end up basically hard-coding pixel values, which leads to just as many kittens getting killed. Mathias's patches will make a lot of people very happy.
-
Almost the whole Beijing team at the Great Wall:
-
The hackers in Beijing take a healthy dose of good food every day.
I've been sitting with Wu Peng (吴鹏), looking at why CJK languages got much slower between GNOME 2.12 and 2.16.
First, we compiled Pango, Cairo, and Freetype with optimizations but no inlining (-O2 -fno-inline) to get readable profiles. Then, we ran the Chinese benchmark in pango-profile under Sysprof. There are some interesting things.
First we saw that Freetype's hinter was taking a lot of time; it has to compute the hinting for every Chinese glyph that appears in the text. However, there is a cache in Cairo to avoid recomputing glyphs. The cache lets you access the glyphs in a scaled font without recomputing them every single time. The cache is nicely done; it is of a fixed size and has a random replacement policy.
However, the cache is too small for CJK languages! From cairo-scaled-font.c:
/* XXX: This 256 number is arbitary---we've never done any measurement * of this. In fact, having a per-font glyph caches each managed * separately is probably not what we want anyway. Would probably be * much better to have a single cache for glyphs with random * replacement across all glyphs of all fonts. */ #define MAX_GLYPHS_CACHED_PER_FONT 256
We wrote a little patch to change the cache size through an environment variable; with it you can set CAIRO_SCALED_GLYPH_CACHE_SIZE to an arbitrary number. This makes it easy to run tests with different cache sizes.
Cache size Percentile Time (seconds) Writable memory 256 61.12 92.28 4732 KB 1024 89.52 59.60 4820 KB 2048 97.30 39.99 4960 KB 4096 99.77 38.40 4984 KB The percentile is based on the frequency of characters in Chinese: if you store the first 2048 most common characters, you'll hit the 97th percentile of all the characters in a piece of text. This seems to be the sweet spot; a bigger cache doesn't change the timings very much.
Memory usage does increase: when you increase the cache size from 256 entries to 2048, pango-profile increases its memory consumption by about 230 KB (from 4732 KB to 4960 KB in the table above). This will be larger for most applications since they will be loading fonts at various sizes, whereas pango-profile just uses one size.
After making the change to use 2048 entries for the scaled glyph cache, the profile looks a lot better. Near the top of the profile shown above, you can see pango_ot_buffer_output() take 60.71% of the total time. Now it is only 13.69%:
There seems to be some low-hanging fruit in that call to hb_buffer_ensure(). Pango seems to allocate many little buffers around there, but I don't really know what they are for. A little patch to print buffer reallocations gives us this:
reallocating HB_Buffer from 0 to 8 items reallocating HB_Buffer from 0 to 8 items reallocating HB_Buffer from 8 to 20 items reallocating HB_Buffer from 0 to 8 items reallocating HB_Buffer from 8 to 20 items reallocating HB_Buffer from 20 to 38 items reallocating HB_Buffer from 38 to 65 items reallocating HB_Buffer from 0 to 8 items reallocating HB_Buffer from 0 to 8 items reallocating HB_Buffer from 8 to 20 items reallocating HB_Buffer from 0 to 8 items reallocating HB_Buffer from 0 to 8 items reallocating HB_Buffer from 0 to 8 items reallocating HB_Buffer from 0 to 8 items reallocating HB_Buffer from 0 to 8 items reallocating HB_Buffer from 0 to 8 items reallocating HB_Buffer from 0 to 8 items
I.e. you can see that it creates new buffers pretty often, and resizes each one just a few times. Would it be possible to use a static buffer of a reasonable size, and only allocate another buffer if more space is needed? Cairo does this in a bunch of places with good results.
-
I'm in Beijing, where there is construction all over the place. This is the view from my hotel window:
-
I'm happy to see that openSUSE 10.3 is released. We've fixed a *ton* of bugs for this release. Whereas 10.2 was a disaster in terms of the quality of GNOME (we were all busy fixing things for SLED 10), 10.3 is really nice. More things seem to "just work" out the box than ever before, including suspend on my Thinkpad T41p and much faster boot time.
-
I was very sad to read Kohey Yoshida's horrible experience with Sun and his Calc Solver for OpenOffice.org. It reminds me of the days in which I was working on OO.o myself; it was as if the project was designed to discourage people from contributing. Essentially, if you want to contribute to OO.o because you think it is a tremendously important project, you have to do what Sun says. And Sun wants you do do this:
-
Give up your ownership of the code, i.e. copyright re-assignment. Ximian also did this for Evolution, and it's exactly the same reason why Evolution failed to attract outside contributors. "I'm writing code for free, and you want me to not own it? Screw that!"
-
Go through a massively bureaucractic process of writing specifications and getting them reviewed. I'm all for writing specifications before writing code, but you are not going to get weekend hackers to do this for every single minor change they want to make to the software. Even if you happen to write a major new module, your code has no chance of being included in OO.o if you don't go through the specification process.
-
Suffer through the technical mess. OO.o is hard to build, even with with the go-oo.org build infrastructure. It will probably kill your old hard drive and your computer's fan (it did for me). Wade through code that was written with zero attention to readability (footnote: and this applies to Mozilla as well — C++ is really good at making people think that you can turn it into a real language, while in fact you do nothing but put crutches to clutter the code into simulating the features of real languages).
Summary: We want to 0wn you. We will make your life hard. And our code will make your life hard, too.
With all that, I'm very happy that the go-oo.org team keeps doing amazing work under sensei Michael.
-
-
It's too bad Sun has been working as hard as they can, in their typical Sun way, to destroy Java by holding on to it so closely that nobody else can actually improve it.
If you s/Java/OpenOffice.org, it's still pretty accurate.
-
A little while ago we had a (periodically ocurring) discussion on why ChangeLogs are needed.
My new favorite way of committing is
$ git commit -m "One-line description here `head -42 ChangeLog`"
This gives you a nice and short description for gitk(1) and other tools like git-format-patch's message subjects, and the good old ChangeLog-as-commit-message. Note the newline between the one-line description and the "insert the top of the ChangeLog here" part.
-
I finally got off my ass and made the file chooser show exactly the same drives and volumes as Nautilus's places sidebar, and in the same order. This fix should be in libgnomeui-2.20.1 (it's already in the corresponding branch and in trunk).
-
Everyone: go check out Michael Meeks's iogrind tool. This is a valgrind skin plus a graphical tool to let you profile I/O easily. Be the first to re-live the heart-pounding, edge-of-seat profiling experience that we delivered during the Lightning Talks at GUADEC!
-
Are you an openSUSE user? Add your ICBM address to the openSUSE Community Map!