[Lcdproc] Improvements to imon driver: special characters and smoother hbar

[Ethan Dicks]

On 6/5/07, Joris Robijn <joris@robijn.net> wrote:
> On 5 Jun 2007 at 16:29, Ethan Dicks wrote:
>
> > being able to, at the driver level, have the code "know" what custom
> > glyphs are already in the device to avoid the overhead of custom
>
> Indeed, the driver should know this and place these chars. There's no
> limitation to do this now.

Agreed.

> > This brings to mind another feature I'd like to find a way to
> > implement, which is glyphs that are larger than one char cell...
>
> I'm in favor of this, also for "normal" icons. I consider client-defined
> graphs just a special case of icons.

I hadn't considered it in those terms, but I can see it.

> The client defines an icon and gives
> it a name and then this new icon is available to be placed everywhere,
> like a normal icon.

OK...

> But in the past my idea of multi-char icons was kind of "vetoed" :( Maybe
> it has a chance of a second life now :)

Hmm... I must not have either noticed your proposal or understood it.

> It is somewhat difficult to define exactly how to handle them. For graph
> LCD's there is no problem, they can do an infinite amount of custom
> chars.

Right.

> But what to do with normal LCD's... Currently only the cellsize is
> told to the client, we could add the number of programmable custom
> chars...

I don't see that as a problematic thing to add to the protocol.  I
wouldn't mind if it were a special transaction, since most clients
won't case, and it only has to be asked once.

> I am afraid the client will simply need to assume a multi-char
> icon will take multiple custom-char.

Fair enough.  Conversely, it needs to be included that a client has to
handle not being able to do what it's asking if the display isn't
capable of satisfying the request.

> I think we should not make the
> interface more complex than this. More complexity = more problems.

I entirely agree.  It should be as simple as possible.

-ethan