More than Just a Name

Most Popular Solitaire is the most popular solitaire game for Mac OS X.

The Good News over the last few weeks has been that our solitaire title, Most Popular Solitaire, featuring 30 favorite solitaire games, has proven to be the most downloaded solitaire game at Apple Downloads.  Ever since the latest update, Most Popular Solitaire 2.02 has been receiving amazing numbers of downloads, even eclipsing the Windows version of Pretty Good Solitaire.

Most Popular Solitaire appears on the ‘Top Downloads‘ list on the left side of every Apple Downloads page, and has consistently done so since shortly after its release.  Charting as high as #7 and only dropping off for a single day.  (As of this writing, MPS is ranked at #12.)  Note that this is for all downloads from Apple’s site, including such packages as iTunes, Safari, and Mozilla Firefox.  At times, our solitaire game has been ranked higher than QuickTime, and no other solitaire game has appeared on the list.  In fact, we have regularly had the most download game (period).

Now comes the Bad News.  Whether it is due to some oversight in the midst of the iPad excitement, or related to the recent change to remove the ‘Downloads’ link from the main Apple page (in favor of “iPad”), or just a run-of-the-mill screw-up, the ‘Most popular’ pages for each category are not being updated, and this problem has lasted for three weeks now, which means that these pages show the top downloads from just before our game update was released.  It is clear that Most Popular Solitaire should be ranked #1 on the Cards & Puzzle: Most popular page, and probably no lower than #2 on the Games: Most popular page.

Now we still have the problem that traffic is falling off due to the lack of updates, and assuming that the problem will be fixed (hopefully soon), there will probably be a frenzy of product submissions, especially with those already in the pipeline, and our products could become lost in the noise.  Since Apple Downloads is a very important distribution point for Mac OS X titles, this issue is already impacting our marketing.

Despite this inconvenience, development for this platform is continuing apace, and there should be an official announcement about Pretty Good MahJongg Mac Edition in the very near future, as well as one for a related platform, hinted at the end of the most recent post at A Shareware Life.

In any event, I am currently enjoying an absolutely beautiful day, with summer temperatures, bright sunshine, and the stress-free knowledge that all of our business and personal taxes have long since been filed.  Happy Tax Day!

Most Popular Solitaire 2.02

Our entry level product for Mac OS X and Windows is updated.

This week, Goodsol Development released Most Popular Solitaire 2.02, a maintenance release of this popular solitaire title.  The product contains 30 of the most popular solitaire games, including FreeCell, Spider, and Klondike (known to many as simply “Solitaire”), plus 13 more bonus variants (not available in the evaluation version).

Ostensibly, this update contains a few bug fixes and does not change much about the product itself, though internally it takes a sizable step forward.  This version brings the code up to the latest (properly tested) version of the Goodsol Solitaire Engine, so future updates will be easier to build and maintain (on multiple platforms).

Most Popular Solitaire is available for only $16.95 via secure server, and trial versions are also available for Windows and for Mac OS X.

More is yet to come.

A couple of weeks ago, I decided to challenge myself to completing three products in three weeks.  I have been sequestered in my office, for the most part, since then.  As much as I would like to proclaim the two Most Popular Solitaire 2.02 SKUs as two of those, the truth is that they were not even considered, so there are still three products (and SKUs) yet to come, albeit not next week.

My status is that the first priority, a full Mac OS X port, has taken longer than originally anticipated, but it will be announced shortly.  The second project, extending a recent product to operate on a new platform, has been forcibly pushed back for at least 9 more days.  (You figure it out; I cannot talk about it.)  The final product in this group, Pretty Good Solitaire Mac Edition 2.20 (with 100 more games and a few new features), is making good progress but…  there is only so much we can do at once.

Finally, although I have not had any time for Facebook during my challenge, I will tell you that you — yes, you! — can now become a fan of Pretty Good Solitaire.

Pretty Good Solitaire Mac Edition 2.11

