First one in the updates line is Dock Detox, our free haxie that gets rid of bouncing icon application notifications from the Dock. Some people find it annoying (not to mention it eats plenty of CPU for single processor Macs), yet Apple didn't provided a way to turn it off - so here's the haxie that will do it. Nothing more, nothing less. More customizations are planned for next version (like exclude/include list, etc). [ download ]

Ever noticed how life is -- sometimes it feels so darn fast, you can feel it whizzing by. Sometimes it feels too slow, you see the seconds crawling away s...l...o...w...l...y... Weirdly enough, for me, now is neither. Life goes at its usual tempo, and I got sucked into a bunch of needed, but sort-of boring work activities -- making updates to 4 haxies at once and planning on fifth. This eats a lot of time, hence the absence of blog posts (although I should slack off less on that!) and status updates.

The most important thing - the work goes on. The life does too.

Mmm, I stumbled upon this site that sells various hacker-related stickers (including "Mac Pirate", heh) - makes me want some sort of a 'haxies' sticker - not sure what for, but it'd be nice. We've been talking about making various Unsanity merchandise (not that anyone would want it ;), but that is still under slow discussion here at the Unsanity camp. And yeah, CafePress service is nice, but the quality is no good, in my opinion.

So while we decide on Unsanity stuff, I'm getting myself this one:

Here I go again, ranting about Mac OS X bowels. This time I want to talk about particular implementation details of Mach-O runtime ABI (Application Binary Interface). Before you get too confused, there are two different things under the 'Mach-O' name:

• Mach-O ABI, which defines how every application in the system executes and calls functions (stack conventions, register usage, and more);
  
• Mach-O File Format, which defines a way for compiled executables to store different parts of them in the same file (compiled code, data, strings, etc).
  

The latter is not what I want to talk about today; the first is what puzzles me most. I admit I am just a "small programmer" with no relationship with the powers-that-be at Apple at all (this means, no insider contacts who can explain the reasoning behind the particular important design decisions to me), so my impressions, judgements and guesses expressed in this article may be slightly or totally off the mark. I, however, as many other developers who have dug deep into the implementation of such things, can see obvious drawbacks and oddities about Mach-O ABI, and this is what I am going to talk about.

Mach-O originates from NeXTstep, an operating system created at NeXT for its NeXTstation machines, and later expanded to x86 hardware with OpenStep. NeXTstations were originally based on Motorola 68k CPUs, just like old Macintoshes.Mac OS (classic), on the other hand, used an ABI for PowerPC which followed the ABI principles defined in a document by IBM/Moto for PPC processors. So as you all may already know, m68k and x86 are CISC architectures; PowerPC used in all new Macs is RISC.

To make a long story short, Mac OS X uses an ABI designed for CISC processors, mostly ignoring RISC design principles.

What do I mean by that? Mach-O ABI we see now used in Mac OS X is more or less a direct port of NeXT's Mach-O designed for m68k - it relies on PC (program counter) register to perform various manipulations with data (for the geeks: PC-relative addressing). There's nothing wrong with that, as its an effective and common practice, except for one little thing: there is no PC register in RISC processors (programmatically accessible). That is not a show-stopper though - Mach-O for PowerPC just takes one of 32 general purpose registers and turns it into a program counter-style register, to base all offset calculations off it. That works well, as you can see, as all of Mac OS X applications (except for the ones compiled with Carbon/CFM) use the Mach-O ABI.

That approach works well, except for one small thing: global/static data access adds about 7 cycle overhead per function, and about triple of that for cross-context calls (that is for the G4 class processor) compared to the old, Mac OS Classic ABI (excuse me for the geek talk). Mac OS Classic CFM ABI, in comparison, needed almost 0 cycles for static data access and about 5 for cross-context calls. To rephrase - applications in Mac OS X could be faster, if the Mach-O ABI followed the principles set for the PowerPC chip, and not the ones created over a decade ago for CISC ones.

