Tag : source-code

Playing with Git

Git is a version control system (VCS) software that is used for source code management (SCM). There are several examples of VCS software, such as CVS and SVN. What makes Git different is that it is a distributed VCS, that is, a DVCS.

Being a DVCS, when you use Git you create fully capable local repositories that can be used for offline work. When you get the files of a repository, you actually grab the full information (this makes the initial creation of local repositories out of a remote repository slower, and the repositories are bigger).

You can install git by installing the git package. You can test it by opening a terminal window, and running

git clone git://github.com/schacon/whygitisbetter.git

The files appear in a directory called whygitisbetter. In a subdirectory called .git/,git stores all the controlling information it requires to manage the local repository. When you enter the repository directory (whygitisbetter in our case), you can issue commands that will figure out what’s going on because of the info in .git/.

With git, we create local copies of repositories by cloning. If you have used CVS or SVN, this is somewhat equivalent to the checkout command. By cloning, you create a full local repository. When you checkout with CVS or SVN, you get the latest snapshot only of the source code.

What you downloaded above is the source code for the http://www.whygitisbetterthanx.com/ website. It describes the relative advantages of git compared to other VCS and DVCS systems.

Among the different sources of documentation for git, I think one of the easiest to read is the Git Community Book. It is consise and easy to follow, and it comes with video casting (videos that show different tasks, with audio guidance).

You can create local repositories on your system. If you want to have a remote repository, you can create an account at GitHub, an attractive start-up that offers 100MB free space for your git repository. Therefore, you can host your pet project on github quite easily.

GitHub combines source code management with social networking, no matter how strange that may look like. It comes with tools that allows to maintain your own copies of repositories (for example, from other github users), and helps with the communication. For example, if I create my own copy of the whygitisbetter repository and add something nice to the book, I can send a pull request (with the click of a button) to the maintainer to grab my changes!

If you have already used another SCM tool (non-distributed), it takes some time to get used to the new way of git. It is a good skill to have, and the effort should pay off quickly. There is a SVN to Git crash course available.

If you have never used an SCM, it is cool to go for git. There is nothing to unlearn, and you will get a new skill.

Git is used for the developement of the Linux kernel, the Perl language, Ruby On Rails, and others.

Should UI strings in source code have non-ASCII characters?

There is a discussion going on at desktop-devel about whether the UI strings in the source code should also have non-ASCII characters. For example, should typical strings with double-quotes have those fancy Unicode double quotes?

printf(_("Could not find file “%s”n"));

instead of

printf(_("Could not find file "%s"n"));

The general view from the replies is to go ahead and add those nice Unicode characters.

Actually, there are UI messages already with non-ASCII characters (the ellipsis character, …) in GNOME 2.22:

  1. glade3
  2. epiphany

In GNOME 2.24, there are even more (with ellipsis):

  1. gucharmap
  2. epiphany
  3. gnome-terminal
  4. gedit
  5. glade3

Regarding the fancy Unicode double quotes, there are UI strings in GNOME 2.22 (same list for 2.24) in the following packages:

  1. evince
  2. cheese
  3. epiphany
  4. eog
  5. gnome-doc-utils

What are the arguments against having non-ASCII characters in UI strings?

  1. There might be systems that still use 8-bit legacy encodings. In this case, the UTF-8 encoded may not be displayed properly. However, when I tried to demonstrate this on my system (Ubuntu 8.04), I failed miserably. I downloaded a small GTK2 text editor (called tea), I changed a source UI string to include “” and ellipsis, compiled and installed. I then opened a shell, set LANG to POSIX (or C), and ran the text editor. The UI message was proper Unicode and I could even type non-ASCII in the text editor. I resorted to changing a system locale (I picked en_IN) to ISO-8859-1, then logged out. In the login screen it did not show the 8-bit encoding. If someone has a proper legacy 8-bit encoding system with GNOME (OpenBSD, FreeBSD, etc), could you please try it out?
  2. As Alan Cox mentioned in the thread, the canonical way to deal with UI strings in the source code should be to keep as ASCII, and put any fancy Unicode characters in the translation files (even for en_US, get an en_US translation file).

Is GNOME (or components) used in a legacy 7-bit/8-bit environment?

