As noted on my projects page, last year I worked on an inspired little app, LaserLine.
Last week Joey Hagedorn (LaserLine’s progenitor) shared some of his recent brainstorms for the next iteration of LaserLine (he’s already started building new and improved hardware), and I must say I’m rearin’ to go.
Seeing as spring break is starting soon, and I’ll have a whole week’s worth of free time (well almost) I think I’ll try and devote a sizable chunk of it to refreshing that old code.
Over the weekend I managed to get some more coding in (though as usual, not as much as I’d have liked). So here’s a post about that:
Miscellaneous Projects: I decided I’d better make a home for all of my little projects. So now they all have a spot on my miscellaneous projects page. And of course since no page would be complete with out the obligatory picture, I made a question-mark-in-a-package icon to keep them company, cool eh?
CTBadge: I knew when I started it that I’d eventually have to ditch the ripping of Mail.app’s badge images for my own purposes. And after some suggestion I decided to make eventually now. It turned out making ‘counterfeits’ was actually not that bad… started up Illustrator, and a little while later (after finding the Zig-Zag Filter) I had vector (I love vector!) replicas of Mail’s raster badges.
I can’t tell the difference
So now, thanks to the vector masks, CTBadge will get you renders of badges at any size, and also allows you to set the label and badge colors to what ever you’d like (while retaining the classy shading at the lower right corner – beautiful!).
And while all that is swell (and it is) I still wonder if letting people choose any color that they’d like for their badges is a good thing, I’ll rue the day when I see electric purple badges on my dock… but alternatively colored badges have their place I suppose – so there you go. (Though I sure hope people have a darn good reason for not using the classic white on red when they do – and “it looks better” doesn’t quite do it, but I suppose that’s just me).
CTGradient: Now it has a method to do a radial fill. After putting off including the code for a while, I finally settled on the implementation I preferred, which was leaving axial/radial specifics in the drawing methods where they belong – and not as a part of the instance. Though a few questions still remain – as I have it now, it draws so the gradient progresses from the center to the outermost edge, would there ever be a reason to have it progress to either the nearest edge or even off to the corner? meh, it’s good enough for now.
I also finished implementing all the boring parts of CTGradient, that is, I finally implemented the NSCopying and NSCoding protocols, and also added some extra accessor methods, documentation, and #pragma’s to the source.
CTTabView: This a new project I’ve started work on, a view designed for doing more of a “Tabbed Views” sort of thing (like Safari/Adium/Firefox) than the “View with Tabs” thing that NSTabView does (and does well). Other people have made things like it… but none have really caught my fancy.
Well, that’s enough for now – I’ll save the rest for a later post.
CGShadings are a pain, or well, lets just leave it at all of Core Graphics (CG). While CG is a heck of a powerful library… It always seems to take an elaborate amount of code (as well as time, if your not yet acquainted with it) to do some of the simplest little things. For a discussion on creating gradients with CGShading go here.
Now, AppKit provides a pretty decent layer of abstraction, but I find that there are still a number of holes in its coverage of those lower level APIs that could use some filling.
One of those that AppKit doesn’t cover (that it really, really should, especially given the whole resolution independence thing that’s in the works – 10.5 maybe? please?), are gradients.
When I started coding up a sourcelist (you know, the tableView with the iTunes/iPhoto/Mail styling) and also thinking of a few of the mini-projects that I had plans for, many of which could use gradients also – I figured that I might as well take a little detour and try my hand at filling in that gap.
And so, let me introduce you to my little Cocoa Obj-C Gradient class, CTGradient. It’s a small class that should provide a decent cocoa interface for CGShading.
In my case, CTGradient has gone a long way toward making the code in several of the projects I’ve been working on significantly less cluttered (and that’s always a welcome change). I no longer have lines of GCContext junk in my drawing functions nor do I have CG function callbacks proliferating my code. The few convenience methods that I tacked on help a bit with readability as well.
 |