This brings us the question, "how much faster would the applications be if the ABI was done right?". The answer is, according to some tests done by my friends on a Macintosh Development IRC channel, the speed gain would be 10-30%, depending on each particular application (how often does it calls functions). Realistically, the speed gain would be around 10 to 12 per cent (how do I get these numbers, below).

So why did Apple used an outdated ABI for a modern operating system? Frankly, I don't know the reason. About the best one I have heard - it saved Apple a few months in the Mac OS X development time so they didn't have to do massive updates to its NeXT-derived tool chain.

There are signs of change though -- the recent update to GCC, the compiler shipped with OSX, allows it to perform so-called -mdynamic-no-pic optimization, which hard-codes the data addresses in the code, so the result is roughly equivalent to the CFM ABI used in Mac OS Classic -- so the GCC itself, compiled with that optimization, is 10% faster. Applications, to take advantage of that, need to be recompiled, so it doesn't affect 80% of the titles already shipped for Mac OS X. Then again, the optimization above only works for executables and not shared libraries.

Either way, there is no way to change the ABI now, as it would break all of the existing applications - which is obviously not what Apple (or us) would want.

And after all, who cares about a 10% speed loss? You can always get a faster Mac, right?

Further reading:
Mach-O Runtime Architecture [developer.apple.com]
CFM-Based Runtime Architecture [developer.apple.com]

Update 10/21: Warning, even more technical stuff follows!

Somebody on /. pointed out you can easily add a new ABI to the system. While this is true, but if you do it, you run into three problems:

• All current import/exports must go through some kind of mixed mode/thunking glue to map between the ABIs
  
• You need separate copies of all libraries to link them directly with the ABI native format
  
• For some plugins, you can't determine what ABI they are compiled with or are expecting to use
  

The downside is that (1) adds back a lot of the CPU hit that you was trying to get rid of, whereas (2) trades the CPU hit for a lot of extra memory and complexity (ie, having two copies of the code) - and Mac OS X uses already so much memory it is already a problem.

I've also been told OPENstep runs on RISC processors (non-PowerPC) - however, I have not investigated how the Mach-O ABI works there - quite possible it obeys the PowerPC guidelines, although I am pretty sure it does the same as on PowerPC.

Mac OS X was originally not moved to the PPC ABI because the NeXT Toolchain used the Mach-O ABI and it would have delayed the release of OS X a few months. Now Apple is spending a few months to speed up OS X in ways that may not have been necessary if they had gone with the PPC ABI in the first place.

Thanks to the Macintosh Development oriented channel regulars and an anonymous Apple engineer for helping me with this article.

LOL. Look at the top hit for Google search for "stoned chicks":

http://www.google.com/search?q=stoned+chicks

Obligatory credit: kinch mentioned that link to me.

I get asked or see people ask how to either get front application switched events in Cocoa or how to get global hot keys in Cocoa applications. It takes some extra work, but it is possible. I'll show you how.

Hot Keys in Cocoa

This is easy. Subclass NSApplication with your own version. Set the Principal class in the target settings window to your class then use the following code in your subclass.


enum {
// NSEvent subtypes for hotkey events (undocumented).
kEventHotKeyPressedSubtype = 6,
kEventHotKeyReleasedSubtype = 9,
};

Yeah, that helps, right? [theEvent data1] is the registered hot key's identifier. You register hot keys using the normal Carbon code.


err=RegisterEventHotKey(keyCode,inMods,hotKeyID, GetApplicationEventTarget(), 0, hotKeyRef);
//hotKeyRef is the ID returned by [theEvent data1]


There's very little to it. You just need some way to find out what is supposed to happen when the hotkey is pressed. I use a dictionary to store the hotKeyRef in of each hot key I registered. I then add the key command pressed to the dictionary and execute that key command to my app's menu when the hotkey is pressed.

It really is that simple. Always check for errors.

