LCDproc development and user support list

Text archives Help


[Lcdproc] Alphanumeric "bignums"


Chronological Thread 
  • From: epooch at cox.net (epooch at cox.net)
  • Subject: [Lcdproc] Alphanumeric "bignums"
  • Date: Tue, 5 May 2009 18:20:42 -0700

Federico,
Rather than mess with the bignum implementation, Add a "CellSize"
configuration for imonlcd, and write some code to scale the font to the
CellSize specified. So, between "Size" and "CellSize", you can basically
create a pseudo 1 line LCD with a big character size. It would be
transparent to LCDproc and you would not need to mess with legacy support for
bignum. Check out the sed1330, which according to the docs, MIGHT do
something like this (but as I recall, CellSize might not be totally
implemented).
Anyway, bignum is not the right way to do what you want.

--Eric

---- Ethan Dicks <ethan.dicks at gmail.com> wrote:
> On Tue, May 5, 2009 at 4:43 PM, <rickx at libero.it> wrote:
> > ok, I get it. But these two philosophies can meet...probably they should
> > meet!
>
> Perhaps they should, but with us trying to gather things together for
> the first release in two years, they will not meet anytime soon.
>
> > I did not seriously analyze the whole code, but I thought from the
> > beginning
> > that
> > having a bignum method was strange and that the only logical reason was
> > some
> > hidden and old software/hardware constraint.
>
> It's not a "constraint" as much as originally an attempt to express
> the features of the one and only supported module. Modules have
> changed in 10+ years and it has become a constraint (except on
> HD44780-based modules which haven't changed and are still probably the
> most popular type of module used with LCDproc).
>
> > I don't mean to be respectless to other's work - I'm even new here in the
> > list - but I don't think
> > the fact that there is a lot of different hardware to support can be the
> > reason not to
> > evolve, at least not for a long time.
>
> It's not being used as a reason not to evolve, but it is a reason that
> the evolution isn't particularly fast.
>
> > That being said, I'd probably better go and code something instead of
> > writing...which I'll do asap.
>
> If you are new, you've missed much discussion of the direction of
> LCDproc and feature additions, but let me just say that anything as
> radical as you are proposing is unlike to make into this version. It's
> something to propose for 0.6 when we have the ability to open the
> doors to new ideas.
>
> -ethan
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc





Archive powered by MHonArc 2.6.18.

Top of page