developing for Linux part 2

[Peter Alcibiades]

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 
left off.

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 
quite expert.

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 
have helped.

Peter