openshot.developers team mailing list archive

[TJ <ubuntu@xxxxxxxxxxx>]

On Sun, 2009-08-30 at 14:11 -0500, Jonathan Thomas wrote:
> TJ,
> I was thinking about all of the PATH changes you are making, and just
> wanted to be sure you understood something (of course this is without
> seeing your code)....

Probably my emails make it sound more dramatic that it is, since I'm
focusing on resolving the paths issues I've created right now :)

The reason for starting the program directly from a Python script is to
make the project more amenable to cross-platform operation in the
future.

As I've got it right now, forgetting about the Debian packaging, Python
distutils does a complete install to share/openshot (usually the prefix
is /usr/ but could be /usr/local/).

distutils and its setup() function impose some requirements on the
layout of the packages and modules, one of which is that it is much
easier if all scripts are in packages below the 'root' of the
application. This is why I've moved OpenShot.py functionality to
"openshot/openshot.py".

That leads on to moving "classes/" "windows/" and "languages" modules to
be in sub-directories (packages) below "openshot/" since it means the
relative import paths remain unaffected ("languages.py" has moved to
"classes/" since it is separate from the "locales/" data files).

I've introduced "launcher.py" in the 'root' directory which is the
script that boot-straps the application. (This is simply symbolic-linked
from /usr/bin/openshot in the Debian package installation.)

The data directories all remain at the first directory level.

The change the Debian packaging requires is separating the writeable
files from the read-only application files (using "~/.openshot/").

I've introduced global variables in "openshot/openshot.py" that
calculate and store the key paths used throughout the application just
once. In modules that need these paths they simply do a sub-set of:

from openshot.openshot import DEBUG, BASE_DIR, USER_DIR, PROJECT_DIR,
GLADE_DIR, IMAGES_DIR

according to their needs. The reason for that is code simplicity -
various functions throughout the application shouldn't be constantly
recalculating what are static constant values - and being declared once
ensures no future mismatches as the code gets more complex.

BASE_DIR being correctly calculated as it now is, regardless of launch
method, means that however or where-ever the application is launched the
paths will always be correct.

The actual changes are pretty mundane - replacing path calculations
based on argv[0] with BASE_DIR or one of the other definitions as
appropriate. I've also fixed up some path calculations that used
formatting strings (e.g. "%s/%s" % (path1, path2)) since that is
non-portable - the reason for having os.path.join() is to build paths
using the correct path separator for the host operating system (in other
words, can't assume "/" is the separator).

The one change that was catching me out (the SEGFAULT episode!) is
moving to the user's read/write "~/.openshot/" directory. Most of my
problems are due to me originally doing a fast find/replace operation
without thinking about the intent of the code, but I'm sorting out my
own mess there now I realise what I missed :)

One thing the SEFAULT has taught me though is that all file paths need
testing for validity before attempting to use them, so this kind of
obtuse error can't inadvertently occur to users who have corrupt
file-systems or tinker with their files.

If I get the time I should be in a position to publish the changes I've
made to the core application, and the Debian packaging, to bzr on Monday
night, as well as publishing a binary to my PPA for testing.

As I said, once at that stage I can rebase my changes on top of the
current HEAD and parcel the changes up into small manageable patch-sets
specific to each change.