Tips

Tips

This section has a few more technical hints for application authors:

• You can use any toolkit you like (or none at all). However, try to make your application fit in with the other ROX applications. The best way to do this is to use the same toolkit: GTK+.
  ROX-Lib contains some useful code that will help to make your applications fit in well. It also allows users to change the behaviour of all applications in one place (eg, if someone actually prefers mini-filers to drag-and-drop they can edit ROX-Lib to affect all programs).
• While editor windows should try not to waste space, dialog boxes are temporary and therefore may use more room. A border of a few pixels around the window edge, and a small gap between buttons, can make a big difference.
• Don't provide a Help button unless you have something useful to say. Broken or pointless Help buttons just train users to ignore them. Some GTK+ widgets (eg, the colour selector) have Help buttons by default. Hide them.
• User preferences should be stored as explained in Configuration settings.
  Try to avoid saving choices if nothing has changed.

Portability

The ROX desktop works on many different systems, almost all of them some variant of Unix. However that are many small differences between operating systems, between distributions of an operating system and between versions of a distribution. Some of these you will need to know about when writing ROX applications.

The Bourne Shell and the Bourne Again Shell

One thing that makes Unix a powerful operating system is its shell, the program that lets you type in commands and execute them. The default shell, the Bourne Shell, is quite a powerful scripting language (although its user inteface features may be lacking). Some commands on a Unix like system are not compiled programs, but instead are Bourne shell scripts. Under ROX the AppRun files of wrapper applications and compiled C programs are normally Bourne shell scripts.
Although the Bourne shell (normally located at /bin/sh) is a good scripting language it is not so good as a user interface. What's more it is proprietry. Thus a free open source replacement is required for Linux and other free OSes. One such (and there are many others) is the Bourne Again shell (/bin/bash). Unlike some of the other shells the Bourne Again shell is fully compatible with the Bourne shell and adds many useful features. Under Linux /bin/sh is actually a symbolic link to /bin/bash. This causes problems that Linux users and programmers may be unaware of.

When acting as /bin/sh, the Bourne Again shell still supports all its extended features. Thus a programmer on Linux can write a Bourne shell script using Bourne Again features and not know it, until it is run on a system with a genuine Bourne shell such as the commercial Unix's.
Here are a few of the more common problems.
export of variables

This works in bash, but not sh

export VAR=val

in sh it must be

VAR=val export VAR

test

The -e argument to test to test for the existance of a file does not exist in sh, use -f. e.g. replace

if [ -e "$@" ] ; then

with

if [ -f "$@" ] ; then

Equality

Use only a single = symbol to test for equality, not ==

pygtk

The pygtk 2.0.0 module is fairly recent, some versions of distributions are still using the development series 1.99.x. Most of the diffences are minor, but one that has caused trouble is the creation of GtkLabel's. In pygtk 2.0.0 you can omit the string argument to get a blank label but in some of the 1.99.x releases you cannot. Simply replace

lbl=rox.g.Label()

with

lbl=rox.g.Label('')

and it should be fine.

which

The which program is used to locate executable programs. Except that under Solaris it works differently than under Linux. It is explicity tied to the C shell, not sh, and produces more output than you may expect. Best to avoid it.

killall

Under Linux killall kills all the processes with the program name given as arguments. Under Solaris killall kills all user processes prior to system shutdown and pkill kills processes by name. Best to avoid it.