Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!bryan
From: bryan@cs.utexas.edu (Bryan Bayerdorffer @ Wit's End)
Newsgroups: comp.sys.amiga.misc
Subject: Re: random thoughts on iconification
Message-ID: <379@mohawk.cs.utexas.edu>
Date: 29 Jun 91 19:05:59 GMT
References: <37090018@hpfcdc.HP.COM>
Reply-To: bryan@cs.utexas.edu
Organization: Spam Detection & Removal Squad, Austin, TX
Lines: 41
Spam-Content: Negligible

In article <37090018@hpfcdc.HP.COM> koren@hpfcdc.HP.COM (Steve Koren) writes:
=-
=-Here are some random thoughts on iconficiation:
=-
=-* What 2.0 does with CLI windows is not really iconification.  It
=-  can switch between two window sizes, which is quite nice, but
=-  the smallest size is large enough to be annoying nonetheless.
=-  I think a small icon is better (ala xoper, calc3.0, pfm, etc).
=-
=-* Iconfication of screens: why not?  This doesn't seem any harder
=-  to do than iconification of windows, using Leo Schwab's(sp?)
=-  library.  Seems generally useful to free up chip ram for other
=-  things.
=-

Davide Cervone's excellent wIconify utility already fills this void, and the
latest versions allow iconification of screens, autoiconification, and have a
programmer's interface, among other features.  It's better to make iconification
a system function than to compile it into each application. This is the approach
taken by wIconify.  Hopefully it will work equally well under 2.0.

=-It might be nice if C= adopted Leo's iconification library, and
=-made it a "standard" for applications to support.  Having used this
=-library for several things I've written, I know it is quite easy to
=-do.
=-

Let's face it, if C= were inclined toward such things, they would long ago have
adopted as standard a halfway-decent shell, and half a dozen other things.  Look
how long it took just for that cheeseball MicroEmacs to show up on the
distribution disks.  Without all the wonderful free utilities such as wIconify,
Snap, PopUpMenu, etc. I'd find the Amiga user interface unbearably cumbersome
(to say nothing of having to live without SKsh :-) ), with these utilities, it
beats anything else I've ever used, for my purposes. 

The problem is of course that the 512K default RAM size of the A500 rules all at
C=, which is understandable.  All of these neat toys take up a fair amount of
memory, so they won't be built in any time soon.  This shouldn't stand in the
way, however, of choosing a standard set of these well-designed and well-written
utilities and distributing them in place of a lot of the trash that currently
comes on the distribution disks.