openshot.developers team mailing list archive

[Jonathan Thomas <jonathan.oomph@xxxxxxxxx>]

Thanks TJ for the update.  Sounds good to me.  Just let me know when you are
ready to merge back into the main line.

Thanks,
-Jonathan

On Sun, Aug 30, 2009 at 3:20 PM, TJ <ubuntu@xxxxxxxxxxx> wrote:

> 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.
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openshot.developers<https://launchpad.net/%7Eopenshot.developers>
> Post to     : openshot.developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openshot.developers<https://launchpad.net/%7Eopenshot.developers>
> More help   : https://help.launchpad.net/ListHelp
>