Messages

1

General discussions / SFML 2.0 Mac OSX in App Bundle

« on: June 19, 2011, 06:29:19 pm »

I just noticed I misread your posts, I thought you were adding the function to OSX SFML, not to a pregenerated source file. I'd prefer the former.

As for the convincing part, my arguments still stay the same:

* You definitely need GetResourceDirectory() if you want to deploy on OS X and use any kind of data file, and and GetWriteableDirectory() if you want to save anything to the hard disk. It is similar for Windows and Linux if you want your application to be a good citizen on those platforms.

* There are default locations for both on all major platforms.

* Getting their values "the right way" requires platform specific code, and in the case of OS X even the use of another language (assuming most SFML users write C++).

* When you use SFML for what (I again assume) is the most common project, something game-like or at least an application that does its drawing itself and doesn't need a OS-supported menu bar, you don't need any platform specific code for the entire application and still got every kind of functionality (graphics, sound, input, networking, file access) at your disposal,

except for finding your own friggin' files.

* There are no good fire-and-forget (or include-and-link-to in this case) solutions for this problem, apart from libraries doing magic without asking you (like SFML did).

* I often read the argument of high or low level here, but isn't the task finding out what will be the most needed/used functions and supplying them instead of clamoring to some arbitrary measure of leveled-ness?
[/list]
I hope I don't sound too harsh, or else I'm sorry. I just had the questionable pleasure of working with SFML without those functions and spend days getting all of this working and compiling, and I don't get why everyone will have to suffer through the same.
And lastly, what about people starting development on Linux and wanting to port their application to OS X? Instead of cross-compiling, they will have to get the necessary functions from the XCode templates and somehow stitch it all together.

I admire the work you do here, but this a decision I just don't get. Especially since the cost of providing the functions are so much less for SFML than for SFML-using applications.

OK, rant done. ;-)

2

General discussions / SFML 2.0 Mac OSX in App Bundle

« on: June 19, 2011, 12:21:11 pm »

It's great news that GetResourceDirectory() will exist

It is already available on the git repository. Get the last version, install the xcode 4 templates and you go!  :wink:

That's great!

But what about a writeable directory? Will you provide GetApplicationSupportDirectory() as well?

This feature won't be present with the xcode 4 templates because it is not related to the application bundle. Anyway, you can get this function from my svn here : http://svn.tuxfamily.org/viewvc.cgi/hblog_svn/cpd/trunk/ (Download GNU tarball), the documentation is available here : http://hiura.tuxfamily.org/online/doc/cpd/ . It's a cross platform thing so you can use the same header on Mac, Unix and Windows. And because it's a header-only-libriary no installation is required.  

Not the way I would do it, and probably not the way it should be done, but from what I can gather ~/Library gets internationalized for display only, the real path stays the same, so it will work at least until OS XI ;-)

What I had done previously was this:

Code: [Select]

const sf::String& FileManagerMacOsX::internalWriteableDirectoryPath() {
  if (writeableDirectoryDefined)
    return writeableDirectory;
 
  NSArray* allPaths = NSSearchPathForDirectoriesInDomains(
    NSApplicationSupportDirectory, NSUserDomainMask, TRUE);
  CFStringRef path = (CFStringRef)[allPaths objectAtIndex:0];
  writeableDirectory = cfstringToSfString(path) + "/Duergar/";
  writeableDirectoryDefined = true;
  return writeableDirectory;
}
But that needs separate compilation again and is no fun to get to work in a C++ project.
As I said, I think we had this discussion already, and I think it would make sense especially when you include a GetResourceDirectory(), but if you don't agree I can't force you ;-)

3

General discussions / SFML 2.0 Mac OSX in App Bundle

« on: June 18, 2011, 10:40:18 pm »

Hey, isn't this the same question/whish I had some time ago? It's great news that GetResourceDirectory() will exist, that means I can scrap my code for that. Getting Obj-C and C++ to interact (and compile in the first place) wasn't fun at all.

But what about a writeable directory? Will you provide GetApplicationSupportDirectory() as well? Or did I miss it in this thread? Anyhow, you can't write to the resource directory, and finding that directory needs Obj-C code as well (due to internationalisation issues), so it would really make sense.

4

General discussions / SFML 2 for OS X comes true!

« on: March 06, 2011, 02:57:44 pm »

Good to know, I had included SFML/Graphics.hpp for that.

5

Feature requests / File System Support, Part II

« on: March 05, 2011, 03:43:25 pm »

Color me amazed.

After decades, Windows is catching up. Well, guess I'll have to learn using it at some point. From the comparisons I found bash looks a bit more concise, but the differences are minor, which is a good thing.

