LCDproc development and user support list

Text archives Help


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


Chronological Thread 
  • From: ethan.dicks AT gmail.com (Ethan Dicks)
  • Subject: [Lcdproc] Improvements to imon driver: special characters and smoother hbar
  • Date: Wed Jun 6 01:38:01 2007

On 6/5/07, Joris Robijn
<joris AT 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




Archive powered by MHonArc 2.6.18.

Top of page