An update to our primary Mac product is published.

Goodsol Development released Pretty Good Solitaire Mac Edition 2.11 last week.  This updated version is a maintenance release that adds no features, but fixes a number of issues that were discovered in the previous version, including a couple of obscure crash bugs.  It is definitely a recommended update, and it is free to all previous PGSME customers.

Pretty Good Solitaire Mac Edition features 200 different types of solitaire games using standard playing cards, plus an additional 45 bonus games in the full (purchased) version.  You can download an evaluation version, or just purchase via secure server for only $24.95.  For more information on the product, please visit http://www.goodsol.com/mac.

This is our third or fourth product release in 2010 (depending on how one counts), and the regular release schedule should continue for a while yet.  Upcoming releases will include Pretty Good MahJongg Mac Edition, the first version of our MahJongg solitaire game for Mac OS X, and Pretty Good Solitaire Mac Edition 2.20, which will increase the game count to 300 (plus even more bonus games).  We also have some other titles planned in the near future, so stayed tuned for more announcements (soon).

Disk Images Revisited

There are some issues under Snow Leopard.

In a blog post last year, I gave detailed instructions on Making Mac Disk Images Pretty.  Unfortunately, I have discovered that the most recent version of Mac OS X has some issues of which developers should be aware when using that technique (not that there is any obvious alternative).

I recently upgraded my development system to Mac OS X 10.6 (Snow Leopard).  Apple is fairly aggressive with requirements for its development tools,  and I need to upgrade in order to use the latest iPhone SDK.  Of course, I already had a Snow Leopard partition that I had used for testing, so I knew that our software would work, and I never experienced any previous problems.

When the time came to build an update for one of our products (FreeCell Plus 4.00/4.01), I had a few minor niggles with Xcode 3.2.1 (the latest version), described later, but I got the product built and packaged properly.  Then it was time for testing on our other supported versions of Mac OS X, Tiger (10.4) and Leopard (10.5), and I was surprised to learn that, although the software itself ran flawlessly, the disk images showed no background image when mounted, and the folder size was wrong.  The icons were in the correct locations, relative to the top left corner of the window, so the formatting was not entirely ignored, just effectively ignored.

After some research into the problem, I found the answer in this DropDMG forum thread, where it is stated that Apple has confirmed this as a bug in Snow Leopard.  I moved DropDMG over to my Leopard partition, rebooted to that version of Mac OS X (10.5), and build my packages there.  That solved the problem, and the background images showed in all supported versions of OS X.

Conclusion: In order to have background images appear in disk images on older versions of Mac OS X, you must build the disk image under Leopard or earlier, not Snow Leopard.

Caveats: Sometimes, when opening a prepared disk image under Snow Leopard, there is a blank space on the bottom (probably not coincidentally exactly the same size as the folder toolbar), which does not appear on other versions of Mac OS X.  Also under 10.6, the folder toolbar includes a slider control for quickly changing icon sizes (a.k.a., fouling up your layout).  I have not been able to determine the cause of the former issue (yet) nor the reason for the latter.  (How often does one actually change icon sizes that this is even remotely necessary?)

There were some build issues with Xcode 3.2.1 under Snow Leopard.

As I mentioned, I experienced a couple minor build issues after the upgrade to Xcode 3.2.1, both of which were addressed, albeit with differing degrees of success.

First, the default compiler in the latest version of Xcode is GNU 4.2, which is incompatible with the 10.4 (universal) SDK, and the very first build let me know that.  Faced with a choice, downgrading the compiler to GNU 4.0 versus upgrading to the 10.6 SDK, I chose the latter, which I saw as the path of least resistance (see “Apple is fairly aggressive with requirements for its development tools” above).  Unfortunately, at least for our project, the 10.6 SDK does not function as advertised and, despite properly setting the target OS to 10.4 (and obviously not using any 10.5 or 10.6 features), a product built with the 10.6 SDK will not run under Tiger (period), although it does work under Leopard.  I switched (back) to GNU 4.0 and the 10.4 SDK and all was well.

