|
|
|
|
|
|
Archive for the ‘Development’ Category
Tuesday, January 15th, 2013
 Version 1.3.2 of App Tamer is out, sporting high resolution graphics for all you lucky Retina Display owners. It also lets you scroll the windows of applications that are stopped in the background. This lets you read web pages while Safari is in the background, for example, even if you have App Tamer’s AutoStop feature set to stop it so it doesn’t use extra CPU time.
I’m also excited about an upcoming feature I’m working on for App Tamer 2.0. It lets you set a maximum amount of CPU to give an application – it doesn’t stop the app, but just slows it down if the app starts sucking down too much processing power. I’ve found it very useful in keeping Spotlight from taking over my machine while I’m working, and limiting churn from other applications that inevitably spike the CPU right when I’m trying to get something done. It’s still in need of a lot of integration – the feature works but there isn’t any real UI for it yet (it currently just limits Mail, mds and the Finder to no more than 10% CPU as a proof of concept). It’s very cool to watch it do its thing, though!
Posted in App Tamer, Development | No Comments »
Friday, October 5th, 2012
A new public beta of Default Folder X 4.5 is available, resolving a number of issues that have been occurring when running under Mac OS 10.8.2 “Mountain Lion.” It fixes problems with Default Folder X appearing intermittently or refusing to respond to mouse clicks when you use it. It also properly accesses iCloud items, adds support for additional applications, and resolves a number of bugs.
Complete details and download links are on the Default Folder X Beta Testing page.
Posted in Default Folder X, Development, Mountain Lion | 4 Comments »
Sunday, November 6th, 2011
We’ve put up a quick public beta just to make sure there are no lingering problems with Default Folder X 4.4.7. I finally tracked down the issue that’s been dogging us since Lion’s release – the beta should cure any remaining compatibility problems (namely with Bias Peak and Apple’s Keynote, but there may be others, including GraphicConverter and System Preferences).
Please take the time to download a copy from the Default Folder X Testing page and put it through its paces. Your feedback will really be appreciated.
Thanks!
– Jon
Posted in Default Folder X, Development | 2 Comments »
Wednesday, March 30th, 2011
Thought I’d post about this little developer experience because it was incredibly frustrating and not at all obvious. Maybe this will save someone else the headache that I’ve been through.
Background: When preparing an application for release on the Mac App Store, you code sign your application, then bundle it into an installer pkg which is also code signed (using either Xcode organizer or the productbuild command line tool). When the application is installed, it gets extracted from that .pkg file, the user runs it, and it checks for a Mac App Store receipt. If there’s no receipt, OS X checks to make sure that the application is signed correctly, then contacts the Mac App Store to get your receipt.
Problem: This would all work for me as advertised except that when the receipt check failed, OS X would complain that my application wasn’t code signed, and therefore wouldn’t contact the App Store to get the receipt. From a user’s perspective, the app would just fail to launch.
I’d followed all the instructions. I double- and triple-checked to make sure the application was signed before I built the .pkg file. I tried building the .pkg using both the Xcode organizer and productbuild – they both worked with no problems or error messages. Yet when the application came out of the .pkg file on the other end, it was always unsigned! I deleted all of my certificates, regenerated them, and redownloaded them from Apple’s developer site (several times). I checked every step along the way in my build process – they were all working. It was incredibly frustrating because the signed app went into the ‘black box’ of the .pkg file just fine, but came out on the other end without its code signature.
Solution: After tearing my hear out for a while, googling for answers, and checking the developer forums, I finally tracked down the solution. I had a single image file in my application’s resources that had its permissions set to 640 instead of 644, meaning that it was not readable by everyone. That threw the entire game off – apparently when the installer unpacked the .pkg file, it ran into this problem file and either stopped short of installing the code signature, or invalidated the signature. Either way, the application it installed was useless. Simply changing the permissions on that one tiff file fixed the problem I’d been fighting with for days.
Soooo…. If your app builds and runs fine UNTIL you package it, and then comes out unsigned on the other end, check the permissions on the resources in your application. And Apple, please emit some kind of warning when hapless developers feed productbuild a file with the wrong permissions that’s gonna screw up the whole process.
Tip: There’s a really cool developer utility called Cong, written by Stephane Sudre. It checks your application for all kinds of minor errors, from localization goofs in .strings files to incorrect Info.plist entries to missing files in your package. I’ve contacted Stephane and checking file permissions is now on his To-Do list for Cong. If you’re a developer, get a copy of Cong – a simple drag-and-drop could save you a lot of time and trouble!
Posted in Development, Random Ramblings, Tips | 2 Comments »
Friday, September 10th, 2010
 So I’ve been working on this little application that fixes an annoying problem in OS X.
