doron's blaahg

First, I pulled the source as of 1:00AM PST 17 Sep.

I was able to successfully build Seamonkey using your patch, with the caveat that I had to build with the option:

ac_add_options --disable-tests

Without this option, the build would fail because one of the tests referenced iomanip.h. I forget which one, and I (for some reason unknown even to myself) did not save a log. Anyway, it should be 100% duplicable, so its not a big deal.

I also tried building Firebird with your patch, using the following .mozconfig:

export MOZ_PHOENIX=1
mk_add_options MOZ_PHOENIX=1
# mk_add_options MOZ_CO_DATE="17 Sep 2003 01:00 PST"
ac_add_options --enable-crypto
ac_add_options --disable-tests
ac_add_options --disable-mailnews
ac_add_options --disable-composer
ac_add_options --enable-optimize
ac_add_options --disable-ldap
ac_add_options --enable-extensions=cookie,xml-rpc,xmlextras,p3p,pref,transformiix,universalchardet,typeaheadfind,webservices
ac_add_options --enable-static
ac_add_options --disable-shared
ac_add_options --disable-profilesharing
ac_add_options --disable-installer

While the compile succeeded, when I run MozillaFirebird.exe, it bails on me complaining in the console window (that is present in debug builds) that:

nsDebug::Assertion
ASSERTION: Error occured reading image preferences: 'NS_SUCCEEDED(rv)', file d:/dotnetpatch/mozilla/extensions/cookie/nsImgManager.cpp, line 113

I'd love to see this get checked into the trunk and also have support for building Firebird directly from the trunk fixed. :)

I always disable tests, that is why.

Dunno about firebird, don't use it or care about it. Sounds like a bad build to me.

You Must Promise. To call your mother, to help old ladies cross the road, and to turn your cell phone off at the movies.

Whether native or not, this is obviously one of the first steps on your way to OS X. Keep in mind that often, the functionality of your code has a lot to do with how your interface is designed. How many developers have come up with great functional ideas from working with their interface or looking at their competitors'? Start working on your Aqua compliance from day one. Don't wait until the last minute.

The simple fact is that, when all other factors are equal, where will consumers spend their money? I believe that in the long run, the best looking, easiest-to-use applications will also be the most successful. I think that's why Apple encourages developers to write programs that are 100 percent Aqua-compliant.

You Must Promise. To call your mother, to help old ladies cross the road, and to turn your cell phone off at the movies.

User Assistance. This is helping the user with the proper "next step" when performing a task. Less guesswork for the user on what to do next makes for a better experience.

Other examples of these animations might be to show the status of an FTP transfer, the progress of media being digitized, or an updated time signature. And don't forget that users may want to have some control over this, so give them plenty of options, including the ability to turn these functions off.

Help! Did you include help tags in your applications? (I'd be lost without them.) Also, be sure to take extra time to develop your other help files. The Apple Help Viewer supports HTML, QuickTime, and also AppleScript. Take advantage of it! There isn't anything I hate more than going to the Help menu and finding there isn't any help.

If an application is designed well, the reward for users is that they will learn it faster, accomplish their daily tasks more easily, and have fewer questions for the help desk. As a developer of a well-designed application, your returns on that investment are more upgrade revenue, reduced tech support, better reviews, less documentation, and higher customer satisfaction. The rewards of building a good-looking Aqua application are worth taking the extra time.

You Must Promise. To call your mother, to help old ladies cross the road, and to turn your cell phone off at the movies.

If an application is designed well, the reward for users is that they will learn it faster, accomplish their daily tasks more easily, and have fewer questions for the help desk. As a developer of a well-designed application, your returns on that investment are more upgrade revenue, reduced tech support, better reviews, less documentation, and higher customer satisfaction. The rewards of building a good-looking Aqua application are worth taking the extra time.