Tomboy 0.13.3, Tomboy 0.12.2, Tasque 0.1.8, and Giver!
- Tomboy 0.12.2, an update to the stable series, fixes a nasty bug that could cause notes to be mistakenly deleted during synchronization. Versions of Tomboy affected by this bug are: 0.12.0, 0.12.1, 0.13.0, 0.13.1. If you are using any of these versions, and you like to use sync (or set note contents via the dbus interface), please upgrade now! Note that this was fixed in the unstable series in Tomboy 0.13.2.
- Yesterday I finally made new Windows/Mac builds. You can get binaries for Tomboy 0.13.3 at our download page.
- Last month we released Tasque 0.1.8. It fixes problems communicating with RememberTheMilk.com and a kabillion other bugs. Windows and Mac binaries are available at the download page.
- Ankit Jain has started reviving Giver development. For one thing, he has Windows builds available for download (an obviously useful feature for a file sharing tool).
- I've discovered the best theme for openSUSE: Shiki Colors with the Shiki-Wise color scheme and the GNOME-Colors icon set.
So what else is going on? Tomboy 0.13.3 features some fixes that cut down my memory usage by 25% (with ~200 notes). It should also speed up start-up time if you have a big note collection. One user with 621 notes reported a change from 11 seconds to 4 seconds when he upgraded! The fixes were almost all related to extra work done on a per-note basis, so the memory and performance wins are most significant on these large note collections.
That being said, there is a lot more work to do on memory and performance. Ruben Vermeersch blogged about adapting Federico's timeline tracing tools to chart Tomboy start-up performance. This is going to be extremely helpful in figuring out where we're slowing things down. And as for memory usage, I have only fixed the low-hanging fruit; there are more wins to be had! If this is an area of computer science that you find fun, all help is welcome. :-)
My day job of working on the Mono Accessibility team has kept me pretty busy, and it's been hard lately to find time to work on Tomboy and Tasque. Sure, my team understands when I take a few hours every couple of weeks to prepare a Tomboy release, but that doesn't provide enough time for big feature work or difficult bug fixes. For example, we knew about the problems with Tasque and RememberTheMilk.com for a month before we were able to fix it and get a release out. Fortunately, Novell has its cool "ITO" (Innovation Time On) program. I accumulate 4 hours of ITO every week; that's basically the equivalent of 10% time! As I used up all of my regular time off with hospital visits last year, I scheduled four days of ITO during the week of Christmas. I was able to use that time to review a ton of outstanding patches for Tasque, fix the bugs in the RTM and SQLite backends, and make it easy to build on Windows and Mac OS X. This is also when I did all of the memory fixes for Tomboy. So a big thanks to Novell for supporting me in this work.
Lastly, I'm really excited about Ankit Jain's work on Giver. I never worked on Giver, unless you count the moral support I lent during that first Hackweek. :-) But I am amazed at how many people are asking for updates, Windows and Mac versions, etc. As somebody who works from home, Giver isn't that useful to me, but apparently it is very popular and more people are learning about it every day. With Ankit's help, this project may not be so dead after all. You can help him out by testing his Windows builds, trying latest SVN, filing issues, and hanging out in #giver on GIMPNet.
Tabbed Browsing for Packages
There are many approaches to managing software packages. Some users like to use command line tools like zypper. Others prefer a GUI tool like the YaST2 package selector. And even within such a GUI tool, there are many ways to deal with the packages you’d like to install, update or remove: Install a bunch of packages that make up a functionality like “KDE desktop” or “web development”, find one specific package with a known name, or just look through packages that are available. That’s why there are different filter views for those different approaches.
How do you select any of those filter views? In previous versions of the (Qt) package selector, we used to have a combo box to do that:
That’s somewhat unusual, and there have always been critics who claimed that we should use tabs instead. Our standard reply was always that this would not really be helpful because there are so many of them; you’d run out of screen space quickly, and with the number of filter views we have, this would look overwhelming and confusing:
Ugh… not good. Not even at this screen resolution. Now think about 800×480 netbooks and more verbose languages like German, French or Hungarian. No way to make this fit on the screen. And left/right scroll buttons are the last thing you want for tabs.
So, what else could we do?
Reduce the number of filter views? Well, we’ve been down that road for a while. But new ones come along all the time, and it always hurts some users when we throw out their favourite one. The “RPM groups” (the one with a tree) was such a case; it had to make way for the newer PackageKit groups. A number of users complained.
And we have more filter views in store. There are many more cool things we could do. But this should not add to confusion, so right now, we avoid to add more views.
But how is everybody else doing it? Let’s have a few looks at that.
What is it we are doing here? We are browsing for and through packages. So, let’s compare it with other kinds of browsers. Let’s look at Konqueror:
In Konqueror, you can use tabs. Once you got used to it, that’s a powerful and efficient way to avoid cluttering your screen with multiple browser windows. They are all neatly tucked away in that row of tabs.
Another application that uses a similar approach is Konsole, the KDE terminal emulator:
While in Konqueror you use the middle mouse button to open a link or a bookmark in a new tab, there is a limited number of options in Konsole. You select a session type from a pop-up menu on a special button on the bottom left corner:
So, let’s try someting similar with the YaST2 Qt package selector. Let’s try to use tabs, but not in an overwhelming number. Let’s open only a few of them right away. The user can open more if he likes.
First try:
Hm – or maybe put that “View” button in the top left corner?
Of course, the user can close any of the open tabs (except the last one) again – just like in Konqueror or in Konsole:
If we really do that, that means that the door is now no longer closed for new filter views. Some that could be added immediately are:
- Show all available (not installed) packages (yes, available via “Installation Summary”, but not that obvious to novice users)
- Show all installed packages (also available via “Installation Summary”)
- Keywords / tag cloud (“KDE application” (linked against KDE libs), “GNOME application”, “mail client”, “Java application”)
We don’t want to overdo it, of course.
So… what do you out there think? Do you like it? Should we use tabs there? If yes, where to put that “View” menu? Left? Right? Elsewhere? Use a toolbar button with just an icon (like in Konsole) instead? Add it to the main menu, too?
Comments? (on topic please, there are other tools and forums for support or bug reports)
Smolt Popup
kupdateapplet shows a popup that asks the user to send his/her hardware profile to the smolt project.

