LCDproc development and user support list

Text archives Help


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


Chronological Thread 
  • From: joris AT robijn.net (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 http://www.powarman.de/vdr_graphlcd.htm (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
detected...

I guess the 2 or 3 exta packages should be compiled separately, not by
LCDproc.
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/Makefile.am

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

16x1
16x2
16x4
20x2
20x4
40x2
40x4

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.

Joris




Archive powered by MHonArc 2.6.18.

Top of page