Re: Mousetext toolbox

["ict@ccess" <gids.rs@sasktel.net>]

>  Any plans to release a version that adheres more closely to the Apple
>  Human Interface Guidelines?


In a word,  No!

I had a chance to review your guidelines.

There are a couple of new ideas that I might implement, but for the
most part, most of your suggestions are not really feasible.  And I
will explain why by explaining some of my personal experiences.

My biggest goal was to keep everything in Main memory and keep Aux
memory and expansion memory strictly for data for a word processor,
spread sheet, data base and html viewer.  And adding to the toolbox
would limit the applesoft program in main memory.

For me, any solid inverse areas such as menus and dialog boxes are a
severe strain on the eyes when using a real IIe, IIc, IIGS.  Although,
using inverse areas with a vga monitor or flat screen where the white
can be dimmed so the glare is reduced, might be acceptable.  The white
menu is a pain when trying to use a word processor.  I find myself
staring at that bright line at the top of the screen while in
thought.  It is like stareing into a fire pit and one loses all
concentration.

Aesthetically mousetext characters look better on a black screen, as
there is not so much white on the screen that tends to blur out the
detail.
The flash buttons looks way better when flashing a white button on a
black screen instead of flashing a black button on a white screen
On a black menu, the open apple character can be used for the
unselected menu and the closed apple character can be used when the
menu is selected
The background can also be changed to any character or set of 2
characters and not just the gray scale look.
An 'x' is the standard on both a Mac and a PC for closing windows and
will be more easily remembered as a close button
Both the dot in a box and the check mark are better used as radio
buttons and selection indicators

As for dimming windows and using multiple windows is not really
feasible because of the huge amount of extra coding.  This more than
likely will force the toolbox to extend into Auxiliary memory.  And if
that happens then, memory managers and other drivers would then be
needed.  Where does it end?

The toolbox is meant to be easy, fast and compact and with enough
power to make an applesoft program easy, fast and compact.  Almost all
commands need to access applesoft's variables.  This is much more
complicated when the toolbox is run from Aux memory.

So for now, I hope some of you are enjoying the power that the toolbox
can provide.

I will consider suggestions if anyone would like to add to the
toolbox, if it is simple and I can program it in under $100 bytes (It
is actually easier for me to think in hexadecimal) and at the same
time, save a lot of programming space if the same were done in
applesoft.  Please, no structured programming suggestions.  Heard from
the peanut gallery "Ok, that leaves me out!    Me too!    Awwwww"

Cheers

Rob