If there is any reason to keep UI strings in the source code as plain ASCII, speak now, or the Unicode flood gates are about to open.

Update 16 May 2008:There is a document at the ISO/IEC 9899 website (C programming language), that mentions the issue of character sets in C. It is http://www.open-std.org/jtc1/sc22/wg14/www/docs/C99RationaleV5.10.pdf.

On page 26, section 5.2.1, it says

The C89 Committee ultimately came to remarkable unanimity on the subject of character set requirements. There was strong sentiment that C should not be tied to ASCII, despite its heritage and despite the precedent of Ada being defined in terms of ASCII. Rather, an implementation is required to provide a unique character code for each of the printable graphics used by C, and for each of the control codes representable by an escape sequence. (No particular graphic representation for any character is prescribed; thus the common Japanese practice of using the glyph “¥” for the C character “” is perfectly legitimate.) Translation and execution environments may have different character sets, but each must meet this requirement in its own way. The goal is to ensure that a conforming implementation can translate a C translator written in C.

For this reason, and for economy of description, source code is described as if it undergoes the same translation as text that is input by the standard library I/O routines: each line is terminated by some newline character regardless of its external representation.

With the concept of multibyte characters, “native” characters could be used in string literals and character constants, but this use was very dependent on the implementation and did not usually work in heterogenous environments. Also, this did not encompass identifiers.

It then goes on with an addition to C99:

A new feature of C99: C99 adds the concept of universal character name (UCN) (see §6.4.3) in order to allow the use of any character in a C source, not just English characters. The primary goal of the Committee was to enable the use of any “native” character in identifiers, string literals and character constants, while retaining the portability objective of C.

Both the C and C++ committees studied this situation, and the adopted solution was to introduce a new notation for UCNs. Its general forms are unnnn and Unnnnnnnn, to designate a given character according to its short name as described by ISO/IEC 10646. Thus, unnnn can be used to designate a Unicode character. This way, programs that must be fully portable may use virtually any character from any script used in the world and still be portable, provided of course that if it prints the character, the execution character set has representation for it.

Of course the notation unnnn, like trigraphs, is not very easy to use in everyday programming; so there is a mapping that links UCN and multibyte characters to enable source programs to stay readable by users while maintaining portability. Given the current state of multibyte encodings,
10 this mapping is specified to be implementation-defined; but an implementation can provide the users with utility programs that do the conversion from UCNs to “native” multibytes or vice versa, thus providing a way to exchange source files between implementations using the UCN notation.

Update 7 Aug 2008: According to PEP 8, Style Guide for Python Code, under Encodings, says

    For Python 3.0 and beyond, the following policy is prescribed for
    the standard library (see PEP 3131): All identifiers in the Python
    standard library MUST use ASCII-only identifiers, and SHOULD use
    English words wherever feasible (in many cases, abbreviations and
    technical terms are used which aren't English). In addition,
    string literals and comments must also be in ASCII. The only
    exceptions are (a) test cases testing the non-ASCII features, and
    (b) names of authors. Authors whose names are not based on the
    latin alphabet MUST provide a latin transliteration of their
    names.

    Open source projects with a global audience are encouraged to
    adopt a similar policy.

(Emphasis mine)

One-line hardware support (USB Wireless Adapter)

I got recently a USB Wireless Adaptor, produced by Aztech. It was a good buy for several reasons:

  • It advertised Linux support
  • It was affordable
  • It had good quality casing; you can step on it and it won’t break
  • It had the Penguin on the box and was really really cheap

When I plugged it in on my Linux system, it did not work out of the box. The kernel acknowledged that a USB device was inserted (two lines in /var/log/messages) but no driver claimed the device.

With the package came a CD which had drivers for several operating systems, including Linux. Apparently one would need to install the specific driver. I think the driver was available in both source code and as a binary package (for some kernel version).

The kernel module on the CD was called zd1211, so I checked whether my kernel had such a module installed. To my surprise, there was such a kernel module, called zd1211rw. I hope you have better chance with the URL because now the website appears to be down (Error 500).

Therefore, what was wrong with my zd1211rw kernel module? Reading the documentation of project website, I figured out that you have to report the ID (called the USB ID) of your adapter  so that it is included in the kernel module, and when you plug in your device, it will be automatically detected.

You can find the USB ID by running the command lsusb. Then, it is a one-line patch for the zd1211rw driver to add support for the device,

— zd1211rw.linux2.6.20/zd_usb.c      2007-09-25 14:48:06.000000000
+0300
+++ zd1211rw/zd_usb.c    2007-09-28 11:35:51.000000000 +0300
@@ -64,6 +64,7 @@
{ USB_DEVICE(0x13b1, 0x0024), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x0586, 0x340f), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x0baf, 0x0121), .driver_info = DEVICE_ZD1211B },
+       { USB_DEVICE(0x0cde, 0x001a), .driver_info = DEVICE_ZD1211B },
/* “Driverless” devices that need ejecting */
{ USB_DEVICE(0x0ace, 0x2011), .driver_info = DEVICE_INSTALLER },
{ USB_DEVICE(0x0ace, 0x20ff), .driver_info = DEVICE_INSTALLER },