Second, the latest version of Xcode upgrades its tools (obviously), and one seemingly innocuous change to the linker was to eliminate the need for the “-mlong-branch” compile option for certain object files (generally kernel files, which means primarily for Apple and not so much for the rest of us).  Unfortunately, a warning message was added to that effect, yet Apple did not update its PPC object files accordingly.  As a result, every time one links a universal binary (supporting PPC), the linker throws this warning: “Object file compiled with -mlong-branch which is no longer needed.”  The only permanent solution is to recompile certain (protected) development files oneself, or wait until Apple fixes the problem.

The latter issue is extremely annoying to me, because now I am in the position of either ignoring linker warnings, which I never advise, or spending hours (or days) figuring out how to rebuild a portion of the development tools.  Can you say, “not my job“?  Personally, from my experience of Apple over the last few years, my bet is that this problem will soon be addressed by a campaign to suggest that developers should not continue to be stuck in the past supporting PPC systems.

Does anybody want a piece of that action?

FreeCell Plus 4.00

A new FreeCell solitaire game for Mac and Windows

Today, on the 14th anniversary of version 1.0, Goodsol Development published FreeCell Plus 4.00, a major update to its basic collection of FreeCell-type solitaire games.

FreeCell Plus 4.0 is an entry-level collection of 8 solitaire games, including the original FreeCell (with compatible deals), plus several similar card solitaire games, including favorites such as Sea Towers and Penguin.  The registered version includes 4 more bonus variants, all for only $9.95.  As with all of our products, one can download trial versions from the FreeCell Plus web site (or for Windows or for Mac OS X directly).

This particular update has been interesting because the previous version, FreeCell Plus v3.0, was released way back in 1998, for Windows 3.1!  Aside from being a less expensive product for FreeCell lovers, this title makes two new games available on the Mac side (and in Windows climb mode): Two Cells (standard) and Three Cells (bonus game).

We are just getting ramped up for a very productive year, with two releases already, plus three or four more in the pipeline for the next couple of months.

Goodsol Solitaire 101 Mac Edition 2.00

A new product release for the New Year

Last week, Goodsol Development released Goodsol Solitaire 101 Mac Edition 2.00, as our first new product for 2010.  Now equivalent versions of Goodsol Solitaire 101 are available for both Windows and Mac OS X.

Goodsol Solitaire 101 is a collection of 101 of the most played solitaire games the world over, plus 34 bonus games for customers, and it includes support for climb mode.  You can download the product for Mac OS X here (or for Windows here) and purchase the game now for only $19.95 here.

In the several days since its release, Goodsol Solitaire 101 Mac Edition 2.0 has (as of this writing) taken the #4 position in the Cards & Puzzle category at Apple Downloads, which translates into #9 in the general Games category.  (Most Popular Solitaire 2.01 is still hanging in there at #15 of the 20 games on the first list, too.)

This release is the first of many expected throughout 2010, including some new products, major upgrades, and probably support for a new platform as well.  There are already two more products scheduled for publishing in the next few weeks.  This New Year is starting out to be as strong as last year ended, and I hope only to build on this momentum.

Beatles-style sweep of the top 3 positions, anyone?

Pretty Good Solitaire Mac Edition 2.10

A major update to our best-selling Mac solitaire game is published.

Last week, Pretty Good Solitaire Mac Edition 2.10 was released by Goodsol Development, capping a very successful period of development.

Pretty Good Solitaire Mac Edition 2.10 adds 99 new games since the previous version (2.0), bringing the total to 200 games, nearly double the previous count.  The full (purchased) version includes a few more bonus games, so our Mac users now have access to 245 solitaire games, and this is a free upgrade to all previous PGSME customers.

