Text-based User Interface library new release

[Kaouthia]

I haven't delved too deep into this yet, but looks pretty cool - should certainly save me a lot of time for something I'm working on at the mo.

Was just wondering if you, or anybody, had tested to see if it was working with the ShiftRegLCD library (this one) using 74HC164 shift reg.

[FalconFour]

Alright, I've been addicted to Arduino lately, partially as a result of this darn library... haha...

As an avid, gracious, and happy user, I just wanted to post a little list of the issues I'd been having with phi_prompt, mainly out of frustration that as a library I really can't do anything to fix them myself. But in an effort to help along, I'll post the changes I'd *like* to make to the code to make it work

• Menu up/down is reversed.
  um... wat? I know, it's weird. But it's true, as soon as I attached an "up" button to my setup (a little pushbutton on the breadboard), I found out that the menu direction is reversed... I sure don't remember editing this myself! It makes sense to increment a list item when you push "up", but when you're printing a list with item 0 on the first line, 1 on the next, 2, 3, etc., you'd increment to go up the list Just buttons being reversed, that's all. Lines 657-667 in phi_prompt.cpp, swap case 1 and case 2.


• Buttons can't be dynamically reassigned
  This became trouble when I had a program that had 4 buttons, needed a menu input and a number input, with heavy left/right and up/down use. I wanted to reassign L/R to U/D when entering a menu, as I would use the 4th button to exit (up/down -> select "load slot" -> up/down to choose number -> select to perform = 3 buttons). The program itself made use of left/right/select functionality (with "up" as a shortcut). I ended up having to assign the physically-placed left/right buttons as phi_prompt's up/down, and having the program read for up/down in place of L/R. Hackish. I originally tried writing different button pointers to btns[] and calling ini_phi_prompt() but it just crashed phi_prompt (basically). When I enter the selection that redefined the buttons, the whole thing ate itself, dancing through the menus on its own then corrupting the screen. Ick. Not sure how to handle this one, maybe provide a btn_switch() function that reassigns the pointers internally in a controlled manner? This would allow programmers to make better use of limited buttons as would be expected on most implementations, I'd imagine...


• ok_dialog and yn_dialog only take strings; menus and lists only take PROGMEM
  Kind of a big one. Either we're gonna go with RAM strings or we're going with ROM strings, but unpredictably shuffling them around is kinda... "boo". I had a bit of an undiscovered bug in my program where I did "yn_dialog(PSTR("Error! Retry?"));", and it kinda ate itself when I encountered it. On the other hand, if I need to create a list of items generated in the program, like filling a buffer with values and needing to pick one, I'm SOL, because it's hard-coded to read from PROGMEM. Eep. That should be relatively simple, just add a para->option that selects pgm_read_word or direct access... maybe "if option 1, read values into buffers, else use buffers" sort of thing at the beginning of the function. Looking over it, I think that might reduce complexity overall


• code is squished and sprawled a bit...
  OK, this is really just a tiny programmer's gripe, but just figured I'd mention it lightheartedly... just looking over the code while I'm writing this, and I'm getting a headache from the use of two-line "} ....... else ....... {" statements, then right below, a crunched up "lcd->setCursor(para->col+((i-_first_item)/rows)*(para->width+1), para->row+(i-_first_item)%rows)" statement. In an effort to make things as readable as possible (for my future use, at least), I try to collapse standard syntax and expand non-standard crunching. For example, repetitive commands like "lcd.write(' '); lcd.write('/'); lcd.write(' ');", I put on the same line since it's pretty easy to see what's being done. And I try to use single-line while/if/for statements whenever possible (if the conditional statement is one line, you don't need braces). So instead of "for (j=0;j<para->width;j++) ........... { ............. list_buffer[j]=' '; ............... }", I could just write "for (j=0;j<para->width;j++) list_buffer[j] = ' ';" and save 3 lines for visual flow's sake It just makes it a lot easier to follow, IMO... especially when trying to debug


• Huge functions like sprintf (over 500 bytes) and sscanf (over 1,000 bytes)
  This is kind of an annoyance more than anything, since the program still works fine. Problem is, if a function's even referenced once, it's included in the code sent to the Arduino. So even though we may only use it once in the whole thing, it still includes all 1000+ bytes of code for that function. I'd think there'd be a better way to strip out the integer and decimal parts of the number and recycle the functions used in input_integer. They're nice and all, but I dunno if I can tackle a huge project like mpguino with "only 32kb" of Flash (which now becomes "only" after seeing how big the battery hacker is!). =P


• Menu index list is left-aligned on right side of screen - can't think of a good way to fix this, so I'm not really too concerned... just gotta work around it (e.g. in long list with 10+ items).


• phi_prompt_struct is hyooge and confusing...
  I finally found that I can just "setupMenu = mainMenu;" to copy all its parameters into a new menu, which is nice, but I really do take second thoughts about creating a new phi_prompt_struct for a new program. I'm more of the function-parameters kinda guy... I'd rather send a function like "switch (select_list(listPtr, 0,0, 15,1, listIdx, listOptions)) {..." which would present a menu with listPtr's items at 0,0, stretch to 15,1, and have listIdx selected by default with listOptions applied to the menu. I'd do that with no second thoughts... I need to select something, just barf up a quick list (maybe of pointers) and throw select_list at it. I think input_integer is a prime example of this... I should just be able to "int myVar = input_integer(0,100, 7,1, 3, myVar, options)" to prompt for an integer between 0 and 100, located at 7,1 on the display, 3 digits long, with myVar as the initial value, using "options" as the options (like zero padding). Would make it a lot more appealing, I think
  

I think that's about it... hopefully this is more of a nodding-in-agreement sort of thing than a ugh-newbie-trying-to-tell-me-how-to-write-software kinda thing! Just throwing this out here since you'd said you wanted feedback from users

Thanks for all the hard work and hours of debugging... I'm in the same boat with my stuff too!

[liuzengqiang]

FalconFour,

Thank you! Lot to absorb so I don't attempt to simply reply right away. BTW, I've finished the documentation 33 page long:

http://liudr.wordpress.com/libraries/phi_prompt/

I used to do the switch (select_list(listPtr, 0,0, 15,1, listIdx, listOptions))  but I gave it up when writing the phi_prompt library. There are too many parameters and their orders matter unlike the structs with name identifying which parameter gets what value. It might fair better to newbies that may just be intimidated by the enormous list of parameters in the parentheses.

My other problem is whether to do:

result=get_number("Please input number", result);

or do:

get_number("Please input number", &result);

The first one needs no "&" so is newbie friendly but does waste 2 bytes on the stack and the second one is more elegant to more experienced programmers and makes less sense to beginners. I went for the second way but want to revert back with additional "simplified versions" of the more complex versions such as input_integer().