oolite-saves and GNUStep directories

Problem · Post by **Problem** » Tue Jul 14, 2009 8:59 pm

Hello, I'm new on this board.
I just discovered oolite, and I really like it so far. There's just one simple thing that annoys me with the Linux version.
I'm using Debian 5.0, and when I play Oolite, it creates two directories "oolite-saves" and "GNUStep" in my home directory.
As I want to keep my home directory clean, I'd like to know if this behaviour can be changed, so that hidden directories can be used. Usually, Linux games use hidden config files and directories like ".oolite-saves".

Website · Post by **Cody** » Tue Jul 14, 2009 9:35 pm

Can't help with that one, Problem, I'm on Windows, but welcome to the Oolite boards.

Website · Post by **DaddyHoggy** » Tue Jul 14, 2009 10:37 pm

Hi Problem - welcome to the boards - I don't appear to share your issue when I run Oolite under Ubuntu (7.10) - I just get the .oolite-saves dir.

zevans · Post by **zevans** » Wed Jul 15, 2009 12:13 am

DaddyHoggy wrote:
Hi Problem - welcome to the boards - I don't appear to share your issue when I run Oolite under Ubuntu (7.10) - I just get the .oolite-saves dir.

Having compiled trunk now, I have a suspicion a few things were moved around in the Ubuntu package. What would happen if I pulled the 1.65 Ubuntu package source, put the nightly code into it, and built the package, I wonder?

Post by **another_commander** » Wed Jul 15, 2009 5:38 am

zevans wrote:
What would happen if I pulled the 1.65 Ubuntu package source, put the nightly code into it, and built the package, I wonder?

Why bother with 1.65 anymore? Just stick to the trunk build, it is better in every possible sense compared to 1.65.

Website · Post by **DaddyHoggy** » Wed Jul 15, 2009 6:43 am

I get the impression that Zevans is planning to use the packager to trick Ubuntu into building the trunk version - or have I misunderstood?

Problem · Post by **Problem** » Wed Jul 15, 2009 9:44 am

DaddyHoggy wrote:
Hi Problem - welcome to the boards - I don't appear to share your issue when I run Oolite under Ubuntu (7.10) - I just get the .oolite-saves dir.

Maybe the Ubuntu packagers have changed this.
I just installed Oolite 1.72.2 (autopackage from BerliOS) and still get the "oolite-saves" and "GNUStep" directories.

zevans · Post by **zevans** » Wed Jul 15, 2009 1:53 pm

Problem wrote:
DaddyHoggy wrote:
Hi Problem - welcome to the boards - I don't appear to share your issue when I run Oolite under Ubuntu (7.10) - I just get the .oolite-saves dir.
Maybe the Ubuntu packagers have changed this.
I just installed Oolite 1.72.2 (autopackage from BerliOS) and still get the "oolite-saves" and "GNUStep" directories.

Yep, I was talking about building an Ubuntu package (for internal consumption at this stage) but with trunk codebase because I quite agree, it's hugely better, and I am using it.

So:
@another: I quite agree.

@DH: Correct!
@Problem: The autopackage version seems slightly different to trunk and Ubuntu, and that is what got me into such an almighty tangle when I had autopackage and trunk both lying around.[/i]

Problem · Post by **Problem** » Wed Jul 15, 2009 4:30 pm

Here's a workaround for the moment. I have written a small bash script:

Code: Select all

#!/bin/bash
mv .oolite-saves oolite-saves
mv .GNUstep GNUstep
oolite
mv oolite-saves .oolite-saves
mv GNUstep .GNUstep

The script unhides the directories, starts oolite and hides them again when the game quits.
Just put this script (e.g. named ".oolite-starter") into your home directory, make it executable and change the Oolite menu entry to use the script.
It's really just a dirty workaround, but it works for me

zevans · Post by **zevans** » Wed Jul 15, 2009 4:58 pm

If you want the same folder to be used for both builds... why not just link 'em?

I've done this with OXPs now: moved all the OXPs onto a different filesystem and I can enable and disable them by plonking symlinks in and out of .Oolite/AddOns.

Problem · Post by **Problem** » Wed Jul 15, 2009 5:12 pm

I don't use two builds, I just wanted the directories to be hidden in the build I currently use

Post by **Micha** » Wed Jul 15, 2009 7:01 pm

Hi Problem, and welcome to the boards

The ~/GNUStep folder can't be renamed/moved - this is a shared directory for all GNUStep applications which you use, not just Oolite.

As for the rest, I use a personal build which does use hidden directories (with appropriate symlinks for when I play with vanilla trunk etc on my dev machine).

When I proposed submitting these changes there was some reluctance from the longer-serving developers; backwards compatibility, confusing people who can no longer find the Addons directory, etc.
Personally I don't really care (since I've got my own build which I play with anyway) but if we get enough Linux people wanting to have a more Linux-standard directory layout perhaps we can re-raise this.

Cheers,
- Micha.

Problem · Post by **Problem** » Wed Jul 15, 2009 9:01 pm

Micha wrote:
The ~/GNUStep folder can't be renamed/moved - this is a shared directory for all GNUStep applications which you use, not just Oolite.

This is true indeed, I should have mentioned that. I didn't think of it, because for me this not a problem. I don't use any GNUstep applications except for Oolite. As I said, it is just a dirty workaround to hide these two directories. I just don't like it when applications create files that are not hidden. If every application did that, my home directory would be a complete mess. So apart from Oolite, I really wonder why GNUstep does it.

Personally I don't really care (since I've got my own build which I play with anyway) but if we get enough Linux people wanting to have a more Linux-standard directory layout perhaps we can re-raise this.

I'd support it.
Anyway, as this is somehow "solved" for me, I'll stop complaining and play the game instead. It's time to practise docking a little more.

Diziet Sma · Post by **Diziet Sma** » Thu Jul 16, 2009 12:37 am

I'd support this too. Under Linux, things ought to be done in a standard Linux way. After all, from what I've seen/read, under Mac and Win, things are organised to suit the way those OS's work.

Post by **Micha** » Thu Jul 16, 2009 5:40 am

Not under Windows either - in fact, Trunk has gotten worse from 1.72 by installing Oolite in the root of C: drive by default instead of in C:\Program Files (or the regionalised equivalent).

IMHO a big issue in Windows is that Oolite doesn't use the users' home directory for saving files or accessing AddOns. This used to be possible by tweaking the batch file which starts up the Windows version of Oolite (in fact, this approach was quite neat as it allowed people to tweak Oolite to either use standard Windows paths OR relative paths to where Oolite happened to be installed which was useful for USB stick installs), however current trunk hard-codes the paths to be relative which is very bad from a Windows philosophy as no user-generated files should be stored in the installation directory of a program.

This new approach is a hack to work around Windows Vista's virtual store approach, which is a nasty hack by Microsoft to work around poorly coded apps (of which Oolite is now an example in this particular respect).

I don't use Windows for (Oolite) gaming, so it doesn't worry me, but if I did, I'd customize my build

As for Mac OS X, that -is- the primary platform, so of course that's got the best support

It also helps that OS X is a descendant of Next so of course it's got great support for that style of directory layouts.

Anyways, my hiatus of the past few months is hopefully coming to an end soon (I've even set up my Dev Machine again, woo!) so I can take a look at cleaning up my path sanitizing code for Linux and make the case to the senior devs again