What makes this particular release special is that, for the first time, Mac users have access to game features that are not (yet) available to Windows users.  In particular, PGSME includes climb mode for all of the 200 (+45) supported games, which gives users of this title access to 99 (+11) climb mode online high score listings that are not yet accessible from any of our products for Windows.  (Goodsol Solitaire 101 supports climb mode for all its games, though.)

Pretty Good Solitaire Mac Edition 2.10 is available for only $24.95 and can be ordered via secure server, and you can get the (optional) CD for only $7.50 more.  A 30% discount is available for registered Pretty Good Solitaire [Windows] users.  Of course, as with all of our game products, a trial version is available for download.

But wait!  There’s more!! PGSME 2.20, with 300 games, has already been announced for release in 2010, and it will be a free upgrade for everybody who purchases the current version.  Buy now!

Most Popular Solitaire 2.01

A maintenance release of our popular Windows and Mac game is released.

Last week, Goodsol Development published Most Popular Solitaire 2.01, an update to this title available for both Windows and Mac OS X.  This update fixes a couple of bugs that were uncovered since the release of MPS version 2.00 back in May.

Most Popular Solitaire is a collection of 30 of the most popular solitaire games, including Klondike (a.k.a., Solitaire), FreeCell (same deals as Windows FreeCell), and Spider (plus the One Suit and Two Suits variants), as well as some more unusual games, such as Crazy Quilt.  There are 13 more bonus game variants for registered users, for whom this is a free (and recommended) update.

If you are looking for a fun collection of solitaire games, but feel overwhelmed when confronted with hundreds of different games, try Most Popular Solitaire.  You can download and try either the Windows 98/Me/XP/Vista/7 version or the Mac OS X 10.4+ version, or you can simply and safely purchase online for only $16.95 (with an optional CD for $7.50).

Note that the Windows and Mac OS X are compatible, such that all initial deals are identical, saved games can be exchanged between platforms, and they both use the same online high score tables.  This allows for result comparisons and discussion of games in the (active) Goodsol discussion forum.

(Yes, we have been very busy on the development side lately, and an even bigger release is scheduled for next week…)

Three Steps to Apple Help, Part 3

Accessing Apple Help from C++ Code (Carbon)

The third/final step in implementing Apple Help is programmatically displaying the main contents or individual topics within your help pages.  This, of course, assumes that you have already created a set of HTML help pages for Apple Help and then indexed and integrated these files into your Xcode project.

Accessing Apple Help from C++ using Carbon is fundamentally simple.  The Apple Help Reference contains only 4 functions (plus one constant enumeration that is no longer used).  There is a little bit of necessary mucking about with bundle references and whatnot that may be unfamiliar to programmers who have not worked with Mac development before, but it is all fairly straightforward.

In order to access Apple Help from the application, you first register your help files using the AHRegisterHelpBook() function.  This only needs to be done once, ideally during program initialization, and we do it something like this:

bool RegisterHelp ( void )
{

    CFBundleRef const bundle = CFBundleGetMainBundle ( );
    if ( !bundle )
        return false;

    CFURLRef const location = CFBundleCopyBundleURL ( bundle );
    if ( !location )
        return false;

    FSRef file;
    if ( !CFURLGetFSRef ( location, &file ) )
    {
        CFRelease ( location );
        return false;
    }

    _Error = AHRegisterHelpBook ( &file );

    CFRelease ( location );

    if ( _Error )
        return false;

    return true;

}

(Additional validity checking and error reporting has been stripped from this sample code for clarity.)

In the above example, most of the code is just to obtain the FSRef (file system reference) of the application bundle from which the help is to be displayed, and it assumes that you want help for the current application.  (Obviously, you could instead pass a reference to any other bundle and access a different help system, but that would be unusual.)

Once the help files are registered, you can display the main help page using the AHGotoPage() function (with default parameters), which we accomplish with a function similar to this:

