On Tuesday 14 May 2002 09:12 am, Bob Jacobsen wrote:
a) Ops mode programming
Good.
d) Improvements to the roster - being able to copy & delete
locomotives, better editing, import/export to various common formats,
etc.
It would be nice to have a simple way to copy the programming of one decoder
into anther. I have 2 GP9s and would like them to both have the same
characteristics.
It would be nice to be able to 'inherit' a roster entry when a new
decoder/loco is added to the roster. For example, loco #123 exists and loco
456 has the same decoder. It would be nice if the configuration from loco 123
could be copied to loco 456 as a starting point.
f) Integrated installers, esp. for Windows. The current multi-step
install process is getting in the way. It would be pretty simple to
create a two-step install process of the form "Run this Java
installer, then run this DecoderPro installer", perhaps with an
updater that makes future updates quicker downloads.
And perhaps: add a bin directory where all the scripts live and place
jmri.jar in the lib directory. For a Linux install, one could then simply
place DecoderPro in /usr/local/DecoderPro and create a symlink from
/usr/local/bin/dp -> /usr/local/DecoderPro/bin/DecoderPro.csh (or something
like that). Other platforms may have similar conventions to follow.
g) Lots more decoders
An Internet decoder registration tool built into DecoderPro. This would be
similar to the various CD players where if the CD player does not recognize
the CD (based on number of songs and length of each song) it queries the DB
on some Web server. If the unknown CD (decoder) is in the DB then DecoderPro
can update itself and the user can then use that definition. (you no longer
have to spin a new version of DecoderPro when new decoder files become
available). If the CD is not in the DB, the DB server also provides a way for
a user to enter the CD information and upload it to that central DB
(presumably someone checks the upload).
cheers,
Mike
