Mi blog lah! Το ιστολόγιό μου

3May/080

Using Anjuta in Ubuntu 8.04 to develop a GNOME C++ application (gtkmm)

You can install Anjuta 2.4.1 from the Synaptic package manager. You also need to install a few development packages. I do not know if there is a nice meta-package such as build-essential (used to install compilers et al), so I'll just ask you to install the packages by hand. A more elegant way would be very much appreciated to see in the comments.

$ sudo apt-get install build-essential libgtkmm-2.4-dev autogen automake libtool intltool libglademm-2.4-dev

That is the order of installation when you go trial by error inside Anjuta to compile a project. Each package draws in several other packages. Also, if you have the Ubuntu 8.04 DVD in your drive, most of these packages will be installed in a jiffy. We have the Greek localisation enabled, so bear with us. Thanks to Giannis Katsampiris for completing the recent update of the Anjuta 2.4 localisation.
Screenshot of Anjuta, initial screen (Localisation: Greek)
Once Anjuta is installed, you are presented with the Anjuta main window.

We then click on File/New/Project (Αρχείο/Νέο/1. Έργο),

Project creation wizard

We click on Forward here.

Choose project type

There are many many project types. We wade through and we pick to use C++ and GTKMM (C++ bindings for GTK+). We could pick any other variation; GTKMM was a request from the Ubuntu-gr mailing list.

Fill in some contact details

We then fill in some contact details.

Sorting out the project settings

There is an option to specify at this stage external packages. We opt not to specify them now.

We are actually done!

Once you click Apply (Εφαρμογή) - the button with the green tick, Anjuta will create an initial dummy package (actually a hello world application), and will run automatically the equivalent of ./configure for you.

Read to work!

Now, this is the final screen, when you start working. Here you would click on Κατασκευή/Κατασκευή έργου (Build/Build Project), so that the project gets compiled.

Then, you would click on Κατασκευή/Εκτέλεση προγράμματος... (Build/Run program...) to run the program!

Start typing!

Here is shows that we have located the source file (main.cc), and we see main().

It takes about 3 second to compile a program with g++ (at least on my system). Therefore, the dead time between (a) Let's compile it and (b) Oh, I am running my program!, is under 5 seconds, which is good.

23Mar/083

Timezones, clock applet and marketing dangers

It is great to receive feedback from users that try out the development versions of distributions (such as Ubuntu and Fedora). Usually, these are small bugs that can easily get fixed. However, there is this bug that looks potent to lead to political dissatisfaction and bad publicity to GNOME.

The clock applet (gnome-panel) now shows the timezones of cities that one selects. You click on the Edit button, you select the city (it comes from Locations.xml - libgweather, which has the coordinates of each city entry), and the applet makes a guess of what is your timezone (each timezone comes with longitude information).

So, if a city is far away from the capital city of your country (and closer to the capital city of a neighboring country), then the applet often proposes the wrong timezone. Considering that in some (=many) cases there is some animosity between neighboring countries, this makes users unhappy.

Launchpad bug report: Bug #185190, Clock applet chooses wrong timezone for many cities (eg Pittsburgh, Beijing)

GNOME Bugzilla bug report: Bug 519823 – Cities associated with wrong timezone

Updated (8Apr2008): The bug has been fixed upstream (thanks Dan!) and most likely makes it in GNOME 2.22.1, which means Ubuntu 8.04 and other distributions will get the update as well. Some countries with regions that have more than one timezone may want to check that the correct timezone is selected for each region.

15Mar/081

How to easily modify a program in Ubuntu (updated)?

Some time ago we talked about how to modify easily a program in Ubuntu. We gave as an example the modification of gucharmap; we got the deb source package, made the change, compiled, created new .deb files and installed them.

We go the same (well, similar) route here, by modifying the gtk+ library (!!!). The purpose of the modification is to allow us to type, by default, all sort of interesting Unicode characters, including ⓣⓗⓘⓢ , ᾅᾷ, ṩ, and many more.

The result of this exercise is to create replacement .deb packages for the gtk+ library that we are going to install in place of the system libraries. Because these new libraries will not be original Ubuntu packages, the update manager will be pestering us to rollback to the official gtk+ packages. This is actually good in case you want to switch back; you will have the enhanced functionality for as long as you postpone that update.

There is a chance we might screw up our system, so please make backups, or have a few drinks first and come back. I take no responsibility if something bad happens on your system. If you are having any second thoughts, do not follow the next steps; use the safer alternative procedure. You may try however this guide just for the kicks; up to the dpkg command below, no changes are being made to your system.

We use Ubuntu 7.10 here. This should work in other versions, though your mileage may vary.

