Tag: mac

Apple has always insisted that their users are not smart enough to handle more than one button on their mouse. So, people promptly replace their Apple mouse with one more efficient. I myself use a Microsoft IntelliMouse Explorer 4 on my Mac Mini (I use the same one with Windows, too).

Well, if the news of Apple switching to Intel processors, after years of claiming Intel’s processors were inferior to PowerPC chips (which was never true), now Apple is adding more buttons to their mouse. Either Apple has decided that their customers’ IQs are rising and realized that if they can operate a car with more than one pedal they can click more than one button, or they finally got with the 21st century and made a decent mouse.

Although, after looking at pictures of the new mouse, one wonders if they simply don’t understand how a mouse is used. Oh well, looks like I’ll be keeping my trusty IntelliMouse for a few more years, even on the Mac Mini.

Everything is a learning experience.

I’ve blogged here previously about being impressed with Apple’s development tools for Mac OS. I have been working with XCode and Interface Builder, using the Cocoa Framework. After several months of development, here is what I have learned.

The initial shine of XCode and IB has worn off. In the beginning of my development work on SwordSearcher Mac, I was primarily writing my “database” code for the Bible, commentary, dictionary, and book storage, search, and access functions of the program. This basically meant that I was enjoying coding stuff in Objective-C –- a language I find that I really enjoy working with. But it also meant I was not doing much of the user-interface design and didn’t have to work with Interface Builder much.

Well, I finished most of that “database-ish” work and moved on to creating a user interface for Bible display and other stuff. What happened? Well, it’s kind of like seeing a really pretty woman, then all of the sudden she pulls out a cigarette and lights up. Not attractive.

Apple’s development environment is practically in the dark ages when it comes to “rapid application development.” Maybe I am just spoiled with Delphi, but really, when I put a button on a form, I want a property list and want to be able to start writing an event handler for that button with a double-click. With XCode and IB, you simply can’t do that. The amount of hand-holding you have to give the IDE is absurd in comparison to Delphi. And it’s not just Delphi – I’ve used Visual Studio 2003 a bit, and I get nice, easy-to-work-with property lists with my UI components there, too.

The reality is that even though I have already put several months of real, nose-to-grindstone development into SwordSearcher Mac, bumping up against this fundamental weakness of the development environment means that continuing down this path will make me a frustrated, inefficient developer. It’s not that it’s hard –- it isn’t. But when I am developing SwordSearcher on Windows, I can be fast and efficient and write good code. I don’t have to waste time manually connecting methods to events, write IBOutlet and IBInlet, etc, when I should be able to just code the function! Switching between Windows and Mac development has become too much of a “shock” and I just don’t want to deal with it.

What does this mean? Am I abandoning SwordSearcher Mac? NO!

There is a nice little company called REAL Software that makes a cross-platform, visual development environment called REALBasic. With REALBasic, I can drop a button on a form, and, (imagine this), look at a list of all of the properties of that button, and click an item to write the code to handle events! Sound familiar? Delphi has been doing that for Windows developers for over a decade.

So I am going to give REALBasic a try. My preliminary plans are to design a new version of Daily Bible and Prayer in REALBasic – this way I can learn the language and the environment with a smaller project. I have lots of things I want to do with DBAP – and with REALBasic I will be able to write it for Windows, Mac, and Linux all at the same time. No more duplicated effort.

Then, once that is done, I will come back to SwordSearcher Mac. I am really committed to doing a Mac version of SwordSearcher –- but I want to enjoy the work. Using a more Delphi-like IDE will let me enjoy coding without feeling like I have one hand tied behind my back by an antiquated development paradigm.

What this means for SwordSearcher Mac is a delay. Not a delay of Longhorn proportions, but a delay nonetheless. Now I am looking at late 2006 for SwordSearcher Mac. And of course, development of the Windows version of SwordSearcher will continue in Delphi for the foreseeable future.

So, off to work I go! I will keep this blog updated as time progresses.

Apple expected to switch to Intel chips – Uh, excuse me?

I’ve really been enjoying writing code for the upcoming Mac OS X version of SwordSearcher. I’ve passed a few self-placed milestones in the code and I am progressing about as quickly as I had hoped to. I have people lined up for beta testing. My understanding of Cocoa (the framework for programming Mac OS X) has hit critical mass and I am able to think out problems in my head without having to refer to reference books.

Imagine my surprise when I read that Apple is now planning another architecture shift.

I really, really don’t understand this move. According to some recent news stories, Apple has actually managed to increase its desktop computer market share recently. They are on the right track. Now it looks like they are set to undo the progress and success of OS X.

The problem with a fundamental architecture shift, like switching from Power PC chips to Intel chips for the central processing unit, is that it will require all existing programs to be re-compiled for the new chips. As someone who has just invested a lot of development time on the current archetecture, I am not pleased.

I can only hope that XCode will allow me to easily cross-compile for both archetectures. In theory, this shouldn’t be too much of a problem — the underlying compiler is already cross-platform. As long as Apple takes care to make the frameworks the same on the new system, we (developers like me) just might be spared the agony of platform migration. But all programming is as much an archane art as it is science, and these kind of changes inevitably cause problems for developers, and by extension, end users.

For now, I will continue my development work as I have. But I do have to admit to being a little bit disheartend at Apple’s move. I can tell you one thing for sure: if I had read this news late last year instead of this month, I would have had a much harder time convincing myself to embark on this new Mac adventure of mine. No doubt other developers will feel the same way, which is not good for Apple.

Since I am keeping busy with programming on the Mac, I haven’t had much time to update my progress on the blog. Much apologies to those of you who have emailed me asking me for more information.

Anyway, I wanted to write a small update.

On Windows, I use a program called Wnbrowse to view the contents of any file on my hard drive in hex or ascii. This is quite useful, as I design my own data file formats for SwordSearcher and like to look at the raw data in a file I have generated while doing so.

I had to find an equivalent for OS X because Finder (the Mac equivalent of Windows Explorer) doesn’t include a “hex viewer.” After a little searching, I found Separator. It’s not quite as good as Wnbrowse for my use (I like how Wnbrowse lets me show any file as if it were a text file), but is good enough. Until I found this program I was doing things a really awkward way: I would use my Windows machine to browse my Mac hard drive and use Wnbrowse to view the files I wanted to see over the network. Obviously, using a native Mac program is a better solution.