[NTLK] Very bare-bones note package to play with

[Warren Ockrassa]

On Tue, Dec 6, 2011 at 9:29 PM, Tony Kan <tony.kan at clear.net.nz> wrote:
> Hi Warren
>
> You're certainly a colorful writer!  I had a grin from ear to ear afterward.

Well, I tend to try to cant eloquent when I'm venting. If I'm going to
whine, it should at least be interesting whining.

> Viewtest installed OK this time.

I think I know what happened last time. The previous version wasn't
configured to talk to the system correctly about rotation. Well,
interestingly, if you set your base view (that's the main window
everything else appears within in your program) to be initially
visible in its view flags, apparently NOS treats it as running, even
when it's not. So the first thing it did when it installed itself was
send a garbage message to the system about its inability to handle
rotation, without the program even being visibly running.

I found that view-flag caveat entirely by accident when trolling
through the docs this evening. You'd think it would be placed a little
more prominently somewhere.

> I get an editable box with lines.  No
> action buttons or anything, I assume they are yet to come.

Minimally. The plan is to use the system scroll arrows (the silk
arrows on 1x0 MP's) for scrolling, rather than placing onscreen arrows
in the view, something like the Notes program does now. Once the
program is functioning a little more dependably, the scrolling will
become automatic as new text is entered in the edit field.

There'll be folder style storage too, but only possibly in folder
tabs. I haven't quite decided yet how I want to do that.

> Hitting the
> downward scroll button results in the error msg:  "This application doesn't
> support scrolling."

That doesn't surprise me. The initial state at the moment for the edit
view is to have no active caret in it, so depending on your system it
might not be recognizable as a view intended to scroll until after
it's been activated with a tap.

Also, the status field to the left is a hack. It won't be there
forever. I'm using it now to flag events in the edit view, because
there's really no other way to get useful feedback on the device. I
mention it because if a given machine thinks that field is meant to be
the active one, it's not going to work.

> But if you fill the page with text by pasting some random text, and then
> start adding extra then it doesn't scroll by itself but the scroll buttons
> seem to work..

Right. The next step is to get the scrolling to behave intelligently.
Getting it to behave at all was about 2.476 tricks all by itself.

> On the scrolling arrow convention, I'd stick to NOS convention on that.  Its
> too confusing and one of the nice thing about the Newton was all the
> attention given to reduce unnecessary taps.

Which is funny, because to my eye pushing the up arrow means 'move
this here thing up', and down means the opposite. (I've clearly
adapted rapidly to the 'natural' scroll style imposed on desktop users
by OSX.7, as well as the gestures from iOS).

The reversed scrolling direction was an accident. I inverted my
addition and subtraction. To scroll, you set the Y-axis origin of the
view you want scrolling, and the origin's initial value is 0. Adding
to that moves the top edge of the view up; subtracting moves it down.
I set the up arrow message behavior to add and the down arrow to
subtract, since it made perfect sense in code.

Sigh.

> BTW did you know there is a style guide where UI conventions are documented?

Oh, I know; I've read that as well. For the most part I agree with it.
It's sensible. But there are alternative ways to do at least some
things, and I think the 'natural' scroll arrows are worth keeping,
settable as a user option.

In many contexts, the Newt UI conventions prefer on-screen scroll
controls. That's fine if you've got a whopping great lot of pixels to
play around in, say in the range of 1024x768 or larger. But the
purpose of this particular program is to provide a large editing
window (on a small screen) that behaves as a more or less plain text
editor, with the only settable options for text being typeface and
size, per-window, not per-selection or per-word. The aim is to have
the maximum screen real estate dedicated to the text input area, with
a consistent text view, and as few onscreen controls as possible. So I
elected to use the system scroll arrows.

I also need to add a hook for the 'overview' button. Tapping it now
gives a popup about the program not supporting overview.

Additional controls will include font settings, filing, and I've got
to work out a method to get the text available to outside programs,
such as Notes, and set up to be exportable to desktop. The scroll
arrow settings will probably be in there, as will a toggle for
handedness - basically the location of the control frame, left or
right.

Refining the scroll and centering it around a caret kept at or near
Y-axis center at all times will require the kind of work I've always
liked least in code: Setting and responding intelligently to rectangle
dimensions - *dynamically changing* rectangle dimensions. It's
stupidly easy for the math to go way, way wrong.

At the moment I'm just glad it doesn't reset your 2100 on install.

-- 
-- Warren Ockrassa | nightwares.com