jmlich / frdl Goto Github PK

swing-worker JAR files version 1.1 and 1.2 are required. Only one of them
(1.2) should be required.

The current help system is a very quick and dirty mod of an example from
Sun demonstrating the use of trees.

Basically its not very big and the functionality is OK and doesn't need to
be upgraded to something as grand as Javahelp (unless this is really easy -
I've not looked at it).  

The main problem with it is that it must display html pages so it is all
easily transferrable to the same thing at flymicro.com/frdl, but the
'browser' window they're currently displayed in seems to be very limited in
it's capacity to interpret CSS, and things like hyperlinks don't work at all.  

Even getting the hyperlinks working would be a significant improvement
(there's already the class BrowserLaunch which might be the way to do it...)

It is necessary to have relatively 'severe' warnings if you are about to go
into download only mode for the first time because stuff gets written
permanently to your Championship file from the logger and it will continue
to append stuff thereafter. (The warnings are mostly to stop organizers
going into download only mode by mistake and making a mess of their own
championship settings - there are backups though...)

In fact download-only mode should really just be 'read-only mode', in other
words the operator can't make mods to the logger.frdl file if he hasn't got
a pw match, but otherwise should be able to choose whether he makes an igc
file according to the organizer's settings (which are on the logger in
logger.frdl) or his own, (which are in his championship .frdc file).

You then wouldn't need any warnings at all because non-pw holders could
freely swap between the two modes.... the default would be organizer
settings so you get exactly what he did, but no reason why you can't have
your own for some other reason, maybe with the option to copy organizer
settings to your own settings if you want them.

However; not so easy to implement because it would mean having 'hot
swappable' championship settings, one set which was yours and one which is
the organizer's, and presently championship settings are rather deeply
embedded in the app. as a single entity.

Perhaps blue track lines when you're using organizer settings and red ones
if you're using your own?

v2 maybe...

Need to move main codeline from FRDL to trunk

FRDL at the moment makes one single GeneralPath for the entire duration of
the track within the task window in both the AltitudeView and MapView classes.

In other words it joins up track fixes with a line even when there is a
significant time gap between fixes.

Would be more intuitive to show gaps, perhaps when there's a 'dead'
interval of > 30 sec or something.

It thinks you want to select a file rather than a 
directory, so unintuitively makes a sub-directory of where you think
you should be making a directory.

If the task window is changed, perfectly possible to re-write igc files
from the backed up data without the logger being present....

Good idea???  Might be confusing??

sessionproperties (properties style config file with not much in, but does 
control language changes) is created in install location.

Default install location on windows is program files

Vista only lets users with admin permissions write to Program Files, so 
sessionproperties never gets written.

1) sessionproperties needs a new location
- needs to be constant (ie not where championship file is saved)
- needs to be automatic (ie use an environment variable pointing at 
somewhere you can write to on Vista, which will also work on win2k, XP and 
other OS's)

2) Must be done before someone submits a translation.

FRDL ignores something being either plugged into or removed from a USB
port.  Needs a bit of research to identify how Macs see USB ports. 

The File - New dialog has nowhere to put a file name (or for that matter to
create a new directory to put one in).  Needs a bit of research on how
these things are done on Macs as it may be normal to provide a default file
called "Untitled.frdc" or something.

At boot, FRDL should try to look at flymicro.com to see if there is a newer
version available.

If there is, just shows a gentle reminder that there is one.  

No message if there's no contact or current version is OK.

The page http://www.flymicro.com/frdl/checkLatestVersion.cfm is already up
with "2.0" as it's entire content.  Once working, I'll change this to
whatever the current version is.  

Would be desirable to have a dialog with a grid in it with columns listing 

compno (will need leading zeroes to order correctly)
Logger Priority
Pilot Name
Nation
Logger type

...of all the loggers currently registered in the championship file.

perhaps orderable by a click on each column header?  
To make sense this would generally need a 2nd and perhaps a 3rd sort column
too, for example 
compno / priority 
Pilot / priority 
nation / pilot name / priority

Exportable to CSV?

The Joda Time library is not correctly referenced in the build. Solution is
to create a new Library referencing the joda-time Jar file and include it
in the project classpaths.

Distribution in a simple zip file would be fine if it wasn't for Vista...

The default Vista .zip file integration is so crappy it is often broken,
net result is all files extract to the same dir rather than the lib/
sub-dir being in the right place.

Of course you can always install a 3rd party zip file add-on utility which
solves it completely, but some people aren't aware this problem even exists
and then FRDL fails to work...  (I saw this yesterday, told the chap on the
phone to make a lib subdir, put everything but FRDL.jar in it and then it
worked fine...)

True solution is an installer / uninstaller which will presumably have the
bonus of making shortcuts and things too.

Should be cross-platform if possible, then don't need to offer the standard
.zip file install as well.

Suggestions?

Currently get written anyway

Dialog asking "You are about to write an empty igc file which is not much
use to analysis.  Continue anyway?"

Pros and cons of doing this....

Unknown if this is an issue or not...

Mostly getAbsolutePath() is used in FRDL

This might cause unexpected problems on OSes which have case sensitive
directory systems?

getCanonicalPath() is probably the fix, but need to:
a) Discover if it really is a problem.
b) test getCanonicalPath() works OK on Windows.

So it is possible to say thankyou to everyone who worked on FRDL....