Entries Tagged 'Mac Rumors' ↓

If you think you are ready to sink your teeth into Core Data, you should definitely start with Scott Stevenson’s tutorial.

Granted, you may want to use XCode 2.x for the tutorial, since that is what the tutorial is in. The differences between Interface Builder with XCode 2.x and XCode 3.x are pretty huge. The workflow is very different. (not to mention the interface, no pun intended)

I myself am still getting acquainted with XCode 3.x and my new Intel-based MacBook is in the shop, so I’m on the reliable old G4 iBook today, so it is an exercise I can work on in the interim.

Although you don’t need to be an expert at Cocoa Bindings, and there’s a strong chance you’re not. (not many people are) You will want to at least have covered the frustration of trying to work with bindings a little bit before sticking your nose into Core Data. And, as always, I will say if you’ve worked with Ruby on Rails and Active Record before, you will find Cocoa, Cocoa Bindings and Core Data a little less frustrating, but don’t expect it to be the same thing. It does still work like ORM (object relational mapping) so having a basic understanding how CRUD (create, retrieve, update, destroy) applications work with databases will help you a lot.

I’m now diving into XCode 3, thanks in no small part to my new black MacBook! One thing I had been looking forward to is the syntax highlighting that shows you the scope of the function or method or code block. Beautiful stuff. I had envisioned it myself several years ago, when I first learned CSS. (I’m sure I’m not the first and obviously not the only…)

Now that XCode 3 finally has code folding, though not as slick as TextMate’s code folding, it will flash the scope depth highlighting colors. But it goes away quickly. Here is how to turn it on to stay (it isn’t obvious or self-apparent).

View>Code Folding>Focus Follows Selection

Or a picture …

What’s the secret to getting good results from Icon Composer?

That’s actually very easy to answer. Most of all, a good design that follows the ideals set forth in Apples HIG (Human Interface Guidlines). But aside from that, you need to use Photoshop for the final image. Regardless of how you design the initial image, in Photoshop, create two layers. One for the image, one for a black shape that is the same outline as the image. Make sure you’ve got a square canvass in Photoshop also. Then, Save As… select TIFF as the format, with no compression and preserve layers.

Now drop that tiff file onto icon composer. You’ll get as good as possible at this point.

So, you, like me, want to make your own buttons in interface builder? I too struggled with this. Sometimes the help menu in Interface Builder just sucks. Well, generally it sucks. The problem you may have had, the problem I have had, is simply that your button graphic when clicked gets a white rectangular background during mouse down. Well, I finally figured it out! (This is for XCode 2.x and I don’t know how it goes in XCode 3, but I imagine it is similar.)

First off, of course, you need a graphic of your own. PNG format is best. Make it pretty in Photoshop, export it as a PNG with transparency, and at the desired size. Now, drag it into the XCode window, into the Resources group. Next, open your NIB file in Interface Builder. Add a button to the window. In the inspector palette, with the button selected, you need to change a few options. For Type: choose Square Button. Now, click on the Images tab in the window that holds Instances, Classes, etc… Drag your image onto the button you created. Then, with the button selected, uncheck the Bordered checkbox. Next, change the inspector from Attributes to Size, and resize the button to take up the amount of space you like. Finally, change the inspector palette back to Attributes, and change Behavior: to Momentary Change.

Try it out with command+R. Click your button and see it change the way you expected! No more white background on mouse down!

As an aside, if you don’t want the default shaded button on mouse down, create the alternate appearance in Photoshop. Save it like before as a PNG of the same size, but with a slightly different name. (just append ‘down’ to the end of the name) Add the button to the XCode project’s Resources group like before. In Interface Builder, it should now appear in the Images. Select your button. In the inspector palette, just copy the image name as it is in the Icon: field and paste that into the Alt. Icon: field and append ‘down’. Or, just type the name of the image minus the .png extension. Test it out. Your button should change exactly as you like with a mouse down action.

If you want more complex changes or animation, you’ll probably do well to use the Core Graphics API and build it yourself with that.

Back in the days before OS X came out, there was Yellow Box. If it were available today, it could easily be described as XCode and Cocoa for Windows. There was also Red Box back then, essentially the same as what we’ve got now: OS X on Intel processors. To make things interesting, it is well-known that iTunes exists for Windows, and (somewhat infamously) also known that Safari exists for Windows. Apple even makes a utility for Windows to manage AirPort base stations.

“So, what!?”, right?