What Aztech should have done is to submit the USB ID to the developers of the zd1211rw driver. In this way, any Linux distribution that comes out with the updated kernel will have support for the device.

It is very important to get the manufacturers to change mentality. From offering a CD with “drivers”, for free and open-source software they should also work upstream with the device driver developers of the Linux kernel. The effort is small and the customer benefits huge.

GUADEC Day #1

I am writing this in the morning of the second day (posted at the end of the second day). Just had breakfast and there is a bit of time before making it to the conference venue.

Yesterday Sunday, was the first of the two days of warm-up for the GUADEC conference. At 11am the registration started. I was in front of the queue and got my badge quickly, then picked up the bag with the goodies; three cool t-shirts, a copy of Ubuntu 7.04, Fedora 7 Live, Linux stickers, two Linux pens, a mini Google Code notebook (no, that’s an actual notebook (not that type of notebook, it was just the paper-based thing)).

During registration I met up with Dimitrios Glezos (of Greek Fedora fame) and a bit later with Dimitrios Typaldos. It was the first time I met both of them in person.

Between a choice of two sessions I went to the one on X.org developments (XDamage, xrender, etc extensions and how to use them). Ryan Lortie gave the presentation.

Next was lunch time, and Dimitrios T. recommended a pub for traditional English food and drink. Sayamindu came along.

The next session I went to was the Hildon desktop, which is what we used to call Maemo; GNOME for internet tables such as the Nokia 770 and Nokia 800. There are special technical issues to solve. Lucas Rocha mentioned refactoring issues with the source code. In addition, as far as I understood, there is an issue with the internationalisation support for the platform.

Next, Don Scorgie talked about the GNOME documentation project. Several things can be improved and one of them is the introduction of a simplified XML schema for the needs of GNOME documentation. When compared to DocBook XML, the new GNOME documentation schema has only 6 elements (or do they call them tags?). In addition to this, there is a documentation editor with a special rich-edit widget for this schema. Mallard is a type of duck(?).

I also attended the last 10 minutes of the presentation on project Jackfield (sadly no special significance between Jackfield and what the project is about). Jackfield is apparently a way to run Javascript scripts on the desktop. OS/X is supposed to have it, and there are already scripts available. With Jackfield, you can run those scripts unmodified on Linux. The demos where really impressive.

The final session for the day was a presentation by Richard Rothwell on free software for the socially excluded. No, you do not have to go to Africa for this. His work relates to families in Nottingham, UK. It reminds me the situation and effort in Farkadona, Greece, that was described by Kostas Boukouvalas. I think it would have been helpful if Kostas Boukouvalas could have attended this. Richard is running a 3-year project that provides a number of PCs (in the hundreds?) with Linux to socially excluded families. Even in the UK, funding is hard to come by.

OpenVistA information system for hospitals and medical care

