Hints

The Ubuntu desktop

If you don't have much experience with the Ubuntu desktop you'll find you can come up to speed pretty easily. The Apress book  Beginning Ubuntu Linux, Third Edition is a reasonable starting point. Here are some tips for setting up your desktop environment:

• If you have an nVidia video card, install the proprietary drivers with System -> Administration -> Hardware Drivers, reboot, and your resolution should be okay. For setting up external monitors, run gksudo nvidia-settings.
• With other video cards, Ubuntu unfortunately fails to detect the actual resolution of many monitors, especially when you're using a laptop with an external monitor. You may need to set the resolution manually using the xrandr command; for example, you might run xrandr --output VGA --mode 1920x1080 .
• In Nautilus (the file browser), you might want to turn off the side pane. Also, you probably want to go to Edit->Preferences and set "View new folders using:" to Compact View, and clear the checkbox which says "All columns have the same width".
• By default, Ubuntu has toolbars (also called panels) along both the top and bottom of the screen. This eats up vertical space, and is unaesthetic to some of us. You might want to move all widgets from one panel to the other, then delete the empty panel.
• You'll definitely want to install the nautilus-open-terminal Ubuntu package, which lets you easily open a terminal whose current directory is the directory you're currently viewing in Nautilus. You'll use this all the time. Note that after installing nautilus-open-terminal you'll need to log out and log back in before you'll see the Open In Terminal item appear in the Nautilus context menu.
• You probably want a desktop icon pointing to your home directory. Setting this up is not hard, but is not as easy as it should be: follow the instructions  here to enable the home_icon_visible GConf key.
• By default, Ubuntu enables desktop effects, which are animations that occur when you perform desktop actions such as minimizing a window. If you find these distracting, you can disable them via System->Preferences->Appearance->Visual Effects.
• You may want to show the System Monitor in your desktop panel to have a visual indication of CPU activity. To add it, right-click the panel, choose Add to Panel... and select System Monitor.
• meld is a nice graphical diffing program; you can install it through Synaptic.
• You might want to set up your machine to generate a core dump if a program crashes; that will be useful if you encounter a difficult-to-reproduce bug in our code. To set this up, edit /etc/security/limits.conf and add a line that looks like this:

  *		 soft	 core		 200000
  

  Above, the number 200000 is the maximum core dump size in kilobytes (i.e. 200 Mb).  You'll need to log out and log back in for this change to take effect.
• devhelp is a nice development help file viewer. Many GNOME-related packages have an associated doc package which includes documentation in devhelp format; for example, install libgtk2.0-doc and the GTK+ documentation will appear in Devhelp.
•  accerciser or  gtkparasite can be used to do Firebug-like inspection of a GTK program.

gedit

