[Xastir] suggestion

[Curt Mills, WE7U]

On Wed, 7 Aug 2002, Jim Shorney wrote:

> >Ah, but it does work!  What it does is clear the objects & items out
> >of the file.  It doesn't clear them off the screen.
>
> Ah, I see.  So will they then fade off the screen after a time?

I'd have to think about it.  Perhaps not.  You're not implying that
I forgot a critical step are you?  ;-)

I'll refer to both objects and items here as "objects".

We might need to clear out the file, then process the station
database looking for locally-owned objects and write their latest
positions into the file.

Either that or clear out the file, process the station database,
clearing out locally-owned objects as we go, then do a refresh to
clear them off the screen.

What sort of functionality should we have?

I see three possible things that people might want to do, there may
be more:

1) Clear out the history so that a restart of Xastir will have no
objects transmitted.  Current objects would be left on the screen.
Any changes to the objects would get their new info written to the
log file.

2) Clear out the history file and clear all objects off the screen
and out of the station database.

3) There may be times when it would be nice to clear out the
previous history of the objects, but leave the currently
displayed objects most recent positions in the file.  This would get
rid of changes to the object including position changes, so the
trail would go away after a restart, but the last position of the
objects would remain.

How should we go about this?  What do people want/need?

Three Buttons?

    Clear My Objects/Items
    Clear My Objects/Items & History
    Clear My Object/Item History

First and second buttons would start transmitting deleted object
packets all locally owned objects.

With the current implementation, if you create an object and then
delete it, every time you restart Xastir it will again begin
transmitting the deleted object.  Forever!  Same for objects you
don't delete.  They go on forever at your posit rate.

We should probably process the history file, sorting by object name,
and refusing to add them to the station database if the final result
is a delete.  Whether or not they should be completely deleted from
the history file is yet another question.

Note that this is an initial stab at the implementation.  If we ever
get around to implementing object expiration times, those times
should also get written into the log file so that the expiration
will work properly across restarts.

Let's hear some discussion.  Anybody have any suggestions?

Curt Mills, WE7U                         hacker.NO_*SPAM at tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U