LCDproc development and user support list

Text archives Help

[Lcdproc] bounding box

Chronological Thread 
  • From: joris AT (Joris Robijn)
  • Subject: [Lcdproc] bounding box
  • Date: Sun Aug 3 16:15:02 2003

I've swapped the order of things...

> Handling a scroller that is too wide has to be done in a different way
> than handling a string. In the rendering code you have the chance to do
> so. You simply can't do that in the driver.

I don't agree on that. The driver can cut any object in the same way.
That's why I like it, there is no knowlegde needed of the object being
drawn. It can in most cases be done in the _char function. (and in the
string function because that is an optimization for the char function).

> > In your code, all the test, computation are done in that same
> > render_frame. This mean we have solution 1. It is however a complex
> > function with potential for bug.
> But it's one function. A single piece of code, not code that has been
> copied and modified in 15+ drivers.

Same code in every driver is no argument because you can put the code in
an include file.

On 2 Aug 2003 at 0:32, Rene Wagner wrote:

> On Fri, 2003-08-01 at 23:50, David GLAUDE wrote:
> > Michael Frase wrote:
> >
> > >>4. bounding box
> > >>- I still think it's not neccessary.
> > >>- Please, present the reasons that make it neccessary.
> >
> > > If you want frame support you will use a kind of a bounding box !
> > > If a widget moves out of a frame has to be cutted of.
> > > the "cut-positions" are a bounding box. (if you looked at my new
> > > render.c
> > > you can find the places where widgets are cutted off !)
> >
> > I think we all aggree on that. ;-)
> Certainly :)

Acknowlegded. This is the core of the question if you ask me.

My alternative was:
- We can accept any (future) API functions to draw objects bigger than
one char that can not be cut by the rendering code. That requires an
extra API function.

Rene's alternative was:
- We can only have API functions that draw objects cuttable by the
rendering code.

I think we're close to a conclusion.

I have no problem with "Rene's alternative" if we agree on the
consequences, like bignum/char cannot be in frame because it can never be
cut by the rendering code, bars will need new API call and bars need care
in the future if we want fancy options for the bars (like a slider-bar),
and the limits on future objects to be drawn.

Aren't there some more people that have an opinion on this ?

> And actually I don't get it why we should mess with the design
> of LCDd for the sake of other projects.

Nah, that's right. LCDproc does not have a symbiotic band with an other

Rene, can you tell us what the last problems with 0.4.4 are ? Is there
anything anyone else can do to help with the last work on 0.4.4 ?


Joris Robijn
<joris AT>
Mobile: 06 288 41 964

// To understand recursion, we must first understand

Archive powered by MHonArc 2.6.18.

Top of page