ns@CAT.CMU.EDU (Nicholas Spies) (01/23/88)
A suggestion for another HyperCard object: graphics fields.
If backgrounds were retained as they are now but all foreground ("card")
graphics were drawn on graphics fields that could be moved around, resized,
made opaque or transparent, copied, pasted, etc HyperCard would even be
MORE fun to work with. Compatibility with current stacks could be maintained
by automatically opening them with one card-sized graphic field per card
containing the current foreground graphics.
Graphics fields would greatly simplify layout and animation and would be
consistant with the object-oriented flavor of the HyperCard evironment.
Nick Spies
Center for Design
of Educational Computing
Carnegie Mellon Universityt-jacobs@utah-cs.UUCP (Tony Jacobs) (01/28/88)
I have found a need in a number of cases for a foreground as apposed to a background. In some cases I have wanted a field which changes each time you enter a card. I don't need or want to use the extra space that a background field uses. What I did was use a button as a field. Background buttons don't normally contain different information from card to card where as a background field does and it uses up more space for more cards. I'm thinking this forground would be global to the whole stack and not something you use as a template space for a database like the background is. You could use this forground to do special filters for any kind of object. The background has this ability but only if the message gets passed on to it. The forground would be the first layer in all message paths and could thus intercept anything, do it's filtering and then pass the message on. -- Tony Jacobs * Center for Engineering Design * U of U * t-jacobs@ced.utah.edu