koren@hpfcdc.HP.COM (Steve Koren) (06/28/91)
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. 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. - steve
bryan@cs.utexas.edu (Bryan Bayerdorffer @ Wit's End) (06/30/91)
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.rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (06/30/91)
In article <379@mohawk.cs.utexas.edu> bryan@cs.utexas.edu writes: >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. Another problem with some of these programs is that they cause problems with certain applictions. PopUpMenu GURU's the hell out of my system. Even if I boot clean, load VLT, and use PopUpMenu I get GURU's galore. I'd like to use PopUpMenu but it's too unreliable on my vanilla system. Snap works fine. C='s shell is ok, but I think WShell should be shipped with the OS just like Arexx was. Everyone has their favorite utility. If C= shipped WShell, Sksh/CShell users would scream and vice-versa. If Commodore shipped DeluxePaint with the OS, Digipaint users would be mad. I tink the best solution is to give the user coupons for free software and let him buy what he likes. -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
bryan@cs.utexas.edu (Bryan Bayerdorffer @ Wit's End) (06/30/91)
In article <1991Jun29.192118.19947@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes:
=-
=- Another problem with some of these programs is that they cause problems
=-with certain applictions. PopUpMenu GURU's the hell out of my system.
=-Even if I boot clean, load VLT, and use PopUpMenu I get GURU's galore.
Of course programs tha cause problems should be avoided, but one has to be
careful in placing blame. Just because a PD utility interacts badly with some
commercial application, for instance, doesn't mean the utility is at fault.
Many applications are poorly written and break all kinds of rules. Sadly, there
are many commercial programmers out there whose knowledge of the Amiga and its
requirements is minimal compared to the better 'hobbyist' programmers, because
they must work with many types of machines.
I've had NO bad interactions between PopUpMenu and any other programs, including
VLT, so I'm surprised to hear about these GURUs.
=-favorite utility. If C= shipped WShell, Sksh/CShell users would scream
=-and vice-versa. If Commodore shipped DeluxePaint with the OS, Digipaint
=-users would be mad. I tink the best solution is to give the user
You can't please all of the people all of the time. Does this mean you should
please none of the people none of the time? That's the IBM philosophy. :-)
=-coupons for free software and let him buy what he likes.
=-
This is a good alternative to bundled commercial software, but how does this get
the novice user the free tools and utilities that might make his life easier,
but of which he's never even heard? The vast majority of Amiga owners know
nothing about Fish disks or Usenet archives when they first buy the machine, and
almost all of them never get to see or try all the stuff that we do, because it
costs them real money and a lot of time to download PD hacks or copy disks.
My point is simply that there's a lot of stuff currently on the Amiga
distribution disks whose usefulness is doubtful at best. It doesn't take that
much head scratching to replace it with something better.rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (06/30/91)
In article <380@mohawk.cs.utexas.edu> bryan@cs.utexas.edu writes: >My point is simply that there's a lot of stuff currently on the Amiga >distribution disks whose usefulness is doubtful at best. It doesn't take that >much head scratching to replace it with something better. I agree, but what should we replace MEmacs with? DME? Qed? UEdit? TurboText (Yeah!!) I'd personally go with DME, but if you want to distribute a commercial editor, I'd like TurboText. The better method may be to let dealers decide. Let them sell Amiga's packaged with commercial software. Or have them have the Fish disks in the store. My local Amiga dealer lets you copy utilities off the demo Amiga's harddisk (like mandelvroom, dme, snap, etc) I think the dealers should be more active. IBM dealers sell packages all the time. (like PC clones with Windows+Word perfect, etc) -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
sbeagle@kennels.actrix.gen.nz (Thomas Farmer) (07/01/91)
bryan@cs.utexas.edu (Bryan Bayerdorffer @ Wit's End) writes: > In article <1991Jun29.192118.19947@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit. > =- > =- Another problem with some of these programs is that they cause problems > =-with certain applictions. PopUpMenu GURU's the hell out of my system. > =-Even if I boot clean, load VLT, and use PopUpMenu I get GURU's galore. > > Of course programs tha cause problems should be avoided, but one has to be > careful in placing blame. Just because a PD utility interacts badly with som > commercial application, for instance, doesn't mean the utility is at fault. > Many applications are poorly written and break all kinds of rules. Sadly, th > are many commercial programmers out there whose knowledge of the Amiga and it > requirements is minimal compared to the better 'hobbyist' programmers, becaus > they must work with many types of machines. > > I've had NO bad interactions between PopUpMenu and any other programs, includ > VLT, so I'm surprised to hear about these GURUs. I wonder if there's two versions of Popupmenu around? I too had very serious problems when I installed Popupmenu which went away when I removed it. The rest of the time my system is very stable. I also wished Popupmenu just brough the bar down, rather than changing from a horizontal menu to a vertical one... sbeagle@kennels.actrix.gen.nz aka Thomas Farmer Ph.+64-4-796306 "Apricot sometimes wished she lived in as ordinary a household as did her neighbours; though the more she considered the neighbours the less ordinary they seemed. ... perhaps all the normal people lived down another street?" Darcy's Utopia - Fay Weldon