Application switched events for Cocoa.

Painfully easy once you know what to do. In your application's delegate, register for the distributed notification com.apple.HIToolbox.menuBarShownNotification in -awakeFromNib. This is notification is sent whenever the front application changes. I also register for app launched and app died events "just in case" the menu bar notification fails. You also need to prepare your code in case it receives two notifications in succession. It will when launching or quitting applications.


// The below registrations are made to check if the front application has changed
[[[NSWorkspace sharedWorkspace] notificationCenter] addObserver:self selector:@selector(checkFrontApp:) name:NSWorkspaceDidLaunchApplicationNotification object:nil];
[[[NSWorkspace sharedWorkspace] notificationCenter] addObserver:self selector:@selector(checkFrontApp:) name:NSWorkspaceDidTerminateApplicationNotification object:nil];
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(checkFrontApp:) name:NSApplicationDidBecomeActiveNotification object:NSApp];
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(checkFrontApp:) name:NSApplicationDidResignActiveNotification object:NSApp];
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(checkFrontApp:) name:NSApplicationDidHideNotification object:NSApp];
[[NSDistributedNotificationCenter defaultCenter] addObserver:self selector:@selector(checkFrontApp:) name:@"com.apple.HIToolbox.menuBarShownNotification" object:nil];


checkFrontApp: is the selector that gets called when the front application changes. That is, the method called when one of the notifications is received.

Make sense? Any questions? Special thanks to Evan Gross and NoisyApp.

Update 10/16/02: Apple has reduced the price of the lowest end flat-panel iMac to $1199. It is now cheaper than the lowest end Profile 4 equipped with the same HD size, modem, and a CD-RW.

Well, this is my first entry to this blog and I am wondering how to start. I like rants, so I might as well start with one of those short ones.

A lot of schools and the like are making a switch to Windows from the Mac citing silly things like "That's what the business world uses," or "The rest of the world uses Windows, we should too so our students aren't at a disadvantage." What total poppycock.

Let's say some parent has a kid that is graduating from high school soon. This kid is a very good cook and loves cooking. She wants to go to a college that specializes in the culinary arts. Her parents deny her that privilege. Why does she need to go to school and then get a job at a restaurant (or even start her own) when she can just as easily get a job at Taco Bell or McDonalds since that are so many more fast food joints around than there are fine (unfranchised) dining establishments. Do you think the kid will actually accept that?

Others, especially those advising educators, cite cost as a deciding factor. These people have obviously done no research into the educational discounts available to schools. Apple's educational discounts are very competitive and range from 6% (for personal purchases) to 10%-20% for site purchases. This alone can take a massive chunk out of the price, making Macs much cheaper for schools (even when compared to PC makers' 5% discount).