The compilation procedure takes time (about 30 minutes) and space. Make sure you use a partition with >2GB of free space. We are not going to use up 2GB (a bit less than 1GB), but it's nice not to fill up partitions.

We are going to use the generic instructions on how to recompile a debian package by ducea.

First of all, install the development packages,

sudo apt-get install devscripts build-essential

Next, we use the apt-get source command to get the source code of the GTK+ 2 library,

cd /home/ubuntu/bigpartition_over2GB/
apt-get source libgtk2.0-0

We then pull in any dependencies that GTK+ may require. They are normally about a dozen packages, but we do not have to worry for the details.

apt-get build-dep libgtk2.0-0

At this stage we need to touch up the source code of GTK+ before we go into the compilation phase. Visit the bug report #321896 – Synch gdkkeysyms.h/gtkimcontextsimple.c with X.org 6.9/7.0 and download the patch (look under the Attachment section). You should get a file named gtk-compose-update.patch. If you have a look at the patch, you will notice that it expects to find the source of gtk+ in a directory called gtk+. Making a link solves the problem,

ln -s libgtk2.0-0 gtk+

We then attempt to apply the patch (perform a dry run), just in case.

patch -p0 --dry-run < /tmp/gtk-compose-update.patch

If this does not show an error message, you can the command again without the --dry-run.

patch -p0 < /tmp/gtk-compose-update.patch

Finally, we are ready to build our fresh GTK+ library.

cd libgtk2.0-0
debuild -us -uc

This will take time to complete, so go and do some healthy cooking.

At the end of the compilation, if all went OK, you should have about a dozen .deb files created. These are one directory higher (do a "cd .."). To install, use dpkg,

dpkg -i *.deb

If you have any other deb files in this directory, it's good to move them away before running the command. If all went ok, the .deb files should install without a hitch.

The final step is to restart your system. To test the new support, see the last section at this post. Use Firefox and OpenOffice.org to type those Unicode characters.

If you managed to wade through all these steps, I would appreciate it if you could post a comment.

Good luck!

5Mar/082

Testing the updated IM support in GTK+

In Improving input method support in GTK+-based apps, we talked about some work to update the list of compose sequences that GTK+ knows to the latest version that comes from Xorg. From 691 compose sequences, we now support over 5000.

The patch has landed in GTK+ (trunk), and here are instructions for testing.

  1. If you have not used jhbuild before, read the jhbuild instructions and install it.
  2. Add the following to your ~/.jhbuildrc file
    branches['gtk+'] = None    # Makes sure you build from the trunk of GTK+
  3. Install gtk+ using the command (see the comment of James on this post on how to avoid Step 5 below)
    jhbuild build gtk+
  4. About 40 minutes later, and about 700MB of space (~600MB for source, ~100MB for installation of files) consumed, you should get a working copy of GTK+ 2.12.
  5. You can use this compiled version of GTK+ by running
    jhbuild shell

    This should give you a new shell, and whatever you run from here will use our fresh GTK+. Try running "gedit". You will notice that the theme is different; it uses the default theme due to the special GTK+. This shell has set special environment variables so that program that run will use the fresh GTK+. The rest of the libraries come from our distribution.

  6. If you try to type compose sequences, you will notice no improvement. This is because at the moment jhbuild builds the branch 2.12 of GTK+ and not trunk. We need to download GTK+ from trunk and rebuild.
    cd ~/checkout/gnome2/
    mv gtk+ gtk+-branch-2.12
    svn co svn://svn.gnome.org/svn/gtk+/trunk gtk+
    jhbuild build --no-network gtk+
  7. Perform Step 4 and get gedit running.

How to test?

  • Setup a keyboard layout that supports a good variety of dead keys. My preference is GBr (United Kingdom). Here, AltGr+[];'#/ and AltGr+{}:@~? produce different dead keys. You press one of these combinations and then you press a letter. If such a combination exists, then it gets printed. For example, the old GTK+ produces öõóôòx åōőxxx. The new GTK+ produces öõóôòọ åōőǒŏȯ (12 dead keys).
  • Setup Greek, Polytonic (Ancient Greek). The dead keys are [];' {}:@ AltGr+[] (10 dead keys). Produce characters such as ᾅᾂᾷῗὕὒᾥᾢῷ.
  • Try compose sequences as described from the upstream file at XOrg. For example,
    ComposeKey+(   1 0 )  produces ⑩. Try the same for 0-20, a-zA-Z.
  • Other miscellaneous, Ṩǟấẫǡ (using GBr layout)

The next step would be to parse the list of compose sequences and produce a documentation file.

3Mar/084

Designing a command-line translation tool for GNOME

