[comp.sys.amiga] Egad!! Its done!!

crunch@well.UUCP (John Draper) (11/25/86)

                     ALL ABOUT THE GADGET EDITOR
		                 or
	              "Egad!! Its almost here!!
                     ---------------------------
		           by John Draper
		         Programmers Network
		       

  On Sunday,  I went over to Ray Larson's place in Berkeley and physically
recieved his latest changes,  on Monday,  found and fixed a few nasty
bugs,  then hacked on it making lots of strange gadgets, control panels
and lots of strange looking goodies that you can control with the mouse.
We made a spiffy looking Graphic Equalizer for sound.   Later,  I made
a nice looking Oscilloscope, and a few audio control panals.  

  So,  it looks like tonight is the final release night for EGAD, the
spiffy little utility to ease your programming headaches.

  Ray Larson has left for a week,  and he was the one that put the final
touches on it.

  It's not perfet yet,   but good enough to be called Ver 1.0.   There
are things that can crash it,   but if you are careful and save your
gadget set ocassionally,  it will do good for you.   There are things
that we haven't checked yet,  like asking it to read in a 4 bitplane
gadget set when we entered it specifying 2.   At the last moment,  we
decided to add more than 2 bitpanes.   We can now have up to 4.


  Starting it up,  at the CLI,  type "egad <number>" where "number"
specifies the number of bitplanes you want.   If you omit the number, the
default is 2 bitplanes,   then when you enter, you will get an empty
window.   Using the menu options,  select the type of gadget you want,
set the Activation and gadget flags,  also the propinfo flags if
appropriate,  then using the RIGHT menu button,  we draw out the rectangle
specifying the gadget.   Point to lower right to re-size it,  or put
cursor within window, press RIGHT button to move it.    You can make
as many of these "outlines" as you like.  They only specify WHERE the
gadgets go.    To make them gadgets,  you "Add new gadgets" using the
"utility" menu.   This makes it easy to make a lot of gadgets that
are the same.    We plan on adding CLONE GADGET as a future enhancement.

  It has a very nice self contained Image editor that can be linked
into your OWN code that allows image editing.   Upon exit,  it returns
a pointer to the Allocated Image and associated data.   Other routines
include converting Image to Bimap.    The image editor allows line draw,
pencil draw,  box draw,  and circle draw,  and box fill.    The Image
editor has it's own menu set and remains active until we return the
image.   The Image editor entry allows editing of an existing image
by passing it's structure pointer,  or if NULL is passed,  it edits a
new image.   Ray Larson did all this nice code.

  The IntuiText Editor allows font selection,  text type ie: slanted,
bold,  etc,  and you can set the forground and background pens.   Text
is actually displayed as you set them.   Actually,  the Gadget editor
edited it's own nice IntuiText Requester panal that allows all
this to happen.    When you exit the IntuiText editor,  you have this
funney text stuck at the end of your cursor.   You move the cursor and
the text to where you want it,  then press the left mouse button when
you want to "stick" it there.    You can have more than one IntuiText
and can change them at any time.    You can save as many Gadget set files
as you like,  they are VERY COMPACT and large sets of gadgets usually
are less than 5k in size.    You normally won't have to "Save as Source"
until the very end.   It can be done at any time.   The source that you
get is a separately compilable module that can be fed to the Manx C
compiler.    All you need to know are the Gadget names.   It's also
smart enough to add the #include's for all the appropriate header files
that know about the Gadget stuff.   It also has "fontinfo" structure
according to your IntuiText needs.    Here is the sample output for 
the Graphic Equalizer I talked about earlier.    None of this code was
generated by a human.

/**********************************************************************
 *                    Gadget Structure Definitions
 *
 * The following structures were defined using the Gadget Editor created
 * by the Programmer's Network.
 * The credits for the Gadget Editor are:
 *
 *     John Draper    - Initial design, coordination, and integration.
 *     Ray Larson     - Images and Intuitext.
 *     Brent Southard - Saving and restoring gadgets in binary form.
 *     Dave Milligan  - Gadget Editor Main menu.
 *
 *
 **********************************************************************/
 
/*  The header files needed for gadget definitions  */
#include <intuition/intuition.h>
#include <intuition/intuitionbase.h>
#include <libraries/dosextens.h>
#include <graphics/gfxbase.h>
#include <graphics/gfx.h>
#include <graphics/display.h>
 
#include <graphics/text.h>
#include <ctype.h>
/*  Definitions for Gadget ID numbers               */
#define  LO1GAD   0
 
/**********************************************************************
 *  Text attribute structures used in rendering IntuiTexts
 **********************************************************************/
 
 
