The application ‘ffmpeg’ consist of three executables and 5 libraries. All the sources can be downloaded using the following svn command:

Ø      svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg

 Required patch

One version which I tried ( download: svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg –r 17944)

has a known problem with the sources. If you try to build the code, then you will get a compile time error:

 libswscale/swscale.c:488: error: ‘PIX_FMT_YUV420PLE’ undeclared

The solution is solved by copying the contents of the libswscale directory from .   http://www.ffmpeg.org/releases/ffmpeg-0.5.tar.bz2    (see http://www.ffmpeg.org/download.html)

Please Note, only the libswscale directory should be copied over the top of the existing files.

Build Instructions

Following instructions will help you build ffmpeg under a Linux system assuming that the tar ball from the download is copied to <install_directory>:

 Ø      cd  <install_directory>

 Ø      cd tar xvfz  ffmpeg.tar.gz   #Extract the tar ball to your local directory. You will find a directory tree under the name ffmpeg installed. All the required sources are installed within this tree provided that you are not enabling any additional third party libraries.

 Ø      cd ffmpeg

 Ø      ./configure –help <cr> # to show all the options available to rebuild ffmpeg. For a reference build with gcc there is no need to provide any parameters to configure. However if you would like to enable any third party libraries like ‘libfaad’, ‘libx264’ etc. then you need to add --enable-libfaad --enable-libx264 etc. as parameters to configure. If this is required make sure that you have these sources available on your development environment and that the third party libraries are rebuilt with the selected compiler / compiler options.

 Ø      ./configure <parameters as below>

 Ø      make <cr> #recommended sequence is ‘make clean’ followed by ‘make’. The rebuild will take several minutes (depending on your development environment). Two versions of each executable are produced: ex. ‘ffmpeg’ and ‘ffmpeg_g’. The ‘*_g’ contains the executable with debug information while the ‘*’ is the stripped version. In addition ‘ffplay, ffplay_g, ffserver and ffserver_g’ are produced as executables and libavutil, libavcodec, libavformat, libavdevice and libswscale are rebuilt.

 Icc build:

Depending on what version of icc you are using different configure parameters may be necessary.

 Using icc v10.1.xxx:

 Ø      ./configure cc=icc --extra-cflags=”-xL –O3” --extra-libs=-lsvml <cr> # Without linking in the extra library (libsvml.so) you get several references unresolved.

 Using icc v11.0.xxx:

 Ø      ./configure cc=icc –extra-cflags=”-xSSE3_ATOM –O3” –extra-libs=-lsvml <cr> #  The option –xSSE3_ATOM do require that you run the code on a processor which does support the ‘movbe’ instruction. If you would like to test the code on a processor not supporting the ‘movbe’ instruction you can add the option ‘-minstruction=nomovbe’ in the extra-cflag part of the command line above.
Ø      Make sure that the LD (linker) options do not contain ‘–march=generic’ in the config.mak file. This option causes an error from the compiler.

Using icc v11.1.xxx:

Ø      To avoid a run time erratum following source change is needed:   Open file ./libavcodec/x86/dsputil_mmx.c and on line #2944 insert // before || __ICC > 1100. The line is highlighted below.

Ø      After the change it will look like: #if ARCH_X86_64 || ! ( __ICC) // || __ICC > 1100

Ø      ./configure cc=icc –extra-cflags=”-xSSE3_ATOM –O3” <cr> # This simple configure does work but you get better performance if you also add the ‘--extra-lib=-lsvml’. Additional compiler switches can be used to improve the performance – for example ‘-no-prec-div’, ‘-vec-‘. As the no-prec-div has an effect on the fp calculations please refer to the compiler documentation before it is used. In addition the ‘-xSSE3_ATOM’ switch are no longer requiring a processor with ‘movbe’ support.

 Cross compilation.

It is standard practice to build the library and executables on a development machine and then copy the resultant files to the MOBLIN target.  You can use the option --enable–cross-compile in this case.

Once you have completed the configure stage you can just run the ‘make clean’ followed by ‘make’. You could expect additional warnings produced.

Building ffmpeg with third party libraries:

The application can support 21 different external 3^rd party libraries. Each of those are selected in the configure process by adding the option ‘--enable-<library-name>’.

