LCDproc development and user support list

Text archives Help

[Lcdproc] new LCDproc-0.5 "meta"-driver soon

Chronological Thread 
  • From: joris AT (Joris Robijn (webmail))
  • Subject: [Lcdproc] new LCDproc-0.5 "meta"-driver soon
  • Date: Tue Jan 25 12:13:01 2005

Hi Lucian,

> , but basicly it's a refactoring of the graphlcd plugin
> for VDR, see (the animated GIF
> is cool to look at).

Very nice indeed !

> The maintainer of this VDR plugin already split it up in libglcddrivers
> and a libglcdgraphics (so this will probably be the upcoming
> graphlcd-base-0.1.2 that I'm actually using),

> up to now are in an own format emerged from earlier versions of the
> VDR-plugin, but I already experimented whith using FreeType2 in the
> graphics library, to load any scalable font and prepare it for usage
> in the graphics library).

Interesting. I'm also still looking for an easy fontsystem (which should
include a _very_ small font) for SED1330. FreeType is good for you ? (don't
know how it's used)

> It's a library containing just one class implementing a generic
> LCDproc

> Does it make sense to release this specialized wrapper library as a
> separate package, or include it in a subdirectory in
> ...lcdproc/server/drivers/glcdlib whith a Makefile of its own
> instructing the compiler to compile C++ here and then link all

Yeah good question. It's C++ so it does not fit in the standard LCDproc
package. You could decide that it can be compiled when a C++ compiler is

I guess the 2 or 3 exta packages should be compiled separately, not by
Because they probably also have their own configuring system.

> wanted? Either way, I'd need help on how to create this Makefile if
> it's to be included in LCDproc, and how to write the library auto-detection
> code in ....server/drivers/

That's a long time ago that I've done that. I've read some things onm the net
about the autoconf/make system and after a couple of tries I got it working.
would say just try to act as if you're only creating a driver. If you don't
have too many source files, all can stay within the driver directory. That's
least the simplest solution.

> , and let the
> wrapper library itself to check if it has all the dependencies
> satisfied

Yes that's the best way.

> it's size if using FreeType2. Concerning this, are there any
> "standard" LCDproc display sizes (in fixed width characters) I should
> enforce in my


But any size works for the daemon, the problem is usually that most clients
can't generate nice screens for all screen sizes.

> P.S. Licensing will be GPL

Required for LCDproc.


Archive powered by MHonArc 2.6.18.

Top of page