char def_font[] ="topaz.font";
 
struct TextAttr TxtAt_Plain = { (UBYTE *)def_font, 8,
        FS_NORMAL, FPF_ROMFONT};
 
struct TextAttr TxtAt_BIU = {(UBYTE *)def_font, 8,
        FSF_BOLD | FSF_ITALIC | FSF_UNDERLINED, FPF_ROMFONT};
 
struct TextAttr TxtAt_BU = {(UBYTE *)def_font, 8,
        FSF_BOLD | FSF_UNDERLINED, FPF_ROMFONT};
 
struct TextAttr TxtAt_BI = {(UBYTE *)def_font, 8,
       FSF_BOLD | FSF_ITALIC, FPF_ROMFONT};
 
struct TextAttr TxtAt_B ={(UBYTE *)def_font, 8,
       FSF_BOLD, FPF_ROMFONT};
 
struct TextAttr TxtAt_IU ={(UBYTE *)def_font, 8,
       FSF_ITALIC | FSF_UNDERLINED, FPF_ROMFONT};
 
struct TextAttr TxtAt_I ={(UBYTE *)def_font, 8,
       FSF_ITALIC, FPF_ROMFONT};
 
struct TextAttr TxtAt_U ={(UBYTE *)def_font, 8,
       FSF_UNDERLINED, FPF_ROMFONT};
 
 
