barnett@grymoire.crd.ge.com (Bruce Barnett) (02/01/91)
In article <981@borg.cs.unc.edu> lusk@hilbert.cs.unc.edu (John Lusk) writes: Followup-To: lusk@cs.unc.edu Followup should be a newsgroup, not a mailing address. > Ok, ok, thanks for all the mail regarding Macintosh vs. X windows. I > feel like I tried to get a drink of water at a fire hydrant. Let me > refine my question a little: Macintosh vs. XView. Most of the > complaints about X had to do with the grunginess of Xlib and Xt. Can > anyone compare the Mac Toolbox to Xview? Well, I can try. Take an XView panel, with text and a scrollbar. (I'll simplify it somewhat.) There are only a few procedures you need to learn: xv_init(); xv_create(); xv_destroy(); xv_set(); xv_get(); Use xv_create() to make a new object. The first argument is the parent object (a pointer), the second argument is the thing you want to create. A list follows with optional arguments. It is terminated by a NULL: frame = xv_create(NULL,FRAME,NULL); To create a panel in the window, use: panel = xv_create(frame,PANEL,NULL); To create a button in the panel: button = xv_create(panel,PANEL_BUTTON,NULL); Notice how the toolkit will fill in the necessary defaults. In the case that you want to change the defaults, just specify them. You can do it at create time, or use the xv_set() command. button = xv_create(panel,PANEL_BUTTON, PANEL_LABEL<STRING, "Label", /* the label */ PANEL_NOTIFY_STRING, pushed, /* where to go when pressed */ NULL); You can create a large panel with several types of items. Sliders, choices, numeric items, etc. Once you get done, you call a procedure to get everything going. The user can select different items, choices, scrollbars, etc. The toolkit does everything. That's right, you don't have to do any code for this. The toolkit runs the show. How do you get the values and do something with them? With xv_get(). The button event procedure (called when the button is pressed) can get the current value of each of the items on the panel. Or, if you want, you can handle each event yourself and make it do something special. Like check each event to see if it is correct, make other panel items visible, etc. The toolkit picks a reasonable position for each item in the panel. If you want to, you can override the defaults. But you don't have to. The idea is - get it working first. Tune it once you have it working by changing the defaults. You don't even have to know about the options until you find yourself with the need for that option. And when it comes to events, you tell the toolkit which events you want to worry about, and which ones you want to ignore. Your event handler only sees the events it is interested in. If you don't want to handle keyboard events, you specify this. Same with mouse events. And all of this is documented in the XView book. One book. Well, if you want to draw some graphics - you use the XLib manual. Let's look at this from the Mac toolkit. Also assume you are using Think C. What book do you get? Well, the Macintosh Programming Primer Volume 1: "Inside the Toolbox using Think C". And you also want Volume II. But that doesn't tell you everything, so you need to buy all 5 Inside Macintosh volumes. But this is still confusing so you end up buying Macintosh Revealed, Volumes 1-4. That's eleven books. Then you try to read this stuff, and you keep finding out that routines described in Inside Mac Vol 1 are obsolete. And the routines in Inside Mac Vol. 3 have been enhanced, so you have to read the new sections in Vol. 4 and Vol. 5. Oh - you may want to buy Inside Mac XRef book. Now when you finally have prepared yourself with the 12 books, you now find out that the toolkit does very little. When the user clicks on the scrollbar, you have to figure out how to redraw the text or graphics yourself. You have to handle the events. If you aren't interested in a certain event, you must pass it thru. And you better do it right! Mouse up, mouse down, keyboard presses. And if the mouse down occurs outside of your window, you must pass it to the window underneath. Because the application whose window is in the front gets first crack at all of the events. But hey, it's just my opinion. -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett
claytor@tandem.physics.upenn.edu (Nelson Claytor) (02/01/91)
In article <BARNETT.91Jan31134827@grymoire.crd.ge.com> barnett@grymoire.crd.ge.com (Bruce Barnett) writes: > Well, I can try. Take an XView panel, with text and a scrollbar. (I'll > simplify it somewhat.) [stuff about simplicity of XView window creation deleted] [more stuff about complications of THINK C deleted] OK, now let's try it with MacApp. What routines do you have to know? Essentially none, if you want the "working application that does nothing" described. Use the 1 1/2 pages example program that initializes the MacApp routines and the toolbox. Now use the application called ViewEdit that is included with MacApp, and *draw* your window's interface. Then you have a working program that does nothing. My observation on the subject would be that I have yet to see an X program with an interface anywhere near as nice as the typical Mac application's, so how easy could it be? (Word is specifically excluded here >:-)) The object oriented approach described in the original message has been implemented in the forms of both MacApp and the THINK class library. No one *has to* know every last toolbox detail any more, or even how to do scrolling. Nelson Nelson Claytor claytor@tandem.physics.upenn.edu
barnett@grymoire.crd.ge.com (Bruce Barnett) (02/01/91)
In article <36715@netnews.upenn.edu> claytor@tandem.physics.upenn.edu (Nelson Claytor) writes: > OK, now let's try it with MacApp. Okay, and while we are at it, try DevGuide, IBuild, TAE+, or any of a dozen other UI builders for X. I would be interested in anyone comparing these with MacApp. > My observation on the subject would be that I have yet to see an X program > with an interface anywhere near as nice as the typical Mac application's, I can give you a list of 100 things wrong the the Mac interface. :-) But let's save that for talk.religion.user-interfaces. > The object oriented approach described in the original message has been > implemented in the forms of both MacApp and the THINK class library. No > one *has to* know every last toolbox detail any more, or even how to do > scrolling. Remember - I was answering John Lusk's specific question. How many books does a beginner need to do serious programming with MacApp? I assume you are saying Inside Mac Vol 1-5 aren't needed? Hmm. I have a MacApp book in front of me. In fact, I have a whole shelf from the E. T. O. CD-ROM. I'm not to sure which of the 6 3-inch Binders I have to read first. Are you sure this stuff is simple? :-) :-) -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett