[Lcdproc] CVS changes for CF63* users

[Peter Marschall]

Hi,

On Saturday, 7. October 2006 22:04, Jannis Achstetter wrote:
> Since I got an CFA-635 today, I can comment the changes now.
> CFONTZ_WRITE_DELAY seems to work, at least the chars are not scrambled
> or what.

Good to hear.

> The "--enable-seamless-hbars"-thing however doesn't work. When passed
> to configure, it does nothing, the display behaves as it does without
> the configure-parameter. However, when I add -DSEAMLESS_HBARS to the
> CPPFLAGS, it works. I don't know exactly why this is but there is no
> line saying "checking for *seamless* ..." or so, maybe you made a typo
> or what. I looked at the "configure"-script myself but can't figure
> out any mistake.

It was not in configure.in but in server/drivers/lcd_lib.c.
Now fixed in CVS.
Thanks for finding it.

> Another thing about the bars concerns their size. At the moment, one
> completely filled bar-block has 8x5 pixels, meaning it fills the block
> completely. This has two disadvantages:

Are you sure ?
If I am not mistaken the hbars in the CFontzPacket driver the CFA-635 are made 
so that they leave the bottom-most line empty. 
The code in the CFontzPacket_hbar() routine says:
  unsigned char hBar[p->cellheight];
  ...
  memset(hBar, 0xFF & ~((1 << (p->cellwidth - i)) - 1), sizeof(hBar)-1);
I.e. sizeof(hBar)-1 = 7
Thus the full block is filled 7 pixels high and 6 pixels wide.

I did it on purpose to make the hbars align with the square brackets '[', ']' 
surrounding them in some lcdproc screens

> - The bars at the top of each screen (where the title and the
> heartbeat is) "touch" the chars of the next line, so they can't be
> read as good as if there was some space between them.

Reducing the size of the hbars should be as easy as redefining the line
  memset(hBar, 0xFF & ~((1 << (p->cellwidth - i)) - 1), sizeof(hBar)-1);
in the CFontzPacket driver's hbar() routine to something like
  memset(hBar+1, 0xFF & ~((1 << (p->cellwidth - i)) - 1), sizeof(hBar)-3);
This should leave the 1st and last 2 lines empty
(I did not do it this way because of the alignment with the brackets)

The issue hier are not the hbars bar the icons that really are 8 pixels high.
Unfortunately I have not found a clean way to re-define them to beonly 7 bits 
high, since the ICON_BLOCK_FILLED serves two/three purposes:
a) the simple "block filled" icon
b) the filled block in vertical bars
c) the filled block in horizontal bars if --enable-seamless-hbars is not given

Since a) and b) may occur on the same screen together with the heartbeat icon
(see lcdproc's Load screen), we can only make the "block filled" icon 8 pixels 
high to have seamless vbars (which I consider a very important feature,
that I do not want to give up ;-)
But then we have to define all icons 8 pixels high to not have "jumpy" title 
lines (the "block filled" and the heartbeat icon appear next to each other)

That's why I did like it is now.
Of course I am open to new ideas, but they must work on all models the
CFontzPacket driver supports.

> - The first block of a bar shouldn't have the first column black,
> because they "touch" the char right left of the bar, and the last
> block touches the char directly right of the bar when the bar is set
> to 100% of it's length.

I guess this only affects displays that have no gaps between characters such 
as the CFA-63[135] series (i.e. those displays that are capable to make use 
of --enable-seamless-hbars).

Although I consider it a good idea, it is not possible without a major rewrite
not only in the driver but also in the network protocol, the server core 
(protocol parser) and the clients (using another hbar syntax).
Here's why:
- clients currently announce the hbar width in pixels derived from the values
  of (width in chars)  and (cell width in pixels)
- reducing the width of a hbar by 2 pixels in the driver (this is what you
  essentially suggest) would make all clients make false assumption on the
  full width of the hbar. This may not be impotant for long bars, but for 
  2-char hbars (e.g.) it makes a difference whether they are 12 pixels or
  10 pixels wide
BTW on screens with brackets surrounding the hbars this idea increases the
distance between the hbar and the brackets ;-)

Maybe this can be made an option (compile time or run time).


Technically it should be feasible as long as the user-defineable characters 
outnumber the cell width in pixel by two:
- cell-width user-defined characters for the hbar
- 1 for the heartbeat
- 1 for the "block filled" icon
So, with 8 user-defined characters the CFA-63[135] series driver can be 
adopted to that provided the hbar / vbar syntax is adapted accordingly.

What about a syntax alternative for hbars/vbars that looks like this
  hbar X Y %LEN FULL
where 
- X and Y are the position as they are now, 
- FULL is the full length of the hbar in characters !!!
- %LEN is a literal percent sign followed by a floating point number giving
   the actual percentage of the hbar that shall be filled

Example:
  hbar 1 1 %50.0 2
is a hbar starting at (1,1) that can be maximal 2 characters wide and that is 
currently only 50% filled

This syntax is compatible with the current syntax (i.e. the server can 
unambigously distinguish whether a client sent the command using the old 
syntax or the new one) and act accordingly. (Hint: the '%' is the 
discriminatory element ;-)

Taking this thought a bit further:
Maybe every widget should allow an option giving its size.
Then the widget can be restricted to that size only on the server core
and maybe the client can be made simpler.

..and still a bit further
Maybe the position and the size of a widget should be given when
adding the widget to a screen or a frame.
(How often to widget change positions in a screen/frame ?)

This makes setting the widgets a lot simpler.
IMHO adding happens very rarely while setting happens quite often.

How do other widget systems work (GTK, QT, ...) ?

Compare for example:
Currently:
  widget_add SID WID string
  widget_set SID WID X Y "text1"
  widget_set SID WID X Y "text2"
Idea:
  widget_add SID WID string -pos (X,Y) -size N
  widget set SID WID "text1"
  widget set SID WID "text2"

What do you think about it ?
Rodijn ? David ?


This syntax change is clearly not for 0.5.1 but for 0.6-devel.


> I don't know wether it's technically possible to change the size of
> the bars (are they defined in the display-charset?) but it would be
> nice if the misbehaviors described above could be changed.
>
> BTW: The CFA-635 runs perfectly together with an HD44780-display at
> the same machine.

Thanks for the feedback !

Peter
-- 
Peter Marschall
peter@adpm.de