You may have noticed that the remaining battery life on your MacBook Pro (or whatever laptop you have) often plummets if you leave Safari displaying an ad in the background. That’s because most web browsers, as well as a number of other apps, continue running tasks or animations even when they’re sitting idle in the background. This can be pretty frustrating if you’re actually trying to conserve battery or use that CPU power for something useful.
I wrote App Tamer to fix this. It pauses apps in the background to prevent them from chewing up CPU time (and battery life). I know, I know – you’ve probably seen some utilities that do this already. BUT – here’s the cool part – App Tamer stops and starts applications automatically. You don’t have to distract yourself by manually stopping and starting applications – it just magically works.
Have a look at the App Tamer page for details. It’s in the final stages of beta testing, and you’re welcome to download a copy of the latest beta and try it for yourself. Let us know what you think at AppTamer@stclairsoft.com.
Posted in App Tamer, Development | No Comments »
Friday, November 6th, 2009
So, Apple added this cool little capability to the Launch Services API in Leopard: LSSharedFileListAddObserver will call your observer function whenever there are changes in a number of different file lists maintained by Launch Services. One of those lists is the “Recent Documents” list in the Apple Menu. “Great!” I thought, “I’ll roll this into Default Folder X to ensure that it doesn’t miss any recently used folders.” It’s a simple API – what could go wrong? As a long time developer, I should have known better – if you EVER say this (even if you never even say it out loud), you need to poke yourself with something sharp and realize that the consequences will probably hurt quite a bit more than that. “What could go wrong?” indeed.
So yes, here I am apologizing for not having poked myself after I used LSSharedFileListAddObserver without asking more questions – or at least without testing more. Here’s how Default Folder X ended up using 60% of some users’ CPUs while doing nothing useful:
- DFX added itself as an observer for kLSSharedFileListRecentDocumentItems.
- The observer function got called by Launch Services because the user double-clicked a document in the Finder.
- DFX looked at the list, took the most recent entry in it (the first one), asked Launch Services for the URL of the document, and added the folder enclosing that document to its Recent Folders list.
Pretty simple, right? Yeah, I thought so too. This was tested thoroughly on Snow Leopard and performed fine, and all my Leopard testers reported that it worked well for them too.
So what’s the problem then? Well, there’s this little “issue”… If a user has a Windows server mounted on the Desktop, things get a little more interesting. Normally, when Launch Services calls your observer function, it hands you the file list and you ask for a copy of the list. The list itself is just a series of ID’s and references – to see what’s in an entry, you have to call LSSharedFileListItemResolve(). And that’s where the interesting part happened. On Leopard, if the shared file list item lies on a Windows server, the act of calling LSSharedFileListItemResolve actually results in the item being changed, so your observer function gets called again the next time you hit your event loop. The result of this is that you get called over and over again if you naively use LSSharedFileListItemResolve to get more info about the items that Launch Services is handing you.
So – the warning: If you use LSSharedFileListAddObserver to watch the list of recent documents, keep a copy of the ID’s from the previous call and ONLY call LSSharedFileListItemResolve if there’s a new ID in the array. Otherwise do nothing, or work off cached information – otherwise you’ll end up in an infinite loop, sucking down lots of CPU time. And if you’re doing anything that interacts with the filesystem, make SURE you test with SMB shared volumes too.
Posted in Code, Default Folder X, Development, Leopard | No Comments »
Thursday, November 5th, 2009
Well, there’s definitely a bug in Default Folder X 4.3.2. When running under Leopard and accessing SMB file servers, DFX will start consuming 20-60% of one CPU and will start to lag or become completely unresponsive. This may also affect Snow Leopard and / or other types of file servers besides SMB.
I’ve got a test build available with a fix:
http://www.stclairsoft.com/download/DefaultFolderX-4.3.3b1.dmg
If you’re having any trouble with Default Folder X, please download and install it. It should fix your problems. If you run into any problems, please let me know as soon as possible at DefaultFolder@stclairsoft.com.
Thanks, and I apologize for the bug (I’ll post the gory details in a few minutes, since it’s an interesting little ‘gotcha’ in the Launch Services API).
Posted in Default Folder X, Development, Leopard | 1 Comment »
Monday, July 27th, 2009
There are more compatibility fixes for Snow Leopard in this pre-release build. Specifically:
- Updated the Default Folder X preference pane to run in 64 bit mode.
- Eliminated “auto malloc” errors in applications that use garbage-collected memory management.
You can grab a copy of the installer from:
http://www.stclairsoft.com/download/DefaultFolderX-4.2.2d7.dmg
Again, because of some of the fixes I’ve made since version 4.2.1, anyone running Snow Leopard should be running a pre-release build of Default Folder X 4.2.2.
If you encounter any issues with this build or have suggestions, please don’t hesitate to drop me a line at DefaultFolder (at) stclairsoft.com. Thanks!
Posted in Default Folder X, Development, Snow Leopard | No Comments »
Wednesday, July 22nd, 2009
 I’ve put together a development build of Default Folder X that incorporates a couple of important fixes, plus some handy new tweaks. If you’ve noticed a process called DFPreviewServer slowing down your machine or have experienced problems while running Snow Leopard, this build will fix those problems.