Below is an example of using some of the different external libraries available:

 Ø      ./configure <other options as above> --enable-libfaac --enable-libfaad --enable-libmp3lame --enable-libtheora --enable-libx264 --enable-libxvid 

The invocation above assumes that you will be using 6 external 3^rd party libraries:

 - libfaac       # for example you can download ‘faac-1.28.tar.gz’ or later version from the web.

 - libfaad       # for example you can download ‘faad2-2.7.tar.gz’ or later version from the web.

 - libmp3lame # for example you can download ‘lame-398-2.tar.gz’ or later version from the web.

 - libtheora    # for example you can download ‘libtheora-1.0.tar.tar’ or later version from the web. Please note that you can not use ICC v 10.1 to rebuild this library due to a compiler issue. This has been fixed with 11.1 version of the compiler.

 - libx264      # for example you can download ‘x264-snapshot-20090117-2245.tar.bz2’ or later version from the web.

 - libxvid      # for example you can download ‘xvidcore-1.2.1.tar.gz’ or later version from the web.

Performance Notes: 

Best option combination for ICC: “-xSSE3_ATOM –O3 –vec- -static –no-prec-div –ansi_alias”. Also make sure you add –extra-libs=-lsvml in your configure invocation.

Two ways of improving the performance of ffmpeg:

1) Use the external 3rd party libraries which are supported – 20+ are available. They are optimized for their specific field. You need to select the suitable library – download the code and build them using the ICC.

2) Use PGO. Here it is important to produce a set of .dyn files for the most common conversion you will be using. The code size improves a bit and the performance also gets a boost provided that you use any of the conversions for which you generated a .dyn file. If you select a totally different conversion you actually could get a slower performance compared to both gcc and icc (general optimized version). For those who are not familiar with the PGO optimization this is a three step procedure:

a. Add the option –prof-gen to the extra-cflags section for the configure generation. Build ffmpeg.

b. Run the resulting binary on your target. Make sure you use representative input files and output formats. You may want to repeat this process several times. For each run you will have a .dyn file generated on the target. Copy these files over to your development system.

c. Now use the options –prof-use and –prof-dir <directory path where you have the .dyn files which you copied in step b> [make sure to remove –prof-gen option]. Generate a new make file with configure and build your ffmpeg. You may see a number of warnings ‘missing .dpi information for <file name.’ This is information only and can be ignored. The finally generated ffmpeg should be both smaller and faster.

Optimization Notice

Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice. Notice revision #20110804

Update: Mar 29, 2011 MeeGo (v1.1 released Oct 2010) is the successor of Moblin 2.0. MeeGo still uses GeoClue and Gypsy as Location Services for providing geolocation data. However, MeeGo has gained a robust set of APIs that utilize Qt. It is strongly encouraged that application developers code to the QtMobility Location APIs, which provide geolocation data. The Qt APIs are guaranteed to be a stable part of the MeeGo APIs, while the GeoClue/Gypsy APIs are not. However, the current implementation of the Qt Location APIs utilizes GeoClue/Gypsy for retrieving geolocation data on MeeGo devices. It may still be of interest to the reader to learn about how Gypsy works (article below), but LBS apps should code to the Qt Location APIs.

Gypsy

Gypsy has replaced gpsd as the GPS daemon for reporting location coordinates in Moblin 2.0. There are many reasons [1] as to why Gypsy may be considered an improvement over gpsd. This article will briefly describe what you can do, as a developer, with Gypsy. A complete API[2] and tutorial [3] are available at http://gypsy.freedesktop.org.

What can Gypsy do?

Gypsy is a convenient way for getting location information from a GPS device. Multiple client applications can connect to Gypsy, and Gypsy can connect to one or more GPS devices [4]. Gypsy can interact with both Bluetooth and Serial (direct connection) devices, and will parse the device's cryptic data [5] into clearer, programmer friendly values [6].

Developers interface directly with Gypsy by using its GLib API. Gypsy also has an open D-Bus API which can be controlled via Linux IPC (interprocess communication). This means that a location based application can be written in any language that supports [7] D-Bus communication, and can appropriately receive information from Gypsy.

How Gypsy data is organized

One difference between Gypsy and gpsd is in how Gypsy organizes its information, using Glib Objects to encapsulate different types of data [8]:

GypsyPosition: holds position data (latitude, longitude, altitude)

GypsyCourse: reports velocity information, in the form of speed, direction, and climb