It is quite common to expect the availability of free and open-source software for common needs, such as an operating system and an office suite. What is the situation when your needs are much more advanced? Such as, when you are looking for an information system for a hospital?
Luckily, there is such a software package for an information system for hospital needs, called OpenVistA. OpenVistA comes from VistA, a public-funded medical system for the United States Department of Veterans Affairs. Due to the source of the funding, the source code of the medical system has been available with a liberal license, and gave birth to OpenVistA.
An interesting issue with OpenVistA is that the backend is written with the MUMPS programming language. This programming language is quite old with syntax dissimilar to modern languages. However, MUMPS has become popular in medical care systems and especially VistA. There are people that criticize the programming language; it is important to understand that a big piece of software working well has much more weight over the language preferences. In addition, the front-end is what the end-user uses, and in our case it is written with modern programming languages.
Screenshot of Mono frontend of OpenVistA
Traditionally, the major front-end of OpenVistA was written in Delphi. Quite recently, a new front-end has been written, in Mono. Thanks to Mono, the front-end is cross-platform and supports i18n (the front-end can be translated in many written languages).
You can try out OpenVistA straight away by downloading the OpenVistA VMWare appliance (image file that contains an installation of an operating system, configured and ready to use). The specific VMWare appliance is based on Xubuntu.
Software for hospitals is quite expensive, and is a lucrative business for software houses. However, when one takes into account that in many countries hospitals are public-funded, it is easy to understand how important it is to use free and open-source software in this case. Sadly, in many cases, hospitals make ad-hoc agreements for such software, resulting to inefficient use of public funds.

Using SVN for GNOME Translators

Update 3rd June 2009: This is a very old post when GNOME was using SVN for the VCS (now we use git). My blog theme does not show the year, so I am writing this in case you are confused by the post.

Now GNOME uses SVN to manage the development of the software.
To use SVN, the basic relevant commands are described at Getting the most out of Subversion in GNOME.

If you are a translator, the work is further simplified. You would normally new SVN to get a copy of the source code of a package so that you can extract the translation messages of the UI or the documentation. In addition, in some cases you can provide localised images and screenshots.

First of all, if you do not have an account on SVN yet, you need to connect using Anonymous access. You still have all access, however if you want to upload any translations would need to give them to someone else who has such an SVN account.

Furthermore, the source code of a package is often branched during a GNOME release so that when there is ongoing development, the released version of the package is not affected. Branches usually have a name similar to gnome-2-18. The not-branched branch is called trunk (or HEAD, in CVS lingo), where all cutting-edge development usually happens.

To checkout (here checkout means to obtain a copy) the source code of a package.

Checkout trunk as anonymous

svn checkout http://svn.gnome.org/svn/gnome-utils/trunk my-trunk-gnome-utils

Checkout trunk as simos

svn checkout svn+ssh://simos@svn.gnome.org/svn/gnome-utils/trunk my-trunk-gnome-utils

Checkout branch called “gnome-2-18” as anonymous

svn checkout http://svn.gnome.org/svn/gnome-utils/branches/gnome-2-18/ gnome-utils-stable

Checkout branch called “gnome-2-18” as simos

svn checkout svn+ssh://simos@svn.gnome.org/svn/gnome-utils/branches/gnome-2-18 gnome-utils-stable

To commit you changes means that you send your changes upstream to the project.
In order to commit, you enter the directory you checked out and you run

svn commit -m “Updated Greek translation”

The changes you make typically include updated your language’s LL.po file, and also updating the ChangeLog file.

You cannot commit in a anonymous checkout. The system knows that it’s you when you are commiting because the checkout command saved the username you used earlier.

In the SVN commands, you can abbreviate checkout with co, and commit with ci. Sometimes this leads to the most common newbie error; you tend to think that co is for commit. In practice you cannot make a mess though, as the command line parameters between the two actions are very different, and the command will fail.

Translating OLPC software

The core OLPC software is developed at http://dev.laptop.org/ using the GIT source code management system.
For the tasks of the translator, one needs to look into the different projects and locate any po/ subdirectory. The existence of this subdirectory show that the piece of software is internationalised (=can be translated).

For example, the core component sugar can be translated. In the main sugar page, and locate the po/ subdirectory that shows up. Click on it and you get the sugar po/ subdirectory with a few translations. Specifically, Yoruba, Hausa, Igbo and Italian. The italian translation is sadly useless. The translator made a mistake; he saw

msgid “Hello”

msgstr “”

and changed to (WRONG)

msgid “Ciao”

msgstr “”

instead of (CORRECT)

msgid “Hello”

msgstr “Ciao”

Normally, one would need to regenerate the Template PO (POT) file before translating, instead of working on one of the existing translated files. To do so, one needs to download the source code of sugar using the git tool and then use intltool-update -P to create the fresh sugar.pot file.

