|
|
Post by filmor on Jun 27, 2008 20:49:42 GMT
Okay, all Objective-C-Code now resides in main.m. I had to modify some files, but it hopefully still compiles for every other system out there. The patch is here, the folder with the .xcodeproj to be placed in the opentyrian-root here. If whoever made the git-repository could give me write access, I could push the changes there. Current build: CocoaTyrian |
|
|
|
Post by filmor on Jun 28, 2008 20:40:52 GMT
Hmm, I think I've mistaken Carbon for CoreFoundation. The latter is C and provides all Cocoa can do. I'll look into removing even that last bit of ObjC  |
|
|
|
Post by simx on Jul 5, 2008 6:49:27 GMT
So I downloaded the latest version of CocoaTyrian from this thread and it works perfectly. Yay! Thanks, filmor, for taking over where I left off. I'm glad you could modify my code so that all the Objective-C is in one file.
Two notes: first, I'm not sure it's appropriate to include the data files within the application package. As far as I know, the datafiles will never change, so it's kind of useless to make people download the datafiles all over again. Although, then again, it only makes the disk image a few megabytes more in size. If you're not worried about bandwidth, then I guess it doesn't really matter.
Second, and this is nitpicking, but I think it'd be more appropriate for the datafiles to live in ~/Library/Application Support/CocoaTyrian/ , not ~/Library/Application Support/Tyrian/ , because putting them in the Application Support folder is custom to Mac OS X anyway, and given that the app name is CocoaTyrian, people will be looking for that and may not instinctively look for "Tyrian".
|
|
|
|
Post by filmor on Jul 5, 2008 11:47:22 GMT
Hmm, bandwidth is not a problem, it's not exactly my server (university account with no limitations I think ). Application Support is definitely wrong as it is stated by Apple it should be used for files that are not critical for running the application. The possible other solution would be ~/Library/*Tyrian but then every user on the system would have to install the data files there (or to /Library/*Tyrian). I don't think that's practical. Besides it's just not the OS-X-way™ to use installers for simple programs like games. Also the size of the application bundle comes mainly from being a Universal Binary (I hope that it is one, but I couldn't try it as I only have an Intel Mac). And hey, it's 6M, that shouldn't be a problem for anyone I chose Tyrian as the (neutral) directory name because I intended (if you don't object) to rename the OS X port to OpenTyrian as soon as it's accepted into the main opentyrian source-tree. |
|
|
|
Post by yuriks on Jul 5, 2008 13:39:20 GMT
what about Library/OpenTyrian?
|
|
|
|
Post by filmor on Jul 5, 2008 14:44:52 GMT
For savegame/config or data? For the former it should be ~/Library/ Application Support/OpenTyrian. But that can be changed when the sources are in the tree. For the latter IMO it just doesn't fit the system. It's like having an .exe-installer on gentoo. The .app-bundle has to work out-of-the-box/dmg. It would be possible to use an .pkg-installer, but that has no real advantage. /edit: Current build (renamed to OpenTyrian already, if that's okay, I was just too lazy to change it ;P): OpenTyrian.dmgSVN-Revision 774 and config and savegames moved to ~/Library/Application Support/OpenTyrian (just rename the folder "Tyrian" if you've already got one). |
|
|
|
Post by Mindless on Jul 5, 2008 18:02:26 GMT
I chose Tyrian as the (neutral) directory name because I intended (if you don't object) to rename the OS X port to OpenTyrian as soon as it's accepted into the main opentyrian source-tree. if you provide a complete patch (maybe you did earlier and I'm too lazy to notice), I see no reason not to include it now. |
|
|
|
Post by filmor on Jul 5, 2008 18:59:51 GMT
I did It now only modifies 4 files and adds main.m (which I gpl'ed, I guess that's okay with you simx ) www.uni-bonn.de/~bcsauer/tyrian/macosx.patchThe macosx directory to be placed in the source-root is here. The XCode project expects SDL.framework und SDL_net.framework to lie in macosx. I still have to include the mkdmg-script I use but I don't think that's critical. |
|
|
|
Post by simx on Jul 5, 2008 23:46:45 GMT
Application Support is definitely wrong as it is stated by Apple it should be used for files that are not critical for running the application. Err... whoops. I misspoke there. What I meant is that ~/Library/Tyrian/ for the savegame and the config/ini files is wrong. The datafiles should definitely not be going in the Application Support folder. If you change the app name and the folder name both to be OpenTyrian, that's perfectly fine. Also the size of the application bundle comes mainly from being a Universal Binary (I hope that it is one, but I couldn't try it as I only have an Intel Mac) I used to have a PPC Mac, but it got stolen so I can't verify that it actually runs on PPC Macs. But yeah, it *is* a universal binary. Get info on it, and the kind says "Application (Universal)". However, are you sure the size comes from being a universal binary? The executable itself is only 1.2 MiB, whereas the datafiles are 11.2 MiB uncompressed. If you compress the datafiles into a zip file, they're still 4.5 MiB, so I think the bulk of the download is coming from the datafiles. As for the *location* of the datafiles, I think it makes sense for them to live in a folder called "Data" that lives outside of the application bundle. So you'd have a folder called "CocoaTyrian" or "OpenTyrian", and inside you'd have two things: a folder called "Data" which holds all the datafiles, and the Mac application package. Then you can have two disk image downloads: one that includes both the Mac application as well as the data, and one that only includes the Mac application for people who just want the updated code. This would still be a drag-and-drop installation method that is typical for most Mac apps. which I gpl'ed, I guess that's okay with you simx Personally, I'd prefer a more liberal BSD or MIT open-source license rather than GPL, but since the overall project is released under the GPL, it's fine by me. |
|
|
|
Post by filmor on Jul 6, 2008 10:26:59 GMT
Err... whoops. I misspoke there. What I meant is that ~/Library/Tyrian/ for the savegame and the config/ini files is wrong. The datafiles should definitely not be going in the Application Support folder. If you change the app name and the folder name both to be OpenTyrian, that's perfectly fine. Done. I used to have a PPC Mac, but it got stolen so I can't verify that it actually runs on PPC Macs. But yeah, it *is* a universal binary. Get info on it, and the kind says "Application (Universal)". Yep, I just couldn't try it and would like to know However, are you sure the size comes from being a universal binary? The executable itself is only 1.2 MiB, whereas the datafiles are 11.2 MiB uncompressed. If you compress the datafiles into a zip file, they're still 4.5 MiB, so I think the bulk of the download is coming from the datafiles. Sorry, I should've looked that up. I just guessed But as I said, bandwidth is not a problem. As for the *location* of the datafiles, I think it makes sense for them to live in a folder called "Data" that lives outside of the application bundle. So you'd have a folder called "CocoaTyrian" or "OpenTyrian", and inside you'd have two things: a folder called "Data" which holds all the datafiles, and the Mac application package. Then you can have two disk image downloads: one that includes both the Mac application as well as the data, and one that only includes the Mac application for people who just want the updated code. This would still be a drag-and-drop installation method that is typical for most Mac apps. Hmm, we could enable both (first lookup inside the bundle, next in /Library/OpenTyrian then ~/Library/OpenTyrian). Would that be okay with you? I'll try to make the .pkgs for it. You see, I don't want to give up the "inside Resources method" because I really like the self-containment of it BTW, that modification might also be useful for other Unices as they should have the data files in /usr/share/opentyrian or alike (modifiable by Makefile as i.e. Gentoo should use /usr/share/games/opentyrian). /edit: Ah, I see that came up in the "gentoo ebuild" thread. Any progress on it so the same work isn't done twice? |
|
|
|
Post by yuriks on Jul 6, 2008 15:13:08 GMT
I think the best would be to put the binary and the data in different packages. So you would have OpenTyrian.dmg and OpenTyrian Data.dmg and needed to put both in the same place. (Preferably with a non-dmg way to store the data as an alternative, like putting it in a folder.)
|
|
|
|
Post by filmor on Jul 6, 2008 17:42:37 GMT
I don't think the deployment is the most important question here It would be like this: 1. OpenTyrian (Full).dmg - OpenTyrian.mpkg installing: --> OpenTyrian.app without the data files --> OpenTyrian Data.pkg to install the data into either /Library/OpenTyrian (for all users) or ~/Library/OpenTyrian 2. OpenTyrian (Upgrade).dmg - Only OpenTyrian.app without the data files 3. OpenTyrian.dmg - Like it is now You don't have to advertise the last one but I'll still provide it I don't see the point in providing an extra data disk image. What is the status of the "find tyrian data"-code mentioned in the gentoo ebuild thread? |
|
|
|
Post by simx on Jul 7, 2008 2:05:16 GMT
I don't think the deployment is the most important question here It would be like this: 1. OpenTyrian (Full).dmg - OpenTyrian.mpkg installing: --> OpenTyrian.app without the data files --> OpenTyrian Data.pkg to install the data into either /Library/OpenTyrian (for all users) or ~/Library/OpenTyrian This doesn't seem to make sense at all. Why is it necessary to put the datafiles into /Library/OpenTyrian/ or ~/Library/OpenTyrian/ ? What's the advantage of that over just putting the datafiles into a folder right next to the application? Not only does it obscure where the datafiles are, but it makes a drag-and-drop installation more confusing. If you use an installer, it makes people more wary at installing the app because they don't know where things are going. If there's to be a single app+data download, I still think the data should just live in a folder called "Data" right next to the app. That way the user can just copy a single item (the enclosing folder) to anywhere on the hard drive that they wish. They can copy it to a location in their home folder (effectively, a single-user installation), or they can copy it to a location to which everyone has access (effectively, a multi-user installation). The data doesn't need to live in /Library/OpenTyrian/ in order to provide a multi-user installation. If you put the datafiles in /Library/OpenTyrian/ or ~/Library/OpenTyrian/ (which, again, I highly discourage), then choices 2 and 3 would be equivalent. Well, the problem with that is that new users will have to figure out that they have to download *two* things before they can play OpenTyrian for the first time. Furthermore, users won't be able to run the app from the disk image; they'll need to copy it to their hard drive first, then copy the data to the hard drive, and *then* run the app. The way it is right now is ideal, except for the fact that you re-download the data every single time. If we change it to a app+data disk image and a just-the-app disk image, new users will download the app+data disk image and be able to run the app from the disk image. Returning users will download the just-the-app disk image, and they'll know that they need to copy the app to where the data lives in order to run it. (And they won't have a problem with that since they already installed it.) So, again, I think that the data should just live right next to the app folder. (We can also add support for Sparkle, so that updating the app is a much simpler process for the user. This would be Mac OS X-only, though, and it would require a little research because I'm not sure how to add Sparkle support to SDL apps; SDL apps don't seem to have a menubar resource in the nib file.) |
|
|
|
Post by filmor on Jul 7, 2008 6:48:25 GMT
This doesn't seem to make sense at all. Why is it necessary to put the datafiles into /Library/OpenTyrian/ or ~/Library/OpenTyrian/ ? What's the advantage of that over just putting the datafiles into a folder right next to the application? Not only does it obscure where the datafiles are, but it makes a drag-and-drop installation more confusing. If you use an installer, it makes people more wary at installing the app because they don't know where things are going. It's pretty simple, the application bundle should go into /Applications and there shouldn't be a folder called Data inside that directory. That's the reason I moved the data to Resources in the first place. If you put the datafiles in /Library/OpenTyrian/ or ~/Library/OpenTyrian/ (which, again, I highly discourage), then choices 2 and 3 would be equivalent. No. Now the data files are included in the app-bundle (3), choice 2 would rely on having the data somewhere else. |
|
|
|
Post by simx on Jul 7, 2008 7:15:13 GMT
]It's pretty simple, the application bundle should go into /Applications and there shouldn't be a folder called Data inside that directory. That's the reason I moved the data to Resources in the first place. The folder is called "Applications", not "Application Bundles". There is no guideline that says you can't have other visible folders inside an enclosing folder in the applications folder. Many applications (usually games) do this, precisely because the data does not change, but the application code does. There is strong precedence, even on Mac OS X, to have a visible "Data" folder next to the app bundle. I'd argue that the "Application Support" folder is not for essential datafiles. It's for templates (which need to live outside the app bundle because users sometimes want to add additional templates), and for extraneous files that the app creates when it's running that store some information, but can be tossed out at a moment's notice. Essentially, they're ancillary preference files. Datafiles which don't change, ever, shouldn't be housed in "Application Support". What's the point of having the datafiles *both* in /Library/Application Support/ *and* inside the app bundle? That's just a waste of hard drive space. If datafiles are going to live in /Library/Application Support/ , there's just no reason to provide an app that uses datafiles from inside its app bundle. |
|
