cleanup info.plist

[core-code]

from your info.plist

	<key>CFBundleGetInfoString</key>
	<string>Seashore 1.0 - GNU General Public License</string>

1.) the CFBundleGetInfoString key has been deprecated for about 10 years (since 10.6) and should be removed
2.) its contents don't make sense anyway, its not version 1.0 and the GPL is already mentioned in the NSHumanReadableCopyright string

in summary i think this should be removed

[core-code]

futhermore, the LSMinimumSystemVersion key to indicate the required minimum OS version is missing

[robaho]

The codebase contains a lot of deprecated code. I’ve been working on getting the app to be published on the App Store as well, so have been updating the code where necessary. The App Store requires the icons to be done differently so it touches the plist.

Feel free to submit a PR for the changes.

[robaho]

@core-code also, I’m nottraditionally a Mac developer so it would be nice to know similar issues you think that need to be addressed. I’m more concerned about really only things that have been deprecated because things start to break, like the color sync api.

[robaho]

@core-code not sure why the min says version is not picked up from the build settings. In most cases it should be 10.7 but I suspect it is really 10.12 due to api usage in some functions.

[core-code]

hey robert. currently quite busy but i'll try to look into this in the next few days ;)

[robaho]

fixed in 2.1.4

[core-code]

thanks i can confirm the info.plist problems have been fixed in 2.1.4

about the LSMinimumSystemVersion. previously that was a big headache because Xcode wouldn't tell you when you are using APIs that aren't available on the deployment SDK. however, that has been solved a few years back by Xcode 8 (if i remember correctly). however, i tried out compiling seashore, and when i deliberately introduced a 10.13+ API call, i didn't get any additional warnings. which is quite weird, and i wasn't able to pinpoint the cause for this. so, its hard to know if there are 10.12 calls here, without the warning working. there is definitely a lot of cruft and old stuff in there. i'd also recommend not specifying your 'development team' right in the Xcode project as this will lead to compiler errors for anyone who isn't part of your team. you can migrate this to an additional file e.g.

Seashore.xcconfig
which is empty in the git checkout but you can write your team into your copy of the file

DEVELOPMENT_TEAM = YOURIDENTIFIER

[robaho]

@core-code thanks

[robaho]

@core-code don’t I need to select that config file for each build configuration ? Or is the project name one used always? I’m working on getting it deplorable to the App Store and it is much harder to do this after the fact.... but a lot I think is due to the somewhat strange structure originally - not sure I would of used all of the plugin projects but rather some sort of build script so it could be changed in one place - but is seems that is what the build config files are for.

[core-code]

don’t I need to select that config file for each build configuration ?

i can't tell you that because i only ever use projects with a single .xcodeproj file
i suspect though that a single file linked in the main Seashore.xcodeproj is good enough
in any case, unless there are other people interested in contributing and hindered by this issue, it may not be worth putting much time into that at this point

but a lot I think is due to the somewhat strange structure originally

i've also wondered why this needs to be so complex. maybe there are valid reasons, maybe it could be done a lot simpler.

[robaho]

@core-code I've cleaned it up a lot - I think the original design was that people were supposed to be able to create their own plugins - but there was never a "plugin framework" they could link against so the code was duplicated in every plugin - so I fixed that.

anyway, thanks for your help, I am hoping to button this up today