One messy task with GNOME translations is the whole workflow of getting the PO files, translating/updating/fixing them, and then uploading them back. One would need to use command line, and several different commands to accomplish this.

KDE and KBabel has a nice feature that allows you to easily grab all translation files, work on them, then commit through SVN. All through the GUI! It helps a bit here that the translation files for a specific language are located under a single directory.

The current workflow in GNOME translations typically consists of

  1. Getting the PO file from the L10n server (for example, GNOME 2.22 Greek) (also possible to use intltool-update within po/)
  2. Translate using KBabel, POEdit, GTranslator, vim, emacs, etc.
  3. svn co the package making sure you have the correct branch. One may limit to the po/ directory.
  4. Put the updated file in po/
  5. Update the ChangeLog (either with emacs, or with that Perl script)
  6. Commit the translation.
  7. (If you committed on a branch, also commit on HEAD)

Tools such as Transifex (used currently in Fedora) take away altogether the use of command line tools, and one works here through a web-based interface. Apparently, Transifex is having a command-line tool in the TODO list.
What I would like to see in GNOME translations, is a tool that one can use to

  1. Grab all or a section of the PO files from GNOME 2.22. Put them in a local folder.
  2. Use the tools of my preference (translation tools, scripts, etc) to update those translations I need to update.
  3. Commit those translation files that changed (using my SVN account), automatically add ChangeLog entries, also commit to HEAD if required.

I would prefer to have a command-line tool for this, for now, though it would be great if GUI tools would get the same functionality at some point. For a command line tool, the workflow would look like

The workflow would be something like

$ ssh-add
Enter passphrase for /home/simos/.ssh/id_rsa:
Identity added: /home/simos/.ssh/id_dsa (/home/simos/.ssh/id_dsa)
$ tsfx --project=gnome-2.22 --language=el --collection=gnome-desktop --user=simos --action=checkout
Reading from http://svn.gnome.org/svn/damned-lies/trunk/releases.xml.in... done.
Getting alacarte (HEAD)... done.
Getting bug-buddy (branch: xyz)... done.
...
Completed in 4:11s.
$ _

Now we translate any of the files we downloaded, and we push back upstream (of course, only those files that were changed).

$ tsfx --action=commit
Found local repository, Project: gnome-2.22, Language: el, Collection: gnome-desktop, User: simos
 Reading local files...
Found 6 changed files.
Uploading alacarte (HEAD)... done.
Uploading bug-buddy (branch:xyz, HEAD)... done.
...
Completed uploading translation files to gnome-2.22, language el.
$ _
29Feb/081

FOSDEM ’08, summary and comments

I attended FOSDEM '08 which took place on the 23rd and 24th of February in Brussels.

Compared to other events, FOSDEM is a big event with over 4000 (?) participants and over 200 lectures (from lightning talks to keynotes). It occupied three buildings at a local university. Many sessions were taking place at the same time and you had to switch from one room to another. What follows is what I remember from the talks. Remember, people recollect <8% of the material they hear in a talk.

The first keynote was by Robin Rowe and Gabrielle Pantera, on using Linux in the motion picture industry. They showed a huge list of movies that were created using Linux farms. The first big item in the list was the movie Titanic (1997). The list stopped at around 2005 and the reason was that since then any significant movie that employs digital editing or 3D animation is created on Linux systems. They showed trailers from popular movies and explained how technology advanced to create realistic scenes. Part of being realistic, a generated scene may need to be blurred so that it does not look too crisp.

Next, Robert Watson gave a keynote on FreeBSD and the development community. He explained lots of things from the community that someone who is not using the distribution does not know about. FreeBSD apparently has a close-knit community, with people having specific roles. To become a developer, you go through a structured mentoring process which is great. I did not see such structured approach described in other open-source projects.

Pieter Hintjens, the former president of the FFII, talked about software patents. Software patents are bad because they describe ideas and not some concrete invention. This has been the view so that the target of the FFII effort fits on software patents. However, Pieter thinks that patents in general are bad, and it would be good to push this idea.

CMake is a build system, similar to what one gets with automake/autoconf/makefile. I have not seen this project before, and from what I saw, they look quite ambitious. Apparently it is very easy to get your compilation results on the web when you use CMake. In order to make their project more visible, they should make effort on migration of existing projects to using CMake. I did not see yet a major open-source package being developed with CMake, apart from CMake itself.

Richard Hughes talked about PackageKit, a layer that removes the complexity of packaging systems. You have GNOME and your distribution is either Debian, Ubuntu, Fedora or something else. PackageKit allows to have a common interface, and simplifies the workflow of managing the installation of packages and the updates.