6

Feature requests / File System Support, Part II

« on: March 04, 2011, 11:08:50 pm »

Interesting. Honestly didn't know about that.

But PowerShell doesn't look like the thing that will make my life easier on those machines I use that run Windows. Because it won't be installed. And I wouldn't have the rights to do so.
And I guess it doesn't help the fact that Windows simply wasn't built with a shell in mind. Or does it provide file-based access to settings instead of that abomination that calls itself registry? ;-)

But again, a matter of preference. You are happy with Windows and PS and I am happy with OS X and bash and can feel at home at every Unix and Linux that comes my way, so everything's fine. :-)

7

Feature requests / File System Support, Part II

« on: March 04, 2011, 07:44:23 pm »

Thanks for the link, but I'm already doing that in a similar way. But that is exactly the problem I mean, you need Cocoa, .mm files and so on, and I think this is a small (and limited) field of objectives where SFML should provide a few helper functions to minimize the need for platform specific code (and what application using SFML doesn't need data files?).

Oh, and no, the Bundle is not read-only, but configuration files shouldn't be stored in there so that the user can delete and reinstall applications and their settings are remembered. But I'm not exactly sure about bundles installed to /Applications that are used by non-admin users. They should be read-only again, but again, not sure there.

And I have something better, at least for OS X:

Code: [Select]

std::string cfstringToStdString(const CFStringRef cfstr) {
  CFIndex bufferLength = 1 + CFStringGetMaximumSizeForEncoding(CFStringGetLength(cfstr), kCFStringEncodingUTF8);
  char* buffer = new char[bufferLength];
  CFStringGetCString(cfstr, buffer, bufferLength, kCFStringEncodingUTF8);
  std::string result = buffer;
  delete[] buffer;
  return result;
}  


std::string getDataPath() {
  NSArray* allPaths = NSSearchPathForDirectoriesInDomains(NSApplicationSupportDirectory, NSUserDomainMask, TRUE);
  CFStringRef path = (CFStringRef)[allPaths objectAtIndex:0];
  return cfstringToStdString(path);
}


That should be the official way to do it.

[edit]
Just to be clear, that snipped needs #import <Cocoa/Cocoa.h> and compilation as an Objective-C(++) file.

8

Feature requests / Re: File System Support, Part II

« on: March 04, 2011, 07:23:03 pm »

Sorry if I skipped an important note in one post but I haven't got a lot of time these days...

A writeable directory for written config files, savegames and so on.
This again might be %appdata%/MyProjectName (or in the user's My Files/My Games or what's it called) under Windows, Library/Application Support/MyProjectName for Mac OS X, and ~/.myprojectname for Linux

You might want to have a look at what I've done

I assume you mean the CPD part of the link? Thanks for that, that's at least a way to do it for now. I'm not sure getenv() is the best way to go here though. And it doesn't solve the problem for the readonly directory, but that is mostly a OS X problem as the CWD for a graphically started application is / there for some reason.

9

Feature requests / File System Support, Part II

« on: March 04, 2011, 06:54:34 pm »

In my experience bash has always been preferable to cmd.exe, but I haven't really used the latter in quite some time. Does Windows have something like grep/ack installed by now? Always missed that. Program output is usually less easily machine readable as well (e.g. dir.exe vs ls).

What bothers me more is the missing POSIX compliancy, as there are many really good tools for these. But I guess in the end it comes down to preference as well, and we shouldn't let this thread degenerate into discussions about that.

But I'd be happy to see what I'm missing if you happen to have a good tutorial at hand. I'd try it out the next time I happen to use a Windows system.

10

Feature requests / File System Support, Part II

« on: March 04, 2011, 01:45:11 pm »

Shouldn't you... you know... ask the player where to install?

