LCDproc development and user support list

Text archives Help

[Lcdproc] bounding box

Chronological Thread 
  • From: dglaudemailing AT (David GLAUDE)
  • Subject: [Lcdproc] bounding box
  • Date: Wed Jul 30 19:50:01 2003

Michael Frame wrote:
> render functions could do the most of the filtering
> (the actual one doesn't really care about the correct
> widget position in a screen or frame !).
> In normal main screen the "widget-cutting" is no problem
> for renderer (except bignums).

Bignum was introduced without prior thinking about the frame issue.
At that time, frame where not working so we have excuses.
The only known usage of BigNum is for BigClock.
One solution to your problem could be to say:
"BigNum can not be used simultaneously as frame."

> But does nobody want to use frame widgets ???
> We have enough information for renderer !
> But why should the render code care about the margins of a screen ?

Well, because you are not suppose to ask the driver to write outside of
the screen.
I really think the bounding box can be done internally.

> That should be really a problem of the driver ! (IMHO)

The screen/driver can protect itself from badly written rendering code
that ask it to write outside the physical boundary. But the driver does
not have to know about logical boundary. If it was not about 20 drivers
to modify, maybe the easiest solution could be used.

If you want to simplify your rendering code, you can create "generic"
function that hide/embedded the function from the driver. In your code
use only those function. It is however likely that you will have to
reinvent the frame buffer in that "generic" layer.

> Nobody wants an unclear render code. I think
> driver side solution would be the nicest/best solution !
> I have already made a solution for non-driver-integrated bounding box
> (except bignums).
> in this variant the render.c has to do all the widget-cutting ! Too much
> code for nothing !

Maybe you can send both version of render.c on the mailing-list so that
we can have a look at the complexity.

No, having it in render.c make it easier for anybody to write driver. We
have already too much complexity, cut&paste, no proper checking in the
driver code. Making it more complex is not a good thing.

> the handling of multiple char icons should really be changed !
> (or removed ;)
> perhaps the client should put single chars together to one big char !

The multiple char icons is Joris idea. I think it was introduced without
too much prior discussion on the side effect.

We can choose to:
* Remove it (but keep the graphics and explain how to use them so that
client that want them can deal with the complexity)
* Make it available to user but split in multiple one icon call in render.c

> (the only thing you can do with bignums is a clock... so much work for one
> screen ?)

I would like to say... forget about BigNum... or forget about
interaction between BigNum and Frame.

> That sounds plausibly... if frame support doesn't work ...
> you can't use it !
> But i think it's a nice feature of lcdproc ... and should work.

We put all our hope on your shoulder. ;-)


Don't let the computer/expert control the election
Information for Belgium in french:

Archive powered by MHonArc 2.6.18.

Top of page