LCDproc development and user support list

Text archives Help


[Lcdproc] half bars


Chronological Thread 
  • From: michael at reinelt.co.at (Michael Reinelt)
  • Subject: [Lcdproc] half bars
  • Date: Sun, 27 Jan 2013 13:58:05 +0100

Hi there,

Oh yes, I really know these "split bars". Maybe due to the fact that I coded
them ;-)

I agree with Markus that implementing such stuff into lcdproc may be quite
complex, because of the driver approach being
very different to lcd4linux.

In lcd4linux, all the bar stuff is done by a "generic driver", which takes
care of all the fancy calculations, and does
"error diffusion": it is possible to use split bars in differnt directions
(left/right and up/down) at the same time,
which leads to a lot of needed user-defineable characters. usually displays
provide just eight of them. therefore a
"most similar" display is created. Another annoying fact is that you should
not redefine a character which is currently
being displayed, because that would lead to ugly artefacts.

You can also mix "hollow bars" (thats how we call the "bordered bars") with
regular bars, but you will really soon run
out of free characters.

All this 8really complicated) stuff is done by the "generic bar driver". A
display driver just registers with the core,
telling it a) "I am a text display", b) "I have n user-defineable characters
available" and provides a method for
character rendering. Thats enough for the core to use all sorts of bars, and
also "icons" which are animated
user-defined characters (a blinking heart, for example)

As driver design works very different in lcdproc, I also think that
implementing this stuff in a global way is nearly
impossible.


by the way, if you ever use to be in a suicidal mood, DO NOT look into
lcd4linux/drv_generic_bar.c



Am 2013-01-27 13:04, schrieb Markus Dolze:
> On 26.01.2013 21:28, Chris Jones wrote:
>> Hey folks
>>
>> Is it possible (or how hard would it be to implement) for hbar/vbar
>> widgets to show two values at once (by splitting the bar along its
>> main axis).
>> I have quite a small LCD and for things like Rx/Tx network traffic,
>> it's quite nice to have a long axis for lots of scale, without
>> requiring two lines.
>>
>> (If it's not clear what I mean, take a look at the LAN/DSL bars
>> in
>> http://ssl.bulix.org/projects/lcd4linux/attachment/wiki/CoolStuff/dual_display.jpg
>> )
>>
>> (Also I quite like the way they are able to draw a border around the
>> bar - is that possible/hard in lcdproc?)
>>
>> Cheers,
>>
>> Chris Jones
>> cmsj at tenshu.net<mailto:cmsj at tenshu.net>
>> www.tenshu.net<http://www.tenshu.net>
>>
>>
>
> Hi,
>
> the idea is very nice. These are my thoughts:
>
> Widgets can be 'anywhere'. The may even overlap. During rendering they
> are just passed to the driver.
>
> The core does know about all widgets, so it may check for any
> overlapping. But bars are rather complicated regarding their length
> (there is some weird pixel length calulation in there). Additionally,
> there is no interface to the drivers for 'split bars'.
>
> During rendering those widgets are just passed to the driver. In the
> case of barsthey key may overlap too. So the driver may check for
> overlapping bars. It needs to keep track of any rendered bars, which
> currently no driver does (and should not need to).
>
> Additionally it needs a different way of using custom characters.
> Currently, all possible bar characters for a bar are loaded to the LCD
> if a bar is used. This will not be possible with split bars anymore as
> there are too many combinations.
>
> I currently cannot think of way to do this globally for all drivers. At
> the end each (or some) driver(s) will have to be modified to make use of
> this. And this is something I don not really want to happen.
>
> Regards,
> Markus
>
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>
>

--
Michael Reinelt <michael at reinelt.co.at>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781




Archive powered by MHonArc 2.6.18.

Top of page