| View previous topic :: View next topic |
 |
| Author |
Message |
|
|
# 16 Nov 2007 16:43:03 Re: Quay is coming... |
 |
|
| OK, the Quay first public beta (10.b4) is out! Details on that page... I'm still busy emailing press releases, changing links and whatnot. Whew. |
|
|
|
|
|
| # 13 Nov 2007 17:27:23 Quay is coming... |
|
|
I took off a week to work on a new shareware app for Leopard!
It's called Quay and you probably will be able to guess its purpose from the icon:
Watch this space for announcements. I just need to set up the pages, the web store, yadda yadda... |
|
|
|
|
|
| # 09 Nov 2007 10:41:06 Leopard simplifies your code |
|
|
In line with others detailing goodies (Matt Legend Gemmell and Blake C. are two I remember), here's a new Leopard API that appears to eliminate an entire page of my old code: | Code: |
FSRef ref;
// now point FSRef at some file or folder
IconRef iconRef = NULL;
GetIconRefFromFileInfo(&ref,0,NULL,0,NULL,kIconServicesNormalUsageFlag,&iconRef,NULL);
NSImage* image = [[NSImage alloc] initWithIconRef:iconRef];
|
Then you can do setSize: if you want a particular icon size for that file or folder.
True, if you had a path to the file, you could always do: | Code: |
NSImage* image = [[NSWorkspace sharedWorkspace] iconForFile:somePath];
|
but if you're already handling FSRefs, getting a path back from it is slower and also suffers from the PATH_MAX limitation (1024 bytes maximum path size).
I also seem to remember that NSWorkspace fails for certain types of file system items, but I can't quite recall which ones right now. It does work for run-of-the-mill folders, apps, and files though. |
|
|
|
|
|
| # 01 Nov 2007 06:44:50 Aspie test |
|
|
Just found this test again after several months - this time, via John Scalzi. Last time I forgot to record/post the results. So, for what it's worth:
| Quote: | Your Aspie score: 132 of 200
Your neurotypical (non-autistic) score: 79 of 200
You are very likely an Aspie
 |