That's another thing that makes me mad. Those lame Gateway Commercials that advertise their profile PC is faster, cheaper, has more storage capacity and can run thousands more applications. The faster thing I will not comment on except to say you can't fairly compare chips of different architectures and Intel is being sued for lying about the performance of the Pentium 4. The price issue is a real beef with me. The profile 4 (at it's cheapest $999 model) comes with a 20gig HD, a CD-ROM Drive, and no modem. At $1299, the base iMac comes with a 40gig HD, a CD-RW drive, and a modem. Adding these items to the Profile 4 brings the price to $1,159.00 (as low as $32.20/mo for 48 months). Gateway also charges for shipping, whereas Apple does not. The total price for the Gateway system is $1219.00. The price for the iMac is $1299.00 ($35/mo for 48 months and $29/mo for 60 months).

If you are going to go with financing, the minimum interest is 14.9% APR for qualified customers. Maximum APR is 27.99% on the Gateway system. Apple has something called the Apple instant loan. The minimum APR for the loan is %9.99 and the maximum is %26.99. If you are taking out a loan for the Gateway, you better purchase a butt plug as well just for the interest.

My only real problem with the more storage issue is that the Profile 4 only has more storage at the $1999 model (120gig vs 80gig) but it should also be noted that, at this price, the iMac comes with a DVD-RW drive. This drive can write 4.7gig DVD-Rs (at $5 a piece in 10 packs) and DVD-RWs. At any price, the Profile 4 doesn't include a DVD-RW drive.

Yeah, Windows may have many, many more applications available, but historically the Macintosh community doesn't tolerate poop software. They always navigate towards the best and stick with their decision on software like with MS Office and BBEdit (Pepper was just axed). You'll often find that the largest part of Windows applications are, sadly, very poorly written and/or implemented and are not ready for prime time. Do you really need 60 text editors that do only half as much (when combined) as BBEdit?

I personally think schools are putting their students to a significant disadvantage by choosing PCs over Macs. I have seen users of both and Mac users deal much better is a lot of situations. They learn to explore and find out stuff about the computer. They aren't afraid (or weren't until OS X) that some little file rename or move may disable the computer or some application they depend on. They were not scared to check out "what this does" or "why that exists". Windows users, however, are scared to death of their computers in most cases (or they use the brute force method in fixing problems). They work for their computers, not the other way around. Mac users gain confidence from using their computers, that is probably why so many mac users are so quick to defend the Mac OS or Apple when lame journalists are so eager to insult either one based on information from 1986 that may or may not have been true. Anyways, when computer users are brought up around Macs, they have absolutely no problem using Windows or the Mac OS. Mac users also seem much more adept at fixing problems on Windows than Windows are at fixing Mac problems. In fact, I have seen many a Windows user disable a Mac completely because they used Windows methods and called themselves computer literate. Anyways, by using just PCs, students won't know what to do with a Mac when they see it. The students will insult it, call it a MAC, and then dismiss it's existence. Not to mention Mac users make more money per capita and are better educated.

Not that any of this matters. The students will most likely use in business whatever they use in school. If it's a mac, they'll use a Mac in business if they have a choice. But it's still a chicken and the egg problem. Chances are whatever they learn in middle school and below won't even be valid when they actually get into the business world. That is, of course, if they don't get into the fast food industry.

It's been getting on my nerves lately how much any particular news item gets repeated all over the 'Net. I realize this is what the Internet is about, but it's kinda annoying, from my perspective, to read about the same thing over and over again during your morning blog-reading.

Take the recent Microsoft fluff, or Elvis journaling - at least half of the blogs I read (yes, I am a technology nut ;) already mentioned it, and I suppose the other half will pick it up within next few days, as well.

I wish there was some universal 'newsbit' ID valid for the whole internet - if somebody posts something new, he receives a new ID for that story; if somebody comments or reproduces that story, he will use the same ID. This way, with special software (hello, Ranchero!), I can skip the repeats and rants about a particular newsbit I don't care about, or got tired reading all over.

But of course, this is just a dream. It would be nearly impossible to make the whole blog community use some unique ID numbers, and even harder to make people obey the rule of admitting you were not the one who picked up some newsbit (and thus making a new ID).

Then again, I haven't gave this much of a thought. I probably will next time I have less work to do... ;)

Hello,

Like I said earlier, I'll post when Gethsemane will be done, and it is =) (To those of you who missed my previous post, Gethsemane is a song that was used in Mint Audio as an intro track. This version was made using professional audio software with quality samples. Lots of stuff has been added - like new melodies and better transitions and stuff.)

http://www.sitosis.com/~silverdemon/Gethsemane.mp3

E-mail me what you think of it and if you want to hear some of my other tracks.

Comments, suggestions, criticism are always welcome.

Thank you =)

This was written mainly as a response to an email I received on the Omni Group's MacOS X-Talk mailing list. The email said:

If the implementation [of haxies] is poor or unsupported, there's a good chance the software is eventually going to cause problems. This is particularly unfair to Apple and third party developers who have to field technical support and do PR repair for issues they didn't create.

