- Version 0.5dev
(Peter Marschall, 2006-10-02) -
Next to the stable version, an 'unstable bleeding edge' development
version (aka current) 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/.
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.
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 WasteTM to program
features twice ;)
We implemented a new idea gathering (aka feature request) tool utilizing
IdeaTorrent hosted on Sourceforge. Anyone with a Sourceforge user account
may submit new ideas for LCDproc or vote for ideas of others.
Check it out at
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.
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.
- Adding your driver
will we accept it? -
You have written a driver and want to know how you can have it included in
We will commit new drivers if the following conditions are met:
- The hardware (display or enclosing product) is publicly sold OR the
design is publicly available. (Note 1)
- The drivers is released under GPL and has an appropriate copyright notice.
- The submitter is or is acting on behalf of the original driver developer. (Note 2)
- The driver contains a valid email address for contacting the submitter or developer.
- The code is commented AND includes appropriate Doxygen comments.
- End user documentation (updates to man pages AND user-guide in docbook) is available.
- Driver options are described in the user guide AND LCDd.conf.
- The code style complies with the Code Style Guideline.
Note 1: Therefore I will not commit drivers for displays ripped out of an old
telephone and otherwise being unavailable or for your private hardware project.
Note 2: I will not submit drivers found somewhere on the internet and
submitted without the original developer's acknowledgement.
If you need help with creating the Docbook documentation we can help you
creating that (or even write it for you if you provide the necessary input).
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 dynamically 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 dynamically.
- There is a new driver API with the following features:
- Key interface is now using descriptive key names instead of only
- 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.
All pending ideas should be in the TODO file in CVS that every developer can
modify. Currently this file contains:
NOTE: Use of this TODO list is obsolete! A list of things to be done is
automatically created by Doxygen. You may create the Doxygen documentation
yourself by running the doxygen command from the docs/ directory.
Ideas for new features can be entered at the IdeaTorrent:
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 non-standard serial baud rates (57600 and higher) only optional.
Things for the longer term
- 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)
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), ...
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
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.