Refactor todo entries in the documentation and add them to the TODO file Document some known bugs and remove some that are known to be fixed.
78 lines
2.7 KiB
Plaintext
78 lines
2.7 KiB
Plaintext
Stuff planned for future releases... (in no particular order)
|
|
|
|
Feel free to help out with any of this stuff! :)
|
|
|
|
Please send a message to the mailing list if you have any question.
|
|
|
|
Things for the short term:
|
|
- Use centralized command message parsing engine (more secure)
|
|
- more features for existing display drivers (e.g. adapt them to bignum library)
|
|
- documentation (any help is appreciated)
|
|
- lcd_lib: Make use of the options parameter to specify SEAMLESS_HBARS, the
|
|
height of hbars, etc.
|
|
- lcterm: Support keyboard input
|
|
- MtxOrb: Recover the code for I2C connectivity to MtxOrb
|
|
- shuttleVFD: Use output() method for these special "out-of-band" symbols.
|
|
|
|
|
|
Things for the longer term:
|
|
|
|
----------------------------------------
|
|
lcdproc client
|
|
--------------
|
|
|
|
allow more than one instance of a screen with different configuration
|
|
sections (implementation should be possible similar to the one with
|
|
the drivers in LCDd where File=... points to the original driver file)
|
|
|
|
more options in the config file (clocks with offsets from localtime, ...)
|
|
|
|
more options changeable in the lcdproc client menu
|
|
|
|
rewrite machine_get_fs() in machine_Linux.c to use functions from mntent.h
|
|
|
|
get rid of MTAB_FILE compile time definition (for Linux & SunOS)
|
|
|
|
----------------------------------------
|
|
lcdexec client
|
|
--------------
|
|
|
|
more flexbibility: do not just only execute commands, but
|
|
maybe also display their result in a screen, get a command's
|
|
parameters interactively using the builtin input menus,
|
|
confirmation of commands, jumping between commands depending
|
|
on the output of a command (wizards), ...
|
|
|
|
----------------------------------------
|
|
Client driver
|
|
|
|
An LCDproc client can connect, request the "client" driver, then get
|
|
all screen information sent to it! This allows things such as logging
|
|
in remotely and starting up a curses display of LCDproc. It also
|
|
gives another method for writing drivers. In a sense, it could even
|
|
let you write and link in new drivers without having to recompile and
|
|
restart LCDproc...
|
|
|
|
Another bonus is that LCDproc will come with a client which can, for
|
|
example, start up a "client" driver to send "keypresses" from the
|
|
command line. Or,
|
|
|
|
lcdtool -key A
|
|
|
|
would have the same result as pressing a key on the keypad.
|
|
|
|
----------------------------------------
|
|
Scheduling modes
|
|
|
|
Instead of the simplistic "round robin" circular screen-scheduling in
|
|
the current release, later versions will offer several different
|
|
algorithms for screen-ordering.
|
|
|
|
One example: High-priority screens will be shown more often than
|
|
low-priority screens, simply by showing up more often.
|
|
|
|
STATUS: Currently high priority screens will only be shown _first_ after
|
|
a resorting of the screenlist. The time that it's visible is unaltered.
|
|
|
|
----------------------------------------
|