- Version 0.5dev		(Peter Marschall, 2006-10-02) -

Next to the current stable version, an 'unstable bleading edge' development version exists. In this version new features are being tried. The current development version is v0.5dev.

The development source code is in CVS, it is the main development branch. For how to get it, see the CVS page on sourceforge. You can also browse the CVS with your web browser.

Guillaume Filion has made a smoketest page to automatically test the current CVS code on various platforms. You can contribute if you have a non-standard platform by periodically running the smoketest script. Have a look at http://lcdproc.sourceforge.net/smoketests/.

- Current features -

A lot of ideas for LCDproc have been existence for quite some time. In '98 there were already ideas to enable clients to control the LCDproc menu system. They got worked out, but never got implemented. Also there was the idea of dynamicly loadable driver modules. These ideas got me going in creating 0.5, based on the 0.4.3 code. Currently 0.5 is internally quite different from 0.4, and it offers some nice new features:

• A seemingly slightly modified menu system that is in fact a complete rewrite. It now uses widgets itself, just like 'real' clients.
• The possibility for clients to add items to the menu.
• New menu items, like a ring, a numeric and an alphanumeric input. To see what they do, download 0.5, which contains a demo menu.
• The menu uses icons.
• The driver modules are being loaded dynamicly.
• There is a new driver API with the following features:
  • Key interface is now using descriptive key names instead of only a character.
  • More hardware abstraction: Vbar and Hbar now have their size given in promilles, not in pixels.
  • Predefined icons can be placed.
  • There are fill-in functions for if a driver does not support a function. If f.e. Vbars are not supported, they will be emulated. Also, for icons there are standard replacements.
• Some new drivers were added.
• You can reload the configuration and the drivers with SIGHUP.

- Documents -

For all developers interested, there are some documents available about developing for LCDproc. You can find them on the documentation pages and in the docs directory of the distribution. Note that some documents are even more in development than LCDproc itself. In other words: be prepared for some rather outdated texts ;)
If you want to write a client, you might want to have a look at the client examples. There are some LCDd interface routines for Perl, and maybe some other languages. Search the mailing list archive for some links.

- Ideas ?		anyone? -

All pending ideas should be in the TODO file in CVS that every developer can modify. Currently this file contains:

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)
- 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.
- glk: port icon, vBar and hBar to 0.5 API.
- Use non-standard serial baud rates (57600 and higher) only optional.


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.

----------------------------------------

If you have an idea, or you want to write something for LCDproc, please speak up on the mailing list ! It would be A Great Waste^TM to program features twice ;)
The 0.5dev code is quite stable, it seems to run quite well and hardly crashes. There are no really big changes in the pipeline currently, so for the coming time the functionality will remain pretty much as it is. If you want to work on LCDproc code, I suggest you take 0.5dev.