LCDproc development and user support list

Text archives Help


[Lcdproc] Using 0.5 Menus with CFontz633


Chronological Thread 
  • From: David GLAUDE Mailing" <dglaudemailing AT gmx.net (David GLAUDE Mailing)
  • Subject: [Lcdproc] Using 0.5 Menus with CFontz633
  • Date: Tue Sep 24 15:49:02 2002

> > Well, I took all of your advice, and have built my IP configuration
> > tool using the v0.5 menu system.
> >
> > This works pretty well, but I think the use of keys could be better
> > within a few of the menu widgets.
>
> Ah good to hear this positive reaction.

This make me happy too, it mean the driver does work for you in 0.5 too.

> > In particular, it would be nice if left and right moved the cursor in
> > an alpha and numeric screens, and the "enter" key (a green check)
> > would save the result.
>
> > Similarly it seems more intuitive for left and right to move through a
> > ring, and have enter save the result.
>
> Yes. I understand that would be more intuitive if you HAVE these
> keys. I would like it too, but things do also need to work if
> you have only 4 keys.

Joris, I don't know if you saw a CF633 in picture... we have (ASCII art):
^
<= V =>
X v

Or UP, LEFT, OK/ENTER, RIGHT, KO/ESC, DOWN.

I don't feel like you should modify menu navigation just for us...
But I feel like the menu use too many/few keys simultaniously.
When you don't want the menu, you want most key for your client...
When you use the menu, you want it to be more user friendly...
If you use the 0.5 menu in client, you want more keys too.

I think we found a solution to have keys associated with menu,
only when the menu is active and a key to bring the menu.

> I can add something that allows both of these modes to work, so
> that the behaviour of Enter depends on the used mode. Should be
> possible.

Should it be global for LCDd to use "extended menu navigation",
or should it be per driver?
I guess somewhere in the driver we should tell we are "extended menu
navigation"
capable. Then in the config file we should ask for it.
Or does it have to be the client sending a message like:
"If available in the hardware I would like to use extendend menu
navigation."

If by mistake we ask for it and we don't have the keys...
then navigation become difficult/impossible.

Also Joris, don't forget to tell me/us what new 0.5 "keyword" to use for
those key.

> > I'm willing to try my hand at patching these in, but I'm not much of a
> > C programmer, so the results might be a bit more pleasant if one of
> > the core developers were to make this change.
>
> :) np.

If you give it a try, don't hesitate to send your change (those to CF633 at
least)
to me and I can check them and check them in the CVS tree too.
If you could just distinguish in text wich change are for everybody benefit
(like better support for 0.5 feature in the driver) and wich are for you own
comfort (like removing the menu that are not your own).

> > Also, for my application I'd really like to disable the menus that are
> > not my own. Is there any harm in simply commenting these lines out of
> > menuscreens.c?
>
> On itself not. But I don't know what will happen.

Hum, we have configuration option for many thing...
but don't we have/shouldn't we have one to disable the build-in menu?

David GLAUDE





Archive powered by MHonArc 2.6.18.

Top of page