My Response:

When you or anyone has a problem with a haxie, tell me and it'll get fixed. As far as I am concerned, posts like this are just FUD from people that haven't even bothered to use them and for some silly reason think they are implemented the same as extensions, which is impossible in OS X. Haxies do no more trickery than InputManagers, Contextual Menu Items (look at Ittec), Internet Plugins, or QuickTime plugins do.

So unless you are having a problem with a haxie, don't theorize on what bad things they can do. Don't tell me about a friend or some other third party that had a problem and blamed it on a haxie but failed to tell you that he just copied his entire hard drive's contents to another via the finder and tried to boot off the new copy and was surprised it failed or that he decided to install Mac OS X DR4 over Mac OS X 10.2.1, ten minutes after he installed FruitMenu.

If a haxie is causing a problem, it is extremely easy to find out if they are actually the cause of the problem. For one, just remove the ApplicationEnhancer.framework then log out and back into OS X. For another, the crash log will mention something about the haxie in the crash log for the thread that crashed. That's why we designed this new system to have one point of manual failure. Remove that framework and haxies cease to load.

However, there is another side, a good side, to the story. Haxies are actually able to fix bugs in other people's software. Toast 5.1.4 had a problem where it double released memory when it scanning for devices. It would crash in odd cases (usually when other memory was allocated). WSX 2.1.1 actually fixes this bug in Toast by preventing the double release by calling CFRetain on the CFTypeRef that was double released.

Finally, we do not usually talk about the methods used to implement haxies for one simple reason. In the past the parts that make people feel uneasy had been posted to public forums and websites while completely leaving out the massive amounts of checking and verification we do to make sure the bad parts of extensions from Mac OS 9 never occur with haxies.

Ok, the birthday is over, so it's time to get back to work. I've been thinking over the way Labels X work during last few days of my 'vacation'. Along with needed changes for better distinguishing of IconRefs, so mis-coloring in toolbars and search results don't occur, the new code foundation makes it possible to add more searching criterias to files - an additional labels column, or perhaps a tiny icon overlays along with an appropriate Finder column. The big question is whether this is needed or not (heck, why not add "rating" column/criteria to the Finder, a-la iTunes? ;) - I have a slight feeling this may go beyond the original purpose of an utility - ie, many users may not be happy with such a simple utility adding additional weight. On the other hand, probably many will appreciate additional search criteria for files.

This leads me to a thought, maybe it's a good idea to split Labels X into Labels X and Labels X, um, Pro, that would cost a little more but also do more... I don't know. What do you think?

Happy Birthday Slava!!!! :)

A popular topic among developers and users alike is the price and value of various software. It's something that has been on my mind lately and many occasions in the past. So I'm going to try to clear up the jumble of thoughts in my head by spilling it out here.

Open Source - what a great thing!? I love open source stuff, it drives such a big part of the developer community. It amazes me. But I truly don't fully understand it. How can people find the time and energy to come up with such amazing software? Those people that are the true creators in the open source software movement are actually few and far between imho. The rest of us are contributors in various ways: 1) We contribute small bits of code. 2) We talk up the gospel of "open source" to our friends to seem like we are hip with it. 3) We shamelessly use it and really have no clue about how much time and effort has gone into creating it. (which is fine too, as that is the purpose of creating something...to have it be used by someone) Or we are Microsoft. ;)

Then we move up a notch on the software ladder to "freeware". I suppose the only distinction in my mind is that freeware is not necessarily open source.

The thing about both open source products and freeware that sometimes amazes me is the tremendous costs that the developers can incur (both in time and money) in creating and distributing it. I am sure my jaw would drop at the numbers of some of the big projects out there such as PHP. It is not cheap to host a site with the kind of bandwidth they must use. Here at Unsanity, we actually offer more "freeware" products than any other. Why? They cost us a significant amount of money...espescially when they are popular. I suppose we are a microcosm of the open source thing in some small way. We create something that we feel is useful, and decide that others could benefit from it also, but don't feel right charging for it. (though I'm not actually trying to compare our meager "contribution" to the mac community to the big boys of open source)