GypsyAccuracy: reports the estimated accuracy, also known as the Dilution of Precision (DOP) for position in the horizontal and vertical planes

GypsySatellite: contains data from each visible satellite, including the satellite ID # (PRN), elevation, azimuth, and signal-to-noise ratio (SNR)

Each Object uses a method / signal architecture. For example, GypsyPosition has a method gypsy_position_get_position(...) that you can call at anytime to receive the current position. The other approach would be to use GypsyPosition's “position-changed” signal. You can register your own callback method, and instead of continually polling Gypsy for updates, your application will be signaled anytime the position changes.

Manually Locating and Launching Gypsy

The default installation path for gypsy-daemon is /usr/libexec/gypsy-daemon. If you're using the GLib API, you'll need to make sure that the gypsy daemon is running before you try and use it. An added benefit of using the D-Bus API is that gypsy-daemon will automatically launch (if it isn't running already) the first time you make a call to it.

For debugging purposes, it might be useful to execute gypsy-daemon with a “--no-daemon” flag. This will keep the process inside the terminal and spit out debugging information.

Geoclue

Geoclue is a location service that is also included with Moblin 2.0. It uses multiple providers (like Gypsy, gpsd, Hostip, Geonames, etc...) to provide more than the Position/Velocity information given by Gypsy. It can also give Address information based upon your current location. Please see http://www.freedesktop.org/wiki/Software/GeoClue to find out more about Geoclue. If you liked this article, you might also read the author's article on Geoclue.

Building a new ecosystem

In a world where devices are becoming increasingly more mobile, location information is becoming a more integral part of a user's experience. Applications with location features are making it to a variety of different platforms, and are setting a new standard for mobile functionality. Look for Gypsy and Geoclue to carry this standard to Moblin 2.0-based netbooks, MIDs and smartphones.

Geoclue is a geoinformation service that will be included in Moblin 2.0. It uses multiple providers (like Gypsy, gpsd, Hostip, Geonames, etc...) to provide more than the Position/Velocity information given by most location-based APIs. For example, it can also give postal address information based upon your current location. With Geoclue, a GPS device isn't the only way to judge your current position. Providers are included that can estimate your position based on GSM (cell towers) and IP / Mac address.

This article will briefly describe what you can do, as a developer, with Geoclue. A complete API[i] and tutorial[ii] are available at http://www.freedesktop.org/wiki/Software/GeoClue.

•             The Geoclue Master Provider

Selecting a provider to use in Geoclue normally requires some knowledge about the hardware that is being used. You would not be able to use the GPS providers (Gypsy and Gpsd) without a GPS device. Likewise, only a compatible phone can get its position using GSM by communicating with cell towers. You may also need to know something about your environment. Providers using Wi-Fi, GPS satellites, and Cell towers will only work as long as you can get a signal from their respective service. Additionally, there are providers that will only give Position information, and there are others that will only give Address information.

The Master Provider is an attempt to take away all of the complications of choosing the right provider. Just like any other provider, you may query for position and address information. The master will choose the best provider to provide what you are looking for. As the environment changes and a provider's signal goes weak, the master automatically switches to another provider and continues the flow of geoinformation.

The master can be controlled via a D-Bus or C API. As previously noted, a simple example (in C) of how to access the master provider is available at http://www.freedesktop.org/wiki/Software/GeoClue.

•             Selecting your own provider

For more control, you may wish to select your own provider. Below is a table of the standard providers[iii] that are included with Geoclue, along with the services that they provide.

Provider	Services	Description
Hostip	Position, Address	A web service that guesses location based on the current IP address.
Plazes	Position, Address	A web service that gets location based on your current router mac address. Interfaces with a user's Plazes account.
Manual	Address	A user-specified address
Localnet	Address	User-specified address that maps to a router's mac address (home, office).
Gsmloc	Position	Gets cell ID data, and estimates location from a web service based upon that data
Gypsy*	Position, Velocity	A GPS daemon that supports bluetooth and serial GPS devices
GPSd*	Position, Velocity	A GPS daemon that uses TCP sockets
Yahoo	Geocode	A web service that converts an address to a position
Geonames	Geocode, ReverseGeocode	A web service that can convert an address to a position. Conversely, it can also find the nearest address to a given position.

*Gypsy vs. Gpsd: As a note, the user should know that in Moblin 2.0, Gypsy is replacing gpsd as the default GPS daemon. See Gypsy's[iv] site for an article[v] that lists why Gypsy may be considered an improvement over gpsd.

•             How Geoclue data is organized

Geoclue divides its geoinformation into Glib Objects to create a modular separation of different types of data. As viewed in the table above, only certain objects / services are available with each provider.

GeocluePosition: holds position data (latitude, longitude, altitude)

GeoclueAddress: returns a HashTable of address information (divided into "street", "postalcode", "area", "locality", "region", "country", etc...)

GeoclueVelocity: reports velocity information, in the form of speed, direction, and climb

GeoclueGeocode: converts an address to a position (latitude, longitude, altitude)

GeoclueReverseGeocode: converts a position to an address

GeoclueAccuracy: reports the horizontal and vertical accuracy levels. This can be applied to each of the previous services, except for GeoclueVelocity

GeocluePosition, Address, and Velocity each use a method / signal architecture. For example, GeocluePosition has a method geoclue_position_get_position(...) that you can call at anytime to receive the current position. The other approach would be to use GeocluePosition's signal. You can create your own callback method that will  execute anytime a "position-changed" signal occurs. Instead of  continually polling Geoclue for updates, your application will be signaled anytime the position changes.

•             Debugging Geoclue Providers

Each provider has its own daemon that runs when it is asked to. The default location for the Geoclue daemons is in the /usr/libexec directory. Running these daemons in separate terminals can be useful for debugging purposes, if you are having trouble connecting to a provider.

•             Building a new ecosystem

In a world where devices are becoming increasingly more mobile, location information is becoming a  more integral part of a user's experience. Applications with location features are making it to a variety of different platforms, and are setting a new standard for mobile functionality. Look for Geoclue to help carry this standard to Moblin 2.0-based netbooks, MIDs and smartphones.

[i]     C API and D-Bus API

[ii]    Using basic Geoclue Providers tutorial

      Master Provider tutorial

[iii]   Geoclue Providers listed

[iv]   Gypsy - A GPS Daemon

[v]    Why should you use Gypsy over GPSD

Introduction

Build environment

The build instructions below are based on the assumption that the build environment is a Fedora10 installation. 

A copy of the installation disks can be found here. http://fedoraproject.org/get-fedora

It is important that the GCC tools are installed when the Fedora installation is installed.

Cross-development

The clutter libraries  and test environment  are first built on a Fedora installation, and then the resultant executables and libraries can then be copied over to a MOBLIN2 platform.

Virtualisation

The steps below can be undertaken on a virtual machine, the only restriction being that not all virtual machines support video acceleration  

The tests

There are a number of tests that can be used to benchmark the clutter library. The benchmark performance is measured by how many Frames Per Second (FPS) are achieved.

Building the Clutter Libraries

Downloading the sources

The sources for the clutter library can be obtained by using the following command.

In a development directory of your choosing download the sources

   git clone git://git.clutter-project.org/clutter

   git clone git://git.clutter-project.org/clutter-box2d

Progress for each download should be reported similar the following:

$ git clone git://git.clutter-project.org/clutter

Initialized empty Git repository in /home/intel/dv/clutter/clutter/.git/
remote: Counting objects: 25225, done.
remote: Compressing objects: 100% (10261/10261), done.
remote: Total 25225 (delta 20575), reused 18319 (delta 14944)
Receiving objects: 100% (25225/25225), 6.99 MiB | 104 KiB/s, done.
Resolving deltas: 100% (20575/20575), done.

Building the Sources

Directory structure should look similar to this:

             <dev-dir>/clutter/
            <dev-dir>/clutter-box2d

In each of these sub directories build the libraries as follows:

Choosing which compiler

Building with GCC

For our installation, we'll use the environment variable  $PREFIX custom directory so as not to override any existing installation

     export PREFIX=/opt/custom/gcc
    ./autogen.sh --prefix=$PREFIX

Building with ICC

To build the library with the Intel compiler use the following commands

    export CC=icc
    export CXX=icc

   export PREFIX=/opt/custom/icc
  ./autogen.sh --prefix=$PREFIX

Continuing the build

When autogen has completed you should get a message similar to the display below 

  
                                  Clutter    0.9.7
                         ====================
                                  prefix:   /opt/custom/gcc
                                Flavour:   glx/gl
                                 XInput:   no
                          GL headers:   GL/gl.h
                    Image backend:   gdk-pixbuf
                       Target library:   libclutter-glx-0.9.la
               Clutter debug level:   yes
                 COGL debug level:   minimum
                      Compiler flags:   -Wall -Wshadow -Wcast-align -Wno-uninitialized -Wno-strict-aliasing -Wempty-body -Wformat-security -Winit-self
        Build API documentation:   no
  Build manual documentation:   no
         Build introspection data:   auto

Now build the source by calling make

The progress of the make will be reported, the last few lines looking similar to this:

   Making all in tools
     CC    disable-npots.o
     LINK  libdisable-npots-static.la
     LINK  libdisable-npots.la
   Making all in po

Installing the new library

To install the new library call:

make install

Note, depending on the permissions of the installation directory (set with the $PREFIX variable in the previous steps) you may need to do this as root.

Building the tests

The test directory has a number of tests. The README describes the tests as follows 

"The conform/ tests should be non-interactive unit-tests that verify a single feature is behaving as documented. See conform/ADDING_NEW_TESTS for more details.

 The micro-bench/ tests should be focused performance test, ideally testing a single metric. Please never forget that these tests are synthetic and if you are using them then you understand what metric is being tested. They probably don't reflect any real world application loads and the intention is that you use these tests once you have already determined the crux of your problem and need focused feedback that your changes are indeed improving matters. There is no exit status requirements for these tests, but they should give clear feedback as to their performance. If the frame rate is the feedback metric, then the test should forcibly enable FPS debugging.

 The interactive/ tests are any tests who's  status can not be determined without a user looking at some visual output, or providing some manual input etc. This covers most of the original Clutter tests. Ideally some of these tests will be migrated into the conformance/ directory so they can be used in automated nightly tests."

To build the tests, from the top level of the test directory do: 

    make

The build will report:

    Making all in data
    Making all in conform
    Making all in interactive
    Making all in micro-bench
    Making all in tools

Running the tests

Having built the tests, each test can be run from the command line.

Automatic running of  tests.

Many of the tests do not run to completion, but keep running,  The script in the appendix below gives an example of how the tests can be automatically called and killed after a predefined time.

Appendix 1 -  Script to drive test cases

#!/usr/bin/perl
# list of tests TODO: EDIT THESE TO YOUR REQUIREMENTS
@Tests=("test-actors", "test-behave", "test-clip","test-cogl-offscreen","test-cogl-primitives","test-cogl-tex-convert","test-cogl-tex-foreign","test-cogl-tex-getset","test-cogl-tex-polygontest","test-cogl-tex-tile","test-depth","test-layout","test-multistage","test-pixmap","test-project","test-random-text","test-rotate","test-scale","test-script","test-sharder","test-text","test-texture-quality","test-textures","test-threads","test-unproject","test-viewport");

#@Tests=("test-actors", "test-behave");
@Results=();

# for each test run it for 10 seconds
my $Timeout = 10;
## chdir interactive;
my $bStarted = 0;

foreach my $Test (@Tests)
{
    # print "executing $Test\n ";
    eval {
        local $SIG{ALRM} = sub { die "alarm\n" }; # NB: \n required
        alarm $Timeout;
        # system("./$Test --clutter-show-fps > res.$Test.txt");

        # mark end of prev test
        push @Results, "END" if $bStarted;
        push @Results, "TEST:$Test\n-----------------------\n";
        $bStarted = 1;
        open (RUN,"./$Test --clutter-show-fps &|");
        while(<RUN>)
        {
            push @Results, $_;
        }
        alarm 0;
    };
    if ($@)
    {
        die unless $@ eq "alarm\n"; # propagate unexpected errors
        # timed out
        system("killall -9 lt-test-interactive");
     }
}
# mark the end of the last test
push @Results, "END" if $bStarted;

# process the results
my $NumTests = 0;
my $Total = 0;
my $Max = 0;
my $Min = 9999;
my $TestName="";

print "\nName Min Max NumTests Average\n";
foreach my $Line (@Results)
{
    if($Line=~/^TEST:(.*)/)
    {
        # print "IN TEST $Line";
        $TestName= $1;
        chomp $TestName;
        $NumTests = 0;
        $Total = 0;
        $Max = 0;
        $Min = 9999;
    }

    if($Line=~/END/)
    {
        # print "IN END :$Line";
        $Average = 0;
        $Average = $Total/$NumTests if $NumTests > 0;
        print "$TestName $Min $Max $NumTests $Average\n";
    }

    if($Line=~/\*\*\* FPS: (.*) \*\*\*/)
    {
        # print "IN FPS: $Line";
        $NumTests++;
        $Total = $Total + $1;
        $Max = $1 if $1 > $Max;
        $Min = $1 if $1 < $Min;
    }
}

print "exiting ..\n";
 

 Appendix 2 - Essential notes on installing Fedora  

When installing Fedora you must install the Software Development tools.

Design Choices

Many of the functional parts of this application are foundational to everyday applications, requiring features such as user authentication, configuration storage and retrieval, network communications, and user interaction. It’s important to modularize the design as much as possible to both break the overall project down into manageable pieces and to make it easier to reuse the code.

The application checks each time it runs to see whether any user credential information has been entered. If not, it presents a typical user name/password login dialog box and stores the information in an encrypted local configuration file. A preferences dialog box makes it possible to change the user name and password after initial setup along with other program options.

For the initial release of this program, I assume that there is an active network connection. This is a bit of a stretch for the Compal JAX10* MID I tested on: It did not have an active 3G radio, so there was no “always-on” Internet connection. I was able to simulate having a consistent connection by using Wi-Fi, instead. Later versions might check for connectivity and, if currently disconnected, queue up the message to send the next time a connection to the Internet is available.

Another design consideration for the mobile form factor is deciding what happens when a button is pressed. With this particular application, there is a consequence for choosing single-key action; every time the user presses one of the action buttons, a message is sent to Twitter. If you assume the user won’t inadvertently press a button or do something like put the device in a back pocket with the application running, it shouldn’t be a problem. Alternatives might include adding a confirmation dialog box to each action (“Really send message?”), adding a button or a timer to lock the screen, or exiting the program by default after the message is sent.

Building a UI for the Small Screen

One of nice things about Python* is the abundance of libraries to do just about anything you need to do. The Compal* MID used for this project has a number of useful libraries installed as a part of the base operating system, and I chose to take advantage of them. The GTK+* user interface (UI) library contains a wealth of resources for building everything from a simple dialog box to a complex data-entry form. PyGTK is a wrapper around the GTK+ library and provides access to virtually every routine through standard Python objects.
Building a login dialog using PyGTK consists of creating a simple window with individual text boxes for username and password. You can find a good example and explanation of these techniques on the PyGTK tutorial page. In the following code snippet the pass_input.set_visibility(False) line causes the password to be blanked by a dot symbol:

def login(self):
        dialog = gtk.Dialog('Login', 
                            self.window,
                            flags=gtk.DIALOG_MODAL | gtk.DIALOG_DESTROY_WITH_PARENT,
                            buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_REJECT,
                                     gtk.STOCK_OK, gtk.RESPONSE_ACCEPT))
        dialog.set_default_response(gtk.RESPONSE_ACCEPT)
        
        userbox = gtk.HBox(False)
        
        user_label = gtk.Label('Username:')
        userbox.pack_start(user_label)
        
        user_input = gtk.Entry()
        user_input.set_activates_default(True)
        userbox.pack_start(user_input)
        
        dialog.vbox.pack_start(userbox)
    
        passbox = gtk.HBox(False)
        
        pass_label = gtk.Label('Password:')
        passbox.pack_start(pass_label)

        pass_input = gtk.Entry()
        pass_input.set_activates_default(True)
        pass_input.set_visibility(False)
        passbox.pack_start(pass_input)
	  dialog.vbox.pack_start(passbox)