|
|
|
|
|
|
| # 29 Oct 2007 10:48:34 Obligatory Leopard post |
|
|
There's been so many comments about Leopard over the weekend that I stopped reading - and there are too many of them that just repeat each other, too.
I've been running Leopard since the first seeds came out, and the last few have been really stable, especially the last one; I didn't have to reboot it once in about a month.
The final release - 9A581 - was built on Oct. 12 but released to developers on Oct.26, the same day that it (theoretically) was released to users; some journalists got it earlier under embargo. In past major releases, the final build's release date for developers was uneven - sometimes just a few days before, sometimes as much as a week after.
Buzz Andersen, a former Apple employee, wrote a very good post pointing out the difficulty of interpreting Apple's actions from the outside. While I personally think Apple's two-week delay in posting the final release for developers was unfortunate, I must point out that past releases leaked on the torrent sites in less than a day. If some developers won't honor their NDAs, everybody will suffer for it.
Similarly there's much controversy about stuff that got suddenly (or not-really-so-suddenly) taken out of the final release; 64-bit Carbon apps, ZFS support, Java 1.6, backing up over wireless are the ones that immediately come to mind. As usual, people are reading into that all sort of background motivations - Apple is following some Machiavellian scheme, or is completely stupid/clueless. I prefer to believe that they're doing the best they can with their limited resources while trying to follow a multitude of small individual agendas. Ants carrying a large item into their nests come to mind... 
For now, I'd just like to point out that, as in previous years, 10.5.1 will be out within 15 days, probably fixing at least one of those omissions. I think Apple made a good decision in, for the last month, concentrating on polishing existing features. Leopard is unusually smooth and "finished" for a .0 version.
On a personal note, and as I posted to the XRay Support Forum a few days ago, XRay 1.1 suffers from some problems in the final Leopard release. The most annoying is that the file browser doesn't allow you XRay an item - it will crash.
I'm fully resolved to step up efforts to release XRay II, at least in public beta, as soon as other commitments allow. It will be Leopard-only and everybody who paid for XRay 1.x will get a free upgrade to the "standard" edition (there may be a "pro" edition, but I'm not sure yet).
One commitment which, unfortunately, is a great deal more pressing (literally!) is that I've contracted to write a book about "Programming Objective-C 2.0". This also is specific for Leopard, and as you can imagine, deadlines are very short; ideally, of course, the book should be out today! But, the laws of physics and physiology permitting, it will be out as soon as possible. Watch this space for details. |
|
|
|
|
|
| # 28 Oct 2007 19:02:11 Meanwhile |
|
|
| While I haven't had time to really look at, or comment on, Leopard yet, this article by Matt Legend Gemmell is must reading for Cocoa developers. Nice job. |
|
|
|
|
|
| # 18 Oct 2007 15:35:58 No more Xray. Good or bad? |
|
|
Overnight, Apple's changed the Leopard Developer Tools page to confirm officially that the tool formerly known as Xray is now called Instruments.
Well, while both names are certainly better than the prototype name (which, supposedly, was "PowerTrace"), I'm both relieved and worried by the change. When the name first came to my attention over a year ago, some Apple folks told me privately that I shouldn't worry about any conflict with my own XRay utility (now being reincarnated as XRay II). Still, I hoped that the similarity might drive some clients my way, and I even linked from my own page to Apple's, to avoid any confusion.
Now, this last-minute change is a also little worrying, since it's probably a symptom of a cease-and-desist letter. This came up so suddenly that even the icon on the Apple site still uses an "x-ray machine" theme. I can't find any larger Mac software company using any variation of "X-ray", but who understands how lawyer's minds work? It might even be a non-software company. Hopefully my new second-generation name will be non-conflicting enough to avoid any trouble. |
|
|
|
|
|
| # 17 Oct 2007 20:12:51 Halo effect |
|
|
Very interesting post over at the online photographer: | Quote: | ...Canon introduced three coupled tilt-shift lenses for the EOS system, a 24mm, a 45mm, and a 90mm.
...I was told that Canon expected to lose money at least on the 90mm, and that probably all three lenses would never earn back their development cost.
What? So why make them at all?
Because, I was told, the availability of the three tilt-shifts would serve as an enticement for pros thinking of switching systems from Canon's main competitor. The company would never make any money on those specific products, but it would make money from all the other products those "switchers" would buy after they switched. |
OK so far, but now read this: | Quote: | Once, I ran into an even more fascinating phenomenon: a photographer who had switched to Canon because of the tilt-shift lenses, but who hadn't actually bought any of the tilt-shift lenses!
What was that about? "I just like to know they're there," he told me, "so I can buy them if I want to." |
Does this sound familiar...?  |
|
|
|
|
|
| # 17 Oct 2007 14:36:41 Déjà Vu |
|
|
Just saw this over at Amazon: | Quote: | Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers.
...
Amazon EC2 changes the economics of computing by allowing you to pay only for capacity that you actually use.
...Start, terminate, and monitor as many instances of your AMI as needed, using the web service APIs.
Pay for the instance-hours and bandwidth that you actually consume.
...Amazon EC2 passes on to you the financial benefits of Amazon's scale. You pay a very low rate for the compute capacity you actually consume.
...etc. |
History repeats itself... this is very close to what we used to operate with in my mainframe days. You punched out a job control deck and ran a job that used a virtualized instance of the OS. Later on you'd get billed by so many seconds of actual CPU time, I/O bandwidth, and storage. In fact, my M.Sc.-thesis-to-be (1975, I vaguely remember) was about implementing just such a billing system. |
|
|
|
|
|
| # 17 Oct 2007 14:27:07 Re: State of the iPhone |
|
|
Steve Jobs just said (I guess I should say, Real Steve Jobs, hehe) on his blog: | Quote: | ...We want native third party applications on the iPhone, and we plan to have an SDK in developers' hands in February.
...Nokia, for example, is not allowing any applications to be loaded onto some of their newest phones unless they have a digital signature that can be traced back to a known developer. ...we believe it is a step in the right direction. |
This seems to indicate that the application installer - which will in all probability be iTunes - will check if the application is properly signed. Whether they'll allow developer-signed apps is anybody's guess, but I wouldn't rely on it. (Signed apps is one of the 300 Leopard features, by the way. I'll comment on the Leopard day announcement in a few days.)
I wrote two weeks ago: | Rainer Brockerhoff wrote: | Conclusions:
- the current generation of iPhone/iPod touch will remain closed forever, just like the first generations of iPods; (I was wrong there, and a good thing too!)
- an SDK is likely to come out only after everything (especially the hardware) has stabilized; |
So the February OS X version will be the first one with stable, public APIs... meaning current apps, written to reverse-engineered specs, will probably have to be seriously rewritten.
| Rainer Brockerhoff wrote: | | - Apple is unlikely to invest efforts into implementing TrustZone in the current generation, unless Moorestown (or whatever else they might adopt in the future) has a similar security feature - and maybe not even then |
Now I wonder how they'll handle such a hypothetical future hardware migration... probably fat binaries, with the "other" executables being stripped out by iTunes when installing an app; this would be the most flexible without upping memory footprint on the phone side.
Update: Seems that Intel and ARM are collaborating on new TrustZone implementations... might that foreshadow TrustZone on Moorestown...?
Now, some people say this proves that Apple is listening to complaints and that they're changing their original plans; on the contrary, I think this had been the plan all the time, but the Leopard delay also delayed the SDK. Regarding the timing of this announcement, this might be a trial balloon to see if they can minimize the inevitable profit-taking after next week's earnings announcement. Hopefully that will happen.
Last edited by Rainer Brockerhoff on 17 Oct 2007 16:54:58; edited 1 time in total |
|
|
|
|
|
(RSS 2.0)
