Dialog Box

Edited by Neil Ticktin, Editor-in-Chief

Where’s the GUI?

I was disappointed in the articles on Bedrock in the July issue of MacTech; they imply the same old paradigm of line-after-line coding and editing. Much was made of a different factoring of the code libraries available but said nothing about the programmer’s interface.

If Bedrock is such a dramatic improvement, where is the GUI for programmers a la Prograph, AppMaker, Resorcerer, or P-G Pro for Future Basic? One article even implied that resources would still be defined by text! In this day shouldn’t programming be mostly by click and drag rather than type, type, type?

From a browser shouldn’t the programmer be able to click on an object and see its definition (as in Think’s compilers now), click on a method and see its code? From a method shouldn’t the programmer be able to click on a variable and see its definition or click on a method or procedure name and see its code?

For design, shouldn’t a programmer be able to create a window object by drawing it? Shouldn’t he or she be able to write any special behavior for the object while it is still visible on the screen? Will coding still be files? Change a definition in one file and wait to compile dozens of other files dependent on that file though not necessarily that definition? Or will Bedrock have a dictionary of objects, variables, and so on where only the objects that use the item are recompiled?

Will the programmer have to jump between files and scroll the lines of a complete file to see attributes and the code of methods? Or will the attributes of an object be in one panel of a window, the list of methods in a second panel, and currently-viewed methods of the object in separate windows which were opened by clicking in the list of methods?

Will coding still be line after line? Will Bedrock have Nassi-Shneidermann diagrams or some other visual paradigm? Will the programmer create a method graphically and be able to expand or collapse its structure to any level of detail? Will the programmer be able to cut and paste pieces of the structure with a simple hand movement or will it still be by selecting great gobs of lines?

Factoring and rich code libraries are great, but the real programming gains will be made when programmers work in the same way that users do.

- Melvyn D. Magree

In regards to
December’s editorial

Neil, from my end I agree. I have been programming on the Mac for only a year. I bought my first Mac in 1992. Since then I have heard about all kinds of new things coming out for the Mac. I want to get into it all, but it’s overwhelming.

A friend of mine just bought a new 486DX and he couldn’t get a simple mouse to function because of incompatible drivers. Every time he gets some new software he’s got loads of problems to fix along with it. Also, I’ve seen the books that come with Visual C++ - what a nightmare! Anyway I’ll stop now, but I completely agree. Yes we need the power but simplicity can be built in.

- MAtza via America Online

Your December editorial

Neil, I just read “The Editor’s Page” in the December issue of MacTech Magazine, and I just want you to know that I support you fully! I don’t know if you follow any of the Internet news groups, but the same kind of anger/frustration towards Apple are being expressed there. In my opinion it is time to really shake the foundations of “developer support” at Apple. Put Spindler up against the wall, and don’t let him go until he has given clear answers to a lot of questions!

- Per Lindgren

Agree or disagree?

I am writing this in response to your Editor’s Page in December MacTech. I am a Mac Programmer. The Mac once was a one-man machine: meaning a single programmer could learn the entire Toolbox and write wonderful applications (not huge applications) for the Mac. Those days are gone. There are so many Managers in the Toolbox that you don’t ever think of learning them all. Kind of strange - a feeling that I don’t understand my Mac anymore. It is a half-stranger to me.

Things get complicated as the Mac jumps to System 7. However, I do agree that System 7 is more mature than previous version from the user point of view. And I also agree with you that the development cycle advancement provided by Apple is lagging behind. However I don’t blame Apple. It is a difficult job to add capabilities and maintain backward compatibility at the same time. Many basic concepts in System 7 originated from the original Toolbox, kind of out-dated. System 6 to System 7 is an evolution., which undoubtedly involves patches. I guess the difficulty involved in moving from System 7 to (if there is any) System 8 is even more severe. What Apple needs is a revolution from System 7, not an evolution to System 8.

