#9286 closed patch (outdated)
MACOSX: Add Sparkle support
| Reported by: | CeRiAl | Owned by: | sev- |
|---|---|---|---|
| Priority: | normal | Component: | Port: Mac OS X |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
This patch adds Sparkle support for Mac OS X. Additionally needed is a space where to host the update-rss-feed, and of course the private/public keys to sign the update.
Ticket imported from: #3202319. Ticket imported from: patches/1391.
Attachments (2)
Change History (14)
by , 13 years ago
| Attachment: | ScummVM_Sparkle.patch added |
|---|
comment:1 by , 13 years ago
For reference, Sparkle can be found here: <http://sparkle.andymatuschak.org/>
I have not yet gotten around to actually trying this, but here's a quick question based on a look at the code: Why is SparkleMenu a class? It only contains one method, no members... Shouldn't it just be a namespace, if at all?
Did you test the auto-updating yet (of course, if you did, then using a custom website, and not using scummvm.org) ?
If we add this, we need to do some extra stuff: * Generate a DSA keypair, and decide where to keep the private one (probably Eugene or me would have a copy initially. BTW, this is yet another reason why we should establish a GPG network) * Add "dists/macosx/scummvm_appcast.xml" to the list of files that need to be updated prior to release * Add a reminder to the release HOWTO that the only version of scummvm_appcast.xml needs to be updated. * ... more ... ?
comment:2 by , 13 years ago
| Owner: | set to |
|---|
comment:3 by , 13 years ago
Unfortunately, it seems that this patch was made against ScummVM 1.2.1, not against the current master branch. I updated the patch against master, and also moved the sparkle code from gui/ to base/. I also fixed the configure patch (it wouldn't add "-framework Sparkle" unless "--with-sparkle-prefix" was used).
The code for making a bundle looks slightly fishy, as it assumes that Sparkle.framework is contained in $STATICLIBPATH, which it won't be in general. Maybe in $STATICLIBPATH/Framework, but even that is a stretch. The real problem here, of course, is that the current way we use to locate static stuff is, uhm, rahter hacky and limited. So a proper solution is beyond the purpose of the patch at hand; nevertheless, we should address this.
I also renamed scummvm_appcast.xml to scummvm_osx_appcast.xml, just in case something like WinSparkle becomes viable in the future...
comment:4 by , 13 years ago
Another caveat: The menu item title in sparkle_osx.mm still needs to be made localizable.
comment:5 by , 13 years ago
About $STATICLIBPATH and the Sparkle.framework: As there no "official" place for this library (according to the docs, Sparkle shouldn't be put into /Library or ~/Library or /Development/Library, but it should only be packaged with the final bundle) I just copied the Framework to the $STATICLIBPATH in my case as I didn't want to add just another PATH variable to the makefile.
About: "Why is SparkleMenu a class?": There's really no special reason for that, when starting to add Sparkle it wasn't completely clear for my that no other method would be needed, so I added it as a class. Shouldn't be a problem to change that, afaik.
Regarding "Did you test the auto-updating yet (of course, if you did, then using a custom website, and not using scummvm.org) ?": Yep, of course I did this. And it worked nicely :)
"The menu item title in sparkle_osx.mm still needs to be made localizable": Yes, you're completely right, I forgot about the localization.
comment:6 by , 13 years ago
Again a small comment about the missing localization: The whole Mac OSX ScummVM menu isn't localized (yet?), because of the following, it seems: The application menu is generated within SDL, not within ScummVM and is thus not localizable as it is. There would be 2 options to address this: Programmatically replace all the application menu item (it's very easy and possible, I've already done this), but this would be rather hacky and not the real OSX way to deal with that. The other (correct) way would be: supply a .nib file for the menu, and handle the whole application-menu stuff within ScummVM (and not letting SDL do this). What do think? What's your (or the MACOSX' maintainers) preference?
comment:7 by , 13 years ago
So far I avoided using a .nib in order for ScummVM to be easily testable from command line, in non-bundled form (i.e. I don't want to have to do "make bundle" while developing). However, with some effort it should be possible to setup things so that the bundle version uses a custom .nib, while the non-bundled version uses the current way (i.e., relies on SDL setting up the menu an all that). (In fact, this is the reason I wrote all that "works witout a .nib" code in SDL in the first place ;).
comment:8 by , 13 years ago
(In other words: If you want to implement such a solution for the .nib, you are welcome to :) I'll be happy to give advice / review code, if desired).
comment:9 by , 13 years ago
Working on adding support for WinSparkle on windows (I have a test version working, but it needs cleaning).
WinSparkle currently has less features than the MacOSX version (and some of the missing ones are blockers like signature support), but we can hopefully share the appcasts feeds and changelogs.
comment:10 by , 13 years ago
MacOSX sparkle support merged with 9044e17499797ef007c9c8240d79f69382f61765
comment:11 by , 13 years ago
| Owner: | changed from to |
|---|---|
| Resolution: | → outdated |
| Status: | new → closed |
comment:12 by , 5 years ago
| Component: | → Port: Mac OS X |
|---|
MACOSX: Add Sparkle support