LCD menu system

Crosswinds

Hello guys!

I thought that we could start a·discussion here about ideas around a menu system for a LCD.

Some of you may have seen my posts about my clock with temperature-measure, that i needed help with.

I got that working after great help from some guys!


Now i just thought it would be cool to have a simple "Setting" -menu for it.

Scroll from "time-set" to "lcd-backlight" or so, i think you know what i mean [noparse]:)[/noparse]

How would one design that?·

It brings up so many questions, and i think it would be a fun challenge [noparse]:)[/noparse]
·I iam currentlyusing a keyboard for settings, but the base could be same for different inputs!

Any ideas and inputs is greatly appriciated ! [noparse]:)[/noparse]

jazzed

What kind of an LCD will you use?

MagIO2

I assume we talk about a text-based menu, don't we? So, here I have an example.

Pins 16,17,18 are 3 pushbuttons. If you want to change the pins, have a look at ReadMenu function.



PS: A bit uncommented, but you can take it as a learning challenge. ;o)

Post Edited (MagIO2) : 10/16/2009 7:20:56 PM GMT

StefanL38

Do you think about something like

2x16, 2x20 or 4x20 characters ?

I can think of what you MIGHT mean. But there are a lot of different options
As you want to do it as a collaborative project it can have different sizes
starts low at just 3 or 4 fixed textes hardcoded for setting a clock
and can go up to a general system of 1-n submenus cascaded and/or nested
with fully parameterised textes, inputpositions, inputlengths, boundary-checking
moving a cursor forward/backward, delete with backspace etc. etc.

so what size should it have ?
the more comfortable it gets the more it would require a keyboard
So which input-devices shall be supported ?

best regards

Stefan

MagIO2

Oh ... That kind of LCD ... *grin* ... I had my little brilldea LCD in mind.




PS: But even with a dot-matrix LCD with 2x20 or 2x40 or whatever the concept of the MenuDemo would work.·Basically the printMenu and actual functions need to be updated and the box function is not needed.

Post Edited (MagIO2) : 10/16/2009 7:31:17 PM GMT

jazzed

MagIO2 said...
Oh ... That kind of LCD ... *grin* ... I had my little brilldea LCD in mind.

I was thinking of an LCD and existing code that could support a nice GUI

Adam Wiesler

One thing you could do, is create a kind of standard that uses XML to define where a button or a text label should be. For example,

<screen>
<name>Screen1</name>
<background_color>$SOMEVALUE</background_color>
<button>
<name>Button1</name>
<position>Xstart,ystart,Xend,Yend</position>
<type>Momentary</type>
</button>
</screen>

This way you could just have your prop reading that and drawing the screen accordingly. To control, you could use a mouse(draw a cursor), buttons(highlight the closest button), or use a touchscreen.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My website www.quigleyelectronics.com/

jazzed

Adam,

A lightweight Propeller XML parser and generic GUI Propeller code would most likely exceed the precious 32KB hub limit [noparse]:)[/noparse]

A reasonable alternative which I have investigated would use wxFormBuilder generated XML to create Propeller sized widgets.

The problem is having a strategy for creating all the widget code that anyone could follow. I have a minimal set with TextBox, ListBox, Label, CheckBox, etc ... for specific devices, but they need to be generalized. Also the current set of TV/VGA drivers that are capable of color/shading per pixel, etc... do not offer high enough resolution, so that puts a TV like GUI out of range.

Mike Green

Adam,
At the very least, you would need essentially a GUI compiler that would take in either something like XML or a special purpose GUI language and generate some very compact tables and select out the methods that might be needed from a library of methods. This would result in an object that could be included in your program. As jazzed mentioned, even a minimal XML parser would take up too much memory. Given that the Propeller Tool doesn't do elimination of unused methods (within a object), you really need something external to pick and choose the set of methods needed to implement what you want for a GUI.

jazzed

I guess I didn't make it clear that I started writing a GUI compiler in my "investigations" [noparse]:)[/noparse] I also wrote a GUI maker front end which is mostly functional, but decided using a tool like wxFormBuilder (which is cross-platform) might be easier for the user and the developer to a point.

TinyXML looks like a reasonable parser for adding to the "compiler" ... matching the names and applying the properties to code could be very easy using widget templates.

A video that demonstrates some of the widgets possible is available here: www.youtube.com/watch?v=YalcMqkdHEU

Here's a picture of my PropGuiMaker:

Crosswinds

Hi again guys!

Im currently using 2x16, but i have ordered an 4x20 (parallax) god knows when that will be delivered though

MagIO2 thank you for your post, that gave me some code-ideas, great!

Stefan; For now iam using keyboard, but i think the final project will be with, lets say 3buttons, and for my clockproject, the menu will be very simple, with some hardcoded options, but i thought that this thread could help other, more complex projects also [noparse]:)[/noparse]

FredBlais

jazzed said...

A video that demonstrates some of the widgets possible is available here: www.youtube.com/watch?v=YalcMqkdHEU

Hey, that's really great, looks like a must have for gui applications. I always try to do something similar with rect() and text with boundary check for the mouse for my menus, but the work is to be redone each time (and don't look great as yours)! A tool like that is priceless.

Will it be public?

jazzed

FredBlais said...

Hey, that's really great, looks like a must have for gui applications. I always try to do something similar with rect() and text with boundary check for the mouse for my menus, but the work is to be redone each time (and don't look great as yours)! A tool like that is priceless.

Will it be public?

@FredBlais, thanks for your kind words. The code for the LCD's GUI in that video is public.
http://forums.parallax.com/showthread.php?p=817386

That is a raster memory 65k color SPI LCD and not a Propeller only video solution.

Question is: Would a tool that delivers solutions only for such LCDs be useful?
Maybe so if the underlying driver were easily replaced ... it ain't Graphics.spin and never will be [noparse]:)[/noparse]

The PropGuiMaker application that could be used to simplify creating such GUIs has been lying
around in my computer unfinished and may be public some day in one or more incarnations.

One thing that stops me from going further with the PropGuiMaker is having a good Propeller
VGA/TV driver that makes similar quality Propeller video possible. I'm working on this [noparse]:)[/noparse] ...
but I have no idea whether a GUI like in the video can be done with one Propeller or even two.

The display in the video is the Nokia-Knockoff I2C LCD that has built-in memory. I do have the
Parallax OLED128 that I plan to use if possible. Other LCDs with on board memory could be
easily adapted. If there is sufficient interest in the LCD only, I could just work on the GUI maker.

I've been looking at Baggers latest video driver (and others) as an option for a Propeller only
video solution. I could really use a collaborator on a driver since most of the current drivers
I've found are not really suitable for this type of display. Having a front end driver for Baggers'
driver or some other for text and rectangles would go a long way to making a generic solution
possible. Of course the lack of Propeller memory could very likely again become an issue ....

I'll open another thread if I make any progress.