Saturday, November 17. 2007NicePlayer 0.96.X the Early LeopardThe First ReleaseSo the first released was 0.96.0 in the wee hours of the A.M. of October 26th a last ditch effort to release something that actually worked on Leopard combined with a few bug fixes from 0.95 and some minor features I had started working on prior. Version 0.96 (v543) Something, I just found out is that, my pre-sparkle method of updating actually broke on Leopard so users didn’t get this update notification, however since 0.95 doesn’t work at all on Leopard, I’m sure such users have found the update since then who needed it, so it’s a good thing I’ve switched to sparkle on this release. The Second ReleaseI got to fully test the sparkle update method by releasing, two weeks later, 0.96.1, which contained a few bugs that were introduced in 0.96.0’s haste (whoops), but also I got to try out some fun Leopard stuff. Version 0.96.1 (v573) I added code signing as a build stage, however I haven’t figured out if being signed actually does anything. I thought it was supposed to reduce warning messages when downloading updates, however I tested downloading two copies of the same code signed NicePlayer and they both had the same warning dialog. Oh well. Sparkle updates don’t seem to cause warning messages, but i think that is not dependent on the code signing. I also added new 512px icons, they are fun, the main app icon looks like glass in coverflow.
It’s great. I updated quite a few of the default AppleScripts for the script menu. Since Leopard made setting the default dvd player scriptable, I’ve updated my script that previous did the same with laborious UI scripting (but still falls back for tiger). Also I’ve fixed the fullscreen behavior of the aspect ratio scripts so that by default they rescale to fit the screen after change the ratio. Finally, the most interesting to me of the default scripts changes, is that I added a pair of scripts to set the UI resolution for just NicePlayer. This means that if you want to set the scale of NicePlayers interface to 300% you can, with out using Quartz Debug and without effecting any other applications. The ideal usage of this feature in my mind is if you have a large screen and a wireless mouse and you want to control it from across the room. But I’m sure it helps with 30 inch screens upclose as well, I’m sure there are other uses, it’s always interesting to find out the creative things people use NicePlayer for. Here is a picture at 300%, although it’s on my macbook so screen the size isn’t large enough to contain the menus but you get the idea.
I’m very excited to get resolution independence working on NicePlayer, it’s something I tried to do on Tiger but I wasn’t having success, but with the new Leopard docs I finally figured it out. Although the changes I made work for resolution independence on Tiger, there are some weird glitchy bugs in windowing behavior such that I don’t recommend using it on Tiger. The Third Release?So there appear to be two significant bugs in 0.96 that have been reported. The first is that NicePlayer and Leopard Spaces aren’t friends, I have some ideas of where to look to figure out what is going on, so I’m hopeful, and if i do figure out I’ll just release another small update 0.96.3 rather than waiting for 0.97. The other bug I’d like to fix, but It’s only been reported twice and I can’t reproduce it, is that on Tiger some people have reported that the Volume icon shows up over the video and stays there on open and doesn’t disapear, since I can’t reproduced it, even though I have a Tiger install, it makes it kind of difficult. So if anyone has any clues to reproducing it, send preferences files or whatever, I’d appreciate it. Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
I’ve done a fair amount of work with code signing for F-Script Anywhere (without the user trusting the signed code explicitly, FSA won’t work properly). The key to reducing the number of warnings is to make sure the user trusts your signing certificate. I’m not sure how commercially code signed certificates work in this regard, but this is the way it works with self-generated certificates. The best way to do it is to either provide a link to the certificate that people can download and double click on (presumably more secure), or use openFile: on a certificate (I have it stored in the resources folder of the FSA bundle) — this causes keychain to open up and prompt the user to add the certificate to their keychain. In my case I preceded this action with a dialog box telling the user what was happening and whether they wanted to trust the app’s certificate or something like this. Anyway, once the user has trusted the certificate they should no longer get warning dialog boxes on apps that have been code signed with this certificate. The other thing you get with code signing is that the code signature gets removed if the user changes the package (it maintains some sort of checksum). The user will then have to trust the app itself rather than trusting the certificate, since obviously in this case the app has been modified and could be untrustworthy. |
QuicksearchStatic PagesCalendar
ArchivesSyndicate This BlogShow tagged entries |
|||||||||||||||||||||||||||||||||||||||||||||||||