A second option with GTK+ is to create a table that fills the screen with a matrix of buttons that essentially takes up all the screen real estate. Although doing so might not be as visually appealing, it does accomplish the task of building a finger-friendly interface in which you can easily “click” the right button. It also provides a few more options for adding descriptive text to the button for the Twitter application. In Python, the matrix would look something like this:

def create_table(self):
        self.table = gtk.Table(3,4,True) # Create a 3 row by 4 column table
        button1 = gtk.Button("Button 1") # Create a button named button1
        self.table.attach(button1,0,1,0,1) # put button 1 in location 0,1
        button2 = gtk.Button("Button 2")
        self.table.attach(button2,1,2,0,1)	
        button3 = gtk.Button("Button 3")
        self.table.attach(button3,1,2,0,1)
.
.
.	
        button12 = gtk.Button("Button 12")
        self.table.attach(button12,1,2,0,1)

The lines with a single period are meant to indicate that the sequence repeats down to the final definition of button12.

Coding Practices

Python is a language that allows you to write code by the brute-force method, as in the lines above, or in a more elegant way using concepts like iteration. If you were to define all 12 buttons in a linear fashion, you would need 26 lines of code. Using the Python for construct, you can accomplish the same task in a mere seven lines of code. That equates to less than one-third of the code for this simple example, but the difference would be substantial for a larger table. Here’s the code in a more “Pythonic” way:

    def create_table(self):
        self.table = gtk.Table(3,4,True)
        for row in range(3):
            for col in range(4):
            	name = 'Twitter %i' % (row*4 + col + 1)
            	button = gtk.Button(name)
            	self.table.attach(button, col, col+1, row, row+1)