Download CTGradient < 100 KB |
And so, that said, I figure a few people might find it handy.
As it stands right now, it’s not quite finished (I expect the interface to change by a fair amount in the not to distant future – I have a few additions to make). But in any case the code is stable, so if it does what you need it to do, go ahead and make use of it!
With that I’ll end with a short list of those additions I have plans to make:
Update: Updates and other info will be maintained at svn.oofn.net.
Update: With OS 10.5’s AppKit, I would recommend using only NSGradient.
Apple’s badges are excellent. Apart from just looking good (notice the subtle shading on the right) and standing out, they are effective.
The fundamentals of any good interface should always be, most important, simplicity; next, consistency and after that, specificity. And these badges are just that, they send a simple, clear and consistent message to the user – “there ## number of things you care about right here”.
But to dig a little deeper… what makes these badges excellent? – the fact that they pervade the user’s environment, that’s what is key.
When badges pop up any time you drag messages in Mail, songs in iTunes, people in Address Book, or pictures in iPhoto, for users, the little icons send more then just a message, they convey meaning and a sense of familiarity.
When a badge comes up on one of my dock icons I know there is something at that application that I ought to check out (in a timely – but not quite urgent fashion). It doesn’t matter what the meaning is – the message is the same regardless of the fact that they may mean errors in xCode, unanswered messages in iChat, or unread messages in Mail.
And so it’s a shame that AppKit doesn’t doesn’t provide a way to create badges for your own OS X apps – developers, I’m sure, would love to tap into this useful interface element. Apple devs probably wouldn’t mind either – as it stands each and every app that uses the badges has its own copy of the badge images… and NSApp doesn’t provide a private method either (I’ve checked).
|
Download CTBadge ~150 KB |
But these badges are just too good to pass up (no, really, they are) so here are a few tiny methods that’ll do the work for you.
As a side note, notice how the badge in iTunes is noticeably different than the badge in Mail/iPhoto/etc? Radar 4402569
Update: Updates and other info will be maintained at svn.oofn.net.
So you want to put a graph in your application?
Graphs are great things, they’re a great way to pimp out an app (provided you are doing something data-ish). But right now there aren’t a whole lot of options when it comes to adding graph goodies too your applications if your a cocoa developer. — Not Cool. sigh.
So if you want to add graphing you have these options:
Apple’s GraphKit framework If you have access to the documentation then that’s the way to go. Unfortunatly that’s a little hard to come by if you’re outside of Apple. I’ve heard GraphKit almost made it public with Tiger. . . but didn’t — sigh.
SM2DGraphView from Snowmint Creative Solutions. SM2DGraphView is ok, but I’m not too crazy about it. API doesn’t allow for for a whole lot (at least not what I wanted) and the source isn’t that conducive to customization. Also I’m not too sure about how it handles ‘special’ floating point values (NaN, etc.).
Roll your own, Well if 1) and 2) won’t work you don’t have much of an option then… problem is making your own takes time and, well, it’s usually not worth all that time.
So what to do? well 1) and 2) didn’t work for me, and the app I was making was the graph so, eh – I didn’t have much of a choice, I had to take 3).
Keeping in mind that I (as well as other people) did not want to have to go through doing number 3 again in the future, I figured I would take some extra time and start the beginnings of a decent cocoa graphing class.
The two major goals for the project:
Low barrier to entry, I want people to say “hey, a graph would look good here” and to be able to plug a graph right in, without having to muck around figuring out how to do all of this graphing stuff. As a consequence I’ve chosen to do a few things inefficiently (NSTableView style DataSource), but in the hope that usability will benefit.
Extendability/Customizability I’m not going to be able to anticipate how people will want to graph their data, so I’ve made a point of, if not implementing a functionality, (hopefully) making it easy enough to add that functionality with a subclass or thereabouts.
That was a year or so ago, since then all my code has by laying by the wayside, lonely and neglected. These past few months I figured I would dust it off a bit and do a bit more work on it.
I figure now it’s about fit for public consumption. So, if your in the mood to do some graphing eat your heart out.
GraphX Framework – project page