Multimedia support in Ubuntu Linux 6.06

With Ubuntu Linux 6.06, it is much clear how to install those codecs in order to get broad multimedia file support.

In Ubuntu, the multimedia infrastructure is handled by GStreamer; you install GStreamer plugins and any application that uses GStreamer can immediately benefit from the new codec support.

A typical installation of Ubuntu will bring in the free and open-source codecs by default. This includes the base gstreamer plugins package, gstreamer0.10-plugins-base that covers

  1. /usr/lib/gstreamer-0.10/libgstadder.so
  2. /usr/lib/gstreamer-0.10/libgstaudioconvert.so
  3. /usr/lib/gstreamer-0.10/libgstaudiorate.so
  4. /usr/lib/gstreamer-0.10/libgstaudioresample.so
  5. /usr/lib/gstreamer-0.10/libgstaudiotestsrc.so
  6. /usr/lib/gstreamer-0.10/libgstcdparanoia.so
  7. /usr/lib/gstreamer-0.10/libgstdecodebin.so
  8. /usr/lib/gstreamer-0.10/libgstffmpegcolorspace.so
  9. /usr/lib/gstreamer-0.10/libgstogg.so
  10. /usr/lib/gstreamer-0.10/libgstplaybin.so
  11. /usr/lib/gstreamer-0.10/libgstsubparse.so
  12. /usr/lib/gstreamer-0.10/libgsttcp.so
  13. /usr/lib/gstreamer-0.10/libgsttheora.so
  14. /usr/lib/gstreamer-0.10/libgsttypefindfunctions.so
  15. /usr/lib/gstreamer-0.10/libgstvideo4linux.so
  16. /usr/lib/gstreamer-0.10/libgstvideorate.so
  17. /usr/lib/gstreamer-0.10/libgstvideoscale.so
  18. /usr/lib/gstreamer-0.10/libgstvideotestsrc.so
  19. /usr/lib/gstreamer-0.10/libgstvolume.so
  20. /usr/lib/gstreamer-0.10/libgstvorbis.so

With a properly encoded multimedia file, you can play music or video with subtitles. Such good codecs are Ogg, Vorbis and Theora. You can also rip CDs; cdparanoia is also there.
By default you also get the good package, gstreamer0.10-plugins-good
It contains

  1. /usr/lib/gstreamer-0.10/libgst1394.so
  2. /usr/lib/gstreamer-0.10/libgstaasink.so
  3. /usr/lib/gstreamer-0.10/libgstalaw.so
  4. /usr/lib/gstreamer-0.10/libgstalpha.so
  5. /usr/lib/gstreamer-0.10/libgstapetag.so
  6. /usr/lib/gstreamer-0.10/libgstavi.so
  7. /usr/lib/gstreamer-0.10/libgstautodetect.so
  8. /usr/lib/gstreamer-0.10/libgstcacasink.so
  9. /usr/lib/gstreamer-0.10/libgstcdio.so
  10. /usr/lib/gstreamer-0.10/libgsteffectv.so
  11. /usr/lib/gstreamer-0.10/libgstgoom.so
  12. /usr/lib/gstreamer-0.10/libgstid3demux.so
  13. /usr/lib/gstreamer-0.10/libgstlevel.so
  14. /usr/lib/gstreamer-0.10/libgstefence.so
  15. /usr/lib/gstreamer-0.10/libgstmulaw.so
  16. /usr/lib/gstreamer-0.10/libgstossaudio.so
  17. /usr/lib/gstreamer-0.10/libgstrtp.so
  18. /usr/lib/gstreamer-0.10/libgstrtsp.so
  19. /usr/lib/gstreamer-0.10/libgstsmpte.so
  20. /usr/lib/gstreamer-0.10/libgsttaglib.so
  21. /usr/lib/gstreamer-0.10/libgstudp.so
  22. /usr/lib/gstreamer-0.10/libgstvideobox.so
  23. /usr/lib/gstreamer-0.10/libgstvideoflip.so
  24. /usr/lib/gstreamer-0.10/libgstwavenc.so
  25. /usr/lib/gstreamer-0.10/libgstwavparse.so
  26. /usr/lib/gstreamer-0.10/libgstauparse.so
  27. /usr/lib/gstreamer-0.10/libgstdebug.so
  28. /usr/lib/gstreamer-0.10/libgstnavigationtest.so
  29. /usr/lib/gstreamer-0.10/libgstalphacolor.so
  30. /usr/lib/gstreamer-0.10/libgstcairo.so
  31. /usr/lib/gstreamer-0.10/libgstflxdec.so
  32. /usr/lib/gstreamer-0.10/libgstmatroska.so
  33. /usr/lib/gstreamer-0.10/libgstvideomixer.so
  34. /usr/lib/gstreamer-0.10/libgstcutter.so
  35. /usr/lib/gstreamer-0.10/libgstmultipart.so
  36. /usr/lib/gstreamer-0.10/libgstflac.so
  37. /usr/lib/gstreamer-0.10/libgstjpeg.so
  38. /usr/lib/gstreamer-0.10/libgstpng.so
  39. /usr/lib/gstreamer-0.10/libgstspeex.so
  40. /usr/lib/gstreamer-0.10/libgstgconfelements.so
  41. /usr/lib/gstreamer-0.10/libgstshout2.so
  42. /usr/lib/gstreamer-0.10/libgstvideobalance.so
  43. /usr/lib/gstreamer-0.10/libgsticydemux.so
  44. /usr/lib/gstreamer-0.10/libgstximagesrc.so
  45. /usr/lib/gstreamer-0.10/libgstannodex.so
  46. /usr/lib/gstreamer-0.10/libgstgdkpixbuf.so
  47. /usr/lib/gstreamer-0.10/libgsthalelements.so
  48. /usr/lib/gstreamer-0.10/libgstdv.so