In the Virtualisation tracks, two talks were really amazing. Xen and VirtualBox. Virtualisation is hot property and both companies were bought recently by Citrix and Sun Microsystems respectively. Xen is a Type 1 (native, bare metal) hypervisor while VirtualBox is a Type 2 (hosted) hypervisor. You would typically use Xen if you want to supply different services on a fast server. VirtualBox is amazingly good when you want to have a desktop running on your computer.

Ian Pratt (Xen) explained well the advantages of using a hypervisor, going into many details. For example, if you have a service that is single-threaded, then it makes sense to use Xen and install it on a dual-core system. Then, you can install some other services on the same system, increasing the utilisation of your investment.

Achim Hasenmueller gave an amazing talk. He started with a joke; I have recently been demoted. From CEO to head of virtualisation department (name?) at Sun Microsystems. He walked through the audience on the steps of his company. The first virtualisation product of his company was sold to Connectix, which then was sold to Microsoft as VirtualPC. Around 2005, he started a new company, Innotek and the product VirtualBox. The first customers were government agencies in Germany and only recently (2007) they started selling to end-users.

Virtualisation is quite complex, and it becomes more complex if your offering is cross platform. They manage the complexity by making VirtualBox modular.

VirtualBox comes in two versions; an open-source version and a binary edition. The difference is that with the binary edition you get USB support and you can use RDP to access the host. If you installed VirtualBox from the repository of your distribution, there is no USB support. He did not commit whether the USB/RDP support would make it to the open-source version, though it might happen since Sun Microsystems bought the company. I think that if enough people request it, then it might happen.

VirtualBox uses QT 3.3 as the cross platform toolkit, and there is a plan to migrate to QT 4.0. GTK+ was considered, though it was not chosen because it does not provide yet good support in Win32 (applications do not look very native on Windows). wxWidgets were considered as well, but also rejected. Apparently, moving from QT 3.3 to QT 4.0 is a lot of effort.

Zeeshan Ali demonstrated GUPnP, a library that allows applications to use the UPnP (Universal Plug n Play) protocol. This protocol is used when your computer tells your ADSL model to open a port so that an external computer can communicate directly with you (bypassing firewall/NAT). UPnP can also be used to access the content of your media station. The gupnp library comes with two interesting tools; gupnp-universal-cp and gupnp-network-light. The first is a browser of UPnP devices; it can show you what devices are available, what functionality they export, and you can control said devices. For example, you can use GUPnP to open a port on your router; when someone connects from the Internet to port 22 on your modem, he is redirected to your server, at port 22.

You can also use the same tool to figure out what port mapping took place already on your modem.

The demo with the network light is that you run the browser on one computer and the network light on another, both on the local LAN (this thing works only on the local LAN). Then, you can use the browser to switch on/off the light using the UPnP protocol.

Dimitris Glezos gave a talk on transifex, the translation management framework that is currently used in Fedora. Translating software is a tedious task, and currently translators spent time on management tasks that have little to do with translation. We see several people dropping from translations due to this. Transifex is an evolving platform to make the work of the translator easier.

Dimitris talked about a command-line version of transifex coming out soon. Apparently, you can use this tool to grab the Greek translation of package gedit, branch HEAD. Do the translation and upload back the file.

What I would like to see here is a tool that you can instruct it to grab all PO files from a collection of projects (such as GNOME 2.22, UI Translations), and then you translate with your scripts/tools/etc. Then, you can use transifex to upload all those files using your SVN account.

The workflow would be something like

$ tfx --project=gnome-2.22 --collection=gnome-desktop --action=get
Reading from http://svn.gnome.org/svn/damned-lies/trunk/releases.xml.in... done.
Getting alacarte... done.
Getting bug-buddy... done.
...
Completed in 4:11s.
$ _

Now we translate any of the files we downloaded, and we push back upstream (of course, only those files that were changed).

$ tfx --project=gnome-2.22 --collection=gnome-desktop --user=simos --action=send
 Reading local files...
Found 6 changed files.
Uploading alacarte... done.
...
Completed uploading translation files to gnome-2.22.
$ _

Berend Cornelius talked about creating OpenOffice.org Wizards. You get such wizards when you click on File/Wizards..., and you can use them to fill in entries in a template document (such as your name, address, etc in a letter), or use to install the spellchecker files. Actually, one of the most common uses is to get those spellchecker files installed.

A wizard is actually an OpenOffice.org extension; once you write it and install it (Tools/Extensions...), you can have it appear as a button on a toolbar or a menu item among other menus.

You write wizards in C++, and one would normally work on an existing wizard as base for new ones.