Apple is trying this I guess. Newton Technology: it opens new grounds that let Apple develop something from scratch. It also has the potential to open up a new market in real personal computing. Although I found the Newton development system is a bit hard to master at first glance from a C programmer point of view, I think its underlying software architecture is more neat than System 7.

Also there is PowerOpen or Pink or whatsoever. Although it is a bit far in the future. I think this is the revolution Apple needs.

I’m just saying what I feel. I don’t know whether I agree or disagree with you? Ha ha! :)

With Regards,

Don’t stop!

First of all, great magazine! Don’t stop! Regarding your editorial concerning Apple’s support for developers, I couldn’t agree more!

I write Mac games, which are by far some of the hardest apps to do on a Mac, and I am constantly annoyed by Apple’s half-hearted efforts towards developer support. Every time I get a new tech note it seems that I find out about something that has changed that will cause me to have to redo a lot of things. I miss the days when you could call up DTS and talk to a person and get serious help without having to fax your question or pay a fortune e-mailing something on AppleLink.

Personally, I feel that Apple should be a little more devoted to supporting its developers. Nobody upgrades their Mac just because an upgrade is available. They upgrade so that their existing software will work harder for them, and so that they will have to power to run the apps of the future. We, the developers, are the future of Apple Computer.

If I have to change things I don’t know where I would start, but some change is in order. Developers are starting to have the same venom on their lips when they refer to Apple as they do when referring to Symantec. Although I don’t agree with every marketing move that Apple makes I still believe that the Mac is The Right Thing. I just wish they could go back to their youthful, enthusiastic days!

My 2¢ worth. Thanx for listening.

- Christopher De Salvo

December Editor’s Page

I must say that I was surprised to read this December’s Editor’s Page, in which you criticize (to some degree) the “programmer edition” of the Macintosh interface.

Yes, there are far more ROM routines than there were one system software version ago (double that, really). But see it this way: that’s code you won’t have to write. As for new technologies - such as QuickDraw GX or AOCE, among many others - you can be sure that without them, Apple would have a very small chance in staying afloat for much more (one can’t dream of Apple surviving on the Apple ][ or Newton). And since most applications require a partial (sometimes complete) re-write of it’s code, changing some of it to accommodate new such technologies is to me nothing but a routine exercise everyone should expect to do at some point. Stagnation is the beginning of the end.

Then there are development tools. Yes, we are fortunate to have tools like Marksman or AppMaker, but I disagree about further “Macintoshing” MPW. Although Symantec development environments can be useful to some, it fails to do a single percent of the things we can in MPW. And that is simply because MPW is the most flexible development platform around. Granted, the price is that MPW is more complicated. But the reward is much greater - easier integration of different elements (languages, for one), endless customizability, greater control over everything, and the list goes on.

- Martin-Gilles Lavoie

Bad tip?

Brett Bibby’s tip on getting menus to look right in Japanese was well-intentioned but wrong. The problem has nothing to do with single-byte characters being read as double-byte ones (interesting theory though). This much is clear from the fact that “close” has an odd number of letters but looks fine in his screen shot, while “open” has an even number, and is followed by the stroke (actually the Japanese character “no”).

The problem is actually one of using high-ASCII characters, like the ellipsis or curly quotes (which caused the Japanese characters “me” and “mo” surrounding the resource names in ResEdit). KanjiTalk can correctly handle low-ASCII characters. High-ASCII are read as what is called “han-kaku ji katakana” (katakana is a 50-character syllabery, hankaku ji just means half-width characters). In fact, KanjiTalk is reading the font correctly as single-byte, it is just mapping the characters differently.

What Brett recommends would fix the problem in Japanese, but at the expense of violating Apple’s interface guidelines in English, which suggest that menu items that lead to dialog boxes should be followed by the ellipsis. Another possibility for the concerned developer would be to use three periods, and avoid high-ASCII characters in general.

- Adam Rice