Climbing up one more rung on the software ladder...shareware. That's our bread and butter (literally). Our first product, Unsanity Echo (RIP), was released as shareware. The idea is great, you create a product, distribute it, and if someone likes it, they pay for it. Of course there are the little additions such as timeouts, crippleware, demos, etc. (all of which we've played with in some form or another) We started Unsanity LLC with several purposes I suppose. But first and foremost was and is the desire to make a living doing what we love. Creating cool software for the Macintosh. (really the basic idea behind any ideal job right?) Which brings me to the next thought, product pricing. If I may assume a bit here and possibly go out on a limb, I believe we provide some of the best bang-for-the-buck (or seven) software out there. I don't think we've received many of the "your software is overpriced" complaints that come with this territory at times.

Which brings me up to the top of the software ladder...commercial software. What makes it "commercial" ? Price? Boxed? On-a-CD? Popularity? Along with those questions, is our progression as a company. In case anyone doesn't know, existing in the shareware business is not easy. Take a look at how many products you've used in the past still have a company behind them. To survive, a company must grow, expand, and evolve. Sitting still with the same old stale strategy, marketing, and product lineup is a recipe for failure imho. We don't want to end up forgotten along the roadside to Mac software company success. (and we'd like to think our users don't wish that either ;) )

So given I've just admitted the odds are against us, our plan to accomplish or goal of becoming a mainstay in the mac developer community is what then? Can we survive by selling $7 software? (I've even heard grumblings among other developers that our low prices are causing their users to be less-than-enthusiastic about higher prices) Quite frankly, I have no idea. :) I don't think there is a particular price we are going to stick with despite the current $7 trend we have going. What I believe I do know is that our strategy of providing quality software at a great value is one which seems to make our users happy and gives us little warm fuzzies too.

My point in all this? There isn't one. Sorry if you read it all hoping for something earth-shattering. ;) But I would like to put out a big Thank You to our users. I think we're in a win-win situation. We are doing what we love to do, and generally speaking, our users seem to be very happy with our software/value.

Well, tomorrow we'll be celebrating my birthday. (No, the real birthday is on 13th, but it's not convinient to party on Sundays). So I am taking a liberty and taking a 2-days break from programming, Unsanity, and answerring emails (mostly) -- just to pretend I am having ordinary, real, life. Hah.

It turns out I still am thinking (during so-called "real life" activities) about the future of Labels X and particular implementation details for v1.1; about that new half-way done haxie I've yet to finish; about MIP in WindowShade X; and about all sorts of things that occupy the mind of an ordinary programmer.

I answer e-mails, too. Mostly. And I do sit here and browse the web, reading VT reviews on Labels X (only one one-star rating, wow!), and doing pretty much everything I do every day.

I have to realize one thing - real life is not the absense of computers and Internet community; it is just what I do every day. Everything else is a fake, substitute, and false impressions about what the life should be if one takes out his geekness.

I can't.

Well, thanks to our testers, Labels X 1.0 is finally out!

Grab it while it's smokin' hot! ;)

Ok people, I am going to make a public announcement. No matter how obvious or simple this may sound, I still feel the need to spell it out, mainly for myself: Unsanity, LLC is a business.

Why am I telling that? Simply because today I found myself working on two branches of Labels X: 1.0 and 1.1. Sounds a bit silly, as 1.0 is not even publically out, and I am working on an update already, but that's the joys of commercial programming. Being a small company, based in Utah, with employees scattered around the globe (Utah, Arizona, and Russia), we have to try and make a living from the venture we call Unsanity. This means, being a shareware developer, we have to release things at a steady pace to get noticed by general public -- we cannot afford a one-page advertisements in thick magazines, or billboards on your local Main Street. For that reason, about the only way for us to market our things is release often.

