  Eabe Kuik <merciful@worldaccess.nl> wrote:-

>Well I just finished the forwarding part. Together with the reply routines 
>you should now be able to use Infitra for normal mail jobs. This will ease up 
>the testing I think:)

Infitra is getting very close to the point where it can be used seriously,
but there is one glaring lack which makes this impossible...
There is currently no way to delete any mail, neither incoming nor outgoing.

If you feel drag&drop to require more time for proper implementation, then
you should at least implement the 'trashcan' icon so that it can delete all
the currently selected items when simply clicked on (possibly with confirm).
Once that has been added Infitra _will_ be ready for serious, albeit simple,
use in the real world...


>Another funktion will work now. If you use the funktion 'send a message' (alt 
>S) and the cursor in the mailbox is standing on a message, the name and 
>address form the sender of that message will appear in the send window.

All very well, but I also want yet another function...  ;-)
This is the re-editing of an already queued mail, including subject line.
At present, re-editing can be done by defining an editor as external viewer,
but AFAIK this will not affect the 'subject' used in sending the mail, since
that would be in the IDX file.  Thus a new command "Reedit queue mail" would
do this better.


>This  also works also if the cursor is standing on a relation. Of course
>your still able to send a totaly new message. Just press control N for that.

Unfortunately I have not the faintest idea what you are talking of...   ;-)

Evidently you mean something entirely specific by the word 'relations',
but since the meaning you intend is never explained in your docs there
is no way for me to understand you completely.

Nicknames...?  But then how can I use them...?
When I do try to open the 'Relations' sub-box in Infitra, all I get is an
'empty' Icon, just as when I open an empty mailbox...

What you seem to be saying is that here is already a way to access some
kind of address book (it that is what you mean by 'relations'), but that
can not be utilized without any means of entering any such addresses.


>The problems with STiK are not fixed yet. I hope Dan has some usefull 
>information that will help. With STinG there are no problems at all (Not that 
>I know of).
>
>On the hotlist:
>  - Hard message deleting
>  - Mail reading in the main window
>  - The f...ing slider routines
>  - etc.

Ooops, haven't anyone helped you with the sliders yet...?

Basically there are two different philosophies concerning sliders.
Both are equally valid, since they depend on arbitrary decisions.

Thesis 1:
    the total slidebar area represents the total physical area, meaning that
    with slider at top the first physical item is the top item in the window,
    while with the slider at bottom the last pysical item is the bottom item
    in the window.  This was not chosen by Atari...

Thesis 2:
    the slidebar area _not_ covered by the slider itself represents the total
    physical area.  This means that with slider at top, the window is above
    all physical items and with slider at bottom the window is below all
    physical items.  This was not chosen by Atari either...

Yes, I really mean it, and that is the main cause of confusion for you and
others who have tried to get the hang of Atari GEM sliders.  You see, Atari
(perverse as usual) insisted on choosing a hybrid of the two theses above.
But I really should not blame Atari for this, since it was actually Digital
Research who made this decision.

Their hybrid combination works like this:

Thesis 1 applies to slider size calculations
                    BUT
Thesis 2 applies to slider position calculations

So the slider has a size proportional to the percentage of the total physical
area visible in the window, but the positioning values are proportional to
the position of the window edges in the undisplayed portion of the physical
area.  This may sound odd, but does have the advantage that slider size has
no effect on index values.  Precise formulas are given further below.

Assume the following identities:

tot_sz = the total size of the combined sliding area.
         Note that this is in arbitrary units, lines or pixels or mails etc...
         For a viewed text this would be the total line count vertically, but
         the maximum line length horizontally.

vis_sz = the size of the visible area that can be slid around in tot_sz.
         This is in the same arbitrary units as tot_sz, and for a viewed text
         this would be the number of lines visible vertically, but the number
         of visible columns horizontally.

         Note that vis_sz is proportional to window size, so it may in some
         cases exceed the tot_sz value, for example when displaying a short
         file in a big window.  Care needs to be taken in handling this.
         Sometimes forced shrinking of the window is the best way, but that
         is often not the case. This must be decided for each implementation.

vis_ix = the index position of the visible area.
         This also uses the same arbitrary units as above, and for a text view
         this would represent the top edge of visible area vertically, but the
         left edge of the visible area horizontally.  When zero this means the
         slider is at top/left edge of tot_sz, and when at the opposite edge
         it will normally be (tot_sz - vis_sz) .  (Some exceptions exist.)

slide_sz = the size of the slider in 1/1000th parts
           Sets height of vertical slider, or width of horizontal slider
           to correspond to the quotient of visible size by total size.

slide_ix = the index position of the slider in 1/1000th parts
           Sets the position relative to the undisplayed physical area
           where the window is logically 'inserted'.

minim_sz = the minimum size acceptable for the slider, this should be chosen
           so as to represent at least four pixels, since it is very hard to
           'pick up' the slider otherwise, and I recommend at least 8 pixels.
           Note that due to arrows in the scrollbar the size in pixels can't
           be directly calculated from window work area...  Some guesswork
           will have to be sufficient, and except for extremely small windows
           this usually works fine.

The last one, 'minim_sz' introduces some exceptions and special cases in
the calculations, but is necessary to maintain control of the sliders when
the visible portion is very small relative to the slideable area.

For slider control after reaching an area by non-slider means, which should
include slide bar clicks (otherwise we may get digitalization problems),
we can now calculate the slider values as follows:

    if  (vis_sz >= tot_size)    /* Special case: non-scroll window */
    {   slide_sz = 1000;
        slide_ix = 0;
    }
    else                        /* Normal case: window needs scrolling */
    {   slide_sz = 1000 * vis_sz/tot_sz;		/* by Thesis 1 */
        slide_ix = 1000 * vis_ix / (tot_sz - vis_sz);   /* by Thesis 2 */
    }
    if  (slide_sz < minim_sz )  /* Special case: forces slider visible */
        slide_sz = minim_sz;

For access control after pure slider movement, we can now calculate the
new visible physical area start as follows:

    if  (vis_sz >= tot_sz)      /* Special case: non-scroll window */
        vis_ix = 0;
    else                        /* Normal case: window needs scrolling */
    {    vis_ix = ((tot_sz - vis_sz) * slide_ix + 500) / 1000;
        if  (vis_ix + vis_sz >= tot_sz) /* Special case: end overlap */
            vis_ix = tot_sz - vis_sz;
    }

Note that sliding digitalizes positioning to 1000 steps, so the latter
formula should only be used for pure slider drag operations.  For all
others, including clicks on frame arrows or the slidebar areas around
slider, all should be handled by manipulating vis_ix and recalculating
slide_ix and slide_sz.  This way the digitalization only affects the
slidebar display, and does not limit the ability of the window to be
scrolled by smaller increments.

Note that all calculations and variables need both horizontal and vertical
implementation for full window gadget capability.  So where I have used:
        tot_sz, vis_sz, vis_ix, slide_sz, slide_ix, minim_sz
you actually need to expand this into twice as many variables.

For multiple window operations it is best to define a structure containing
such a doubled set of elements, and then define an array of such structures
to be used one each for each of the windows.  Naturally further elements
will be needed for window buffer pointers etc, but that is up to specific
implementation needs, which will naturally vary.

There are lots of other ways to use the sliders, but the above suits me,
and I prefer not to make this description too complex.  Hopefully these
formulas can fill your needs like they have mine.
