LCDproc development and user support list

Text archives Help

[Lcdproc] API related (was once the } issue).

Chronological Thread 
  • From: David GLAUDE Mailing" <dglaudemailing AT (David GLAUDE Mailing)
  • Subject: [Lcdproc] API related (was once the } issue).
  • Date: Tue Dec 4 10:29:01 2001

> Well, it involves no real changes to the drivers, except for the H/V
> bars. For the rest it is an extra parameter in the calls and changes
> in the way driver->wid is used.
And if a driver is not modified for multiple instance,
it will just continue to work if we change the function definition.

> I just got an other idea. If we make two calls, one original and one
> new one. They are both called, and driver writes (or others) should
> move towards the new API. Then after some time, the old one is
> removed.
Yes (but the server code get's more complicate as long as both exist).
It need to be "explain" and "announce" clearly on the list what is
require or going to be require from driver author to addapt to the new API.

> For the new bars that would be:
> void (*vbar) (drvthis, int x, int y, int len, int
> promille, int pattern);
> void (*hbar) (drvthis, int x, int y, int len, int
> promille, int pattern);

Agreed, now we need to define a few value for pattern.
Also if a requested style is not available, we should define the default
expected from the driver (let say BLACK WITH BORDER = fully black no white

> yes sounds ok. I will rename the h/vbars to old_vbar and old_hbar
> then, to encourage to use the new ones.
Sound good to.

> But what parts exactly do you want to work on ?

> MtxOrb adaptation to new API ?
Yes of course I can do that.

> Or vbar/hbar on multiple drivers ?
I can try a thin layer in between to provide compatible interface.
I also hope to be able to move my custom char work to something
reusable by other driver.

> And Mythos ?

And reading from config file in MtxOrb.
And reporting with report.h in MtxOrb.
And software bignum.


Archive powered by MHonArc 2.6.18.

Top of page