This includes generic AVI support, access to digital video and Firewire devices, visualisers, the Matroska codec, access to shoutcast servers, the speex audio codec, the flac codec and many more.

At this point, you can install Pitivi, a gstreamer-enabled video editor written in Python that helps you create your own movie. Make sure you install gstreamer0.10-gnonlin which enables non-linear editing in gstreamer.

Up to here you got free and open-source software.

You can continue with more codecs by installing the package gstreamer0.10-plugins-ugly. This package is not part of the official Ubuntu distribution; you need to enable the Universe repository. Use System/Administration/Synaptic Package Manager to install these additional packages.
Ugly are the plugins and codecs that may have distribution problems in some countries.

Ugly includes

  1. /usr/lib/gstreamer-0.10/libgsta52dec.so
  2. /usr/lib/gstreamer-0.10/libgstasf.so
  3. /usr/lib/gstreamer-0.10/libgstdvdlpcmdec.so
  4. /usr/lib/gstreamer-0.10/libgstdvdread.so
  5. /usr/lib/gstreamer-0.10/libgstdvdsub.so
  6. /usr/lib/gstreamer-0.10/libgstiec958.so
  7. /usr/lib/gstreamer-0.10/libgstmad.so
  8. /usr/lib/gstreamer-0.10/libgstmpeg2dec.so
  9. /usr/lib/gstreamer-0.10/libgstmpegaudioparse.so
  10. /usr/lib/gstreamer-0.10/libgstmpegstream.so
  11. /usr/lib/gstreamer-0.10/libgstrmdemux.so
  12. /usr/lib/gstreamer-0.10/libgstsid.so

This package will bring in, among others, DVD playback and subtitle support, ASF file support, MP3 support (MAD package) and MPEG2 video playback.
You can also get MP3 support if you install the gstreamer0.10-fluendo-mp3 plugin which is available from Universe as well. This package is probably free to use in any country thanks to the efforts of the Fluendo team.

It appears that if you install ugly, it is good to install gstreamer0.10-ffmpeg so that you get support for

FFmpeg plugin for GStreamer

This GStreamer plugin supports a large number of audio and video compression
formats through the use of the FFmpeg library. The plugin contains GStreamer
elements for encoding 40+ formats (MPEG, DivX, MPEG4, AC3, DV, …), decoding
90+ formats
(AVI, MPEG, OGG, Matroska, ASF, …), demuxing 30+ formats, and
colorspace conversion.