No. It’s bigger than that. What Apple is tinkering with more and more in their skunkworks is the development environment formerly known as Yellow Box. That technology never went away. It may have languished with time somewhat, but thanks to Microsoft’s determined support for backwards compatibility, most of what was ever in Yellow Box still works. Sure, some of it is crufty and all that, but the recent developments with Safari and on-going development of iTunes for Windows is indicative enough that they’re definitely toying with the idea of releasing Yellow Box once again.

This makes perfect sense. Macs run on Intel. Windows runs on Intel. Mac users can install Windows on a Mac. Why not develop the same application on a Mac, in Mac OS X, in XCode, then compile it for both operating systems at once!? That’s right. That’s exactly one of the things you will see coming out of Cupertino in the next year or two. If they don’t announce it at this year’s WWDC, you can expect it at the following year’s WWDC.

Working on the RaiseMan application in Cocoa Programming For Mac OS X 2nd Ed, I kept getting ” ‘ClassName’ may not respond to ‘-methodName’ “warning messages on successful builds. The warnings were obviously stupid compiler warnings. Trouble is this: Objective-C (and thus Cocoa) does not care what order you implement methods in your .m file, BUT the compiler is just not clever enough to realize this and wait until later to generate warnings like this.Annoying. Especially so, when you consider, I knew this long ago, but had forgotten it. But to be sure, even though you can put methods in any order, when you get such erroneous warnings, check to see if the method flagged in the warning does not call a method that is defined later in the .m file. If you find this to be true, simply reorder your methods so you can build without warnings. Ideally, you should build successfully with few or no warnings. No warnings is always ideal. Compilers are clever tools but not perfect. The upside of this annoying defiance of the language? When you do get your methods in an order that generates no warnings, your code will be more readable and maintainable because no method will call another method that does not come before it!Finally, I don’t know if this has changed in XCode3. I doubt it, but I have not taken the plunge into Leopard, because I can’t afford to buy a new Mac capable of smoothly running Leopard. (and because I still don’t really like Leopard as much as Tiger and Panther, even though I use it at work every day… maybe another dot-update or two will bring me into the fold…) 

Duh?! Physical access to any machine makes it highly vulnerable to accessing the contents of its storage media. Apple knows that. Any IT manager worth spitting on knows that. Steve Ballmer probably knows that. George Bush might even know that! These guys who developed the cold memory dumper are butt stupid because it’s a waste of time and effort. This is no big secret or mystery. If you have an OS X install disk that is not older than that particular Mac, you can simply put the disk in, force power down, restart booting from the install disk, from the Utilities menu launch Reset Password Utility. This allows you to change the password for any account on any connected bootable volume as well as enable the Root account! That’s a hell of a lot easier than this bullshit attack.Apple’s not stupid and this is no secret.If you really, really need more security, you simply do not allow physical access to the computer. Need more? Do not allow network connectivity. Need more? Enable a firmware password on the drive. Need more? Get custom firmware that disables startup keys normally available on the Mac OS. Need more? Be a Luddite.Security is always a trade-off with any connectivity. The old phrase Boot Access IS Root Access exists for a reason. 

You may have tried unsuccessfully to install the Ruby Gem ultraviolet or the gem it depends on, textpow, and if you did, it likely failed mysteriously. Well, you first need to download and install the Oniguruma regex library. These instructions should work on almost any *nix with GCC, as well as OS X 10.4 and 10.5 !First, go to  http://www.geocities.jp/kosako3/oniguruma/ and download the latest version of Oniguruma. (as of this writing, 5.9.1) In terminal, cd to the directory you downloaded the tarball to.Un-tar it: tar zxf onig-5.9.1.tar.gz Change to the directory of the un-tarred stuff:cd onig-5.9.1 Configure it, in most cases, just add the PATH you use, normally, /usr/local ./configure --prefix=/usr/local After that’s finished, sudo make and then,sudo make install
 Now, you can install that oniguruma gem with no trouble! Same goes for textpow and ultra edit. 

With the recent update to OS X Leopard, 10.5.2, RubyCocoa has been updated (0.13.2) as part of the update as well! This shows that Ruby is being taken somewhat seriously at Apple. (I say somewhat because there is not a bigger effort afoot… but it’s good and getting better.)Now, I just encourage more people to try it and use it, so that it gains more momentum and attention. This in turn will convince Apple management to put more into it! 

Only two days remaining on the MacHeist event for this year! Get it while the getting is good! It’s only $59 USD for the whole package of software and it’s worth that just for the wonderful app SnapzProX2, which I’ve wanted for years! That’s the app that you can use to create your own screencasts and video tutorials. The whole package is cheap. Best of all, the money goes to charity. You can even pick and choose the charity/charities from the list that you want your money to go to!!! How cool is that?!I think I’m going to be doing some serious screencasting in the coming future…