Category Archives: September 2005
Being a translator with the bengali localisation team and volunteer for GNOME since v.2.2, Runa Bhattacharjee shares her experience gathered in the past 2 and 1/2 years of work about technicalities and nuances that develop while doing such translation jobs.
There was a very special reason why I sat down to watch the opening ceremony of the 2004 Summer Olympics. At that time I was translating a list of country names and found it difficult to ensure the correct translation of quite a few lesser-known countries. As each contingent marched smartly past the television screen, I hurriedly jotted down the names from the accompanying announcements.
I started translation of localized interfaces as a hobby but soon realized the serious nuances that influence the way the user-interface would look and its importance from the end-user’s view. In this article, I attempt to put across a brief account of the many aspects that have gone on to determine the way the translation process has transformed from the time I started about 2 years back.
As more and more computer users are shifting base to Linux, localized interfaces are appealing to the non-english speaking users to shed their fears and explore the world of information technology. With expected growth and proliferation in the number of users, translation for localization desktops just turned serious. Besides the mandatory spelling and grammatical corrections there were a whole set of checks that the translator had to perform and one needed more than sheer instincts.
Translators generally start working with what is known as the ‘Portable Object Template’ (.pot) file containing all the user-interface messages from the application. The messages are extracted from the application’s code files with the help of a function named gettext(). The .pot files are available for download from the project repository (for e.g. the GNOME cvs). The translators download the .pot files, translate the messages, save the file with a ”.po” extension and submit it back to the repository with the necessary Changelog entries.
The typical format for the messages within the .po file is :
The ‘msgid’ is the original text from the user interface which acts as the identifier and ‘msgstr’ is the translated version of the message. The top part contains comments that are sometimes used by the translators to figure out the context of the string to translate.
During initial phases the general tendency on the part of the translators (lets assume someone without any prior experience in U-I Translation) is to apply “literal” translation methods. This often leads to incomprehensible text. One of the main reasons for such semantic discrepancy is the change that regular english has undergone within the ambit of information-technology parlance. For instance, hardly any corner of this world is devoid of the not-so-often-liked rodent “mouse” and nearly all languages have a local name for it. Yet substituting the name of the hardware with the regular local name may lead to confusion as often it is seen that the original term is linked spontaneously when used in the context of the computer apparatus. Though quite a few languages, for e.g. tamil have coined their own terms to standardize the translation and leave no chance for confusion.
When I first started translating the GNOME-UI for bengali, the standard practice was to address users-to-computer messages with a low degree of salutation whereas computer-to-user messages were more formal in tone. A friend who happened to take a casual look at the translations shook his head rather thoughtfully. What he proceeded to explain was that all messages are for the user’s perusal, hence stick to one particular format of salutation. Here it is to be explained that bengali as in quite a few other Indian languages, has 3 levels of salutation:informal, semi-formal and formal. At that time, I had vehemently objected, but later, on the user-interface, I found the discrepancies too stark to ignore. One could see the user being addressed differently at times thus giving a comic see-saw effect to the level of interaction.
Testing on the user-interface both for context as well as for the final localized interface is a handy tool. The widgets like buttons, labels etc., created to fit the original text, might get disrupted in case the translated text does not fit into them. This leads to stretched out or ill-fitting dialog boxes and windows. As the GNOME Human Interface Guidelines 2.0 mentions, “at times translated text can expand upto 30% more for some languages”.
The keywords while translating a user-interface are “comprehensibility” and “consistency”. It has to be satisfactorily comprehensible such that it facilitates the user to move around the interface with ease and choose the correct options to perform the desired actions. This is where the translators have to move away from literal translation, retain indentifiable technical keywords, coin new terms if necessary and maintain them across translations. To ensure that the user-interface is not completely unfamiliar to the users, I personally borrowed heavily from the other frequently used electronic media like telephone and other multi-lingual public-service announcements. To facilitate translations, compendiums and glossaries are taking shape as standardized translations are being settled upon and accepted within the language community.
Access keys, an intergral part of the U-I give rise to yet another dilemma. This is an area where perhaps the experiments ought to be kept at a minimum. Languages which use multiple alphabet conjuncts may face serious problems while choosing access keys. Secondly, the localized access keys would risk duplication within the same level of usage unless tested on the user-interface, rendering them completely useless. For languages using non-Romanized script it is generally considered prudent to retain the orignal access keys from the english interface.
The figure shows duplicated access keys in the same usage level.
Translators are often faced with several hurdles, one of which is in the form of “variables”, which would accept values based upon usage. For e.g. consider the text “Print %d pages” where %d would be the number of pages to be printed. Looks easy? Well, try this, “Print page %d of %d”, where the 1st %d is the page number to be printed and the 2nd %d is the total number of pages to be selected from. The translator has to ensure that the sequence of occurence of the %d ’s in the translated text does not override the context. So if in a language the normally translated text would require the sequence of the %d’s to be changed (mine does) then its time for some gymnastics. One has to bend and twist the language such that the sequence is never changed as otherwise it would result in wrong values to be populated in the variables when presented to the user. e.g. “Print page 10 of 2”.
As the number of international applications rises the requirement for fast and standardized translations have seen the introduction of automatic translation tools and/or scripts. These tools mostly use previously translated text or compendiums. Although they do take some load off the translators, context-checks are required to fine tune the generated results. Consider the string: “Open File”, this might be used to indicate “Open (a) File” or ” (a) file that is open”. In such a case the automatic translator would either use the only available option irrespective of its accuracy or ignore it if it finds more than one existing translation to choose from.
As Opensource applications developed by community volunteers are maturing into viable replacements for legacy products, one feels the need to introduce a higher degree of professional touch to the applications. Leaving registered brand names and trademarks untouched during translation, working within release deadlines, developing glossaries and ready reckoners, bug-reporting, translation/file tracking within the community are some of the practices that might be helpful in streamlining the process. The greatest challenge that I have been confronted with is the constant need to rediscover ‘more’ appropriate terminology and ensure accuracy of context. With every new release the translated content has to be updated and if necessary, fine-tuned. As mentioned earlier the user-interface needs to be checked to ensure the correct content. This is of prime importance as a localized interface targets new users in a big way, for whom the english interface is the major hindrance. These new users would be unfamiliar with the interface who will have to find their way around with the help of the the text as provided by the translators. Compendiums, glossaries and other translation tools are necessary to strike a balance between automated work processes and manual rehashing while achieving standardized and easily identifiable interfaces. It is often felt that translators need a high degree of technical understanding of the content. What I personally felt was the need to perceive the end-user’s comprehensible perspective while being familiar with the content. Translation is an ongoing process while also being a learning experience for the translators, as at the end of the day they become familiar with quite a few applications that they would have otherwise not come across during the normal course of work.
Helping other with computer problems can often be complicated, especially if you are far away. Marcus Bauer explores and explains Vino, the default remote administration utility of the GNOME desktop.
Do you know how infuriating it is to explain to somebody via telephone how to administer his/her desktop computer? Have you ever wanted to use your laptop’s screen as a multihead together with your desktop computer? Two different things, one solution: Vino.
Vino is a tool for remote administration readily built into the GNOME Desktop Environment. It allows you to share your local desktop with a remote computer. This can be used for quick and efficient in-house support as well as for remote assistance via Internet. A broadband connection (adsl/cable) is advantageous, but with some speed limitations, classic modem lines are possible, too. Another potential scenario of use is the classroom where the trainer can be given insight into the student’s computers from his desk.
Fire up your favorite package manager and make sure that vino and a vncviewer are installed. Vino should already be installed as it is part of the GNOME core packages. However, a vncviewer may be missing. There are several available and all should work. On Debian, I would recommend xvnc4viewer. Other possibilities are TightVNC, RealVNC, or the older xvncviewer version 3. However, version 4 provides better performance via slow modem lines.
Sharing your desktop is very easy. Select “Remote Desktop” from your preferences menu:
The following dialog will appear:
Now activate the check box “Allow other users to view your desktop”. That’s all!
If another user now connects to your computer you will see the following dialog giving you the opportunity to allow or deny access:
You have the choice to restrict the remote computer to only view your desktop or you can give it full access. In the latter case, the remote computer can control yours with its keyboard and mouse.
You can set up a password, too, which the remote computer needs to submit before being able to connect. By default, you will be asked for confirmation as seen in the above screenshot. This behavior may be switched off, but this is not recommended for obvious security reasons.
Viewing the Desktop
Now that you know how to share your desktop you will most likely want to know how to access your desktop. To do this start a gnome-terminal (Applications->System tools->Terminal) and type in the following command:
For testing purposes you can do that all on one computer and consequently substitute “ip-address-of-remote-computer” with “localhost” or “127.0.0.1”. Voila – a new window opens with the remote desktop in it – in this case your own desktop a second time.
To clarify things here is one more example: Assume
- Computer A has ip 192.168.0.1 and
- Computer B has ip 192.168.0.2
If A wants to share his desktop with B then A is setting his “Remote Desktop Preferences” as shown above and B executes:
As a side note: vncviewer does exist for many platforms allowing you to share your Linux desktop with Macs and Windows, too. See URLs at the end of the article.
A magic key is the key which allows you to copy back and forth the content of the clipboard and to switch between window mode and fullscreen mode.
A common network/firewall configuration in home and office environments is NAT (Network Address Translation). The router translates one public ip address into several private ones (often from the 192.168.0.0 range).
If the computer who wants to share the desktop is sitting behind such a firewall/router, then port forwarding of port 5900 needs to be done on the router. Most SOHO routers nowadays come with a web-based administration GUI and should let you make the appropriate changes with no hassle. That’s all.
For the computer that wants to access another desktop there are no restrictions. Only the port 5900 must be open for outgoing connections which is usually the case.
The data is transmitted non-encrypted. Thus make sure you are not using Vino for sensitive material without further security measures. You can compare it to the transmission of a fax: stuff that should be confidential shouldn’t be transmitted without thought. And if you are a student living on a campus using wireless LAN you most likley want to have some more security, too. A possible solution is to set up an ssh tunnel for port 5900. Details will go beyond this tutorial, but your system admin or google will give you further advice.
Multihead – x2vnc
Many users have both – a desktop computer and a laptop. Quite commonly they are used together at home or workplace. And most users switch between the two keyboards and mice. Wouldn’t it be much nicer to have a “multihead” in no time and without any network magic and even be able to control a WinXP box or a Mac from your Linux keyboard and mouse?
Here is how: install x2vnc on your Linux computer (computer A) from which you want to control the other computer (Computer B, IP# 192.168.0.2). On Computer B you allow remote desktop access like described above and on Computer A you then simply enter the following command in a gnome-terminal:
x2vnc 192.168.0.2:0 -east
If you now move your mouse pointer out of the right of your screen of Computer A it will automatically appear on the left side of the screen of Computer B. The best thing is that the keyboard follows mouse – you don’t need to switch your fingers from one keyboard to the other. Simply move the mouse pointer around. That’s it.
You may have already guessed it, the ”-east” switch can be substituted by a ”-west” switch to allow going out of the left side of the screen. Plus you can go out on the top or bottom by using ”-north” or ”-south”.
This is a quick and easy solution for a pseudo “multihead” system. The advantage is that it only takes 20 seconds to start. The disadvantage is that it leads to a performance slow down on the computer which is sharing its desktop. In most cases you wont feel it. If so you can still switch to native X solutions. As a hint for the interested reader, it may be said that x2x is the solution but needs tweaking with gdm, xhost and xauth and probably ssh_conf and sshd_conf.
I mentioned already that vnc is available for many platforms allowing you the control of Macs and Windows boxes. This multihead solution will only work with a Linux box as master over all the other ones. How else should it be!
Vino is one of the nice little GNOME jewels that currently leads a somewhat shadowy existence. My hope is that this article helps to spread the word about it and to lower the barrier to install GNOME on your friend’s and family’s desktops. They will simply be in awe when they experience for the first time remote administration!
Weather you use it for remote desktop functionality, as a pseudo multihead solution, or both, it is one more component that follows the basic GNOME idea: “It just works!”.
Copyright © 2005; Marcus Bauer (marcus.bauer gmail com)
For immigrants and refugees, the Internet is an easy way to stay in contact with familiy members and to find news about their home country. Murray Cumming describes how an Internet center in Austria uses a small GNOME-based thin-client system to provide access for them.
Linz, in upper Austria, is the second-largest town in a small country. Tradition survives here and is shown by the well-preserved buildings and the dialect still spoken by many instead of “high” German. But the modern world is also welcome, providing up-to-date university training, high-tech jobs, and even a “Museum of the Future”. Not far from the old city’s main square is another example called the Pangea Center.
Pangea is an Internet center for immigrants and refugees with some multimedia activities. There are about 150 registered users from 35 different countries – this year immigrants were mostly from Nigera, Ghana, Iraq and Afghanistan. The project was started four years ago as a spin-off from the Medea multimedia workshop, created six years ago by the non-commerical Radio Fro radio station. Funding comes mostly from the Upper Austrian regional government, with some help from the Linz city government.
Vistors use the computers to communicate with family and friends abroad via email and chat, to stay informed about events in their countries of origin, and to gain valuable computer experience.
Team and infrastructure
There are three employees that make up the Pangea team. The system administrator, Ralph Aichinger, worked previously as a part-time system administrator while studying at Linz University, and Michael is a trained graphic designer who now helps with multimedia and courses. Amra, the manager, first visited the center as a user several years ago, having arrived in Austria as a refugee from Bosnia.
Pangea received fifteen used computers that the city planned to throw away because they were not capable of running newer versions of Microsoft software. As an experienced Linux user, Ralph knew he could use these Pentium 100 PCs (with 64Mb RAM) as thin clients to run GNOME without performance problems. Based on his experience administering Windows
computers, he also knew that GNOME and Linux would require less day to day maintenance work. In particular, he wanted to avoid dealing with daily virus and spyware infections. Naturally, as a non-profit organisation, they were also happy to avoid paying several thousand Euros in license fees.
Pangea has ten thin client PCs running via X Windows from an Athlon XP 2000+ server with 1GB of RAM on a 100Mb/s network. The office also has a separate set of five thin clients using an additional server.
Debian Linux made the setup very straightforward starting with GNOME 1.4 in Debian Stable. When the client computers were replaced after one year with Pentium 200 PCs with better graphics cards, Pangea upgraded to the Debian backport of GNOME 2.4. And about six months ago, Ralph upgraded the server to GNOME 2.8 using Debian’s testing distribution (which became officially stable only recently).
The LTSP project assured Ralph that this setup would work effectively with his hardware. The thin clients have no noticeable performance problems compared to a modern PC running GNOME locally, even without using any of GNOME’s low-resources options. Ralph simply enabled GDM’s remote login feature on the server, and added init scripts to the clients so that xquery would login to the server when booting.
No user data is stored on the client PCs because all accounts exist on the server. Processor, memory and disk space quotas prevent any user from taking all the resources for himself. Because all applications run in shared memory on the server, some things can actually be faster than a normal PC. For instance, OpenOffice is effectively pre-loaded if another thin client user is already using it, so there is no long start-up time. However, local drives such as CDs and diskettes are not yet visible to the users, because the server is not aware of them. After some research, I discovered that the LTSP project is working on a solution for this.
The majority of web sites are well supported by the Mozilla-based GNOME web browser, including sites that use Flash/Shockwave or Java applets, with only occassional Java problems.
Even though GNOME’s interface (the windows, menus and buttons) can be quickly switched to many visitors’ first languages, such as Arabic or French, the computers are mostly used in German or English, because they are learning those languages anyway. However, GNOME allows them to view web sites in any language or script, and GNOME’s keyboard indicator allows them to write emails while referring to a special on-screen keyboard. Users can print to the networked Kyocera printer.
Although Pangea offers email accounts using GNOME’s Evolution email application, most users prefer to use webmail interfaces that can be easily accessed at other locations.
GNOME’s lockdown features allow the system administrator to prevent changes to some parts of of the desktop such as the main panel. But because Ralph is there to help, he prefers to leave things unlocked so he can make quick changes when a user needs something extra. A simple lockdown user interface would allow him to unlock a user’s desktop temporarily. It would also allow him to more easily specify lockdown in more detail such as specifying which panel applets a user may add to his panel, instead of locking the entire panel layout. I added a page about this future Lockdown Editor to GNOME’s wiki because I think it would be a great project for someone getting involved in GNOME.
Most users arrive at the Pangea center without in-depth computer experience or preconceived ideas, but many have visited Internet cafes. According to the Pangea staff, they have no problems starting to use GNOME’s simple user interface and their questions are usually about specific web sites rather than any technical problems.
Dhia arrived from Iraq four years ago and now has an Austrian passport. He visits the Pangea Center almost every other evening after finishing his work as a gardener. He likes to follow events in Iraq via an expatriate web site and communicate with his friends there.
Ofoed, from Nigeria, has been in Linz for only a few months and finds it very important to read Nigerian newspapers online as well as simply to pass the time with friends.
Other users arrange times to chat online with their families which saves a lot of money compared to an international phone call. And in the future, Pangea might offer online telephony via GnomeMeeting. All this technology helps people to feel comfortable in their new home.
Future & Conclusion
Although Pangea must struggle every year for funding, it hopes to expand to meet the strong demand for its service and to better support its community. GNOME and Linux mean that this can be achieved efficiently. The Pangea Center provides a very valuable resource to these immigrants and it was all made possible by the excellent open source software that is Linux and GNOME.
Just another audio player or one that rocks the competition? Ken VanDine provides a tour through the features of Banshee, formely known as Sonance, a music player that is already expected to become the default player for some distributions.
Lack of a robust music player is something that has been a serious deficency of the Linux Desktop. My personal opinion is this is an area that will make or break Linux on the Desktop. For wide spread consumption, Linux needsgood media support. There have been some good music players, but nothing has really filled the void satisfactorily. However, now there is Banshee (formerly known as Sonance) and we are nearly there!
What is Banshee?
Banshee is a music management and playback application for GNOME. Over the course of the year a variety of high quality, highly polished, and all around “swell” Mono GNOME Desktop applications have been popping up. As with many of these apps, Banshee has a beautiful user interface and is well architected.
- Import CDs
- Manage your library
- Play your music
- Create and maintain playlists
- Sync music with your iPod
- Play music directly from your iPod
- Create audio and mp3 CDs
In short, it does what you need!
The first time Banshee is launched, it will prompt you to import music. There are two options, “Automatic Import” and “Import Folder”. Automatic Import searches for music in your home directory and adds it to the library. Import Folder is a bit more controlled: you simply tell Banshee where to look for music.
After successfully importing your existing music, you will see your Library.
Here you can do a variety of things, including playback. Select a song and hit the play button. In your Library, you will see a variety of information about your collection, including playback statistics (when was it last played and how many times). This will come into play in a future version when “smart” play lists are available. During playback, you will notice a nice little tray icon in your notification tray. You can right click on the icon to get a list of available actions.
Next, organizing your music. In the menu, select “File->Playlist->New Playlist” (or simply Ctrl-N). You will then see a new playlist in the left panel and the name (New Playlist) will be highlighted. You can just type in your name. That’s it!
Banshee can import your music from a CD and has a nice integrated CD player. Pop in your desired CD and you will see your CD title appear in the left pane. You can simply select it and hit Play to play your Full CD.
To rip music from a CD to your music collection, simply hit the Rip button near the top right.
iPod syncing is pretty simple, plug in your iPod and you will see it appear in the left panel.
There are three ways to manage the music on your iPod.
Manually – You can browse your iPod, drag music between your library and the iPod.
Automatically sync – Automatically copies everything in your library to the iPod.
Automatic merge – All the music on your iPod that is not in your library is downloaded to your library, and all the music that is in your library and not in your iPod is uploaded to your iPod.
When the iPod is selected, you will be able to see some information about your iPod at the bottom left. Including disk usage, and some buttons (sync, properties, and eject).
And let’s not forget the snazzy About dialog (select “Help->About” from the menu).
Banshee has made a significant impression on me. I have been looking for something just like this for a long time. I have been limping along with a combination of Sound Juicer, GtkPod, GNOME Baker and Rhythmbox for some time. Yes, with some work I have been able to manage my tunes OK, but I can’t say it has been painless. Now with modern Linux distributions starting to use HAL (Hardware Abstraction Layer) and DBUS (message bus used by HAL and other applications), applications like Banshee can really make a difference. You will now be able to just plug your iPod in and not think about it. “It just works”, means a lot to me!
Many thanks to Aaron Bockover for his hard work developing Banshee and his input into this article.
Claus Schwarm and Martin Sevior show how GNOME Office applications, in particular Gnumeric and AbiWord, can be connected to allow multiple authors to directly collaborate on document creation. Welcome to Peer to Peer Collaboration for GNOME Office!
Bob and Jane have a problem. Both have the same employer but Bob works in the United States Marketing department and Jane in the Development lab in Europe. They were just assigned a presentation about the upcoming new company product at the conference in Asia next week. Now they need to write the underlying document.
While this is a hypothetical story, it is not uncommon for people today to form teams to work on a single document. Another common case is to edit a certain document from different computers; such as the office workstations, a personal computer at home, a mobile device.
The usual solutions to such problems are either to synchronize changes regularly between all parties or to store the document at a central place that is accessible through a network.
Developers usually use the latter method when they work on documents that direct the build of software. So called revision control systems work on a central server and enable developers to check out a copy of a document, edit it, and commit the changes back to the central server. In practice, this also means that one must update the local copy of the document often, to include changes that others have made elsewhere and to avoid eventual conflicts. A conflict occurs when at least two people edit the same part of the document so that the revision system is unable to merge both changes into each other.
Bob and Jane could use the revision marks system used within AbiWord to coordinate their work on the common document. However there is always a lag between Bob and Jane seeing what each other writes. This always slows down the development of documents as each person needs to make sure their changes fit into what the other person is doing.
Thus they will probably use the most common method today: sending copies of changed documents to each other by e-mail. As a result, both Bob and Jane will spend a large part of their time to find out what the other one changed and merge these changes back into their local versions.
This may work when only two parties are editing a single document. But it becomes significantly more difficult when three or more parties try to coordinate their changes.
The next major version of GNOME Office will introduce a new way of handling the problem, called GOCollab. GOCollab will basically marry the already built-in revision systems of Abiword and Gnumeric with a P2P network comparable to file sharing applications like Gnutella or eMule. This means that neither Bob nor Jane nor anybody else needs a central server to be set up and run, and most of their changes to a document will be merged together automatically.
GNOME Office currently consists of AbiWord, Gnumeric and GNOME-db.
Imagine then, that Bob and Jane are using AbiWord for their task to write a common document for their presentation. They will first need to agree on who’s hosting the original file. Let’s say Jane starts the document because she’s got a better overview on the features of the new product. Jane then opens AbiWord, makes a new document, writes an initial paragraph, and saves it as usual.
Although the user interface of GOCollab is not yet fixed, Jane’s GOCollab-enabled Abiword will probably have two new options under the existing File menu: ‘Offer Collaboration’ and ‘Join Collaboration’.
When Jane clicks on ‘Offer collaboration’, a collaboration server is started on Jane’s computer that allows other people to join and start collaborating on the current document. Bob’s problem is now to find the new collaboration server on Jane’s machine.
Bob thus starts AbiWord on his machine and clicks ‘File’ -> ‘Join collaboration’. He will then see a dialog asks that lists all offered collaboration documents on his network. But how does AbiWord knows about these documents?
There are two mechanisms that can be used to find and join a collaboration server:
- A direct IP/Hostname based connection. When Jane clicks ‘Offer Collaboration’, the connection details of her machine are presented to her. She can send these to Bob or to anyone else.
- Discovering offered collaboration services using libHowl. LibHowl allows applications to browse and publish services via Zeroconf multicast DNS service discovery. This works over a VPN or within some trusted IP domain. Bob just browses the computers presented until he discovers Jane’s offered document.
Once Bob discovers Jane’s document and attempts to join in, Jane will be given opportunity to confirm or deny his request.
When a connection is established, the server transmits the originating document to the client as a gzipped XML file (*.zabw for AbiWord, *.gnumeric for Gnumeric). A new view on the “remote document” is created and the user can start modifying the document.
In contrast to other schemes, the ‘remote document’ is not really ‘remote’ but local. Bob will see the document in Nautilus like any other file, open it like any other file, and save it like any other file. The difference is that Bob can see Jane’s changes exactly as she makes them and Jane can see Bob’s changes exactly as he makes them. Both documents are always the same. So as Jane types in her document Bob sees his document change. As Bob types in his document, Jane sees Bob’s changes.
Now either Bob or Jane can allow other people to join the collaboration. So the collaboration can grow as big as it needs to be.
Abiword and Gnumeric both implement Model-View-Controller (MVC) paradigm of document creation.
The Model – View – Controller pattern is a way of organizing source code. The Model can be described as the software’s internal representation of content such as documents. The View is responsible for how the internal representation is presented. The Controller is responsible for managing changes to the Model.
The MVC pattern is just a way of organizing source code. The concrete implementation usually differs between different applications.
Abiword, for example, records changes to the Model via ChangeRecord objects. A series of ChangeRecords represent how you altered your document. Gnumeric works quite similarly, but calls its changes ‘Cmd’. One could say that Abiword or Gnumeric already work as revision systems internally. In other words, both Abiword and Gnumeric don’t work with your document directly, but with a recipe of how to build it. Whenever you request a change to your document or spreadsheet by hitting a key or clicking a button, a new command is added to the recipe.
However, humans would rather not work with a recipe. They want the cake. Thus, so called ‘Listeners’ are attached to every model in Abiword. They convert ChangeRecords into a physical file on your hard disk, or to a nicely formatted display on your monitor. Whenever a new command is added to the recipe, corresponding ChangeRecords are created and the application interprets these to build a new version of your document that is shown on your monitor screen or stored on your hard disk.
Every ChangeRecord has a corresponding inverse ChangeRecord that undoes whatever the ChangeRecord actually implements. So for example the inverse of inserting 4 characters of text at a given point in the document is to delete 4 characters of text. As a result of the implementation of ChangeRecords and Cmds, you can undo every action you’ve applied to your documents or spreedsheets: it’s just a matter of performing the inverse operation of the ChangeRecord.
Now, it’s just a small step to take a Change Record or Cmd, and send it over the network to another computer. The instances of Abiword or Gnumeric running on the second computer then just need to catch the ChangeRecord or Cmd and add it to an existing copy of the document or spreadsheet at the correct position.
AbiWord already uses so-called translators to catch a ChangeRecord and apply it to a document. This is used for clipboard operations. If you paste text into Abiword translators catch this and build a set of ChangeRecords that are applied to the document.
Thus there are two main elements to the new GOCollab feature: Listeners and Translators on the one hand to convert changes into network packages and back, and a P2P network on the other hand to transport these packages to participating applications on different computers.
A tricky question remains: How do we deal with network latencies? The fundamental problem is that Jane and Bob could get their documents out of synch because it takes a finite time for changes from one user to propagate over the network to the other’s computer.
Imagine for example, Bob adds a word or character at the end of the document. This forms a ChangeRecord which then travels over the network to Jane. Due to network latencies, this may take some time. Meanwhile, Jane adds also a word or character at the end of the document which forms a ChangeRecord. Thus, from the point of view of Jane’s Abiword, Bob’s ChangeRecord should be applied where one already is: At the end of the recipe, in the same position! This is a problem.
The solution, however, is rather simple. Every ChangeRecord gets a unique number that is increased. A proper document thus consists of ChangeRecords numbered 1, 2, 3, 4, 5, for example.
By transmitting not only the ChangeRecord but also its number, Jane’s Abiword will be able to tell that Bob’s ChangeRecord has the number 6 which already exists because Jane edited the document already.
Thus it will be able to change Bob’s ChangeRecord in two ways: First, it will increase the number of Bob’s ChangeRecord from 6 to 7. Second, it will change Bob’s ChangeRecord itself because Bob’s change affects the same place within the document.
Every ChangeRecord already includes information about the place. This is because AbiWord’s document’s are structured: Every single letter, field, image or format mark has a unique position within the document. Think of it like another series of numbers 1, 2, 3, …, 10, 11, 12.
Bob’s ChangeRecord affects the place 12 as does Jane’s. Thus, AbiWord will not only need to change the number of the ChangeRecord from 6 to 7, it will also need to change the place from 12 to 13.
This may not result in what Bob and Jane want. Bob’s change is now inserted after Jane’s in the document. Both may have wanted it to be the other way around. This is a conflict because Bob and Jane worked at the same place within the document, within the same period of time. Such conflicts are unavoidable because software is not yet able to tell what its users really want.
However, the larger a document, the more information about places are available. Thus, AbiWord’s algorithm to merge ChangeRecords has more information to determine the proper place, and change the place information accordingly. An initial outline of a document helps to prevent conflicts and there will be a deal of social engineering required to work collaboratively anyway. If the users keep mostly to their assigned parts of the document things will work much better.
GOCollab enables a new level of connectivity and collaboration between people. Any change to a document made by any user in the network is automatically distributed across the entire network of connected machines. This technique can also be used to update remote documents stored on a central server. The recent introduction of the Nokia 770, which will ship with both AbiWord and Gnumeric, allows an unprecedented opportunity for collaboration and connectivity by using GOCollab. Users will be able to collaborate on documents immediately anywhere and at anytime.
At present GOCollab exists as a specification and preliminary plugin for AbiWord. The network code used to transmit packages can be reused from other packages. The conflict resolution algorithms have been implemented as a demonstration program in Python. We’re currently devoting our limited resources to completing our next stable versions of AbiWord and Gnumeric in time for the GNOME-2.12 release. We plan to offer GOCollab for the subsequent stable releases of AbiWord and Gnumeric.
Google’s Summer of Code is over and so are the eleven projects that GNOME developers mentored. Julien Gilli and Akbar Pasha contacted the participants to find out what they reached, what it was like to take part in this summer-long event, and if it was fun to collaborate with the the GNOME community.
It has already accounted for one of this year’s major surprises, when Google announced that it would spend US$4500 for each of the four hundred students they would choose to work on open source projects.
Google worked with about forty open source organizations (among them, The Perl Foundation , KDE, Samba and others) to set up a list of available projects. Some were focused on implementing a particular new feature that would make the project shine even more, others were more research-oriented.
Then, students submitted applications to Google. By the middle of June, mentors and projects were assigned to the ones that were valued with the highest potential.
The Summer of Code is now over and it’s time for us to unveil the GNOME goodies that came out of the competition.
Of course GNOME fans and mentors had some great ideas for students to work on. The GNOME Foundation mentored eleven students. They all worked on new features and most of them have a working implementation of their initial plan. The projects’ topics range from music sharing integrated into the desktop to a Firefox extension that will help you to share tips for mastering Google searches.
In this article, you’ll also learn about streaming music to your GAIM buddies, encrypting folders in one click with nautilus or using your web cam and your head as a keyboard and mouse pair.
The first one, called gShrooms, was created by Raphael Slinckx. His initial plan was to allow people to stream music to and from their Gaim buddies in one click. But, “the project is a bit different from the submitted application proposal, especially concerning Rhythmbox integration which was not planned initially.”, says Raphael. As for now, “The application has reached a point where it works when the situation is perfect.”
gShrooms is not finished yet. Raphael “plans to move to a better streaming protocol when Gstreamer is ready, and improve aspects such as firewall/NAT bypassing.” For the moment, the feature will only work “if you have a PC directly connected to Internet or a UPNP capable router, and no firewall.”. One of the biggest problems he faced was “lacking, or even missing documentation”, but he has been “astonished by the GNOME community.”
Charles Schmidt applied to the Summer of Code with the idea to continue an existing project he started on October 2004. As he says, “It’s not just Rhythmbox being able to share playlists with iTunes, but also Rhythmbox sharing its music to other Rhythmbox clients on the network”.
At first Charles “had suggested doing this using a DAAP module for GNOME VFS so that you could hand GNOME VFS a URI like “daap://Lyndsey’s music” and it would return a directory full of music.” But soon enough, he “was convinced by others that the DAAP code should live inside Rhythmbox, not in a GnomeVFS module.” Indeed, he “imagined that one [benefit] would be able to browse DAAP hosts in Nautilus,” but over times, he wondered why a user would want to. Moreover, “several Rhythmbox developers suggested that core changes to Rhythmbox were not out of the question.” Finally, he points out that “the GNOME VFS API is not easy to grasp”.
So far, this move “has definitely paid off”, and he was able to “push out a patch last night that other people were able to get working”. Charles doesn’t want to stop here; he “definitely sees himself continuing to work with the Rhythmbox community to improve DAAP” and he’s “thinking to tackle equalizer support next”. Even if he says that “time management is a skill [he is] still lacking”, great things should be coming from him in the next weeks.
GNOME Core Projects
The core of the GNOME desktop has received a lot of attention too.
Every GNOME user has applets on his/her desktop. Mentored by Havoc Pennington, Travis Vachon worked on a easy way to setup and publish panel applets – the so called panel bundles. “Eliminating the need to build tools and package maintainers was one of the main goals behind this project”, says Travis.
Even if he had “originally thought of the extensions as written in either C or Python. The major problem [with C] is that this would make it necessary to have build tools installed”. Luckily, “Python is a whole lot more fun to write and allows a developer to really focus on the neat stuff”, says Travis.
At first, he “thought [he] would be creating a system to bundle up current panel applets for distribution.”. However “while many aspects of developing panel applets have carried over to the extension system, it is, indeed, a new system.”. Nevertheless, “converting a current Python-coded applet to an extension is pretty simple, and will actually simplify the code.”
Bundles can already be used without any modification to the GNOME desktop because they “are currently being implemented through a container applet”. However, proper integration into the panel is, according to him, “a decent distance away.”
Travis has been “particularly impressed by PyGTK, and all of the related GNOME Python bindings”. On the opposite, he says that “it would be nice to see [the panel] improved”. Indeed, “one original idea for the project was to be able to click on a link to a bundle on the web site and have it appear somewhere on the panel immediately.”. When he tried to accomplish this, “it turned out this wouldn’t be possible with the current implementation of the panel.”
From now on, “there’s a ton of work still to be done from improving the panel_extension Python module to integrating things into the panel and translating things from Python to C to make them faster.” In the meantime, Travis offers a tutorial about bundles.
Lorenzo Colitti, mentored by Owen Taylor, worked on improving the GNOME desktop’s startup time. The project’s focus has a bit shifted from the initial proposal, since Lorenzo’s mentor was more interested in “producing solid methodology and results than getting patches in”.
Lorenzo says that “Owen has been a great mentor”. They were able to meet in person. “He even put me up at his place, and we hacked together a couple of days !”, says Lorenzo. He learned that “performance monitoring is hard” and that “performance and flexibility can be conflicting goals.”
Using measurement tools such as bootchart and custom kernel modules, Lorenzo has been able find bottlenecks and modify the GNOME desktop so it starts almost 50% faster. However, he says that “some of these changes are hacks and it will take time to integrate them properly into the main code base”. However, the project is not done yet “because it’s so broad”, and Lorenzo “definitely hopes to continue hacking on it in the future.”
Mentored by Christian Kellner, Jon Manning hacked the GNOME VFS layer to bring it encrypted folder support out of the box. His original plan changed significantly, since “loopback-mounting an encrypted filesystem” included “mucking around a bit too much with permissions” and “there wasn’t any way to access the data over a network as easily as you could locally.” So they decided to encrypt the files individually with OpenSSL. This “new archive format means that we can get Nautilus to detect its type with more ease than we could if it was a filesystem”, says Jon.
He “was pretty impressed with both how thorough the GObject system [is] and how easy it was to get going”. He also found that “the interfaces Nautilus provides made developing [his] plugin nice and simple”.
One can see that although the UI changes might be quite small, the feature provided is exciting. “There’s a bunch of things we want to implement including integrating with with GNOME-VFS which will allow on-the-fly browsing and decryption, and make the archives appear as regular folders.,” says Jon. For sure, “there are good times ahead for this project!”
Sharing of Google Searches
People often get stuck into unsuccessful Google searches. Sanford is now able to offer a way to overcome this situation. Not only does his Search Party Firefox extension allows you to share search tips with people from all over the world, it also creates communities around similar interests. Type your search on the Google web site, click on the “Join Search Party” toolbar button, and you are connected to a chat room, being notified of other people’s successful attempts at searching similar information.
Client side, the project takes the form of a Firefox extension. As for the server, Sanford had “initially intended to write the Search Party Protocol directly over TCP, and have a Java server somewhere that took care of matching up users with the proper chat room.” However, he changed his plans when Seth Nickell “pointed out early on that this might make the extension unusable for those behind various firewalls”. He then chose XML-RPC, which uses the firewall-compliant HTTP protocol as a transport medium.
One of the main difficulties was to “teach the extension to speak XML-RPC”, because “Firefox’s included implementation is broken”. As a consequence, he hasn’t had “that much time to focus on the trickiest part of the project: deciding what exactly makes two search queries similar.”
He plans to “continue working on it for quite awhile” and thinks that “the server will go through a lot of performance tuning and other re-factoring” apart from “the work he would like to do on the query matching algorithms.”. He can’t wait “for people to download it from the wiki, try it out, and tell [him] what they think!”.
Finally Adam McCullough and his mentor Johnathan Blanford worked together to make GNOME more accessible.
The system, named “CamTrack”, has been divided in two components : the tracker and the input method. The tracker tries to recognize and match facial motions with events (maximizing a window for example). The input device is in charge of forwarding the events to the X Window system and GNOME.
Though his “original proposal was mainly concerned with the details and capabilities of the tracker itself”, Adam needed to create a simple and usable system. This lead to “both a reduction in complexity and a broadening in scope.”
In his opinion, “the attention paid to accessibility in GNOME is more noticeable than in any other environment”. He goes on saying that “it’s been surprisingly simple to add a completely new interface to the GUI”. Overall, he has been very impressed by GOK.
Adam likes to think that he’s “contributing to widening access” and “intends to keep developing [CamTrack] for some time”. He points out that “the system is usable,” but would like to make “a long list of improvements as well as a lot of tidying up needed and probably some bug squashing”.
Unfortunately, some students haven’t had the time to respond to our questions early enough for us to write about their project. Danilo Segan tried to find a way to provide live editing to the GNOME documentation, David Morrison worked on implementing GMail-style conversation view for Evolution, and Daniel Ramage hacked the first bits of the GNOME command line framework.
Overall, it seems that both students and mentors had a very good time hacking during this year’s Google Summer of Code. As Raphael says, “every hacker would enjoy a summer of code!” The GNOME project has successfully managed to gather brilliant students and mentors together to bring new features to the GNOME desktop.
For students, working with the GNOME community proved to be a pleasent experience: “Everyone has been very helpful, friendly, and enthusiastic,” says Travis. As Raphael puts it, “GNOME rocks!”