I think kupdateapplet isn’t the appropriate application for showing this notification because smolt has nothing in common with update installation.
I’ve written a tiny python-qt script that shows the smolt popup.
You can find a package called smolt-qt in my build service home. Feel free to test and comment!
libgphoto2 2.4.4 released!
So get it while it is hot. :)
- Improved Canon and Nikon remote capture, lots more to configure.
- Lots of bugfixes in the ptp driver.
- Faster startup in the ptp driver (but not as fast as it should be able to get).
And last but not least, translation updated, so you can say:
"Фотоаппарат не обнаружен" or "无法检测到任何相机" or "Impossible de détecter aucun appareil" or "Konnte keine Kamera finden", which hopefully all mean something like "Could not detect any camera".
And after 1 hour of uploading and updating news sites, I go to bed now. :)
Novell Teaming on SLES
As per the request of Andrew Wafaa, I thought I’d set up a quick guide to how I got teaming running on SLES. The documentation for Teaming on the administrative end was relatively sparse, but the installation guide was sufficient for most purposes.
Read on to learn more about Teaming and SLES…
Documentation
Most of the Teaming documentation can be found here: http://www.novell.com/documentation/team_plus_conf/
Prerequisites
- SLES (our server platform)
- OES2 (not entirely important, but it knocks out a lot of the pre-reqs and gives you LDAP support if you have eDirectory running)
- Teaming Licenses (a “starter pack” of 20 free licenses is available, contact your Novell vendor for more information)
- I’m assuming you’re running the setup from a Linux box, but this isn’t 100% necessary
Preparing your installation
There are a few things you need to do before getting started. First being to install mysql:
# zypper in mysql mysql-client mysql-shared perl-DBD-mysql perl-DBI perl-Data-ShowTable libmysqlclient-devel
# chkconfig –add mysql
# /etc/init.d/mysql start
# mysql_secure_installation
Next, you’ll need to edit your /etc/my.cnf to change the default character set support. Add the following lines to /etcmy.cnf:
[mysqld] character_set_server = utf8 [client] default_character_set = utf8
Additionally, you’ll need to increase your open file limits in /etc/security/limits.conf:
- hard nofile 65535
- soft nofile 4096
Installation
I like to run everything from a single location, so to kick things off, I created the directory ‘/incoming’. Once there, you’ll need to download your copy of Teaming and extract it into this directory.
Once you’ve gotten everything extracted, download your license file and copy it to the same directory, but make sure that you rename it to “license-key.xml”. The Teaming installer will complain to no end if it’s unable to find this exact file in the install root.
Next, you’ll need to make the installer executable:
# cd /incoming && chmod 755 installer-liferay.linux
Now it’s time to run the installer. The installer comes as a GUI package, but can be run via a text interface as well. If you’re ssh’ing into your server to set up Teaming, you’ll want to forward X to allow the GUI to open (ssh -X -C user@server.com). Otherwise, use the ‘-console’ knob to initiate the text based installer.
# ./installer-liferay.linux
-or-
# ./installer-liferay.linux -console
I recommend choosing advanced options for install as it allows for greater flexibility in options. Once you’ve followed through the installation steps (note, I installed mine copy into /opt/icecore), liferay/Teaming should be successfully installed. Now you’ll need to start the server:
# /opt/icecore/liferay-portal-tomcat-5.5-jdk5-4.3.0/bin/icecore start
To ensure that Teaming starts on boot, issue the following commands:
# cp /opt/icecore/liferay-portal-tomcat-5.5-jdk5-4.3.0/bin/icecore /etc/init.d
# chkconfig –add icecore
After that, you should be able to start, stop, and restart ‘icecore’ using the /etc/init.d/icecore script.
At this point, Teaming should be up and running. To access it and get started, open your browser and navigate to http://yourserver.com:8080 and log in as user admin with the password ‘admin’ (no quotes).
Once logged in, you’ll need to pull the administrative modules down to your view by selecting the ‘Add Content’ option in the upper right hand corner. I like to use the shotgun method and add all of the administrative modules for my admin user.
So there you have it, a fresh Teaming install. Enjoy!
Re: The Gtk+ File Chooser Dialog on openSUSE 11.1
It seems the fix already went to updates (btw i recommend enabling 11.1-test updates) because the openSUSE people is taking a long time to get updates pushed from developers, who already fixed lots of bugs.
So grab the fixed packages from federico home.
Voi lá!
Brasero 0.9.1 Released!!
Main highlight is the new libbrasero-media which results from the splitting brasero
Some more work was done to make brasero work with other apps like totem, rhythmbox and sound-juicer
Nautilus extension was updated (new hint, uses libbrasero-media).
+ some unreported bugs fixed
Reported bugs fixed:
#566721 – Wrong LDFLAGS introduced into BRASERO_*_LIBS
#567582 – Fails to burn a DVD iso
#561451 – Cannot burn CDs with brasero
#564748 – Brasero fails to burn DVDs
Updated translations:
* es.po: Jorge Gonzalez <jorgegonz@svn.gnome.org>
* fi.po: Ilkka Tuohela <hile@iki.fi>
* de.po: Mario Blättermann <mariobl@svn.gnome.org>
* ca.po: Updated Catalan translation by Joan Duran.
* fr.po: Claude Paroz <claude@2xlibre.net>
* zh_CN.po: 甘露(Gan Lu) <rhythm.gan@gmail.com>
* nb.po: Kjartan Maraas <kmaraas@gnome.org>
* sv.po: Daniel Nylander <po@danielnylander.se>
* it.po: Updated Italian translation by Milo Casagrande.
* pt_BR.po: Updated Brazilian Portuguese translation. Contributed by César Veiga.
* hu.po: Gabor Kelemen <kelemeng@gnome.hu>.
* da.po: Updated Danish translation by Mads Lundby
Thanks to all the people who contributed to this release through patches, translations, advices, artwork, bug reports.
Homepage: http://www.gnome.org/projects/brasero
Please report bugs to: http://bugzilla.gnome.org/browse.cgi?product=brasero
Mailing List for User and Developer discussion: brasero-list@gnome.org
Svn Repository: http://svn.gnome.org/viewcvs/brasero/
Thanks to all the people who contributed to this release through patches, translation, advices, artwork, bug reports.
PS: For the next release, since Brasero got accepted on Gnome Desktop platform for 2.26, Brasero versioning will be like other GNOME modules.
I'll blog about the inclusion later.
Graph of Storage Devices
With openSUSE 11.1 on the road we developers can use some time for new ideas. One idea on my mind for month was to show the dependencies of storage devices in a graph. Using graphviz and QGraphicsScene a first version was running within few days.
It’s far from finished. Some items still missing are:
- Use different shapes and colors for different devices types.
- Some basic user-interaction.
Will be available in Factory within the next weeks. Further improvements are welcome.
Modding the openSUSE flashlight
The boxed version of openSUSE 11.1 comes bundled with a LED-flashlight. Nice black and sturdy aluminum, Modern design with 9 white LEDs, no old-fashioned bulb that would produce more heat than illumination. Not flimsy, not heavy, just practical and quite bright. Batteries included. Exactly what I like.
But alas, this high-tech-toy is not perfect. The LEDs produce a strange unnatural light, which makes people look really sick. It gives a bluish-greenish tint to everything. This I don’t like. Okay, it is state of the art with regard to white LEDs, so this is no real reason to complain. Still, it leaves room for improvement.
Let us adjust the color of the light, so that objects look more natural. This posting explains you how to do it in 3 easy (or 4 not so easy) steps.
1 Disassembly
Unscrew the flashlight at the front end. Looking into the cap, you see a
printed circuit board (PCB) tucked down by a metal sheet ring.
I used a pair of good and pointed pliers to bite a notch in the ring to make it collapse. Then it can be pulled out easily. The PCB follows.
2 Reverse engineering
(This is the not so easy step. You can skip it. Step 3 will tell you right away
what you need.)
Inspecting the PCB, I find no resistors there, all LEDs are in parallel and are directly connect to the switch and battery pack. The battery pack provides 3×1.5 = 4.5 Volts — this is a bit too much for any LEDs. Blue and white ones have higheer voltages than other colors, but no datasheet I find for reference goes beyond 3.1V for white or 3.4V for blue. An Ohmmeter tells us, that the push-button switch at the back is only a switch, no resistors there. To see
what is really going on, we remove one of the LEDs, and solder a short length of thin two-wire cable in its place.
We also solder a 1cm piece of flexible wire onto one of the outer pads of the PCB to make contact with the housing. With this, we can reassemble the flashlight without metal ring and front glass, pulling the wires through the now vacant opening in the reflector.
Switching on, we can measure 3.5V at the wires. So all the LEDs in parallel are strong enough to pull down the voltage to an almost sane value, exploiting the internal resistance of those cheap AAA cells. Good.
I test one of my own white LEDs at the wires. It draws 35mA, which is above the nominal 20mA, but it seems to survive. Good. It is definitly brighter than the original LED, which only drew 18mA. Mine also has a larger viewing angle.
With this information, we can estimate that the original LEDs are rated ca. 2000-3000mcd, 3.3V, 15mA, and have ca. 12° viewing angle.
Now let us try to mix a more natural white.
A true white light radiates throughout the entire color spectrum. The human eye can adapt quite well to variations here. Covering a wide spectrum is important. Covering it evenly and without gaps is not.
For judging color quality, I collected a few photos, paintings, magazines, books and several other colorful objects and a white sheet of paper on my desk. You may use different objects. The idea is to compare colors under several lighting conditions. First we study colors in daylight, then with artificial light, and finally with an old fashioned flashlight (with a light bulb).
Now we test our flashlight and several different LEDs. We hold each LED in
parallel to the flashlight, and illuminate the objects and the piece of paper. Covering the exta LED with a finger is a fast way to see what kind of difference we may get.
The original impression was blue-ish. So let us start with yellow, the complementary color of blue.
First, we solder a yellow LED 10000mcd with an estimated 100 Ohm resistor to the wires. In my case it was not much effect. Doing some math, we find that we can risk a 47 Ohm resistor. Better, but red objects are still much to dark.
Next we test a red LED 12000mcd with 47 Ohm. Its viewing angle is wider and
the red was too strong for me. Back to 100 Ohm. Colors are quite good, but everything has a pink-ish touch, when compared to artificial light.
Finally, we try an orange LED 8000mcd with 47 Ohm. that looks quite good to me. Your results may vary, depending on the exact type of LEDs you are using.
This LED has a nominal voltage of 2.0V and current of 20mA, so the nominal resistor value should be (3.5V-2.0V)*0.020mA = 75 Ohm. Okay, It survived with 45 Ohms already, so we can try to lower the value a bit more (if we have one to spare). Let us try 30 Ohm for 5 minutes.
It survives and does not get too hot. The colors are quite nice, although the beam has an orange halo due to the wider viewing angle of the new LED.
We can cure this by replacing one (or a few) of the other LEDs with stronger white LEDs with the same 20° viewing angle as the orange LED has.
I also noted that shadows had green and orange edges, as I was holding my orange LED next to the white LEDs. To avoid these colorful shadows, we should place the orange LED in the center of the others. To reduce the halo, we apply at least one new white LED.
Now we have a plan.
3 Modding
Goal:
Have blue counteracted by sufficient orange. We may not get a perfectly balanced white but that does not matter.
Material:
- One orange LED 4000-8000mcd, 20° viewing angle. 600-610nm, 2.0V (e.g. Art Nr. 15601 or 13601 from www.leds.de)
- A small 30 Ohm resistor, smd-version if you dare.
- Optionally one (or more) white LED(s) ca 7000mcd, 20° viewing angle, 3.1V (e.g. Art Nr. 15005 from www.leds.de)
All in all ca. 0.50 EUR. (Or ca. 2 EUR if you want to replace all white LEDs too.)
Procedure:
- Remove the spring from the center pin by heating it with a soldering iron.
- Remove the center LED by heating both pins.
- Use a pointed knive to cut a gap into the circuit path leading from edge to center. Do not cut into your fingers. (Yes they are softer than the copper, but still, don’t do that.)
- Solder the 30 Ohm resistor across the gap. (Again, solder the copper, not your fingers, even if they have cuts by now.)
- Replace the center LED with the orange LED. The flat side (shorter wire) faces towards the resistor.
- Optionally replace some of the other LEDs bright white LEDs. The flat side
(shorter wire) faces outwards. - Solder the spring back in place, make sure it does not touch the other center LED pin, where the resistor is.
4 Re-Assembly
Take out the plastic glass from the cap, clean it. Put it back.
Fit the plastic reflector over the LEDs, this assembly into the cap.
Bring the metal ring back into shape. Maybe repair the ring by soldering.
Ideally, it snaps into the threading and can be screwed downwards.
If not, push it down onto the PCB using a screwdriver.
The ring should hold the PCB tight, we need good electrical contact
between the PCB and the housing.
Test your flashlight.
Was it worth it?
Saturday evening
What I want to mention is however that on the way back there were 3 young men sitting beside me in the bus who wanted me to take along into the nightlife of Nuernberg ... Age around 20ish. To places like Schmelztiegel and WON (World of Nightlive, a disco), both having visitors of average age of 18 or less ... Well guys, sorry to disappoint you, but I am not just tired from the day, I also am nearly double this age. (It is a bit sad though, since I would enjoy saturday nightlive occasionly ... but ... well.)
Work heavy week as usual, notably we brainstormed enhancements for the GPG key import dialog when adding new repositories to YaST2. It is difficult to secure and it is difficult to make it right, so that users can do good choices (and not just click "OK" to every question). We did not find an all dancing and singing solution, but hopefully some improvements can be done.
Wine 1.1.13 released, some more GPHOTO Nikon property additions and fixes done.

















