developing for Linux part 2
palcibiades-first at yahoo.co.uk
Sat Mar 24 05:31:35 CDT 2007
I forgot to mention one other very important aspect of the Linux environment:
forking. Because its all GPL, the source code is out there. If a team or
person doesn't take 'their' program where users want it to go, or think it
can or should go, they can just take the code and do it themselves. This
means that you are writing closed source for an environment with very
powerful competitive forces working on the opensource competition. You could
see this dramatically with xfree86 and xorg, which are or were the display
drivers for X11. There was widespread dissatisfaction with xfree86 which
finally boiled over. Within a few months, xorg had forked and everyone was
using it. Before, all distros used xfree86. After, it fell off a cliff and
none do. They didn't have to create it from scratch, just from where xfree
So suppose you write your app, and suppose it takes off, and suppose someone
writes a clone, open source, and gets a bit lazy and doesn't do much with it.
It is in the public domain, and anyone can seize it and make something better
of it. The only way he can keep it as his is to keep ahead of demand and the
pack. It means your competition is driven by and subject to competitive
forces far greater than you are, because you can keep your stuff private so
that only you can update it. They cannot. And this is why in the end the
money in opensource is from support, not sales. Sobering.
This for example explains the existence of PythonCard. It is basically just
an ide for Python - which was there, waiting to be used by someone who wanted
to make a Hypercard like product. But they did not have to write a scripting
language from scratch. There were a whole bunch of those to choose from
already out there.
Now, on to a few suggestions. But bear in mind reading them, I don't do this
for a living, and I am very light indeed on coding specifics! Others may be
able to add more on that.
1) Don't worry about matching look and feel: its hopeless and unwanted.
Specifically, don't worry about matching the look and feel of any particular
distribution. Because the look and feel doesn't vary with the distro so much
as with the window manager and desktop environment. And anyway, you are
going to have both gnome and kde users and they will be using apps from both
stables, so they will be used to things looking different.
2) Do however test on multiple distros and multiple desktop environments to
make sure that everything is visible and in the right place. Fonts will vary
unpredictably. I've found on a tiny scale that its a good idea to leave more
space than your development environment suggests you need around objects,
because their positioning can vary just a bit between distros.
3) Make sure you accomodate multiple users. You have to decide in the
installation whether you are installing for one user, or for all users. If
for one user, put your app in /home/user. If for multiple users you should
probably put it in /opt.
4) Make sure you then follow the conventions on where to store user data.
You'll be tempted to think there is such a place as 'where the application
is installed', and that perhaps you should keep your user data there. Like,
where is the programs folder? This would be a mistake. There is no such
place in Linux, except for your application and one or two others like it.
There are two reasons. One reason, which is both the glory and the shame of
Linux (the shame because it leads to 'dependency hell') is that Linux uses
shared libraries to a very high degree. So if you take a typical Linux app,
lets say part of the KDE Office suite, and you look for the database
component, Kexi, you will not find anything that you can really consider the
program Kexi and where it is installed. You'll find a whole bunch of things
scattered all over the system portion of the file structure.
If you try to install Kexi with no KDE installed on a bare, non-KDE Debian or
Ubuntu type system, where it gets all the dependencies for you, you'll be
surprised to discover that you're downloading over 100Mb. But Kexi itself is
quite small. Then you'll find that the rest of KOffice consumes very little
extra space. Its because you've already got the KDE libraries which are used
by all the K apps. Now, your application will be closed source and self
contained, so it will be in one place. But it is unusual in this.
The second reason is the accomodation of a multi user environment. No well
behaved Linux application will store user data in /opt, even if that's where
it installs itself. There are two reasons. First, routine backups will only
back up /home. So that's where all user data should go. The second is that
you have to allow for multiple users to create identically named files,
including preferences. So you cannot put them all in one place.
It follows that all user data belongs in /home/user, even if you are
installing your program in /opt in order for it to be usable by everyone who
logs in. Rev itself on Linux is not well behaved in this sense. It expects
as a default to store your work in the Revolution folder. It should expect
to store them in /home/user.
4) In the file navigation part of your app, don't make users step through all
the dot files. Rev fails here too. /home/user is full of files which start
with dot, as in /home/peter/.kde. When you are offering to save a file, or
open a file, don't display these. Its just confusing and irritating. Rev is
a good example of what not to do. You fire it up, and do open. It offers
you everything in the Revolution folder. However, you do not want that,
because the app you are working on is on the desktop. So you go up a level.
Now you see /opt. Up again and you see the file system. Down
to /home/peter. Now, before you can see the files on the desktop, you have 30
or 40 dot files to step through, and somewhere at the bottom is Desktop.
Don't do it to people! Any Linux app, eg Kate or OpenOffice or Gedit, will
show how this should be done. In compiled versions of course you get around
this by relative addressing, but you do have to think about it if you put
your app in /opt and your user files in /home/user. You'll get into this
mess if you allow them to just do open file, if it defaults to trying to open
a file in /opt/application.
5) Accomodate multiple desktops. All Linux desktops will come with multiple
virtual work spaces. Gnome or KDE will install out of the box with 4.
People need to be able to use them - if it makes sense for your app. This is
something that rev on Linux fails dramatically at. If you have lots of
different windows in an application open at once, you should be able to put
one or two on a different workspace. For instance, if I'm doing a
complicated spreadsheet, I often have the Open Office document open on one
desktop and the help open on another, and flip between them. With Rev, you
can have half a dozen free desktops, but all crammed into one window you'll
have the dictionary, the tool palette, the application, the property
inspector, the script editor, all overlapping and getting in each others way.
I've no idea how to write Rev apps so that they behave properly in desktops,
but if you are going to have this many possible windows, you have to allow
people to manage them as they are used to doing. To see how this should
work, use OpenOffice. Note the little icon and popup menu at the very top
left, above the File menu. Open up a document and also help. Then move help
to a different desktop. Notice how you can use the icons on the reduced
image of the desktop in the bottom toolbar (or the Gnome default is the top
one) to move open windows from one desktop to another. You can do this with
rev windows too. The problem is, as soon as you use them, back they all come
to the same desktop!
6) Be very wary of fonts. You cannot assume that a Linux install has all the
same fonts you have in OSX or Windows. If you are going to use the MS
fonts, you have to make sure they are installed. And alas, how to install
fonts varies from distro to distro. Kfontviewer is the common denominator,
but Gnome installations like Ubuntu will not have it out of the box, they'll
have to get it first. Mandriva has its own font management package. The
safest thing is going to be only use fonts which you are sure come out of the
box for all distros. The other issue with fonts is paths. Even if you
supply fonts, you can't be sure, unless the path is set right, that your user
and thus your app, can find them. Don't go there, unless your users are
I am conscious that this is all a bit high level, but its what has struck me,
and if it prompts others to write more detailed dos and don'ts, maybe it will
More information about the use-livecode