Tuesday, December 27. 2005
Can Apple do Better than Objective-C? Posted by Jay
at
00:26
Comments (0) Trackbacks () Defined tags for this entry: obj-c, programming
Can Apple do Better than Objective-C?Can Apple do Better than Objective-C? a language battle royale between C# and Objective-C. I can’t believe after Christmas I get back onto a computer and find out I missed this. I want to jump into the melee but have to go to bed to go to work. But man, this is what I was hoping would have happened at EAA (Rentzsch almost did it). I think a lot of people are in denial about Objective-C having major short comings. Objective-C is a ton better than C++, harder to compare to C# and Java just because of the static vs dynamic typing philosophies, but very clunky compared with Ruby, Python, and Smalltalk. Objective-C is a very good object oriented C and so if you want C there’s nothing better, but if you don’t care about C it can be an exhausting language because you will be falling back to C a lot (but a lot of that maybe more due to lack of libraries). Update: Eh, too many people post garbage, ended up with not very interesting comments. Continue reading "Can Apple do Better than Objective-C?"Friday, December 23. 2005
In Soviet Russia you don't second ... Posted by Jay
at
11:49
Comments (0) Trackbacks () Defined tags for this entry: cocoa, programming
In Soviet Russia you don't second guess Apple, Apple second guesses YOUFrom ridiculous_fish » Blog Archive » Array: “Don’t second guess Apple, because Apple has already second guessed YOU. In a good way, of course.” I find the quote highly amusing, and the content of this post on CFArrays illuminating (and I’m just being cheeky with my post title). Continue reading "In Soviet Russia you don't second guess Apple, Apple second guesses YOU"Friday, December 16. 2005Naming ThingsSo I know a lot of people who use greek or roman mythology names for computers. Back when I got bought my iBook 2001, I named her Cassiopeia, but not after the greek mythology character, but after the character from the original Battlestar Galactica. After that I stuck to naming my computers after Sci-Fi/Fantasy heroines. I re-christen my Beige G3 (upgraded to a G4, among other things) as Seven, short for Seven of Nine (Voyager) I named my Starmax 4000 (604e mac clone), running as a gentoo linux server, Aeryn (Farscape). I needed a powerful character when I bought my Dual 2ghz, I almost named her Xena, but ultimately decided on Buffy (Buffy the Vampire Slayer) I bought a used powerbook that ultimately didn’t last long, which is too bad because I named her Rose (New Doctor Who) I feel like i want to reuse the name, but probably won’t. So if Apple comes out with a non crippled intel laptop in January, I have some ideas for names when I buy one I’m thinking Vala. Anyway my point in sharing all this was most space bodies have been named from Greek or Roman Mythology (aside from a few from shakespeare). However lately (although they are code names) newly discovered objects in space seem to be named using my scheme, such as Xena and now Buffy. I just thought it was amusing. P.S. I also name my extra hard drives/partions after Sci-Fi Villainesses. Currently I have both Lursa and B’Etor (ST:TNG) they are two partitions on the same drive and I have another drive named Graza (Farscape). The next time I need to name one, it’ll be Saffron (FireFly) Continue reading "Naming Things"Sunday, December 11. 2005Drop FireWire Support?Mac Rumors: New Apple Portables To Drop FireWire Support? If this happens, I’m going to scream. I was already to buy a MacTel laptop if they came out in January, but certainly not if it’s missing FireWire, what is this 1999? Anyway hopefully there is no truth to this rumor. Continue reading "Drop FireWire Support?"Monday, November 21. 2005OMGWell, if Napster can’t get market share with porn that will sure be the sign to give up. Continue reading "OMG"Monday, November 21. 2005Frameworks aren't Teh Suck, they're just a red herringCall Me Fishmeal.: Frameworks are Teh Suck, Err.: Creating shared frameworks is a lot of hassle for third-party developers of consumer software, introduces instability into the development process, and encourages slower and larger applications. Code sharing is better accomplished through creating new directories for shared code in subversion and judiciously including only the files and resources needed by any application in its Xcode project. This seems really target towards the common practice by cocoa developers that lump a lot of unrelated classes together. (I’ve done it before too, and this year started re-factoring into smaller more specialized and logically organized frameworks, because a hodgepodge framework does suck) A large lump of unrelated classes is hardly the definition of a framework. Also I should note that this article omits the use of cross project references that gets rid of most of the configuration and versioning issues mentioned. It also omits the use of frameworks for sharing open source that adds the pros of being easier for other developers to use and contribute changes back. Continue reading "Frameworks aren't Teh Suck, they're just a red herring"Saturday, November 19. 2005Crap..Crap..Crap..Crap Xcode 2.2I don’t like ranting on my blog, but it happens anyway, and today it’s because of what Xcode 2.2 did
OMG, do you know how many nested functions I use, a lot more than in that screen cap. It’s not even a warning, I keeps me from doing any other work on my projects until I change each one. Crap! It’s wasn’t in any release note as far as can tell. I’ve finished remove the ones directly in NicePlayer (the resulting code looks so ugly). Now I’m working on the frameworks that use them, even though there isn’t an immediate, as they are still compiled, but I’ll have to do it at some point anyway so I might as well do it now. The reason I use Nested Functions is mainly that they work as closures and make it easy do HOF enumerations in Objective-C (collect, detect, select, reject, inject — aka. map, find, filter, remove, and fold). Now I have to declare functions outside of @implementation and pass everything I use into a context pointer (which gets old pretty quick) and also be wary of my naming conventions. Normal enumeration’s in objective-c suck
So most of those lines are the same every time you do an enumeration. There are simpler ways to make that enumeration suck less then my prefered. Such as a foreach() style syntax loop that reduce the code to setup the enumeration to one line. See Jonathan Rentzsch’s paper Improving Cocoa ObjC Enumeration or Micheal Tsai or Micheal Tsai’s blog entry Cocoa Enumeration. However macro magic only goes so far, because it has to create variables you can’t see, Micheal Tai’s way seems to reduced the chance of collisions to a reasonable amount, and while Jonathan Rentzsch’s way works fine with loops in the same scope, it doesn’t look like it would work nested. Aside from the downside of macro magic, I prefer HOF over foreach as HOF’s are a mini design pattern that give some insight into what a loop is doing helping with readability. There exist smalltalk like block solutions for Objective-C such as F-Script and OSFoundation, however these solutions use blocks as strings, which works, but keeps me from using them for my enumerations. As a side note I use F-Script for debugging often (there’s nothing better than an interactive shell). HOM enumerations seems like a good way to do things, especially when you read Marcel Weiher’s paper Higher Order Messaging all of those enumeration examples look really clean. However, in practice, most of the time I’m doing things that don’t work with HOM enumerations, or to use HOM would require junking up classes with methods that are only used in one instance and don’t have any business being in them. It breaks down in really simple common cases, such as converting an array of file paths in to anything.
I don’t see how to do this with HOM with out either doing it in two passes (this could be many more passes in a more complicated example):
NSArray* anArrayOfImages = [[NSArray arrayWithObject:[NSImage alloc]] collect] initWithFilePath: anArrayOfImagePaths];
[[anArrayOfImages do] autorelease];
or adding a method to NSString or NSImage to produce a image from a string, the first would be awful design wise, the second might be okay in this case, but with a more complicated and specialized construction it would probably also be bad as well. I think I should clarify that I think HOM is really good, and better than what we have now for non enumeration uses mentioned in that paper and could help lessen the ridiculous verbosity of Objective-C syntax a lot. So I’m left with lots of trade off on the enumeration front. Nested functions helped alleviate another objective-c ail, the lack of private methods. If you had to do any recursion or just wanted a convenience method for use in just one method, you could use a nested function rather than a fake private method with some combination of underscores and prefixes, it just did a little bit to keep your hidden interfaces smaller. Not having nested functions anymore is getting me close to switching to bridged languages like python or ruby, but I’m looking hopeful toward Marcel Weiher’s Objective-Smalltalk. I even know what my first project would be when Objective-Smalltalk comes out. Continue reading "Crap..Crap..Crap..Crap Xcode 2.2"Wednesday, November 16. 2005Convergence Killed JFK UpdateSo I was thinking, I’ve been having bad luck on predictions, in reference to an old blog post I made about how Apple won’t start sellomg video downloads. But as I re-read it, I actually left it to whether the next iMac was designed to be mounted on a wall or not, huh, that’s actually kinda eerie (although the screens still aren’t very big). It’s not as eerie as DB’s post Convergence Kills which I was pretty much nay-saying with that post of mine in regards to DB’s of Apple becoming a the benevolent DRM dictator. I think Jonathan Rentzsch made a good point at Evening at Adler that maybe tolerating DRM because of it’s not so bad now, may cause consumers issues in the future with worse less reasonable DRM. I now have a new perspective with over a year later of events, along with my new grudge in regards to my NicePlayer, a freeware, mac only, QuickTime based player that uses Apple’s own APIS for playback, can’t even playback Apple’s DRM video content, I might be joining the grassy knoll camp now. Ultimately, even though Apple is expanding their DRM reach, they may not be able to prevail against the cable & satellite companies, but of course those companies will just have their own DRM. Continue reading "Convergence Killed JFK Update"Thursday, October 20. 2005
NicePlayer 0.93 the Bad Wolf Posted by Jay
at
00:14
Comment (1) Trackbacks () Defined tags for this entry: niceplayer
NicePlayer 0.93 the Bad WolfSo I think, at the suggestion of Robert, I’m going to get in the habit of naming each release of NicePlayer with the Adjective Noun. 0.92 was the Dark Horse which end up pretty accurate, I said so at the time based on versiontracker downloads compared to that of other alternative movie players for mac. Excluding MPlayer and VLC which get a huge amount of downloads, NicePlayer is probably only second to DjoPlayer (MPlayer based) in Download rates on versiontracker. However there has been recent evidence of NicePlayer being a Dark Horse, while NicePlayer is still quite unknown, there was a review on MacMod’s Video Player Roundup comparing QuickTime Player, Windows Media Player, VLC, MPlayer, and NicePlayer, and the conclusion found VLC the best with NicePlayer as runner up. Niceplayer is one of the best. For watching movies, the onscreen controls are near perfect. With a little work on file compatibility, Niceplayer would quickly reign supreme over the other Mac video players. If only file compatibility require just a little work. NicePlayer is mostly and most importantly a user interface, and for file compatibility, we have very basic plugin interface that really lets you plug in any cocoa view as a replacement and you just have and have it respond to a few commands. So I’m hoping for third party action on the file compatibility front. You can find out more on the NicePlayer Plugins page such as how to make one, and what plugins already exist. Why so Bad?So why call 0.93 the Bad Wolf you say? Chose it at random that’s all…it just sounded good…does it matter? But you’ve heard that before? You’ve heard it lots of times? Everywhere you go? Two words following you? Nah, just a coincidence, like hearing a word on the radio and then hearing it all day. Obscure Cult Sci-fi references aside, there are a few Bad Wolfish things NicePlayer does, such as has a somewhat controversially script menu. Apple provides a global script menu but it’s not a great experience for application specific commands, and especially not useful if you want to provide some default scripts to novice users. Some people say you should only use the Apple provided menu, but there also prominent apple apps with their own menu too. NicePlayer has taken a side and it’s CocoaScriptMenu (since I wrote it for this app). The other thing I added in this release somewhat Baddish was an easter egg, something of no value what so ever, but is now a hidden feature. What is you ask? Well since a signature feature of NicePlayer is the ability to have floating movie windows, the new hidden feature is the ability to have movie windows lay below the desktop icons, see I said useless, but fun Other than that I wouldn’t say 0.93 is Baddish, unless of course this is a case when bad means good. This version should be much more stable, it should work better on 10.3.9 than the last one, it smartly handles non-square pixels with DV footage, and can send us crash reports if you install Smart Crash Reports. The Full Run DownWhat’s new in Version 0.93 (v394)
Tuesday, October 18. 2005
Cocoa Script Menu Revised 1.01 Posted by Jay
at
23:37
Comment (1) Trackbacks () Defined tags for this entry: cocoascriptmenu, niceplayer, object oriented design, open source, programming
Cocoa Script Menu Revised 1.01So I started making some default scripts and other script examples for NicePlayer. I then realized that I needed keyboard shortcuts on the CocoaScriptMenu. DVD Player’s script menu just uses numbers in order, I don’t like that, another solution I considered was to have some kind of separate config, either gui or text file. However, since renaming is required to order and change the menu text in CocoaScriptMenu, that could get a little complicated. Keyboard ShortcutsThe solution I settled on was to add the keyboard shortcut itself to the filename. I feel this implementation ended up working really well. The main worry I had was that user error could end up disrupting the host application’s keyboard shortcuts, but the script menu is loaded later than the other menus, so it’s menu shortcuts have the least precedence and thus show up blank if a user tries to duplicate a shortcut. To facilitate adding keyboard combos to file name, I came up with an ASCII representation for the modifiers that kinda look like the real symbols and all require shift to create them (so they won’t reduce the possible representable keyboard short cuts). The symbols are as follows ∗ – Command $ – Shift ^ – Control % – Option To create a short cut you add it between two curly braces in the file name before the file extension, ordering the modifiers before the key character, such as Hello World {∗^$H}.scpt for command-control-shift-H. However after implementing this, I realized most people are going to be using a filesystem that supports unicode, and this can look a lot prettier. So I added support for these shortcuts, not just in the ascii, but using this UTF8: ⌘ – Command (0×2318 PLACE OF INTEREST SIGN) ⇧ – Shift (0×21E7 UPWARDS WHITE ARROW) ⌃ – Control (0×2303 UP ARROWHEAD) ⌥ – Option (0×2325 OPTION KEY) And you can surround them by LEFT & RIGHT SQUARE BRACKET WITH QUILL (0×2045 & 0×2046) instead of curly brackets. Such as Hello World ⁅⌃⇧⌘H⁆.scpt While UTF8 looks a bit neater, for safety sake, all my default NicePlayer scripts will use the ASCII way. And the ASCII way is also easier to type, so I’m guessing it will end up being the preferred way, but it’s left up to the user. You can even add Function Key shortcuts by just typing out {F13} or {⌃⇧F2} or even {∗F16}. and this scheme should cover a great majority of the possible keys, getting all of them however would require more parsing, which I don’t really see the need at this point, but is possible in the future. The down side is that I added a new instance variable to the Command classes, so if you do any subclassing of these classes you’ll need to recompile those subclasses with this framework Versioning and Compatibility (not a big deal as CocoaScriptMenu is meant to be embedded not shared). Count of ScriptsI added a method to the menu generator to count the number of scripts, this can be used to determine whether or not scripts are currently installed.Panther CompatibilityI did a little bit of hacking to give developers basic usage of the framework under 10.3.9, but I haven’t done any testing with other 10.3ness such as compiling under GCC 3 or actually compiling on 10.3. That said with these compatibility additions there’s a little more work needed when adding support for new filetypes or being more specific with filetypes, as I pretty much just fake the UTI stuff when it runs in Panther and thus more faking or a better solution is required, but if you don’t care about 10.3 then you can continue to not worry about it.PSMarsEdit rocks, I wrote this post in it and didn’t have to worry about the UTF8 characters, they were safely converted to html Entities. Continue reading "Cocoa Script Menu Revised 1.01" Monday, October 10. 2005Patenting a staple of OOPUnited States Patent 6,952,706: Method for providing stand-in objects From the summary of the invention: The present invention provides a method for delaying the instantiation of an object in an object-oriented environment. Instead of creating an actual object, a stand-in object is created. When an actual object is instantiated, a description is referenced to locate the data from a data source that is used to populate the actual object. The present invention can be used with any data source including a user interface, a file system, a database, and an object-oriented database, for example. Proxy (A.K.A Surrogate) Pattern from — Erich Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software (Boston: Addison:Wesley 1995) 207: ::blank stare:: .... yeah…. “stand-in” or “placeholder” ... “resolving the relationships defined in an object oriented relational database model without the necessity of retrieving data from the database until it is needed.” or “defer the full cost of its creation and initialization until we actually need to use it.” ::shakes head:: Update: Patent link changed and is updated with one with the actual patent number. Continue reading "Patenting a staple of OOP"Monday, October 10. 2005iEatBrainz, Final VersioniEatBrainz 1.07 is a small update but it’s got a solution to a major problem that has been plaguing iEatBrainz worse and worse with each new version of iTunes. It should be able figure out what songs you are trying to tag in most cases when the iTunes Music Library.xml file is out of date. It’s got some other minor improvements, but those are basically due to shared code between NicePlayer and iEatBrainz. The reason this is the final version, isn’t quite the same as it was going to be. Originally i was working on directly writing aac/mp3 tags to try and get past that bug that this release has a slow work around for, and to perhaps write a newer version based on the framework I was writing to do this, or just release the framework giving other cocoa programers and easy way to write their own take on musicbrainz tagging. However MusicBrainz has an issue of their own, their acoustic fingerprint server is reaching it’s limits. See the MusicBrainz blog General update: What’s up with TRM??. Their acoustic fingerprint server was donated by a company that’s no longer in business, and is proprietary, and about to crap out. Ironically MusicBrainz’s codebase is licensed under the GPL, which is designed to keep something like this from happening, however fingerprinting was all done on a separate server so it didn’t have to follow the GPL. MusicBrainz’s current solution is to go completely to tag based searches, which hopefully will turn out okay. MusicBrainz meta data, while free and open, hasn’t been as rich as those provided by other taggers such as MPFreaker , but the fingerprint really set it apart. Not too long ago MusicBrainz added advanced relations which promises to give it much richer data, I hope this will be enough of a draw to keep people using it. Since what i’ve been working on is pretty much deprecated by this, and my copious free time is not actually copious, I’m going to officially say this is the last version of iEatBrainz I’m releasing. MusicBrainz was originally going to release their next generation tagger for Mac OS X / Windows / Linux which will use the new scheme of tagging anyway, unfortunately it was announced also that this was no longer going to be the case for Mac OS X Bad news: Picard on OS X. The good news is the problem with it seems to be the cross platform GUI widgets, and since you can use a cocoa gui from python, the potential for porting by someone wanting to take it on is good (However, I won’t be that person). Continue reading "iEatBrainz, Final Version"Sunday, September 25. 2005
My Sunday Project - Reusable Cocoa ... Posted by Jay
at
00:25
Comments (8) Trackbacks () Defined tags for this entry: cocoascriptmenu, niceplayer, object oriented design, open source, programming
My Sunday Project - Reusable Cocoa Script MenuThe Sunday ProjectSo last sunday I started on something new, really it’s a feature for NicePlayer, but also a feature in a lot of other existing apps out there, and could be useful in a lot of cocoa programs that don’t have this feature yet, so I wrote my implementation as an embedable framework, and am releasing under the MPL/LGPL/GPL (my latest preferred OSI approved license for those who notice what license I release under). So here’s a riddle, what do iTunes, DVD Player, Xcode, FlySketch, NetNewsWire, MarsEdit and BBEdit all have in common? Give up? They all have one of these (more or less):
Their own script menu. Uses in NicePlayerHaving a script menu in NicePlayer has been something in the back of my mind for a while. There are some features requests, while really simple, are very specific to individual user needs and we can’t justify adding a feature. Sometimes there are features requests that just don’t fit into Robert’s or my idea of NicePlayer, and we barely have enough time to add the features we want to add, so in the next release users can add their own menu commands in this script menu. One of the features introduced in 0.92 of NicePlayer was an option to remove the fixed aspect ratio. Maybe you want to distort the movie, maybe the aspect ratio is just slightly off, this feature works in those cases, and only adds one more menu to the window and is inline with adding basic window options in the Window menu that we did before. However this isn’t useful when someone has a lot of media that is consistently using non-square pixels. In the case of standard media formats, the proper behavior of NicePlayer should be to automatically adjust (this feature has been added for the DV codec when using the CoreVideo plugin in the next version of NicePlayer 0.93). However there are people out there for some reason, how have media that is encoded with non-square pixels for no standard reason, and there isn’t a way to detect the correct aspect ratio. It turns out writing an AppleScript with the current NicePlayer dictionary to set a Window to a different aspect ratio is pretty trivial, so this is one of the scripts we’ll likely include in the next release (since its one the scripts i’ve been using to test anyway). I think the main benefit of having the script menu, will be nicer integration with other apps. Whether having it integrate with a cataloging app, Toast, or just organizing with the finder, there seem to be many potential uses in this respect. CocoaScriptMenu.Framework in Your Own ProgramThe framework is called CocoaScriptMenu.Framework and available on my software page. It’s not my favorite name of the software I’ve written, but I think it’ll help in being google-able for those wanting it’s feature. I’m releasing it as version 1.0, and as I said before under the MPL/LGPL/GPL license. The basic way to use it is to:
And that will give you a typical script menu once you compile and run your app. FeaturesI wrote typical, as not all script menus are the same. I tried to add what I felt were the best features of all the script menus, while being able to behave, depending on how you use it, like 80% of the script menus I’ve seen with out any extra customization. Some of the features are
Extending w/o ModifyingThe singleton [CSMScriptMenu sharedMenuGenerator] has 4 optional delegate methods that allow you to keep the core functionality but make some slightly different script menus without having to modify the source (although modification is certainly an option. (warning most of this is untested as I use only the default implementation of each of these in NicePlayer) -(NSMenuItem*)showScriptFolderMenuItem; -(NSArray*)argumentsForShellScripts; -(id)scriptMenuItemOrItems; -(NSArray*)scriptLocations; Extending by ModifyingSo in version 1.0 the script running implementations are very basic. They are setup as a Class Cluster, with the CSMCommand class providing the public interface and several subclasses that implement script running for various types of scripts or executables. Diagram of class hierarchy: alloc on CSMCommand returns a singleton instance of CSMPlaceholderCommand. CSMPlaceholderCommand’s initWithScriptPath: works as parameterized factory method and depending on the path passed in returns the correct concrete implementation allocated and initialized. So to extend the implementation of script execution for an existing file type, you would just modify one of the subclasses. To add a new filetype you would modify the initWithScriptPath: factory method and add a new subclass. initWithScriptPath: uses Apple’s Uniform Type Identifiers to determine which concrete class to instantiate, so order does matter, make sure you add the more specific type checks in the beginning of the method and the more general towards the end. There are a lot of ways that I can think of that the concrete script execution classes could be improved, however for NicePlayer these all work well, thus I figured for version 1.0 it was better to stick with the basic implementation and release it now, rather than try and over engineer. So I’ll wait and see if people need more or not, not to mention they have the option of contributing code. Updated at Cocoa Script Menu Revised 1.01 Continue reading "My Sunday Project - Reusable Cocoa Script Menu"Saturday, September 3. 2005
Odds and Ends, Summer of Non-Code Posted by Jay
at
01:22
Comments (0) Trackbacks () Defined tags for this entry: ieatbrainz, niceplayer
Odds and Ends, Summer of Non-CodeApple Bug FridaySo I’m was reading many blogs today, and I feel so uncool with all these “Apple Bug Friday” posts. I have an apple bug (or at least I considerate it, don’t know if apple will) that I had written some unit tests to explain the behavior problems. I’ll have to prime for next friday it’s 19 minutes past saturday!The state of the projectsYeah so this was not the summer of code for Jay Tuley, but now that the girlfriend is finishing school in London, I’ll have some time this fall that will need occupying with code. So basically NicePlayer is the project that has gotten the most attention from me, because Robert works on it too, and I use it on a regular basis being that it’s now september we’ve missed another self imposed milestone, whoops. I’ll have some time to work on this for sure this fall. i’ve worked on iEatBrainz very intermittently, fixing little bugs, trying to get the applescript update to be more reliable, I’m going to release it soon, and that will probably be the last update of that code base by me, then I’ll focus on iEatMeta. iEatMeta was going really good in the spring, and then poof I stopped working on it as life got in the way, it’s current status is that I have reading m4a, m4p, and mp3 metadata that iTunes does plus MusicBrainz data, I want to make some design changes in the api, before releasing the source, I’m not sure the best way to implement writing the m4a tags, I have some ideas, but I think reading is quite useful, and it’s better to get the framework out there, just incase for some reason life gets in the way again. SleepI had some other odds and ends but I’m too sleepy, and am starting to forget what I’m writing, I’d rather just post something now than waiting and posting later. Good night! Continue reading "Odds and Ends, Summer of Non-Code"Saturday, July 2. 2005
NicePlayer 0.92 the Dark Horse Posted by Jay
at
01:27
Comments (2) Trackbacks () Defined tags for this entry: niceplayer
NicePlayer 0.92 the Dark HorseSo NicePlayer 0.92 was released this week, and it seems to be downloaded more an more with each release, it’s by no means the most popular video player but it’s got an devoted fan base growing. Tiger QuickTime 7 playback is just really awesome, and the new NicePlayer Core Video plug-in fixed the problem I had with getting dropped frames with 1080 H.264, it’s now very smooth on my Dual 2Ghz G5. While 0.92 works on Panther, it was barely tested (but I did test it), future versions I can’t guarantee will work. A lot of AppleScript bugs in the previous version disappeared in Tiger, and also I’m getting better at making things scriptable, so I think there will be less problems with this release (at least in Tiger). The most notable applescript change was that I added some multi-screen support for the enter full screen command so that you can do:
tell application “NicePlayer”
activate
open choose file
enter full screen on screen 2
end tell
and get the video to fullscreen on an alternate monitor with out having to move the window there first. Actually, since I haven’t setup my second monitor since moving, I only tested this with “on screen 1”, so that was bad of me, don’t let Robert know, and if you have multiple monitors should let me know if this works. Something fun I thought of after releasing NicePlayer (so it wasn’t added to the example scripts) was a script for auto playing DVDs in NicePlayer when you insert a video DVD.
You just tell the System Preferences to run this script ->
on video DVD appeared aDVD
tell application “NicePlayer”
activate
set tPlaylist to make new playlist
add (POSIX path of aDVD) to tPlaylist
enter full screen window of tPlaylist
play tPlaylist
end tell
end video DVD appeared
And Voilà you don’t even need to set the preferences to auto play or auto fullscreen or anything awesome! The playlist support in NicePlayer is a much simpler than what I had planned, just haven’t had enough time. I’ve been wondering if all the stuff I wanted to add would have been excessive. I’m starting to feel more and more like the simple playlist is closer to the right level of sophistication and to go beyond that NicePlayer needs to just integrate with a separate video database program instead. The last thing I’d like to mention, if you want to localize NicePlayer or fix a localization, email us before you try and we’ll send you the file to edit, by doing it this way we can keep translations with each version that don’t change, this technique isn’t very reliable when we are given a nib rather than this file. Anyway that’s all for now, and I’ll post the full new feature list here: Latest release: 0.92 (v320)
|
QuicksearchStatic PagesCalendar
ArchivesSyndicate This BlogShow tagged entries |
|||||||||||||||||||||||||||||||||||||||||||||||||
