[comp.sys.amiga] Some additions for 1.4

jtb@dhw68k.cts.com (John Gibbons) (08/31/89)

  After reading hundreds of articles in comp.sys.amiga regarding new and
or enhanced features for 1.4 amigados/kickstart, including better icons,
drop shadows, ARP etc. I have decided to add a few more to an already
giant list.

  If I may be so bold, I think I can speak for most of the Amy users here
when I say that pd/shareware utils like dmouse, popcli, runback, various
screenblankers, and loads of others are a part of most of your systems.
(as a matter of fact I cannot live without at least one matt dillon util
running!) :-) So including similar programs as a part of wb1.4 seems a
good logical step for improving the amigas already excellent OS.

  I was/am very pleased to see that many features that I have always
wanted on my amy are now a part of wb1.4 (namely text instead of icons
on the workbench, (a favorite from my ST days) Arexx and FFS in rom).
But a number of excellent features still remain out of the amigas
stock system.

  Add a Dmouse (or qmouse etc) type of util could easily be selectable in
preferences and of course the auto window activation and pointer blanking
would be great to have on a stock amy.

  A screen blanker like the zillions now available in pd could be added
into the OS very easily and of course with ECS all we need is to screw up
our $700 multisync monitors :-)

  Popcli could easily just be a default for a number of user definded
hot keys, or a function that is built into the os to call up a cli/shell
and nothing more.

   Of course dmouse alone already does all of those things now, and I am
sure many of you may find it silly to bother since it is pd. But you
forget that programs like mymenu and handywb will no longer be needed
in 1.4 because wb1.4 already supports definable menus. So why not hot
keys and mouse accelleration?

   In closing, I have named only a few features that are used by most
amy users now, and there are probably many others I should have
mentioned. If by any chance any of these features ARE included in wb1.4
then please don't yell and scream, simply inform me of it. And if you
think that these are useless enhancements then shhhhh, keep quiet! :-)

 Thanks..
-- 
John Gibbons
Internet: jtb@dhw68k.cts.com       UUCP: ...{spsd,zardoz,felix}!dhw68k!jtb
   //     
 \X/ "Amiga makes it possible!"    "Atari. we almost did it right!"             

jimm@amiga.UUCP (Jim Mackraz) (09/03/89)

In article <26115@dhw68k.cts.com> jtb@dhw68k.cts.com (John Gibbons) writes:

[ edited ]

)  Add a Dmouse [...]
) the auto window activation 
) pointer blanking
)  A screen blanker
)  Popcli 
) user definded hot keys,
)So why not hot keys and mouse accelleration?

I am often struck with how easy it would be to add numerous really neat
features (these included) to Intuition, in the "front end" before
input is funneled down to windows, gadgets, menus, ... .

)   In closing, I have named only a few features that are used by most
)amy users now, and there are probably many others I should have
)mentioned.

But what I am more often struck with is the number of different cool ideas.
Pointer jump to gadgets in turn, keyboard driven menus, syntho-type (still
waiting for one of these: plays synthesiser music while you type, sort
of an evolved "keyclick" thing), middle mouse mapping, macros, journaling.

So, there all can't get into the ROM.  Also, if something can be done outside
of the kernel, I say "why not do it outside of the kernel?"  And if it cannot
be done outside of the kernel, I say "what's wrong with the kernel?"

The goal of Commodities Exchange (commodities.library) is to make it possible
to do ALL of these things, or know why.

Commodities (CX) is an input handler with nice habits and easy ways to hook
into the input stream.  A lot of the things you want to assign function keys
to (window stuff, menus, ...) amount to system hacking, though, so we have
to look at the big picture.

One problem with input handler approaches to user interface customization is
that there really isn't a guaranteed relationship between the window which
is active when the handler is processing the input, and the window which
will be active by the time the input gets to Intuition.

This isn't a big problem.  For example, if you have hotkeys mapped "per window,"
and click in a new window "simultaneously" with pressing F1, you might
get the inappropriate key string expansion.  I could live with this, but
there might be a nice way to remove the uncertainty.

There are some open areas, though, and creative ideas are always welcome
(especially the ones that can be expressed in a few sentences ;^).

Here's some:

1) Can we do a complete journaling deal, or do we need more "macro" commands
  like "select gadget."  If we had to, we could make a way to "log" IDCMP
  messages sent to windows.  That might be hot.

2) How do we associate things like a file full of macros with a particular
  application window?  There's some real visonary stuff about "named windows"
  going around on the East coast, but I haven't figured it all out yet.

3) Since the input hacks will be "semi-official" when CX is included in the
  official release, I can envision a product consisting of a nice solid keyboard
  macro thing, maybe with a selection of screenblankers, mouse deals, etc., ...
  and maybe a control panel for the whole lot.

  Is there any money in this, and if so, who's going to make it?

  As the woman said to the psychic: "Oh, I hope it's me!"

	jimm

-- 
Jim Mackraz, I and I Computing	   	"... the signs are very ominous,
{cbmvax,well,oliveb}!amiga!jimm          and a chill wind blows."
							- Justice Blackmun
Opinions are my own.  Comments are not to be taken as Commodore official policy.