LCDproc development and user support list

Text archives Help

[Lcdproc] (h)Bars are weird

Chronological Thread 
  • From: david.glaude at (David Glaude)
  • Subject: [Lcdproc] (h)Bars are weird
  • Date: Sun, 7 Mar 2010 19:31:24 +0100

2010/3/7 Markus Dolze <bsdfan at>

> Hi!
> While working on the Crystalfontz driver for the 635, I had to take a
> closer look at how (h)Bars work. I found that:
> 1. In the client language the length of a hBar is given as 'pixels',
> for which the client has to take the cellwidth and calculate the
> length of the bar.
> 2. In the driver API the length of the hBar is given as a promille
> value relating to the total length of the hBar in characters (full
> cells).
> 3. The server core translates from the client's 'pixel' value to the
> driver's 'promille of cells' value. As it has no idea of how mayn
> 'cells' a hBar consists, it takes the X position (given by the
> client) and the right border of the current frame (identical to
> the screen in most cases).
> 4. Different drivers use different heights for a hBar, some use a
> full cell height, some align the hBar with characters (which
> usually are 1 row less than a full cell).
> 5. The "seamless hBar" compile time options switches between a custom
> character and an icon charcater to display a full block. This
> interferes with 4 in some cases.
> What I would like to do:
> A change 1 to be the same as 2, but this would require an
> incompatible change to the protocol, therefore I will not do this
> right now.
> B make the hBar style (full cell / character height) a global
> configuration option.
> C at the same time remove 5 and always use a custom bar character to
> display a full block. For displays which are known to be seamless,
> the driver can automatically adjust.
> Your ideas?

Since there might be an indentical issue with vbar, I suggest you consider
both kind of bar simultaniously.
Since A break compatibility, the best option is to depreciate the old
interface and create a new interface for bar (both kind). But before you do
that think about all the other driver arround.

Maybe you first need to list all the question:
Should the "BarStyle" be global or per client?
Should it be a compile option, a configuration option, something that can be
set or change by the client?

Have a look around in that "BarStyle" is not present in every driver and
might be something someone added specifically for a taste issue in one
driver or a family of driver. Trying to generalise based on that is IMHO not
the best thing to do... Fix that driver if you believe it should be, but if
you try to create a general solution you will have to check every driver.

David Glaude
-------------- next part --------------
An HTML attachment was scrubbed...

Archive powered by MHonArc 2.6.18.

Top of page