Conference hydra::amiga_v1

3724.0. "WB 2.0 programmer info!" by WJG::GUINEAU () Thu Apr 26 1990 09:37

Article 11735 of comp.sys.amiga.tech:
Path: shlump.nac.dec.com!decuac!haven!uflorida!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!cbmvax!peter
From: [email protected] (Peter Cherna)
Newsgroups: comp.sys.amiga.tech
Subject: Re: GUI interfacing
Message-ID: <[email protected]>
Date: 25 Apr 90 15:53:14 GMT
References: <[email protected]>
Reply-To: peter@cbmvax (Peter Cherna)
Organization: Commodore, West Chester, PA
Lines: 158

In article <[email protected]> [email protected] (Eric Giguere) writes:
>
>If anyone has read this month's issue of Computer Language magazine (the
>one with Ken and Barbie on the cover --- no, I can't explain it either) they
>would have noticed my comments on the Amiga's GUI:
>
>	 "The GUI basics are all there, but the programmer must specify
>	  a lot of details to build his or her own gadgetry for higher-level
>	  items such as radio buttons and list boxes.  This approach has
>	  its advantages (flexibility, for example) but has also led to
>	  inconsistency among applications."  
>
>I don't think anyone who has ever tried to write serious Amiga software
>will dispute this statement.  If they're anything like me, they get frustrated
>quite quickly by the low-level support the Amiga offers for programmers.
>What we need are a set of programming toolkits AND a set of firm style
>guidelines for the Amiga.

Now that the A3000 and Workbench 2.0 have made their debut in New York,
I can explain a bit what we've achieved in software in terms of user
interface toolkits.  I think you'll find it meets many of your needs
(we can never presume all).

2.0 includes the gadget toolkit, which is a shared Amiga library
(gadtools.library), which allows the programmer to easily create
about a dozen kinds of standard, easy-to-use, well-behaved gadgets
with a minimum of effort.  As well, there is extensive menu support.

The kinds of gadgets that gadtools allows you to create include:

	Simple buttons ("OK", "Cancel", etc.)
	Checkboxes
	String gadgets
	Integer string gadgets
	Mutually exclusive choices
	Cycle (multiple-way toggle) gadgets
	scrolling lists
	color selectors
	scrollers (for moving through an area, such as a list or window)
	sliders (for indicating a level, such as brightness or volume)
	read-only text displays
	read-only numeric displays

The advantages of these standard classes are numerous:

You can get your application up and running much faster, without having
to become a gadget wizard.
Your application will have well-behaved gadgets.
Your code size will be reduced.
Your application will gain the new look that we've introduced in 2.0,
giving it a greater consistency with the rest of the system and
other gadtools applications.

Allow me to give an example of the ease of use we give you.

Say you want to have a proportional gadget that runs from 1 to 20
to indicate something in your program (like volume or speed).  Say
the initial level is 10.

The call to gadtools would be something like

	gadget = CreateGadget(SLIDER_KIND, previous, newgadget,
		GTSL_Min, 1,             /* minimum level of slider */
		GTSL_Max, 20,            /* maximum level of slider */
		GTSL_Level, 10,	         /* initial level of slider */
		TAG_DONE);

Note well how you ask in "programmer-friendly" numbers.  Inside
gadtools, these are converted to Intuition Body and Pot values, which
aren't programmer-friendly, but you don't have to care, because you
never see them.

This unusual calling construct (seen on some other systems) is an
example of a tag-based function.  The CreateGadget() call has three
required parameters (a gadget kind indicator, a pointer to the
previously created gadget, and a gadtools NewGadget structure
- which contains some basic dimension and labelling info),
and then takes any number of (tag,value) pairs, followed by a
special terminating tag (TAG_DONE).  An example of a tag-pair is

	GTSL_Min, 1,

which says that the minimum level for this slider should be 1.

There is no limit to the expandability of the tag-based interface,
so you specify just the tags you need, and the other ones you
don't supply can have reasonable default values.  It also allows
us to add new tags later without breaking anyone, nor having to
define extended structures or new entry points.  For example,
the slider kind also supports a running display of the current
slider level (updated in real time as the user drags the slider).
Two more tags are needed, one to specify the sprintf()-style
formatting string used to print the level, and the other to
specify the maximum length of the resulting string.  As in:

	GTSL_LevelFormat, "%ld",
	GTSL_MaxLevelLen, 2,

You would end up with a slider something like:

	   .....................
	   .       XXX         |
	10 .       XXX         |
	   .       XXX         |
	   ---------------------

We also make your life easier on the message receiving side.  GadTools
provides filtering and massaging functions for IntuiMessages to give
you "cooked" IntuiMessages that are more informative.  For this gadget,
you only hear MOUSEMOVE's when the level (1-20) actually changes
(also on GADGETUP/DOWN if you wish).  So as the user slides the knob,
you only get up to 19 MOUSEMOVEs.  Better yet, you may look in the code field
of the "cooked" IntuiMessage to find the new level (say 11) of the slider.

So the fact that it all works with fancy calculations on Body and Pot
is carefully hidden from the programmer.

Performance-wise, the gadgets are very well behaved.  The slider is
no exception, and one good example of what we mean is that when the
user releases the mouse, the slider immediately snaps to the exact
position for the current level.  Since the slider has a knob that
can travel continuously, but a level that changes discretely, this
will prevent the complaint that "I set each of red, green, and blue
to twelve, but why aren't the knobs in exactly the same place?"  This
snap to level corresponds very well to real-world controls that have
"detents" - think of the slider in your car that has settings for
defog, face, face/feet, and feet.

The slider is typical of the kinds of gadget that gadtools provide, as
far as ease of use and so on.


As far as menu-building goes, the gadtools menu routines create and
layout (in a font-sensitive way) your menus, including calculating
all widths and heights, adding sub-menu indicators as necessary,
positioning menus and sub-menus, moving menu panels to stay on screen,
going to multiple-columns if your menus get too tall, etc.

So gadtools sits on top of and complements Intuition.  At the
Intuition level, there are some very exciting gadget enhancements
for those who want to roll their own.  Custom gadget technology
and an object-oriented interface means that people can design gadgets
with much greater control than ever before.

So the answer is yes, we now have an official user-interface toolkit.

>--
>Eric Giguere                                  268 Phillip St #CL-46
>C'est un nom francais, bien sur               Waterloo, Ontario  N2L 6G9
>Bitnet  : GIGUERE at WATCSG                   (519) 746-6565
>Internet: [email protected]         "Nothing but urges from HELL!!"

     Peter
--
     Peter Cherna, Software Engineer, Commodore-Amiga, Inc.
     {uunet|rutgers}!cbmvax!peter    [email protected]
My opinions do not necessarily represent the opinions of my employer.
"Taking care of business... and working overtime"