LCDproc development and user support list

Text archives Help


[Lcdproc] bounding box


Chronological Thread 
  • From: reenoo AT gmx.de (Rene Wagner)
  • Subject: [Lcdproc] bounding box
  • Date: Wed Jul 30 19:43:01 2003

On Wed, 2003-07-30 at 12:02, Michael Frase wrote:
> >I think I aggree with Rene:
> >* we have enough information in redering space to do it server side
> >
> >(that was one of the question I asked)
> >>Is there any reason why this thing can not be done in central server
> >>code? If it is only a filtering, then what is the problem.
>
> render functions could do the most of the filtering

All of this must be implemented on the rendering level.
No further discussion on that with me.

> (the actual one doesn't really care about the correct
> widget position in a screen or frame !).

Nobody said the current code was in any respect perfect.

> In normal main screen the "widget-cutting" is no problem
> for renderer (except bignums).
> But does nobody want to use frame widgets ???

Frames are indeed a nice feature and I appreciate all work done
on this topic, but you can't change the driver API every time
you feel like it was merely simpler to do it that way.

> We have enough information for renderer !

Sorry, I don't get the meaning of that sentence.

> But why should the render code care about the margins of a screen ?

The file is called server/render.c, right?
It does the rendering. Rendering as in transforming client instructions
into simple instructions for the driver.

_SIMPLE_ instructions.

Thus it has to take care of the real functionality.

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

No.

> Nobody wants an unclear render code. I think
> driver side solution would be the nicest/best solution !

It may be simple to implement for now.
But it's wrong.

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

I can't comment on code I have never seen before.
Also, I'm not willing to discuss a non-issue any longer.

The rendering - _all_ rendering - has to be done in server/render.c.

If you need more information from the driver it will certainly be
neccessary to add more functions to the driver API that return
information on whatever you need.

Still the server->driver functions are sufficient to perform the task.

>
> >>Other option, if that filtering is possible to do without knowledge of
> >>the driver internal, then a generic solution can be found for all
> >>driver.
> >
> >* doing this in driver mean duplication of the code, coding in the dark(TM)
> >
> >So let's go back to the reason for doing this:
> >* multiple char icon:
> >** it could be multiple single char icon from driver point of view and
> >the rendering code put each piece of the big icon at the right place.
> >** actually that feature is only available in a few driver
>
> the handling of multiple char icons should really be changed !
> (or removed ;)

Agreed.

> perhaps the client should put single chars together to one big char !

I'm not sure on this one...
The client->server communication mostly is a one way thing ATM.
It would probably be cleaner to have the server return some error code
if a special icon is not supported by the driver currently in use.
Then it's over to the client to decide what to do instead.

With icons we can change the behaviour of the server in terms of
the client protocol, because - IIRC - it's not supported ATM.

Big characters (numbers ATM) form a different topic.
They are useful if you ask me and there are clients that use them.
Thus we have to solve this on the rendering level.

Regards,

Rene





Archive powered by MHonArc 2.6.18.

Top of page