🚀 go-pugleaf

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