Ok, I was a bit dramatizing the situation - it is not the only way -- word of mouth plays some role too, and we much appreciate you, our users, for that.

Either way, to get steady registrations rate, we now have to split features in versions and release them in small batches, rather than doing one-big-release. I think both us and our users benefit from that - us, because, as I said, we get more exposure, our users, because they don't have to wait forever while we polish and enhance a particular piece of haxie until we're totally, completely, absolutely satisfied with its featureset and can sing a song about every single pixel in the designed UI. And also - we don't charge for upgrades. Never. Once you bought it, it's yours. Although I can perfectly understand companies' view on the whole 'upgrades' business (you have to cover your expenses involved in developing a new version), I also understand a lot an ordinary user's point of view - "why do I have to pay for the same software over and over"? And we're on the users' side. Yeah, we may go bankrupt with that attitude, sooner or later, but I hope that we'll be able to make new stuff often enough to keep ourselves alive (oh, I wish I had about a dozen more hands and dozen/2 brains to implement everything I want!).

And this is where it comes to you, our users. So far you've been doing an excellent job of supporting us. It is great -- we can devote all of our time to Unsanity and development, instead of spending hours in offices doing so called "day jobs". Keep doing it. We count on you. And you can count on us, for sure.

This is a completely pointless post. You can see the place where I currently live on my .Mac Photo Album (yes, I paid for .Mac).

If you are wondering, yes, I have three computers in my room. And yes, I have about 100 anime DVDs. And yes, I have about 28 DBZ videos. And no, it's not becoming a problem.

