Mar 94 Dialog Box
|Column Tag:||Dialog Box
Edited by Neil Ticktin, Editor-in-Chief
Wheres 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 programmers 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 shouldnt programming be mostly by click and drag rather than type, type, type?
From a browser shouldnt the programmer be able to click on an object and see its definition (as in Thinks compilers now), click on a method and see its code? From a method shouldnt 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, shouldnt a programmer be able to create a window object by drawing it? Shouldnt 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
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 its overwhelming.
A friend of mine just bought a new 486DX and he couldnt get a simple mouse to function because of incompatible drivers. Every time he gets some new software hes got loads of problems to fix along with it. Also, Ive seen the books that come with Visual C++ - what a nightmare! Anyway Ill 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 Editors Page in the December issue of MacTech Magazine, and I just want you to know that I support you fully! I dont 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 dont 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 Editors 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 dont ever think of learning them all. Kind of strange - a feeling that I dont 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 dont 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.
Im just saying what I feel. I dont know whether I agree or disagree with you? Ha ha! :)
First of all, great magazine! Dont stop! Regarding your editorial concerning Apples support for developers, I couldnt 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 Apples 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 dont 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 dont 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 Editors Page
I must say that I was surprised to read this Decembers Editors 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: thats code you wont 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 cant dream of Apple surviving on the Apple ][ or Newton). And since most applications require a partial (sometimes complete) re-write of its 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
Brett Bibbys 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 Apples 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