Keeps Growing!
LCDproc Development Area
Helping out the Project

- 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

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 ;)

- Ideas ? 2010-11-22 -

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 LCDproc's IdeaTorrent.

- 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.

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 LCDproc's sources?

We will commit new drivers if the following conditions are met:

  1. The hardware (display or enclosing product) is publicly sold OR the design is publicly available. (Note 1)
  2. The drivers is released under GPL and has an appropriate copyright notice.
  3. The submitter is or is acting on behalf of the original driver developer. (Note 2)
  4. The driver contains a valid email address for contacting the submitter or developer.
  5. The code is commented AND includes appropriate Doxygen comments.
  6. End user documentation (updates to man pages AND user-guide in docbook) is available.
  7. Driver options are described in the user guide AND LCDd.conf.
  8. 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).

- 0.5.x 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 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 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.
- Ideas ? anyone? -

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