This is mainly for developers, but if you’re a Quicksilver user and want to get a taste of the upcoming Fumo interface, feel free to tune in.
Nicholas Jitkoff, aka Alcor, the developer of Quicksilver has been extremely generous in providing assistance and code. A developer by the name of “ytrewq1″ has also been very gracious. Sincere appreciation to both of them.
Well, let’s take a look at how Fumo is shaping up. I’ve added a sliding transition for when it’s activated so it shoots down from the top of the screen. I’ve also made the contentView of the window transparent, and added a custom view to which the rendering of the background is done. Trust me, it’s easier that way.
The transition for the window exiting (by sliding out) is very crude and you’ll notice that I’ve had to use the “reallyOrderOut:” method on the window since orderOut makes it fade out, and it looks weird if the window slides out of the screen, then reappears and fades.
Final thing, (actually the first real thing I did) was the subclassing of the “activateInTextMode:” method. Try activating the interface in text mode (you’ll need to have a trigger for Command Window in Text Mode). Hopefully you get a very nice warping effect.
Next on the agenda is changing the background and text color of the actual searching views. Take a shot at it if you like. Here’s the source code:
Fumo Source
Update: Download a (still unstable) version of Fumo from this post.
Remember Fumo? Well, I have slowly been unraveling the source code Alcor kindly provided, and am starting to get the picture of how everything works. I’ve been playing around with different interface ideas, and for Fumo, have so far got something like this:
Yeah, I know it’s a far cry from the actual interface mockups Pavel created, but it’s a start. I mean, I’ve been whinging about this a lot, but you try to subclass views that are as cool and extreme as Quicksilver’s - without looking at their implementations. As ytrewq1 described, writing plugins for Quicksilver is a tedious process involving looking through the available code and just experimenting until something goes right.
Having said that, I’m having a lot of fun writing code for my favorite app, and it shouldn’t be too long before Fumo hits the market… uh… streets. It’s a great idea that is just waiting to be created (in fact, it’s been waiting for several months now. Before I knew about it, of course).
Got any ideas for Fumo? Or for a plugin for Quicksilver? I’m eagerly awaiting that comment 
Update: Download a (still unstable) version of Fumo from this post.
I have been meaning to write about this topic for ages due to a huge response to this article, but with four exams in two days and a few more still left, there’s been very little time. So instead of a full-fledged post / tutorial, here is my view on writing solid security measures into your shareware applications. Note that I haven’t actually written a shareware app myself, so most of this is theoretical (ie. in my crazy mind).
Before we get into the different strategies, I would like recommend this article on software piracy by Ambrosia Software (Snapz Pro X). It really shows how vulnerable Mac apps really are and the effect they can have on small and individual developers. Ambrosia now uses what I believe to be one of the strongest and most fraud-free licensing system of any developer (including Apple). However, the method they use does have drawbacks in slight annoyances for the user. There is no perfect way of protecting your application, and no matter what you do, those that want to crack your application will; Even Microsoft, Apple, and Adobe have their software cracked and pirated. It’s about finding the right balance between safety and resources. How much time are you willing to spend hack-proofing your app? Do you need to go hard core encryption and daily online checks or is storing a hidden encrypted file enough? It’s up to you to review the alternatives and decide.
Continue Reading Shareware licensing techniques
Play with fire.
Download
Feedback and criticism encouraged and appreciated.
© 2006 Ankur Kothari
Interface and eye candy seem to be taking a prominent role in recent Mac developer’s minds. Just ask Dustin MacDonald. But whatever your view, there comes a time when you need something to fly across the screen, bounce up and down or just move. In other words, animate. And animate you shall, with Simon Haertel’s excellent Animation Toolbox 3. Also used extensively in his Mac version of Tetris, Quinn, the toolbox makes things like bouncing and sliding look natural and sleek - with hardly any code.
If it’s animating views you’re after, Matt Gemmell has got you covered. Initially having trouble with NSViewAnimation, someone neglected to tell him that it needs to be subclassed. However, Matt has recovered from his lapse in, uh, frustration and created a little sample animating views subclass. From his blog:
It’s a partial rework of Todd’s NSAnimation Demo code, which subclasses NSAnimation directly and updates all the animated views’ frames itself in the same thread for better perceived performance. For basic “animate a bunch of views at once” uses, you should be able to just change NSViewAnimation to MGViewAnimation and go with it…
But please read these caveats:
- This thing is barely tested at all
- It will probably only work for views (not views and windows, as NSViewAnimation does)
- It doesn’t attempt to do the fade-effects that NSViewAnimation does (though that should be trivial to implement if you need it)
At the very least it’s a good starting point for folk having issues with NSViewAnimation, and just as a general example. I hope someone finds it useful, and a big thanks again to Todd for his original code.
You can download his MGViewAnimation project from Gemmell’s Source Code page.
![[RSS]](http://lipidity.com/wordpress/wp-content/themes/virtuoso/res/img/feed.png){kind=small}
![[RSS feed for this tag]](http://lipidity.com/wordpress/wp-content/themes/virtuoso/res/img/feed_tag.png)