Keeping your code manageable is important when scripts start to get large. Python functions are a good way to break down your code into small, manageable pieces. It’s also important to point out that everything in Python is an object. You can see this to some extent in the create_table function through the use of the self construct. The function create_table creates a gtk.Table and returns it as an object—hence, the use of self to refer to the object being created. There is an abundance of resources on the Web if you’re not familiar with object-oriented programming concepts.

Taking advantage of all the built-in language features and functions is another way to keep your source code manageable. Python has a module for reading and writing configuration files named ConfigParser. This module provides all the tools you need to save and read program configuration information. It supports different sections and creates a file of name–value pairs within each section. There are even individual methods to retrieve specific types, such as getboolean, getint, and getfloat.

If you can’t find what you need in the Python standard library, chances are that someone else has already written what you need. A quick Google* search typically returns multiple choices for a specific tool. Python-Twitter is a good example of a helper library to accomplish the heavy lifting of sending messages to the Twitter service. It’s hosted on Google Code* and even comes with several sample applications.

You can test code on the Compal MID in several ways. File transfer over a USB port is drop-dead simple and works well.  Optionally, you could attach a USB keyboard to the Compal MID and use the VI editor directly on the device for your editing and the Python interpreter for testing. This method works okay for small proof-of-concept efforts but gets out of control for anything but small, simple programs. Another, similar approach is to use Virtual Network Computing* (VNC) to remotely view the screen on the device through your workstation.