Well, so Labels X beta 2 is posted. It is almost the Real Thing(tm) (at least for version 1.0, as there's a lot of things to improve/add) - which means that, if no significant bugs will be found, it will become 1.0 after some repackaging.

If you feel like beta testing this beta for me (without spreading it too much), please drop me a line at slava(unsanity.com) (gosh, gotta obscure these emails so evil spam spiders don't harvest it!). Please mention the version of Mac OS X you're running in the email. I'll do the mail collecting in the evening and will send you the needed information to begin testing.

If all goes well, Labels X 1.0 will be probably out next week, so I can switch to yet another Mystery Haxie(tm) that was in development for 2 months this summer, but I haven't yet finished it.

My RSS addiction is starting to show. Made today an RSS feed for www.unsanity.com news, available at http://www.unsanity.com/rss.php. Use and abuse.

Yeah, right. Chicks dig Mac OS X. Uh huh. Chicks also dig Windows, Linux, FeerBSD and VAX/VMS mainframes. Oddly enough, I haven't seen a decent girl who was attracted by me because I use computer with a particular operating system. In fact, no girls were attracted because I use a computer in general, as well. So computer is like a baseball bat during sex - it's long, nice, and nifty, but it doesn't makes much difference in the above mentioned process (hold your sick comments about baseball bat usage during sex to yourself, willya? =). Yeah, of course I've seen a few nerd girls, who did care, but for some reason, our relationships never worked out -- except for cases when we decided to limit our romance to AIM and ICQ. Real fine young pretty ladies don't care what computer you're using, what socks you wear, and if that-thing-on-your-head-is-from-dkny. Period.

Oh, and to step back a little from the topic of this rather dull blog entry, and to conclude it, I think the following acronym very well describes my feelings after typing all this:

WTF?

PS If you like fine young ladies, visit inluminent/weblog. Sex sells? Nice move for a marketing blog. And don't tell me you go there to read it. I do, though. ;)

So MacMinute now has a full searchable collection of all its articles since it opened on May 9, 2001, and an advanced search mode, so you can easily find stuff you want. PHP coding can be fun!

Well, as promised, here's a summary of my own thoughts and your comments for the future Minimize in Place implementation for WindowShade X.

• Minimize-in-place (MIP) will be available as an additional minimization style choosable from the WindowShade X style popups.
• A window minimized with MIP style will be transformed into a tiny window outline ("MIP windoid")
• MIP windoids will have customizable:
  • Opacity
  • Window level (float above all windows in the current app, float above all windows, behave like regular windows)
  • Parent application icon overlay (should it be displayed or not)
• Also, I think MIP behaviors can be customized:
  • Minimize and leave the MIP windoid at the same position as the original window;
  • Minimize and auto-dock the MIP windoid to the corner of screen of your choice;
  • When maximizing a MIP windoid, make it maximizable by single or double click;
  • When maximizing a MIP windoid, make the original window expand in either its original position, or in the MIP windoid position.

I dunno if the sparse notes above make much sense to you, but please feel free to ask, rant, and discuss this featureset draft with us (in the comments section). Thanks!

This entry is going to be short:

Labels X 1.0 just went beta. There are still issues to iron out, but overall it's looking good!

I've been reading this thread at MacNN forums about how recent software from Apple is slow. But keep in mind both iPhoto and iCal are Cocoa applications. I think it is appropriate to repeat my own rants from now-dead slavakarpenko.com blog -- regular readers, please excuse me for copy-paste! ;)

I think general users are overrating Cocoa. Why does everybody seem to think that something running on MacOS X would be only good if its Cocoa? For some reason, people are getting an impression Carbon is slower, older, and generally unacceptable osx technology made up to easy the transition for existing software. Well, although this is partly true, let me clarify some points about Cocoa and Carbon (and I'll use some technical arguments you can safely ignore if you don't feel like digging in the system documentations):

Cocoa is not a new technology; it has roots in NeXTstep (all of Cocoa classes start with NS, which means "NeXTstep");
Carbon is not a new technology either; it has roots in Mac Toolbox introduced with first MacOS (of course both Carbon and Cocoa evolved a lot since their initial implementations, yet Carbon evolved more dramatically - with the advent of Carbon Events, things became a little bit easier on developers, while Cocoa (AppKit) ideology mainly stays the same);
Cocoa is easier to learn, use, and develop on, especially when it comes down to implementing a functioning GUI fast (I am aware of PowerPlant for C++ and similar frameworks, and used them plenty, but they can't beat Cocoa when you need a simple but functioning GUI right away);
Cocoa largely uses Carbon to deliver some of the stuff (for example, menus code is all Carbon with Cocoa wrappers on top, same applies to parts of appearance themes etc etc etc);
Because of the fact Cocoa is higher level than Carbon (making it easier to develop on) (see my previous 2 statements), it depends on Carbon pretty much;
Cocoa is generally SLOWER than Carbon, despite what most public thinks. (When a Carbon app wants to call a function in itself, it jumps directly to the function address; when Cocoa app wants to do the same, it goes through a single (ok, there are a few variations of it) function called objc_msgSend which finds the correct address and jumps to there. This means each time a Cocoa method calls another Cocoa method there's 16 to 80 instructions overhead compared to Carbon. A true bottleneck, however it is not a design flaw but rather a decision that makes objc quite flexible to make it achieve what it needs to).

So, my point? Cocoa is not better than Carbon; its just different. Do not assume Cocoa applications are better than Carbon. This is often true (bug-wise) due to the fact Cocoa implements lot of high-level sh*t Carbon developers have to much with themselves, which cuts the number of bugs in UI code significantly. However, not all Carbon applications are crap. Look at Finder (lets keep aside the missing functionality aspects here) - it is a PowerPlant C++ application. Compare it to SNAX. Which is faster? When it comes down to tables drawing speed, Finder wins hands down. So don't think Finder would be all that faster and better if it was Cocoa. It wouldn't.

PS I love Cocoa, and all of Unsanity's UI programs (prefPanes, installers) are written in it; however, the haxies itself are all Carbon, because we don't want to slow down user's applications more than they already are. ;)