You can download the latest pre-release build of Default Folder X here:
http://www.stclairsoft.com/download/DefaultFolderX-4.2.2d6.dmg
If you are running Default Folder X on a seed build of Snow Leopard you should install this update NOW.
Changes include the following:
- Default Folder X contains a workaround for a bug in OS X’s hierarchical menu system. The old workaround functioned fine in 10.4 and 10.5, but intermittently causes the hierarchical path menu in Open and Save dialogs to hang or crash in Mac OS 10.6 (Snow Leopard). It’s been rewritten and now works correctly.
- Fixed a bug in DFPreviewServer that could consume a lot of CPU time and memory. This occurred when previewing very large files (greater than 200 MB) that the system identifies as text files.
- Added some user defaults so you can globally set a minimum file dialog size and column width. Use these commands in Terminal to set the values:
defaults write com.stclairsoft.DefaultFolderX minimumSize.width 800
defaults write com.stclairsoft.DefaultFolderX minimumSize.height 600
defaults write com.stclairsoft.DefaultFolderX minimumSize.columnWidth 250
Change the numbers at the end of the commands to the sizes you want to use (in pixels).
- Added a way to override the time before menu previews zoom to full size. In Terminal, use this command to change the value (the default value is 1.5 seconds):
defaults write com.stclairsoft.DefaultFolderX menuZoomDelay 1.5
Change the “1.5” in the line above to the number of seconds you want for the delay. Note that you need to turn Default Folder X off and back on again for this change to take effect.
- Default Folder X’s “New Folder” command would not work in some applications when creating a folder within a folder that was reached by double-clicking on an alias. This has been fixed.
- Corrected a problem with the “Make Save dialogs automatically default to the current document’s folder” setting that would cause DFX to default to the top level of your hard disk or your home folder in certain applications (including Address Book).
Posted in Default Folder X, Development, Snow Leopard | No Comments »
Tuesday, June 30th, 2009
Here’s the 4.2.1b2 build of Default Folder X:
http://www.stclairsoft.com/download/DefaultFolderX-4.2.1b2.dmg
The new menu preview feature now has an on / off switch in the preferences window, and due to popular demand the small sized previews have increased to 192 x 192 (instead of 128 x 128). The zoom-when-you-pause feature now works reliably on all systems, and this build works correctly under Mac OS 10.4. Please download it and give it a spin!
Send any bug reports, impressions, and feature requests to defaultfolder@stclairsoft.com. Here’s the full 4.2.1 change history from the ReadMe:
- Default Folder X now gives you file previews in its menus. As you mouse through Default Folder X’s hierarchical menus from the menu bar, you’ll see a preview of the file that’s highlighted in the menu. Hover there for a couple of seconds and the preview will enlarge.
- In Open and Save As dialogs, Default Folder X now puts a “Computer” item at the top of the folder hierarchy in the path menu.
- New Spotlight tags were sometimes not written out to the shared OpenMeta recent tag list. This has been fixed.
- Spotlight tag completion now ignores differences in diacritical marks.
- Added support for Fluid site-specific browsers when they’re running as menu extras.
- Previews now correctly follow aliases so that a preview of the original file is shown when you select an alias in an Open dialog.
- When two folders with the same name are in a menu, the menu items for them will now include the name of the parent folders that uniquely identify those folders (Default Folder X used to just show their immediate parent folders, but sometimes those had the same names too).
- Fixed an AppleScript problem that would cause Preview to print a PDF file over and over again if you selected a the file in the Finder and chose Print from the File menu.
- Changed the rebound feature so that filenames with a ‘:’ character are recognized correctly in Cocoa applications.
- Corrected a problem that would result in Default Folder X not loading in multiple running applications that had the same creator signature (when running both Photoshop CS3 and CS4 at the same time, for instance).
- Default Folder X was saving empty Finder comments, resulting in Spotlight attaching empty com.apple.metadata:kMDItemFinderComment attributes to some files. This has been fixed.
- Fixed compatibility problems with python-based applications that use appscript.
- Added support for 64-bit PowerPC applications to the scripting addition.
- Corrected inconsistent rebound behavior on network server drives.
- Fixed the Extras/DFX script so it doesn’t show a busy cursor when it pops up the Default Folder X menu.
Thanks!
Posted in Default Folder X, Development, Leopard, openmeta | No Comments »
|
|
|
|
|