• Dealing with soft tabs for source files and hard tabs for Makefiles is a pain. Turn on the Draw Spaces gedit plug-in to visually see when you're using soft or hard tabs. (It can be configured to show all manner of whitespace.) Also check out  autotab, which detects if the current file is using hard or soft tabs and adjusts accordingly.
• By default, gedit displays 5 recent documents in the File menu. You might want to increase this number; to do that, run the Configuration Editor (gconf-editor) and change the value of /apps/gedit-2/preferences/ui/recents/max_recents.
• You'll want to install a gedit plugin that can search for a string in all files in a directory; this is invaluable for programming. There are a few such plugins and none of them are perfect. The best we've found is  File Search, which works reasonably well (though see #627 for a description of some of its limitations.)

Yorba

• Here's how to check out a Yorba module named foo from Subversion:

    svn co svn://svn.yorba.org/foo/trunk foo
  

(If you have commit privileges in our Subversion repository, use yourname@svn.yorba.org so that you'll be able to commit changes later on.)

• The bin directory in our Subversion tree contains a number of useful scripts. We recommend that you check this directory out and place it in your path:

    svn co svn://svn.yorba.org/bin ~/bin_share
  

  Add this line to ~/.profile:

      PATH="$HOME/bin_share:$PATH"
  

• Check the  directory of all our mailing lists and subscribe accordingly. You should obviously subscribe to project(s) you're actively working on and any other you've contributed to or have interest in. (Ideally, all Yorbas should subscribe to all lists.) Note that the mailman list is purely administrative; there's no need to subscribe to it.

Building programs

• If you've downloaded a tarball, you'll typically type "./configure" to configure it. If you've checked out sources from Subversion, typically need to type "./autogen.sh" to generate the configure script and run it, if one exists - otherwise use make.
• Before building any program which exists in a package in the Ubuntu repository, you may want to run the command sudo apt-get build-dep <packagename>; this will automatically install all packages needed to build the given package.
• When you run make, you may want to pass -j2 on the command line to run 2 jobs at once since you probably have at least two CPUs in your system. This will often make builds run twice as fast.
• After building and installing an application from source on Ubuntu, you may find that when you launch the application nothing happens (if launched from the Applications menu) or that you get an error about a shared library not being found (if launched from the command line). This usually means that you need to rebuild the system's index of shared libraries; you can do this by running sudo ldconfig.

Subversion

• Run meld . to see a list of all changes you've made in a directory you've checked out from a Subversion tree.

GTK

We develop using the GTK+ toolkit which underlies the GNOME desktop and runs on other platforms as well. GTK+ is a large and powerful framework and it can take some time to get up to speed with it. The best introduction is the book  Foundations of GTK+ Development by Andrew Krause; you'll refer to this a lot. Havoc Pennington's book  GTK+/Gnome Application Development (available online or on paper) was written back in 1999 during the early days of GNOME, but is still surprisingly relevant and useful, and is the best place to learn about GTK's inner workings, including its interactions with the X Window System.

You'll also of course want to install Devhelp (the GNOME documentation browser) and spend a good bit of time perusing the GTK reference documentation, which you can install as the Ubuntu package libgtk2.0-doc .

•  GTK drag and drop tutorial
•  GTK single instance apps

Useful to know when debugging: If you launch your application with --g-fatal-warnings as a command-line parameter, GTK will abort when an assertion triggers. (Normally assertions are soft, that is, they merely log an error and exit the function.) This is particularly useful when running under gdb.

GNOME

• Here's how to check out a GNOME module named foo from Subversion:

    svn co http://svn.gnome.org/svn/foo/trunk foo
  

GStreamer

 GStreamer is the open-source multimedia framework used in GNOME and on other platforms. We'll likely be using it to build audio and/or video editing applications. There are no books about GStreamer yet, but the  documentation on the Web site is pretty readable and comprehensive. If you want to understand how it works at a deeper level, you'll want to download the source and look at the documents in the docs/design directory.

The Gst.debug_bin_to_dot_file_with_ts function can print out an entire pipeline of elements to a dot file, which can be postprocessed into an image. To enable, you must set the environment variable GST_DEBUG_DUMP_DOT_DIR to the directory where you want the files placed. Call the function at the point where you want the graph pipeline state saved. This function prefixes the file name with a time stamp, so you can call this function from the same point in code without overwriting a previous state. This is useful to see what is happening when a pad is added, for example. To convert a dot file to png format, you will need the graphviz package installed. The following script will convert all the dot files to png format:

for var in *.dot; do dot -Tpng -o$var.png $var; done

Vala

We will be developing new applications in  Vala, a new object-oriented language which looks much like C# but compiles to native code via C. Vala is designed to be tightly integrated with GObject-based frameworks such as GTK. There are no books about Vala yet, and the existing documentation is a bit patchy, so you may need to learn some parts of the language by reading sample code, experimenting and/or asking questions. The  Vala tutorial is worth reading, as is the  reference manual draft. The sample code linked from the Vala home page is worth studying, especially the GTK+ and GTK+ Custom Widget samples.

Don't install the Ubuntu vala package; it's ancient. Instead, subscribe to the  Vala Ubuntu PPA and install it from there (it's kept up-to-date), or download Vala from the Vala site and build and install it yourself. New releases of Vala appear every few weeks or so; we generally use the latest-and-greatest release.

When you're building Vala manually, be sure to include the --enable-vapigen flag so that the vapigen tool will be built and installed. We use vapigen to generate Vala bindings for various libraries.

 Valencia turns gedit into a lightweight development environment for Vala.

When you write GTK code in Vala, you'll want to refer to the  Vala Binding Reference which describes the Vala binding to each GTK class. Unfortunately the Vala reference only lists classes and methods without describing them; for their descriptions you'll have to refer to the C-based documentation. You'll soon find that it's time-consuming to switch back and forth between the C and Vala documentation. It's best to learn how to infer the Vala prototype for a method given its prototype in C; this is usually easy. Then you should be able to write Vala code by looking mostly only at the C documentation and by using Valencia's autocompletion to find the corresponding methods and fields in Vala.