Progress slow but steady...


(No new build yet, but probably by Friday or week-end)

Someone asked me off-list if I had been so badly bitten by Marten—meaning either overwhelmed or extremely taken with it, I assume—that I had forgotten all else.

Nay, nay, not so!

Honestly, I haven't spent that much time messing around with it yet. After determining that the CPX section file import more or less works (for anything (as yet) unsupported in Marten, you either have to figure out a work-around or abandon the code; I used the format primitive in a few non-vital places, some time related externals, etc., so I would have a bit of recoding to do to get my CPX File Importer classes to work in Marten), I also determined that the C export is nothing that is probably going to be of use to me (at least not in the immediate future). And with that my interest flagged somewhat.

While it is nice to use an OSX IDE currently more mature than PhoEdit3/Phoenix to program visually (or graphically, as they would have it) again, I have to admit that it has been nearly a year since I have done anything using CPX more extensive than checking case coding/editing behavior and UI layout. The rest of my programming has been done using Project Builder/Xcode and Interface Builder.

I would like to give Marten more of a trial run; I mean, I've already learned some things and gained some valuable pointers about how I would rather do things in Phoenix/Vcode. But I am finding myself loathe to return to an environment which is constrained by the (application building & class editing) framework which has (thus far) been made available.

In Phoenix, I don't want my Cocoa App Project Window cluttered with a bunch of sections for the Cocoa, Foundation, or AppKit classes (or a Section Window full of those classes)—how many hundreds are there? I want an alias-type graphic indicating the framework is to be linked in. Period. (Naturally, including a function later where clicking this alias to reveal what classes are included and what attributes and methods are available in each class would be helpful, but we will have to find a way to generate this on the fly, showing the information in the header files in graphical format, just as Xcode will show you the content of header files for Foundation & AppKit. I have no intention of trying to recode Cocoa visually.)

Also, I am considering not automatically displaying inherited attributes in subclasses. Including a way of displaying the attributes of the parent class, yes, of course, but not including them in the subclass attributes window. This constitutes another divergence from the Prograph CPX way of doing things, but I'm not convinced yet it will be a major problem: I program in Xcode without all this extra information almost daily.

Anyway, I hope to have the next build uploaded by Friday night (my time); updating the source file in downloads may take a while longer.

(There, now you've a new entry to attach the comment chain to! : )

Posted: Tue - January 25, 2005 at 02:56 PM           |

©