LCDproc development and user support list

Text archives Help


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


Chronological Thread 
  • From: joris AT robijn.net (Joris Robijn)
  • Subject: [Lcdproc] API related (was once the } issue).
  • Date: Mon Dec 3 18:51:01 2001

> Then I send (1, 1, 10, "Hello, World. Welcome to what is left of it!!!").

Oh yes of course it is the visible length.

> > You can do it in flush. Screen should be flushed every tick...
>
> Guarantee?

Ehm... well uhm... no ?

> Isn't it two different concept?
> Otherwise I agree we can do it there.

Yeah maybe it is different. Well anyway, I think we can do this later
anyway, because it is an addition, no change.

> > > What help do you need?
> >
> > Oh that's great. I've now completed the transition of the API and the
> > curses and text drivers (without hbar/vbar, also wid and hgt still
> > exist). I will now start with wid/hgt and other drivers. But for the
> > hbar/vbar a lot needs to be done. Everything needs to be converted
> > from the pixel based stuff that is used in the widget language.
> Yep, not easy but.
> If the API for the new kind of bar is define (at least in the doc)
> then we can start "coding" the driver.
> It does not mean those function will be used yet. ;-).
> I will give it a try in MtxOrb:
> Write the function as I expect it and make the conversion layer inside my
> driver.
>
> Typicaly the driver part of the quantum leap change should be
> distributed accross multiple peaple.

Ah that's where the "warping" came from !
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.

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.

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);

> > Also new features may be supported for the bars.
> Like? style, reverse increase, arbitrary start/stop position???

Yeah they're all in the above.

> Well currently all the change we have done are in the back office of LCDd.
> But one day or another we will have to change the client/server API.
> Driver better have to be ready when we make that change!!!
>
> So I think we should define the "ideal" wanna have API. (how do I read you
> SGML stuff?)

?
Plain text rules. There is a (partial) description in the docs/API-
v0.5.txt document.

> Then shake every driver writer to tell them about the change we need.
>
> When we reach a critical mass of ready to be "migrated" driver,
> then we can try the Widget Language change (and server change to call the
> new API).
> At that time API and driver should be "freeze" at the maximum.
> This reduce the size of the window of time where think could break.
> Before making that last step we should release a "STABLE" version
> for peaple to play with and complain about bug.
> That way nobody not interested in development will get if from CVS
> since the stable is stable.

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

> > Can you have a look at it ? Should I send you my current (BIG) diff ?
> Yes you can send me the diff.

K I'll send it you off-list. But I want to finish some things of a
bit first, so it will take some time.

But what parts exactly do you want to work on ? MtxOrb adaptation to
new API ? Or vbar/hbar on multiple drivers ? And Mythos ?

Joris

--
Joris Robijn
<joris AT robijn.net>
Home: 053 4311 553
Mobile: 06 288 41 964

// To understand recursion, we must first understand recursion




Archive powered by MHonArc 2.6.18.

Top of page