LCDproc development and user support list

Text archives Help


[Lcdproc] bounding box


Chronological Thread 
  • From: dglaudemailing AT gmx.net (David GLAUDE)
  • Subject: [Lcdproc] bounding box
  • Date: Fri Aug 1 22:12:01 2003


Rene Wagner wrote:
> 1. Icons:
> - single character
> - drivers have two options if the don't support a requested
> icon:
> a) replace it like they do now
> b) return an error code and have the server replace it,
> which allows the server to have the driver display
> a workaround/replacement with one or several other
> (single character) icons

I think the best solution is in between.
When a driver is requested an icon it can be:
A) known (we know the graphical representation of it)
B) unknown (this is a new icon this driver was not updated)
It can also be:
X) possible to display (because we have custom char)
Y) impossible to display (because we have not enough custom char)

So it look like this:
A+X: Ok let's do it
A+Y: We have two option:
1) The driver knows the character set available and know what other
character would best fit to replace. The driver does that.
2) The driver is lazy, does not know what character to replace and
return the problem to the server. The server can then choose what to put
there to replace that icon.
B+X: Since we currently want the graphical representation to be inside
the driver and not given by the server... the only option is to replace
by a character. Since the driver does not know what it is all about, it
is to the server to choose.
B+Y: Well, we are in the same problem as above. The server need to take
care and do something to replace that missing character on the LCD.

All in all we can have replacement of icon by best matching character
both in driver and in server. Lay driver can do nothing where good
driver do their best with what is available.

If we want this we need to return something to indicate if displaying
the icon was successfully or not. It can be "OK", "DID MY BEST", "DON'T
KNOW WHAT TO DO... DID NOTHING".

One that want control over the driver may want to be able to ask the
driver not to try to emulate with a character and always return an error
"DID NOTHING" when no custom char are available. I don't think we need
that granularity and since we can always overwrite the driver decision
by overwriting over the character chosen by the driver with one we choose.

> 2. Big numbers/characters
> - should not be removed (I like the K screen of lcdproc ;)
> - may be available in non-frame mode only (full screen)
I think this is what was done in the proposed code.
> - should not scroll if you ask me.
> The impression of a big number/character would probably
> be lost (especially for the emulated implementations
> like that of curses).
I don't know...
I sure want to generalise BigNum to BigAlpha and this is already coded
in one of the driver I took care of (I don't remember wich one however).
But for the scrolling I don't know. If it is only a rendering trick, why
not. If some peaple don't like it, just don't use it. ;-)

> 3. hbar/vbar
> - most widgets are defined by a starting and an end point.
> So, why not do that here?
> - you suggested a float based approach. I like that.
I don't like float.
Do we use float anywhere else?
Is it true that for embeded Linux some processor do not have float or
float emulation?
If we use no float anywhere else, why start here?

I think most important decision about bar is to make they grow in both
direction and start from any location (X,Y).

There is some space for "style" even if most driver will not implement that.

I would be nice to have half size hbar (put two hbar on top of each
other) but this break the no sub-caracter adressing devision.

> 4. bounding box
> - I still think it's not neccessary.
> - Please, present the reasons that make it neccessary.
See the other mail.

David GLAUDE

--
Don't let the computer/expert control the election
Information for Belgium in french: http://www.poureva.be/





Archive powered by MHonArc 2.6.18.

Top of page