When people type in a word-processor, they typically abuse it (that's my statement, not Berend's) by omitting the use of styles and formatting. This makes documents difficult to maintain. Having a wizard teach a new user how to write a structured document would be a good idea.

Perry Ismangil talked about pjsip, the portable open-source SIP and media stack. This means that you can have Internet telephony on different devices. Considering that Internet Telephony is a commodity, this is very cool. He demonstrated pjsip running two small devices, a Nintendo DS and an iPhone. Apparently pjsip can go on your OpenWRT router as well, giving you many more exciting opportunities.

Clutter is a library to create fast animations and other effects on the GNOME desktop. It uses hardware acceleration to make up for the speed. You don't need to learn OpenGL stuff; Clutter is there to provide the glue.

Gutsy has Clutter 0.4.0 in the repositories and the latest version is 0.6.0. To try out, you need at least the clutter tarball from the Clutter website. To start programming for your desktop, you need to try some of the bindings packages.

I had the chance to spend time with the DejaVu guys (Hi Denis, Ben!). Also met up with Alexios, Dimitris x2, Serafeim, Markos and others from the Greek mission.

Overall, FOSDEM is a cool event. In two days there is so much material and interesting talks. It's a recommended technical event.

20Feb/087

Keyboard layout for combining diacritics

Typically, if you want to type characters with accents, such as á, ë, ś, you need to configure a suitable keyboard layout that includes compose sequences for those characters. The produced characters are what we call as precomposed characters; which were included in the early stages of Unicode. Nowdays, the idea is that you do not need to define á as a distinct character because it can be represented as a and ´, where the latter is a combining diacritic.

When put together a character and a combining diacritic, they fuse together, producing a seemingly single character. á is a precomposed (really one character), while á is letter a and the combining diacritic called acute (two characters). You can type the latter á by

  1. Type a
  2. Press Ctrl+Shift+u, then type 301, then press space bar.

Western languages do not really require combining marks, so the existing keyboard layouts do not use them. Other scripts, such as the Congolese keyboard layout (based on Latin) make good use of them.

Gedit, pango and combining diacritics

This is gedit showing off pango and DejaVu fonts (default font in major distributions).

Line 3 is a bit of an extreme, showing a sandwich of combining diacritics.

Line 4 shows the base character a with the combining diacritics from the Unicode range 0x300 to 0x315.

Both lines 3 and 4 were produced easily with a modified keyboard layout, which is show below.

Line 5 is just me being silly. You can have combining diacritics that enclose your base character.

$ cat  /usr/share/X11/xkb/symbols/combining
partial alphanumeric_keys alternate_group
xkb_symbols "combining" {

    name[Group1] = "Combining diacritics";

    key.type[Group1] = "FOUR_LEVEL";

    key <AD11> { [ NoSymbol, NoSymbol, 0x1000300, 0x1000301 ] }; // à   á
    key <AD12> { [ NoSymbol, NoSymbol, 0x1000302, 0x1000303 ] }; // â   ã

    key <AC10> { [ NoSymbol, NoSymbol, 0x1000304, 0x1000305 ] }; // ā   a̅
    key <AC11> { [ NoSymbol, NoSymbol, 0x1000306, 0x1000307 ] }; // ă   ȧ
    key <BKSL> { [ NoSymbol, NoSymbol, 0x1000308, 0x1000309 ] }; // ä    ả

    key <AB08> { [ NoSymbol, NoSymbol, 0x1000310, 0x1000311 ] }; // a̐     ȃ
    key <AB09> { [ NoSymbol, NoSymbol, 0x1000312, 0x1000313 ] }; // a̒     a̓
    key <AB10> { [ NoSymbol, NoSymbol, 0x1000314, 0x1000315 ] }; // a̔     a̕
};
$ diff -u /usr/share/X11/xkb/symbols/us.ORIGINAL /usr/share/X11/xkb/symbols/us
--- /usr/share/X11/xkb/symbols/us.ORIGINAL      2008-02-20 11:11:13.000000000 +0000
+++ /usr/share/X11/xkb/symbols/us       2008-02-20 13:02:07.000000000 +0000
@@ -492,3 +492,12 @@
     name[Group1]= "U.S. English - Macintosh";
 };

+partial alphanumeric_keys modifier_keys
+xkb_symbols "combining_us" {
+
+    include "us"
+    include "combining"
+
+    key.type[Group1] = "FOUR_LEVEL";
+    name[Group1] = "U.S. English - Combining";
+};
$ diff -u /usr/share/X11/xkb/rules/xorg.xml.ORIGINAL /usr/share/X11/xkb/rules/xorg.xml
--- /usr/share/X11/xkb/rules/xorg.xml.ORIGINAL  2008-02-20 11:27:00.000000000 +0000
+++ /usr/share/X11/xkb/rules/xorg.xml   2008-02-20 11:27:48.000000000 +0000
@@ -3643,6 +3643,12 @@
             <description xml:lang="zh_TW">Macintosh</description>
           </configItem>
         </variant>
