🚀 go-pugleaf

     One of the important things I would look for in a requester designer is
efficient code generation.  Or, more precisely, efficient data generation.  If
you design a complicated requester (or set menus, thos are often the worst
offenders) you can easily build up 5, 10, even 20K of data.  The Intuition
gadget, IntuiText, MenuItem structures etc. are all marvelously flexible, but
they can take up a huge amount of room.  The menus for one of my programs would
have taken up about 20K on disk for the structures alone (not including the
unavoidable memory used for the text) if I hadn't generated all of the
structures at run time.  Similarly, a requester generation program should at
least have an option for allocating memory for and initializing all of the
gadget structures.  Not very efficient for simple requesters, but if you have a
bunch of complicated ones, they can share the structure generation code and
potentially save a lot of space.

     This is a type of packing.  Removing of redundant information.  If the
gadgets are all widely different, it won't work, because there isn't redundant
information.  But, it usually works.

     The other advantage to this is that it makes it easier to write re-entrant
programs, even multitasking re-entrant programs, since you don't have all of
these Intuition structures in your data segment anymore.

.Bruce Dawson.

     P.S.  The run time library 'req.library', besides providing some useful
requesters (colour requester, file requester etc.) includes some simple gadget
creation routines, handy for just such a task.