LCDproc development and user support list

Text archives Help

[Fwd: Re: [Lcdproc] bounding box]

Chronological Thread 
  • From: dglaudemailing AT (David GLAUDE)
  • Subject: [Fwd: Re: [Lcdproc] bounding box]
  • Date: Thu Jul 31 15:37:01 2003


I have 100 things to finish before leaving for vacation, so I will more likely not be able to handle this.

I think the list support attachment without problem, however some big one never succeeded. The is is achieved, this mean a patch send here is never lost. ;-)

I think yes it can or should be send to the mailing list so that if some want to discuss the detail it is possible.

Actually a recursive diff which show change to other file can help reproduce and test with other display.

You can test with other "display" like TEXT or curses. I think it is easy to use the curses driver to have a BIG lcd and there frame are easy to use, test and demonstrate. Also it can be tested by many (as opposed to hardware based test on small display.

I would suggest you write a demo client that use frame, overlapping frame, frame into frame and test multiple widget scenario like hbar, vbar, text, icon, ...

I guess you needed something like that to test your code, we might want it for testing it too or to do regression testing if we ever change something to the code.

Don't forget the copyright statement, the changelog, ...

I like the recursive trick. Indeed with such a big function with many vars and big structure... it is frightening to do recursivity there...

I think if frame do work, it would be easy for someone with a 4*20 LCD to test what it display into a 2*16 one. It can help client to be more aware of typical LCD size.

It seems to be clean but I did not try nor compare to what we had. ;-)
The BigNum solution will not break the BigClock (I guess) and no one will complain that BigNum do not work in frame (but it should be documented somewhere).


-------- Original Message --------
Subject: Re: [Lcdproc] bounding box
Date: Thu, 31 Jul 2003 12:34:50 +0200
From: Michael Frase
<Michael.Frase AT>
To: David GLAUDE
<dglaudemailing AT>
References: <3F27085D.27433.2039566@localhost> <002201c35681$aebf7a20$6500a8c0@cruncher> <3F28212E.6050706 AT>

Hi David...

> 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.

I'm sending this to you (and not to mailinglist) because i'm not really sure
whether i should make a diff or just mailing the code !
(btw: is it possible to append files in mailing list ?)

I appended my new render.c ! you can post it to mailing list in that way
you want to !
I've tested this with my hd44780 (i have no other display !).
This render.c will only work with some changes in other files:
* frame in frame support needs a pointer to associated frame widget
** added that pointer to screen struct (NULL for main screen)
* frame in frame support needs the absolute position of a frame in main
** added int left, top to screen struct
* frame handling itself (adding, removing etc)
** changes in commands/widget_commands.c
** changes in screen.c
** changes in widget.c

I made the screen struct changes because i wanted a small function header !
If nobody wants struct changes i can rewrite this part
and add these info to function header ! (this will also need extra vars for
actual info before recursion !)
If you want i can send you the other changed files (like
commands/widget_commands.c ...)

I'm open for improvements !

feature Info (new render.c):
* normal screen rendering
* frame in normal screen rendering
* frame in frame rendering !
* widget speeds indicate frames per movement
(speed of 3 will show 3 times the same screen before moving on !)
* bignums are only drawn in normal screen
* full support for all other widgets in normal screen and frame
* scroller widget changed a little bit (horizontal scrolling improved !)
* all widgets are drawn relative to screen/frame !
** widget (x=1, y=1) in frame(left=5, top=2) will be drawn at 5, 2
* ...and more little changes... i can't remember ;)

greets Michael Frase (my last name is not "Frame"... nobody is perfect ;)

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

Attachment: render.c
Description: Binary data

  • [Fwd: Re: [Lcdproc] bounding box], David GLAUDE, 07/31/2003

Archive powered by MHonArc 2.6.18.

Top of page