Finally, there is a package gstreamer0.10-plugins-bad with plugins of potentially suboptimal quality. It includes

  1. /usr/lib/gstreamer-0.10/libgstbz2.so
  2. /usr/lib/gstreamer-0.10/libgstcdxaparse.so
  3. /usr/lib/gstreamer-0.10/libgstdtsdec.so
  4. /usr/lib/gstreamer-0.10/libgstfreeze.so
  5. /usr/lib/gstreamer-0.10/libgstgsm.so
  6. /usr/lib/gstreamer-0.10/libgstmms.so
  7. /usr/lib/gstreamer-0.10/libgstmodplug.so
  8. /usr/lib/gstreamer-0.10/libgstmusepack.so
  9. /usr/lib/gstreamer-0.10/libgstqtdemux.so
  10. /usr/lib/gstreamer-0.10/libgsttrm.so
  11. /usr/lib/gstreamer-0.10/libgstspeed.so
  12. /usr/lib/gstreamer-0.10/libgstswfdec.so
  13. /usr/lib/gstreamer-0.10/libgsttta.so
  14. /usr/lib/gstreamer-0.10/libgstvideo4linux2.so
  15. /usr/lib/gstreamer-0.10/libgstwavpack.so
  16. /usr/lib/gstreamer-0.10/libgstxingheader.so
  17. /usr/lib/gstreamer-0.10/libgstneonhttpsrc.so

With bad you get GSM audio codec support, MMS support, QT playback support for some formats, Flash (SWF) playing support, Video4Linux2 support, MUSEPACK support and a few more.

How to easily modify a program in your Ubuntu?

Suppose we want to change the functionality of an Ubuntu application but we do not want to go into all the trouble of finding the source code, installing in /usr/local/, breaking dependencies with original versions and so on.

Let’s change Character Map (gucharmap), and specifically change the default font size from 20pt to 14pt, so that when you start it there is more space in the character window. Currently Character Map does not offer an option to save this setting.

We get the source code of Character Map,

# apt-get source gucharmap

Then,

cd gucharmap-1.4.4/

and now we edit the file gucharmap/main.c

We know what to edit because we visited the GNOME CVS Website, at http://cvs.gnome.org/viewcvs/gucharmap/

and we examined the logs for the file http://cvs.gnome.org/viewcvs/gucharmap/gucharmap/main.c?view=log

which show that for Revision 1.69, the following change took place,

Log:

2004-02-01  Noah Levitt

* gucharmap/gucharmap-table.c: Improve square size.

* gucharmap/main.c: Increase default font size.

When we click on the link Diff to previous 1.68 of the above page, we pinpoint the change,

version 1.68, Sun Feb 1 03:46:21 2004 UTC version 1.69, Mon Feb 2 00:48:05 2004 UTC
Line 93 main (gint argc, gchar **argv)
Line 93 main (gint argc, gchar **argv)

gint default_size = PANGO_PIXELS (1.5 * pango_font_description_get_size (window->style->font_desc));

gint default_size = PANGO_PIXELS (2.0 * pango_font_description_get_size (window->style->font_desc));

The change in the multiplier (from 1.5 to 2.0) changes the font size from 15pt to 20pt.

20pt is too big for us, therefore we edit the file gucharmap/main.c and change the 2.0 to 1.4 (14pt).
At this point we can compile the package using the command line

$ dpkg-buildpackage -rfakeroot -uc -b

dpkg-buildpackage: source package is gucharmap
dpkg-buildpackage: source version is 1:1.4.4-1ubuntu1
dpkg-buildpackage: source changed by Sebastien Bacher
dpkg-buildpackage: host architecture i386
fakeroot debian/rules clean

……….

At this point it is possible that you will get an error that an essential package is missing. The above command line will name the missing files, therefore you can simply install by

# apt-get install package-name

In case you do not have the basic compiler packages, you would need to install the build-essential meta-package. Do

# apt-get install build-essential

Finally, after the dpkg-buildpackage command completes, it will create one or more .deb packages in the directory above gucharmap.

# cd ..

# ls -l *.deb

gucharmap_1.4.4-1ubuntu1_i386.deb

libgucharmap4_1.4.4-1ubuntu1_i386.deb

libgucharmap4-dev_1.4.4-1ubuntu1_i386.deb
#

You can now install them (over the original packages) by running