/***************************************************************/
/*  The following data structure contains the image data  */
/***************************************************************/
USHORT loimage_dat[]=  {
  0x0000,
  0x0000,  0x0000,  0x0000,  0x0000,  0x0000,  0x0000,  0x0000,  0x0000,
    <Lots more,  but don't want to bore you>
    
/***************************************************************/
/*  The following data structure defines the image  */
/***************************************************************/
 
struct Image loimage =  {
       0, 16, /* Left, Top */
       62, 22, /* Width, Height */
       4,     /* Depth */
       (USHORT *)&loimage_dat, /* ImageData */
       0xff,  /* PlanePick */
       0x00,  /* PlaneOnOff */
       NULL     /* Next Image */
      };
      
/***************************************************************/
/*  The following data structure contains the image data  */
/***************************************************************/
USHORT sel_dat[]=  {
  0x0000,
  0x0000,  0x0000,  0x0000,  0x0000,  0x0000,  0x0000,  0x0000,  0x0000,
    
   <again lots more>
   
/**********************************************************************
 *  IntuiTexts for the lo1 gadget.
 **********************************************************************/
 
struct IntuiText lo1_Text_0 = {
   1, 0,     /* FrontPen, BackPen */
   JAM2,       /* DrawMode */
   10, -8,     /* LeftEdge, TopEdge */
   &TxtAt_Plain, /* ITextFont Pointer */
   /* The IText */
   (UBYTE *)"50-100",
   NULL
 };
 
/**********************************************************************
 * Proportional gadget info for the lo1 gadget.
 **********************************************************************/
 
struct PropInfo lo1_prop_1 = {
   /* Flags                     */
   FREEVERT | KNOBHIT,
  0x0000, 0x0000,   /* HorizPot, VertPot     */
  0x1000, 0x1000,   /* HorizBody, VertBody   */
    70,   91,   /* CWidth, CHeight       */
  0x1111, 0x1111,   /* HPotRes, VPotRes      */
     4,    2    /* LeftBorder, TopBorder */
};

/**********************************************************************
 *  Gadget Structure definition for the lo1 gadget.
 **********************************************************************/
 
struct Gadget lo1 = {
  NULL,     /* NextGadget pointer */
  57, 48,    /* LeftEdge, TopEdge  */
  70, 91,    /* Width, Height      */
  /* Gadget Flags */
   GADGHNONE |  GADGHIMAGE |  GADGIMAGE,
  /* Activation Flags */
  RELVERIFY | FOLLOWMOUSE,
  /* GadgetType */
  PROPGADGET,
  (APTR)&loimage,     /*  GadgetRender */
  (APTR)&sel,    /* SelectRender */
   &lo1_Text_0,  /* GadgetText */
  0x0,    /* MutualExclude */
  (APTR)&lo1_prop_1,   /* SpecialInfo */
  LO1GAD,    /* GadgetID         */
  0xc     /* UserData Pointer */
};
 
   As you can see,  the code is commented,  and in about 10 minutes,  any
idiot can generate 80k of text file to feed to your C compiler,  and
it should compile it with NO ERRORS (unless EGAD has some bug we haven't
found yet).

   Tommorrow,   I plan on using EGAD to generate all my gadgets for my
commercial product,  and if I don't find anymore bugs,  I will mail it
to Fred Fish to include in his library.    The WELL will get all 20
of the Source modules and Usenet will get them if the sites won't
object because of the large volume of text.    Then Compuserve and BIX will
get it.   And Cm on,  UseNet folks please inform me if it's OK to post 
the Source???   Remember,  it's 20 modules of Source code.   And EGAD
will ONLY work on 1.2 release,  and compile under Manx 3.30c or better,
and I don't know what Lattice will do after it "eats" it.    And Cm'on
Amiga and hurry up and get the 1.2 in the stores.

   So,  Egad!  Egad is done... EGAD!!  Where did all those Gadgets
   come from.....EGAD!!  Where did all this code come from,  EGAD??
   
   
Crunch:  Programmers Network,  the Glogal Village Idiot....
WELL: crunch
BIX: crunch
UUCP: .....ihnp4!ptsfa!well!crunch
CIS: 76703,4322


   

dillon@CORY.BERKELEY.EDU (Matt Dillon) (11/26/86)

	Post it!  Post it! 5 votes from me to post it!  Actually, 20 source
modules may be a bit much, especially considering that this is only V1.00.

	Probably the best way to go about it is to post the UUENCODED 
executable.  There is no doubt that once you release it to the masses, most
of the as yet undiscovered bugs will come to light within a couple of weeks.

	Then, after about a month, you can post a completely updated source.

					-Matt

james@uw-atm.UUCP (11/27/86)

In article <2117@well.UUCP>, crunch@well.UUCP (John Draper) writes:
> ... The WELL will get all 20
> of the Source modules and Usenet will get them if the sites won't
> object because of the large volume of text.
> ...   And Cm on,  UseNet folks please inform me if it's OK to post
> the Source???   Remember,  it's 20 modules of Source code.

The gadget editor sounds great.  The customs on posting large items to usenet
would indicate that you could post a program if its size is M KBytes long
and there are N interested folks where N*3 > M.  Of course this is just my
estimate based on listening to various flames and discussions on the net.
The constant 3 will presumably cause some people to raise their eyebrows!

Since net.micro.amiga was one of the most widely read newsgroups before the
change over to the new naming scheme, I suggest that there may be enough
interested listeners that you should post (translation: I WANT IT!).
(Of course, I don't know how big the program is because I have no idea how
big a module is.)

james.
-- 
---------------------------------------------------------------------------
James M Synge @ Dept. of Atmos Sci, U of Washington (@ DEC in NH, January)
VOX: 1 206 543 0308 (W)   UUCP: uw-beaver!geops!uw-atm!james
     1 206 455 2025 (H)   ARPA: geops!uw-atm!james@beaver.cs.washington.edu

dave@uwmcsd1.UUCP (11/28/86)

> 
> 
> 	Probably the best way to go about it is to post the UUENCODED 
> executable.  There is no doubt that once you release it to the masses, most
> of the as yet undiscovered bugs will come to light within a couple of weeks.
> 
> 	Then, after about a month, you can post a completely updated source.
> 
> 					-Matt
I second Matt's suggestion. 
-- 
The views above are those of my keyboard, not my organization.
Dave Rasmussen c/o Computing Services Division @ U of WI - Milwaukee
Internet: dave@csd1.milw.wisc.edu  Uucp:  uwvax!uwmcsd1!dave
Csnet:	  uwmcsd1!dave@uwm	   Phone: +1 (414) 963-5133

karsh@nicmad.UUCP (11/28/86)

In article <2117@well.UUCP>, crunch@well.UUCP (John Draper) writes:
> ... The WELL will get all 20
> of the Source modules and Usenet will get them if the sites won't
> object because of the large volume of text.
> ...   And Cm on,  UseNet folks please inform me if it's OK to post
> the Source???   Remember,  it's 20 modules of Source code.

  It doesn't really matter how many modules of source code you post.
What matters is how many kilobytes you post.

  Traditionally on Usenet, the various modules of source are
combined together into a "shar file".  (SHell ARchive file).
Lots of versions of shar have already been posted.  You can
probably get a copy from the mod.sources moderator.

  It is a good idea to limit the size of the individual shar files
to about 60k bytes or less.  Then rather than posting all the shar
files at once, post one per day.  In this way, you reduce the
"instantaneous load" that your posting puts on the net.

  I suspect that if Egad! is posted as twenty seperate parts
in one day, there will be lots of flames.  If it is posted as
two or three shar files over two or three days, the number of
flames will be significantly reduced.

                       Bruce Karsh
                       {ihnp4,uwvax}!nicmad!karsh