Another way is to use the emulator approach.  The Moblin* project has a tool called the Moblin Image Creator* (MIC) for building platform-specific images. With MIC you can also use the Xephyr* emulator tool to launch an independent session for testing purposes. This method has the advantage of a rapid build / test cycle to help work the bugs out of your code in short order.

A final way might be to test the initial version of the software on your Linux* desktop.  The advantage is that you don’t need MIC.  The disadvantages are that you may need additional hardware for your desktop (GPS, for example) and that you can’t test MID specific functionality (such as screen characteristics).

Lessons Learned

Don’t get bogged down in the details too early in the process. It’s important to completely flesh out your requirements in the beginning, then make some design decisions based on a clear picture of what you’re trying to accomplish. Get comfortable with your development tools—especially the debugging portion—as you’ll probably use them more than you think.

The easier it is for you to test and debug your code, the quicker you’ll get it running.

Have a convenient way to transfer files to your device that doesn’t require a lot of motion. This could be as simple as keeping an easily accessible USB cable plugged into your workstation. When you get down to squashing bugs, it helps to make the process as smooth and painless as possible, especially if you’re editing all the code on a workstation and have to move it over to the device for testing.

Summary

Building a solid application for the MID platform requires the same set of disciplined steps you would use in any software project. Be sure you don’t skip steps like these:

• Take your time on the design process, and consider alternatives.
• Think through the UI design from a user’s perspective before you start coding.
• Write your code with testing in mind.
• Have a clear set of requirements that you can test.
• Use tools such as source code control, and check in your code frequently.

About Author

Paul Ferrill has been writing in the computer trade press for more than 20 years. He got his start writing networking reviews for PC Magazine on products like LANtastic and early versions of Novell Netware. Paul holds both BSEE and MSEE degrees and has written software for more computer platforms and architectures than he can remember.