void ShowHelpContents ( void )
{

    CFBundleRef const bundle = CFBundleGetMainBundle ( );
    if ( !bundle )
        return;

    CFStringRef const key = CFSTR( "CFBundleHelpBookName" );
    CFTypeRef const book =
        CFBundleGetValueForInfoDictionaryKey ( bundle, key );
    if ( !book )
        return;

    CFStringRef const help = (CFStringRef)book;

    _Error = AHGotoPage ( help, NULL, NULL );

}

(Additional validity checking and error reporting has been stripped from this sample code for clarity.)

You can also display a specific help topic by using the AHLookupAnchor() function, for which we use something like this:

void ShowHelpTopic ( CFStringRef topic )
{

    if ( !topic )
        return;

    CFBundleRef const bundle = CFBundleGetMainBundle ( );
    if ( !bundle )
        return;

    CFStringRef const key = CFSTR( "CFBundleHelpBookName" );
    CFTypeRef const book =
        CFBundleGetValueForInfoDictionaryKey ( bundle, key );
    if ( !book )
        return;

    CFStringRef const help = (CFStringRef)book;

    _Error = AHLookupAnchor ( help, topic );

}

(Additional validity checking and error reporting has been stripped from this sample code for clarity.)

In both of these last two examples, the function reads the CFBundleHelpBookName string from the main application bundle and uses that string for the name of the help system, passed as the first parameter to the appropriate Apple Help function.  (You could, of course, hard code this string, but if you were thinking that this is a good idea, shame on you.)

Accessing Apple Help from Objective-C (Cocoa)

If you are using Objective-C and Cocoa, much of the help system handling is done behind the scenes (which is, in part, why some programmers find Objective-C to be objectionable).  If you follow the steps in the previous two posts (Part 1 and Part 2) to insert your Apple Help into a Cocoa project, your main help system will work automatically.

The main help page in a Cocoa application is accessible by the user through the ‘Help->[ApplicationName] Help’ menu option by default.  If you wish to bring up the main page from your Objective-C code, you may need to reference an anchor on that page (see below) or use the Carbon method described above.

To access a specific help topic (anchor) from Objective-C and Cocoa, this is done through the shared NSHelpManager object using the openHelpAnchor:inBook: method.  For example, to open the ‘rules’ topic, you would use the following code:

    NSString *book = [[NSBundle mainBundle]
        objectForInfoDictionaryKey:@"CFBundleHelpBookName"];
    [[NSHelpManager sharedHelpManager]
        openHelpAnchor:@"rules" inBook:book];

The documentation for NSHelpManager is quite clear that all of its functionality is simply a number of wrappers around the functions described in the first section of this post, so you could always use those functions directly, if desired.

There you have it.  At this point, you should know enough to properly implement Apple Help in your Carbon or Cocoa application for Mac OS X.  The process is a little convoluted to suss out from the documentation, so I hope this provides a decent jump start.

Three Steps to Apple Help, Part 2

Adding Help Files to an Xcode Project

The second step in implementing Apple Help is integrating the help files into an Xcode project, so they will be properly added to an application bundle, and generating an Apple Help index file.  This article describes the process continuing from the HTML files generated in the previous blog entry (Part 1).  Be sure to read the comments there, too, where Alexander Halser of Help & Manual describes an alternative (and probably quicker) method of adding the necessary ‘name’ tags.

First, transfer the entire folder containing the HTML help files to your Mac OS X development system (as/if necessary).  [A discussion of how this is done is far below the scope of this article.]  The rest of this article assumes that this folder is named “Help”; rename the folder or adjust the instructions as appropriate.

Next, you will be adding the files to the application bundle.  Open your project in Xcode.  Highlight the ‘Resources’ group, right-click (or Command-click) it, and select ‘Add->Existing Files…’ from the context menu.  Choose the ‘Help’ folder and then click the ‘Add’ button.  In the next dialog box, mark the ‘Copy items into destination group’s folder (if needed)’ check box, select the ‘Create Folder Reference for any added folders’ radio button, and then click the ‘Add’ button.  This will create a folder reference in the project, such that the entire contents of the ‘<Project>/Help’ folder will be added to the bundle as a unit.  In other words, you can add, delete, or change files in that folder from outside Xcode and those changes will be reflected in the build without explicitly adjusting the project file.