I personally loathe games that just install themselves in some folder of their own choice. (doubly so since my %AppData% is on an SSD with very limited amount of space - I prefer to have all my games apart from the one I'm currently playing on another physical drive entirely).

I can see the usefulness of the stuff you're suggesting if it only has the purpose of providing a good first guess though. That being said, writing an installer for any given OS is probably better to do outside of SFML though (like InstallShield etc for Windows).

Well, this is really only an issue in windows. In linux (and macosx if I am not mistaken) there are standard directories for everything.

For example a linux game:
executable in /usr/bin (depending on distribution this could also be /usr/games)
data in /usr/share/appname (depending on distribution this could also be /usr/share/games/appname )
and user files /home/username/.appname

You typically don't get to choose where things go. Of course since everything uses the same structure you can distribute your partition mount points smartly.

And show me a single windows game where you can decide separately where data and executable go And properly designed games will use the user directories as well for saving (saving anywhere else is just wrong on a multiuser system...)

FULL ACK.

Windows does get better with time though. Well, they're only a few decades late to the game, right? ;-) Maybe they will someday switch to a Unix base as well, so we have a working useable command prompt on all systems (not serious, but one can dream).

"Real" OS X apps (meaning not CLI) don't separate executable and data though, everything is in one folder. The OS treats this folder as a file though, and you can run it everywhere (even from trash, as far as I know). It is a convention to put these bundles into ~/Applications or /Applications though, and most applications offer to do that for you if you if you run them from somewhere else.

11

Feature requests / File System Support, Part II

« on: March 03, 2011, 08:02:35 pm »

I have nothing against making it configurable, and plan to do so, but that first guess is what I need.

Apart from that, I strongly think that the way modern OSs (OS X, Linux, Win >= Vista) organize files makes a lot of sense for a majority of the users. Meaning that there is a read-only directory for static files and executables (no accidental changes to files by users/users' processes), and a central place for configurations and other written data (easy transition to a new machine). The way it's done in general is the same across all platforms here, though it may be %appdata% and My Documents in two seperate directories or ~/ and ~/Library in one directory.
If you are a more advanced user wanting to do something different, sure, that's fine, but instead of hating the software, why not just create a symlink from the preconfigured place to where you want it to be? I do that all the time.

But as I said in the beginning, I like configurability and want to implement it. And installers should ask you where to install (though I like OS X' way of doing applications even more, but I'm biased here :-)). But I wasn't even talking about the installer, my proposition is completely post-install related.


To think a little further down the road, I could see OSs moving away from directory structures and to applications (think iOS), at least hiding the implementation for the majority of users. That would make it even more necessary to ask the OS where a certain type of file needs to be placed.

12

Feature requests / File System Support, Part II

« on: March 03, 2011, 07:00:59 pm »

OK, physfs doesn't do very much of what I need. The only platform specific directory I can query gives me /Users/myusername, which is far from where I would and should be putting written files.

13

Feature requests / File System Support, Part II

« on: March 03, 2011, 06:43:01 pm »

physfs does some of this (at least for the write directory part)

Thanks, I didn't know about that one. Even has a good license :-)
I'll take a look at it and see what I can get out of it.

14

Feature requests / File System Support, Part II

« on: March 03, 2011, 05:04:19 pm »

Hi,

while playing around with SFML again for some time now, I would like to have another try at making a file system support request (previous one I found isn't from me though).

As far as I can tell, any reasonably sized project needs access to two directories to behave well on the three main OSs (Win, Lin, Mac - sorry BSD guys ;-)):

Some sort of resource directory for files included with the project - sprites, textures, models, you know what I mean.
This would probably be ./ under Windows (i.e. the directory the executable lives in), the Resources folder inside the Mac OS X application bundle, or (I'm not too sure here) somewhere in /usr/local for Linux.

A writeable directory for written config files, savegames and so on.
This again might be %appdata%/MyProjectName (or in the user's My Files/My Games or what's it called) under Windows, Library/Application Support/MyProjectName for Mac OS X, and ~/.myprojectname for Linux

The thing is, the OS usually provides methods of getting these directories in a reliable and future-proof way, but these methods are highly OS specific and a pain to code in cross-platform projects. I did this for myself in OS X for now (found a snippet on the net), but that means using Objective-C++ code in my projects, which in turn meant having to use specific compiler flags and so on and was generally a PITA to get working.

This can not be done via boost::filesystem by the way, b::f should be used for path translation and all that, but it's still pretty platform agnostic when it comes to where data is/should be actually stored.

What I would propose is simply having a class providing static functions like GetResourceDir() and GetWriteableDir() that only return a String containing absolute paths to these directories for the given platform the project was compiled on. The rest (checking if the WriteableDir exists already, if not creating it, ...) should still be up to the user / b::f.

So, comments, what do you think? I don't think this would be too much outside SFML's current scope.

15

General discussions / SFML 2 for OS X comes true!

« on: February 09, 2011, 10:17:34 am »

Hi!

Yeah, the symlinks are broken and not yet fixed for some reason. You need to link sndfile.framework/sndfile to, or replace it with, sndfile.framework/Versions/A/sndfile (paths from my memory, but you should be able to correct them if I'm wrong).

sndfile.framework should point to sndfile.framework/Versions/Current, which in turn should point to sndfile.framework/Versions/A/sndfile, but replacing directly works just as well. Doing this by hand should only be a temporarily necessary solution anyhow.