# dpkg -i gucharmap_1.4.4-1ubuntu1_i386.deb libgucharmap4_1.4.4-1ubuntu1_i386.deb libgucharmap4-dev_1.4.4-1ubuntu1_i386.deb

Now we start the Character Map from Applications/Accessories/ and we get the default character size of 14pt!

Is there something we should pay attention on top of this? Yes, we should investigate the GNOME Bugzilla in case there is relevant work on this issue. We visit

http://bugzilla.gnome.org/

and specifically we click on the link Browse.

There, we select the package gucharmap (how do we know that Character Map is gucharmap? We either click on Help/About in Character Map which shows the internal name, or we run ps ax at a Applications/Accessories/Terminal while Character Map is running; the name gucharmap will pop up at the end of the long list.).

gucharmap is under the Desktop heading in the Browse list; or click on this direct link of bug reports on gucharmap.
If you start perusing the gucharmap bugs list, you will notice Bug #140414, titled remember settings. This report describes a superset of the problem we tried to solve above. That is, the bug report asks to enable Character Map to use the GNOME configuration database (gconf) so that it saves/remembers the user settings. However, this specific bug report is still pending.

The correct way to solve the configuration settings issue of gucharmap is to implement what is described in Bug #140414. If you have Ubuntu 6.06, you most likely have a very recent version of the source code of gucharmap. Therefore, the differences would be rather minimal. You can give it a go and try to get the gconf functionality in place.

You compile, install and test. If it works, you can make a patch of your changes; visit another directory and download a fresh copy of the source code using the apt-get source packagename command. Rename gucharmap-1.4.4 to gucharmap-1.4.4.ORIGINAL

# mv gucharmap-1.4.4 gucharmap-1.4.4.ORIGINAL

and make sure you clean the original gucharmap-1.4.4/ directory from compiled files (enter the directory were you did the source code changes and run make clean).

Finally, create a diff file,

# diff -ur ~/tmp/gucharmap-1.4.4.ORIGINAL ~/gucharmap-1.4.4/ > remember-settings.patch

In ideal terms, it is preferable if you could produce a patch for the latest version of gucharmap. That is, the version of gucharmap you get from http://cvs.gnome.org/viewcvs/gucharmap/. By doing so, the developers will love you because they will be able to simply apply the patch and limit the burden of adding the feature. Indeed, if it is too much effort to get a build system running, you can start off with simple patches and if you feel you are doing well with it, make the extra mile to have a build system. More on this in a future post.

Dear VideoLAN users

Dear VideoLAN users,

The VideoLAN team is happy to announce the first beta version of VLC
0.8.4 (Note: 0.8.3 was skipped because it’s technical improvements were
too little)

Highlights from improvements include:
* Mac OS X interface:
– new dialogs (wizard, extended controls, bookmarks)
– drag and drop in playlist
* wxWidgets interface (default Windows / Linux interface):
– renamed from wxWindows
– VLC update checker (?)
* Skins interface:
– Partial support for tree playlist
* HTTP interface:
– CGI handling, you can now use external programs from VLC’s web
server
(like PHP for instance)
– Much richer controls
* Linux binary codecs loader. Now able to read WMV3 under Linux.
* UPnP service discovery
* Bonjour (Apple zeroconf protocol) service discovery
* Shoutcast output module to forward streams to icecast servers
* Internal strings handling is now UTF-8 based
* ActiveX plugin should now work outside IE as well
* New languages: Korean and Romanian
* Loads of bug fixes
(https://trac.videolan.org/vlc/query?status=closed&milestone=0.8.4-test1)

You can get a complete list by reading the release notes:
http://developers.videolan.org/vlc/NEWS

Binary packages are already available for Windows and MacOS X. You can
download those and the source code as well on:
http://downloads.videolan.org/pub/videolan/testing/vlc-0.8.4-test1/

Remember that this is a beta version. Please test it heavily and report
bugs. Known bugs are registered in the trac database:
http://developers.videolan.org/cgi-bin/trac.cgi/roadmap

This beta release’s forum topic is located here:
http://forum.videolan.org/viewtopic.php?t=12634

For the VideoLAN team,

— dionoea Antoine Cellerier

Μπορείτε να συνεχίσετε την ελληνική μετάφραση.