If you want to add a localized help file instead (which is not a bad idea, even if translating the help file is not in the immediate plans), the above process is slightly different.  In that case, explicitly copy (or move) the ‘Help’ folder into the appropriate project language folder, such as ‘<Project>/English.lproj’.  Follow the same procedure (‘Add->Existing Files…’), but select the ‘<Project>/English.lproj/Help’ folder, and do not (or, rather, it is unnecessary to) mark the check box, but the radio button is still important.  In this case, you will see that instead of just adding a ‘Help’ subgroup to the ‘Resources’ group, Xcode will automatically add the group as ‘Help/English’ (or whichever language).  Repeat as necessary for additional languages.

Now that the help (HTML) files will be properly copied to your application bundle(s), you need to identify these files as the Apple Help files for the project.  To do this, open the ‘Info.plist’ file for the project, a property list that contains global project settings.  Right-click (or Command-click) and select ‘Add Row’ from the context menu, choosing ‘Help Book directory path’ [or ‘CFBundleHelpBookFolder’].  Edit the value of that row to be “Help”.  Using the same procedure, add a ‘Help Book main page CONTENT attribute’ [or ‘CFBundleHelpBookName’] row, and set its value to the identical string from the “AppleTitle’ meta name (e.g., “Pretty Good Solitaire Help” [sans quotes]).  You can now close Xcode.

Creating an Apple Help Index

In order for a user to be able to search your help file, you must create an Apple Help index file.  The tool you need for this is (the enigmatically named) Help Indexer, which should already be installed on your system in the ‘/Developer/Applications/Utilities’ folder.  (I find it convenient to create an alias to this particular utility in a more accessible location.)

Launch the Help Indexer tool.  On the first execution (and thereafter as necessary), you will want to set the utility preferences (‘Help Indexer->Preferences…’), as they determine the parameters for the Apple Help index (or indices) you will create.  In the ‘Index Style’ panel, clear the ‘Generate Panther-compatible Indices’ checkbox, unless you plan to support Mac OS X 10.3 or earlier.  (At this point, we only support 10.4 [Tiger] and later [Leopard and Snow Leopard].)  I recommend selecting the ‘Errors and warnings’ radio button in the ‘Logging Options’ panel, as including the status messages for large help files simply produces too much noise that could hide any valid warning or error messages.

To actually generate the help index file, once the tool is configured, is quite simple.  Click the ‘Select…’ button, browse to select/highlight the ‘Help’ folder, and click the ‘Open’ button.  Then, click the ‘Create Index’ button, and the process begins.  When finished, review the warning/error messages (if any), and then click ‘Quit’ to close the tool.  (Note that, if you do generate a Panther-compatible index, the messages are shown in a separate tab, and you may get a ‘Warning: [filename].html — Error parsing file.  Check validity of HTML.’ message for each file.  In our experience, we were unable to eliminate these warnings, but the indexing still seemed to work properly on the older systems.)

At this point, you can open Xcode and, if you look into your ‘Help’ group (added above), you will see that a new ‘Help.helpindex’ file has been added (as well as a Panther-compatible ‘Help idx’ file, if selected).  The advantage of adding the folder as a reference group, as noted earlier, is that changes to the folder contents (such as adding the index file) are automatically reflected in the project.  The corresponding disadvantage, however, is that these changes do not necessarily trigger a bundle rebuild, so after making help file changes, you will want to either clean your target (‘Build->Clean’ or Shift-Command-K) or explicitly incorporate the changes by right-clicking (or Control-clicking) on the project group that hold the help files and selecting the ‘Preprocess’ command from the context menu.

Now you have a fully indexed Apple Help system incorporated into your project.  All that remains is to add code to programmatically access the main help content, as well as individual topics, which I will cover in the third installment, so please stay tuned.