+        <variant>
+          <configItem>
+            <name>combining_us</name>
+            <description>Combining</description>
+          </configItem>
+        </variant>
       </variantList>
     </layout>
     <layout>
$ _

Then, you select this keyboard layout (U.S. English) and variant (Combining) in the Keyboard Indicator applet.

Unlike dead keys, with combining diacritics you first type the base character (such as a) and then any combining diacritics.
Our sample layout variant puts the diacritics in the physical keys for [];'#,./. For example,

  • a + AltGr+[ : à
  • a + AltGr+Shift+[ : á
  • a + AltGr+[ + AltGr+' : ằ

If your language has needs that can be solved with combining diacritics, this is how they are solved.

It is quite important to create keyboard layouts for all languages, and actually make good use of them.

18Feb/084

Create flash videos of your desktop with recordmydesktop

John Varouhakis is the author of recordmydesktop and gtk-recordmydesktop (front-end) which is a tool to help you record a session on your Linux desktop and save it to a Flash video (.flv).

To install, click on System/Administration/Synaptic Package Manager, and search for gtk-recordmydesktop. Install it. Then, the application is available from Applications/Sound&Video/gtkRecordMyDesktop.

Screenshot of gtk-recordmydesktop

Before you are ready to capture your Flash video, you need to select the video area. There are several ways to do this; the most common is to click on Select Window, then click on the Window you want to record. A common mistake is that people try to select the window from the preview above. If you do that, when you would have selected the recorder itself to make a video of, which is not really useful. You need to click on the real window in order to select it; then, in the desktop preview you can see the selected window. In the above case, I selected the OpenOffice Writer window.

Assuming that you do not need to do any further customisation, you can simple press Record to start recording. Generally, it is good to check the recording settings using the GNOME Sound recorder beforehand. While recording, you can notice a special icon on the top panel. This is gtk-recordmydesktop. Once you press it, recording stops and the program will do the post-processing of the recording. The resulting file goes into your home folder, and has the extension .ogv.

Some common pitfalls include

  • I did not manage to get audio recording to work well for my system; I had to disable libasound so that the audio recording would not skip. With ALSA, sound skips while with OSS emulation it does not. Weird. Does it work for you?
  •  The post-processing of the recording takes some time. If you have a long recording, it may take some time to show that it makes progress, so you might think it crashed. Have patience.

I had made one such recording, which can be found at the Greek OLPC mailing list. John told me that the audio part of the video was not loud enough, and one can use extra post-processing to make it sound better. For example, one could extract the audio stream of the video, remove the noise, beautify (how?) and then add back to the video.

It's good to try out gtk-recordmydesktop, even for a small recording. Do you have some cool tips from your Linux desktop that you want to share? Record your desktop!

3Feb/082

Typing squiggles and dots in GNOME and GTK+ applications

Garrett asks how to type squiggles and dots in GNOME; that is, how to type characters such as á à ä ã â ą ȩ ę ő ǰ ǩ ǒ ġ ṅ ȯ ṁ ė.

There are several ways, and one can choose depending on how frequently they need to type them or how much time they need to invest learning.

① One option is to start the Character Map (Applications/Accessories/Character Map), pick the character, copy and paste it. This is good for rare characters and weird situations such as

┏━━━━━━━━━━━━━━━━━━━━━━━┓

⟁⟁⟁⟁♥♀★★▶◀☆♀░░░▒▒▒▓▓▓▙▚▛▙▙▙▞

The Unicode standard, apart from defining characters for languages, it also defines symbols, dingbats and all sort of things. If your distribution is based on the DejaVu fonts (such as Ubuntu), then you are probably covered for many of these symbols. If you do not have a suitable font, or you use Windows, you will be wondering what the hell I am talking about.

② Another option is to use the Character Palette applet which shows an applet on the panel with a configurable small repertoire of characters such as áàéíñó½©ث€. You select one of the characters with the mouse, and wherever you middle-click, this character is typed. This is an improvement over ①, and good when you want to type often rare characters. It is not convenient to type characters found normally on a keyboard layout.

③ To type characters normally found in a specific language(s), it is good to setup a suitable keyboard layout. For this, it is good to add the Keyboard Indicator applet; right click on the panel, click Add to panel... and choose the Keyboard Indicator from the Utilities section. The US English keyboard layout (Default variant) does not provide any interesting characters apart from those shown printed on the keys of a US Keyboard.
Keyboard layout US Intl with dead keys
The US English International (with dead keys) variant might be a better option,

Keyboard layout GB

Or the United Kingdom layout.

You can get a similar image for your layout when you right-click on the Keyboard Indicator applet, then click Show Current Layout.

Each key in the images contain up to four letters. Starting from bottom-left and going clock-wise, these are the keys produced when

ⓐ you press the key

ⓑ you press the key with Shift (or Caps Lock)

ⓒ you press the key with AltGr and Shift (or Caps Lock)

ⓓ you press the key with AltGr

For example, with the UK keyboard layout, the key G produces g, G, Ŋ, ŋ.

If AltGr + Shift + letter does not work for you, see the FDO Bug #2871 Different results for shift-altgr and altgr-shift.

Using the appropriate keyboard layout is the way to go when writing text that require squiggles. You can either choose a layout with dead keys (meaning that some keys lose their normal functionality), or you can pick a layout that still allows you to have dead keys but are available when you press AltGr + key. For example, in the UK Keyboard layout - Default variant, AltGr + ; + a produces á, or AltGr+Shift+]+e produces ē.

OLPC showing the keyboard

Photo by titanas.

The OLPC uses those four level for the keyboard layout. You can see the all the variations printed on the keyboard. Click on the image, choose Large size for the details.

④ Another option to produce more characters on the keyboard is to enable the compose key, and use compose sequences. A compose sequence looks similar to what we described above (i.e. AltGr+Shift+]+e to ē) but the idea is that we use it for characters we want to be available across different keyboard layouts that you may have enabled.
Configuring the compose key
The compose key is very powerful functionality, thus it is not enabled by default, and lays hidden in the Layout Options tab. I prefer to set it to Menu, but every person has their own preference.

For example,

  • Compose key + - + a produces ã,
  • Compose key + < + c produces č
  • Compose key + 1 + s produces ¹ (Superscript on 1. Try to replace 1 with 2.)
  • Compose key + + + - procudes ±

Currently, GTK+ provides 640 such compose sequences involving the Compose key, and hopefully soon it will increase to over 3000.

The Compose key is known as Multi_key in the source code (Xorg, GTK+, etc).

The Compose key compose sequences offer the ability to define smart mnemonics on how to produce characters. It is much easier to type ComposeKey + 1 + s rather than remembering the codepoint value of ¹ (1 superscript). As with many things open-source, there are too many options, and with the Compose key there is the issue of which shall we pick as a sensible default, and how to make it prominent for those who might want to use it.

It appears to me that there should be more effort to promote the functionality that is provided with the standard keyboard layouts (choose a better keyboard layout, produce characters provided in the third and fourth levels, etc). In this respect, Compose key compose sequences should complement after the main discussion on keyboard layouts take place.

⑤ There is a last issue on switching keyboard layouts to cover in a separate post.

30Jan/084

Improving input method support in GTK+-based apps

When a bug report gets long with many comments, it gets more difficult for someone to get the full picture of what is going on. I'll attempt to summarise here what's being said in Bug 321896, Synch gdkkeysyms.h / gtkimcontextsimple.c with X.org 6.9/7.0.

GTK+-based applications use by default the GTK+ Input Method in order to let users type in different languages. Some scripts are very complex (such as SE Asian scripts) and in this case SCIM is used, replacing the GTK+ Input Method. One can even disable GTK+ IM altogether and use the basic X Input Method (XIM) which is provided by the Xorg server, by setting GTK_IM_MODULE to xim. However, the majority of the users have GTK+ IM enabled.

Between GTK+ IM and XIM, the keyboard layouts are being managed by the xkeyboard-config project and Sergey Udaltsov. A keyboard layout is simply a mapping of keyboard keys to Unicode characters, but you can also have compose sequences for some characters using what we call dead keys. When you press a dead key nothing appears on screen but when you press a letter immediately afterwards, you can get an á. This functionality is common to add accents, and there is a big table for these compose sequences (1.3MB) and what Unicode characters they produce.

If you change your keyboard layout (System/Preferences/Keyboard/Layout) to something like U.S. English International (with dead keys), then the ' key on your keyboard becomes dead_acute, and the compose sequence

<dead_acute> <a>  : "á"   U00E1 # LATIN SMALL LETTER A WITH ACUTE

works when you press ' and then a.

There is an issue with compose sequences and input methods; XIM maintains the official upstream version of the compose sequences, and projects such as GTK+ and SCIM carry their own copies of that table.

The issue with GTK+ regarding the compose sequences is that it has a very old version compared to what is available upstream. This is what Bug 321896 is about.

The bug would be have been resolved much much earlier if it wasn't for the insistence of the GTK+ maintainers to cut the fat and reduce the size of the table (~6000 entries) with clever optimisations.

Tor suggested a clever optimisation; a good number of compose sequences (which looks like <dead_acute> <a> : "á") resemble the decomposed form (a la Unicode) of those characters. Thus, we can let the user type what she wants, and we can try Unicode normalisation to see if the sequence is composed to a single Unicode character. Lets demonstrate in Python,

$ python
>>> import unicodedata
>>> sequence=[65, 0x301]     # That's 'a' and acute
>>> result = unicodedata.normalize('NFC',"".join(map(unichr, sequence)))
>>> result
u'\xc1'
>>> print len(result)
1
>>> print result
Á

That long line above takes the array, applies the unichr() function on each member so that they become Unicode characters and then joins them in a single string. Finally, it normalises the (decomposed) string to a single character. The fact that the resulting string has length 1 (single character) is key to this optimisation. Over 1000 compose sequences can be removed from the compose table through this optimisation. This includes a big chunk of the Latin Unicode blocks, about a few dozens of Cyrillic characters, all of modern Greek and Greek polytonic, some Indic languages (are they actually used?) and other misc sequences.

Matthias laid out the requirements for the optimisation of the remaining compose sequences; ① it has to be static const so a single copy is shared all over the place, ② the first column (out of six) is repeated too often, thus use subtables, and ③ each row ends with a varying number of zeroes, so cut on those zeroes as well. This also required the automatic generation of the optimised table using a script.

The work has not finished yet, and requires testing of the patch. The high priority testing is that keyboard layouts do not get any regressions (that is, compose sequences with dead keys must continue to work along with any new sequences).

With an updated compose table in GTK+, one can write things like ⒼⓃⓄⓂⒺ and all variations of accents on characters, in an easier way.

I'ld like to thank Matthias and Tor for their support in this work. And Jeff for adding this blog to Planet GNOME!

3Dec/070

The Google Highly Open Participation Contest

One more initiative by Google to reach out to the community and promote free and open-source software is the The Google Highly Open Participation Contest 2007/2008.

The purpose of the competition is to enable young students older than 13 years old but have not entered yet the tertiary education, to participate in open-source development.

To get started, read the Official Contest Rules and the Frequently Asked Questions (FAQ) pages.

There are ten projects to choose to work from, one of which is GNOME, the desktop environment found in Linux distributions such as Ubuntu Linux and Fedora.

The current list of items to work on for GNOME include several documentation and translation tasks. If there is interest to work on the Greek localisation, leave a comment at this post. The direction I propose is to help with translating the documentation of GNOME applications.

Open-source software progresses by having more people contributing. This effort by Google and also previous efforts (Google Summer of Code) help tremendously towards the wider participation.

16Nov/078

Droid fonts from Google (Android SDK)

Update 10Feb2009: The Droid fonts are now available from android.git.kernel.org (Download tar.gz archive), under the Apache License, Version 2.0. Ascender (the company who created Droid), has now a dedicated website at http://www.droidfonts.com/ (thanks Rex!). At this dedicated website, Ascender presents the Droid Pro family which has several additions to Droid. For the open-source crowd, it is important to have the initial Droid font family dual-licensed under the “OpenFont License”, which would enable the best use with the rest of the OFL licensed fonts.

Two years ago, Google bought a start-up called Android in order to deliver an open platform for mobile applications. A few days ago the Android SDK has been released and you can develop now Android applications that can run in the emulator. Android handsets are expected at some point next year.

Even if you do not plan to develop applications for Android, you can still run the emulator which is functional, includes quite a few samples, and comes with a browser shown above. To get it, download the Android SDK for your system, uncompress it and run

./android_sdk_linux_m3-rc20a/tools/emulator

An interesting aspect of Android is that it comes with a set of fonts that have been specially designed for mobile devices, the Droid fonts. The fonts are embedded in the Android image, in android_sdk_linux_m3-rc20a/tools/lib/images/system.img, a clever guy managed to extract them and a modest guy corrected me (Damien's blog to download).

The fonts are probably licensed under the same license as the SDK (Apache License), however it is better to hear from Google first.

In the meantime, here is a screenshot of Ubuntu 7.10 with Droid.

Update: To extract the fonts from the SDK, run the emulator with the -console parameter. The emulator starts and at the same time you get a shell to the filesystem of the running emulator. You can locate the fonts in system/fonts/. Once located the full path of a file, you can extract with ./adb pull system/fonts/DroidSans.ttf /tmp/DroidSans.ttf (thanks cosmix for the tip).

Switch to our mobile site