Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!boulder!sunybcs!bingvaxu!leah!itsgw!batcomputer!hsgj
From: hsgj@batcomputer.tn.cornell.edu (Dan Green)
Newsgroups: comp.sys.amiga
Subject: IntuiIdeas (long)
Message-ID: <2873@batcomputer.tn.cornell.edu>
Date: Mon, 9-Nov-87 19:07:41 EST
Article-I.D.: batcompu.2873
Posted: Mon Nov  9 19:07:41 1987
Date-Received: Wed, 11-Nov-87 20:36:00 EST
Distribution: comp
Organization: Theory Center, Cornell U., Ithaca NY
Lines: 82
Keywords: Some suggestions for intuition.


I have heard implications that there may be a new version of the
Amiga OS being worked on.  In the off hopes that this is really true,
and that changes have not yet been finalized, here are three
suggestions for new features for the Intuition Library.  I hope these
are not construed as flames on the existing product, but instead as
possible enhancements for a future product.

1) Make Iconify a standard window system gadget.  Window iconifying,
pioneered by DME and intuitionized by WordPerfect, is a very handy
feature.  Currently, you can do it yourself by building a gadget and
putting it in the top border, and converting all GADGETUP events in
it to SizeWindow calls.  However this means you have to manage
repainting your window.  If this was a system gadget, when the window
was in smart_refresh mode, Intuition would know not to throw out the
border if the window was iconified to a smaller size.  For example:
			The + and - define the window that the user
Normal    Iconified	sees.  In the Iconified picture, the S are
+-----+   +-+SSSS	chunks of smart_refresh memory that Intuition
|     |   +-+SSSS	would hold on to, so that when the window
|     |   SSSSSSS	was un-iconified (eg brought back to normal size)
+-----+	  SSSSSSS	the program would not have to repaint the window.
			In this case, iconifying would be completely
transparent to the application.  A NEWSIZE idcmp would still have to
be issued, but the application could ignore it if necessary.  I don't 
think this would break any existing code, because no existing code
sets the (hypothetical) WINDOWICONIFY flag, so no existing code would
have such windows.  New programs would benefit immensely, though.

2) Force CloseScreen() to close any windows open in its screen.  This
has a lot of potential applications.  For example, say you are running
VT100 in its own screen, and would like a clock on the screen.  You
would write a clock program that would open its window on the
Top Screen being displayed.   The clock would function until it got
a CLOSEWINDOW event, in which case it would close its window and exit.
Currently, if you did this but then the VT100 application closed the
screen, clock would have a window with no bitmap memory and bad things
would happen.  If instead, CloseScreen() sent CLOSEWINDOW idcmp's to
any open windows on its screen, and then waited until these windows
all closed, then you could easily do these DA type things without
fear of losing your bitmap.  Again, this would break no existing
code, as current applications all close their windows before closing
their screen, anyways.

3) Have a DEPTH parameter for OpenWindow calls.  This would break
code, but bear with me...  I have an application that opens a 4 bitplane
interlaced screen.  On this screen are 4 windows.  One is a drawing
window and needs the color.  The other three, however, are just text
windows and only need to be one bitplane (eg black/white) deep.  I am
using smart_refresh for all windows, which means that Intuition has
to keep a lot of 4 bitplane memory allocated to buffer these overlapping
windows.  I would like to be able to specify that these windows are only
using the top bitplane, and then Intuition would only keep 1 plane of
memory allocated to buffer the windows, resulting in much less ram
wasted.  I realize I could use simple_refresh and do all the buffering
myself, but that's really not as good, because if my program is busy
"computing" and cannot look at the IDCMP stream, then I don't see that
my window needs to be redrawn.  If Intuition handles this then it is
all transparent and looks nice.  Smart_refresh windows are fantastic(!!!)
but I'd like to set the depth to conserve memory.

A couple of unrelated notes:

o	I remember a while ago someone mentioned that to find out if
	a given screen was in Interlace or not, they looked at the
	screen height, and if it was >200 then that implied interlace.
	Someone else responded that they better check for >256 in the
	case that their software was running on PAL systems.  What I
	have been doing is checking:
		if (screen->ViewPort.Modes & LACE) screen_is_interlaced.

o	Likewise to find the number of colors a given screen will
	support, you can do:
		numcolors = (1 << screen->Bitmap.Depth)

I am not sure if these two methods are the best way of doing these
checks, but they seem to work...

-- Dan Green
-- 
ARPA:  hsgj@tcgould.tn.cornell.edu
UUCP:  ihnp4!cornell!batcomputer!hsgj   BITNET:  hsgj@cornella